MS3 pre-1.1 beta 19 released

[jsmcortina]

We are pleased to announce MS3 pre1.1 beta 19. As we start the approach to "release" we have marked this code as beta.

Changes since alpha 18
Idle:
-Make dashpot apply if the valve even starts to close.
-Remove the RPM window setting and filter for it, they should not be necessary if the main RPM is filtered adequately.
-Make Idle voltage compensation apply at crank
-Make new dashpot feature require larger numbers in the settings.
-Allow the Idle RPM timing assistance to be enabled independently of CL idle

Wheel decoders:
-Allow +/-1 tooth tolerance during SR20 sync
-PT4 as timer reports correct 'usage'
-Adjust SR20 angles by -78.0 degrees
-Add Viper V10 wheel decoder (untested)
-Enable Mazda6 2.3 VVT decoder (untested)
-32-2 wheel and oddfire should calculate triggers correctly

VVT:
-Cam inputs check if inputs are valid in VVT mode.
-Don't restrict most VVT modes to 1 cam.
-Un-break PT6 as VVT cam input.
-Set 50/50/50 as VVT PID defaults.

Knock:
-Knock indicator shows when over threshold.
-Knock CLT scaling.
-Add dedicated outpc variables and gauges for knock per cyl.
-Add peak detect/decay on user visible knock variables
-Knock SPI - check last byte is sent.
-Zero out knock_cyl data on stall

Other:
-Add 8 pt TPS oversample buffer. (experi)

Fixes:
-Ensure that ~100% duty injection is handled gracefully.
-Fix DC1 in ini
-Narrowband EGO gauge ini fix
-Missed out a /1000 in new accel
-3 step. Validate input ; fix 'on' indicator.
-MS3 loader windows (version) handles MS3 in bootload mode. (Teg's reported issue still to-do.)

Internal:
-Auto-convert #defines to .equ for ASM code.
-Add new function to allow more wheel decoders.

For the "internal" knock, the per-cylinder gauges that were in sensors9+ are now in dedicated gauges.

The firmware zip can be downloaded at: http://www.msextra.com/doc/ms3/files/be ... beta19.zip

James

[y8s]

James,

Knock:
I'm not seeing the new raw knock variables and zero data in sensor9-whatever.
do they not show up unless I'm set to per cylinder knock?
Is the "peak decay" implemented on the knockin logged variable?


New AE:
I'm not seeing the lift-throttle spike to 33ms in my first test log so that's good.
Curious if "TPS accel" and "MAP accel" are displaying the actual added percentage. i.e. if TPS accel is "4.1" am I injecting 4.1% more fuel there due to tpsdot AE?

edit: AE values are still configured incorrectly in the ini to show in the curve as XX.X and in the table as XX (ie no tenths decimal).

[jsmcortina]

James,

Knock:
I'm not seeing the new raw knock variables and zero data in sensor9-whatever.
do they not show up unless I'm set to per cylinder knock?
Is the "peak decay" implemented on the knockin logged variable?

That's because they are _new_ knock variables.
I mentioned it here:http://www.msextra.com/forums/viewtopic ... 31#p314367
So replace your "sensor09" gauge with "knock cyl#1" etc.

The peak/decay is implemented on the master knock value and the per-cylinder. Here's a simplified code fragment.

Code: Select all

                a = outpc.knock_cyl[cyl];
                b = knockin;
                if (a > b) {
                    //b = 87.5% a + 12.5% b
                    a = (a * 7) / 8;
                    b = a + (b / 8);
                }
                outpc.knock_cyl[cyl] = b;

So if the old value is greater than the new, then the old decays down to the new. If the old value is less then the new value is used unchanged.

James

[y8s]

That's because they are _new_ knock variables.
I mentioned it here:http://www.msextra.com/forums/viewtopic ... 31#p314367
So replace your "sensor09" gauge with "knock cyl#1" etc.

I think you misunderstood my question. I'm not talking about the TS gauge, I'm talking about in datalogs.

Did you remove the ability to log individual cylinders when not using per-cylinder knock? I was enjoying the use of sensor9-12 to display individual cylinder knock in logs but only using global knock control.

[jsmcortina]

Ah ok. Yes I did remove that because I didn't think it was actually reporting the correct cylinder number in that condition. I was initially uncertainly, but read the code a few times and concluded that it wasn't going to work unless "per cylinder" was enabled. Maybe Ken can peer review my work at some point.

James

[y8s]

Turning on "per cylinder" will show them all, correct?

I am guessing there is not a way (in this release) to see all cylinders AND set up knock control to act globally instead of per cylinder? It currently will retard the knocking cylinder only?

[jsmcortina]

The retard is global. There isn't presently a method of retarding just the one. (Not through knock control, spark trim does operate per cylinder of course.)

James

[braineack]

Of course I get my car out of storage and spend the day on it, upgrading to alpha18 from alpha11 to only come home and discover beta19 was just released

[UnaClocker]

Didn't see the Chrysler 2.2/2.5 decoder mentioned, so I assume it hasn't made it's way up the to-do list yet. I'll load this version up and give it a whirl anyways. Thanks for the continued improvements.

[y8s]

Got a chance to try the /1000 update to the New Accel Enrichment last night.

It reduces the enrichment so much that even maxing it out at "500.0" I can't eliminate a significant lean... something. I can't call it a spike because it's too wide.

I would post a log but spinning the values up to ~500 or so crashed TS and I forgot to restart my log for the drive home.

It APPEARS that the PW is lagging too far behind the change in throttle position. I think that is due to it being pretty much all EAE (the EAE and PW increases overlap). Even where "tps accel" is 30 or 50, the PW is still tiny.

I have not yet had a chance to try New AE without EAE enabled.

[Matt Cramer]

Didn't see the Chrysler 2.2/2.5 decoder mentioned, so I assume it hasn't made it's way up the to-do list yet. I'll load this version up and give it a whirl anyways. Thanks for the continued improvements.

Chrysler 2.2 / 2.5 decoding has been there since the first release - did it need any updates?

[UnaClocker]

Didn't see the Chrysler 2.2/2.5 decoder mentioned, so I assume it hasn't made it's way up the to-do list yet. I'll load this version up and give it a whirl anyways. Thanks for the continued improvements.

Chrysler 2.2 / 2.5 decoding has been there since the first release - did it need any updates?

When using it with wasted spark and fully sequential fuel, it seems to be misfiring. He was going to go back and confirm that he had gotten the sensor angles right when he wrote the code. I did a composite log in the Log Crank & Cam mode to aid in that process.
Oh, and the phasing is backwards, so the coils in wasted spark have to be reversed, and the injectors in sequential need to be shifted down by 2.
We had discussed it in this thread.

[muythaibxr]

Got a chance to try the /1000 update to the New Accel Enrichment last night.

It reduces the enrichment so much that even maxing it out at "500.0" I can't eliminate a significant lean... something. I can't call it a spike because it's too wide.

I would post a log but spinning the values up to ~500 or so crashed TS and I forgot to restart my log for the drive home.

It APPEARS that the PW is lagging too far behind the change in throttle position. I think that is due to it being pretty much all EAE (the EAE and PW increases overlap). Even where "tps accel" is 30 or 50, the PW is still tiny.

I have not yet had a chance to try New AE without EAE enabled.

Alright, I'll have a look at making that more sensitive.

Ken

[y8s]

while I was testing the new AE I had a thought... AE is proportional to pulsewidth, right? But starting off from idle PW is very small. When you jab the throttle, the initial proportional amount of fuel added is a percent of "small" and thus you get very little enrichment.

Typically a "throttle pump" is intended to provide instant fueling to compensate for the lag in fuel delivery behind air delivery (light + fast air vs. heavy + slow fuel) as well as changing atmospheric conditions that can lead to condensation of the fuel vapor on walls and reduce the effective fueling.. That's why lower tps%/second movements need less AE typically. Since you're not going from closed to open throttle as fast, the air speed doesn't increase as abruptly compared to the fuel delivery.

It would seem then that the amount of the throttle pump should be proportional to the expected load value fuel and not exclusively the rate of change of the TPS. I do tend to use a blend of MAP and TPS enrichment since MAP based enrichment helps meet the demands of high MAPdots on fueling.

I'm mostly rambling here but am curious to see if a higher AE gain and use of map-based AE is more accurate.

[elaw]

I don't think it's proportional to the current pulsewidth, it's proportional to req_fuel which is a constant. So I was actually thinking kind of the opposite: the amount of fuel AE injects is much larger in proportion to the current pulsewidth at low flows than at high flows, so maybe it's too much at low flows and not enough at high flows? Of course opposing that is the general tendency of engines to require more AE at low flows than at high so maybe it all balances out?

[elaw]

Just out of curiosity, can someone explain what the /1000 issue in the new accel is (was)?

I was using it before and it seemed to work well, and it seems about the same in 19 although honestly I haven't looked at any logs yet, I'm just going by driving impressions.

[bubba2533]

I would like to know how the new and old AE is calculated, but I'm not a programer so it would be nice if someone could dumb it down to your basic math functions.

I think having a better understanding of how it works will help me tune it.

[y8s]

I checked with Ken. It is based on Req_fuel and not pulsewidth. That makes sense.

the /1000 thing was simply a missed piece of code (as I understand it) where a "divide by 1000" was left out. It may have been what was causing my pulsewidth with alpha 18 to spike to 33+ms at throttle LIFT... but it feels (I don't know for sure) like I'm running an insignificant amount of AE now. I still need to test without EAE on to satisfy the scientific method (and Ken).

Anyway with the alpha 18 AE, I was using numbers like "2" at the low end and "9" at the high end of tpsdot range. Now I've got most set to several hundred up to 500 and get a big spike of lean AFR still.

[gross polluter]

Since upgrading to beta 19 I've had a problem with datalogging through TS. Seems to be related to CAN devices. I'm currently running a GPIO on Mshift. Prior to beta 19 I was able to datalog both MS3 and GPIO just fine. Since changing to beta 19 if I try to open a datalog in MLV I get an error saying "log file contains no data." Each of the log files produced are only 2kb regardless of the duration of the log so I'd imagine TS just isn't logging anything.

SD logging works normal. I can log through the SD card and view the logs on my computer just fine. If I create a project in TS that doesn't include the GPIO board, so it's just logging the MS3, it logs fine. This is what leads me to believe the issue is CAN device related. TS doesn't seem to log when the project is configured with CAN devices. If I log in TS without the CAN devices configured then it logs just fine.

MSQ and dead log included.

[taylorhoff]

Would this beta release affect no spark due to large tooth#1 angles on low tooth trigger wheels (12-1) if upgrading from the current stable release?