[FW MOD] ms2extra 3.3.0b gslender v2.4.4

[gslender]

G'day...

This modified firmware is based on the alpha release MS2/Extra 3.3.0b firmware and adds some further enhancements/fixes - notably the addition of a "TPS Averaging" oversampler similar to the MS3 MAP averaging sample method, and "Adaptive PID" that reduces PID values as idle rpm target is reached.

Changes made from alpha release MS2/Extra 3.3.0b are as follows:

* added TPS averaging oversampler (better noise smoother than LF and Median)
* added separated LF for batt and clt/mat (allows batt to run at 75+ LF for idle voltage comp)
* fixed Adaptive Idle Volt Compensation to use a better baseline response window (try window > 10)
* added optional tpsDOT Smoothing (moving anchor idea from Rob's Noisy tpsDOT post)
* added adaptive pid (allows for very quiet PID based idle duty and yet have aggressive PID values for when load appears)
* added back the original RPM based median sliding window (due to popular requests)
* minor memory re-jiggling, housekeeping and clean-up
* fixed map avg sampling to work/sample before engine running
* fixed window smoothing oversized bug

Firmware >>

ms2extra_alpha_330b_gslender_v2.4.4.zip

(225.22 KiB) Downloaded 263 times

Docs >>

gslender.mod.application_notes.pdf

(416.23 KiB) Downloaded 244 times

Source >>

ms2extra_alpha_330b_gslender_v2.4.4_source.zip

(428.22 KiB) Downloaded 80 times

Enjoy
G

[Greg G]

This is what my MAP, MAPDOT, Tps, and tpsDOT look like with the oversampling turned on, lag factors at 100%! Tested a prerelease version without the extra tpsDOT smoothing- as smooth as it may look now, it will get even smoother!



Adaptive PID reduction allows us to define a zone above and below target, within which a reduction factor is applies to the values of P, I, and D. This factor is set in a 2x5 curve. This allows the user to set aggressive PID values for a strong response far from target, but ramp it down as target is approached. Works very well in combination with AIA. The working theory is that when near target RPM, the idle valve response is too coarse and too slow, and tends to cause small oscillations. So it's better kept relatively quiet, letting Adaptive Idle Advance do the fine tuning.

For those clamoring for an absolute dead zone, you can do just that!

Another nice feature is you can set it up to have an asymmetric response, more aggressive below target.

This log shows the effect of running 0 reduction factor- valve is much quieter than without. Sorry, the small movements are from my voltage correction, it should be even flatter. I am also running a rather small window size, maybe it should be larger fore more transition/ramp.



Status 5 indicates the value of P (so we can log Adaptive PID Reduction)- for the 50%, you see that the value of P (40) is reduced to 20 (at the bottom of the V). For the reduction factor of zero, we actually end up with a P value of zero at target! The width of the V and the clustering of the dots at the valley show how closely the RPMs stick to target. The red line up top shows no PID reduction applied.



Another small but nice improvement is the separation of the battery v from the temperature sensor filters (MAT & CLT). This lets me use heavier smoothing on CLT and MAT, and less on the battery voltage (for less lag and marginally faster --every bit helps-- voltage correction response.)

[techsalvager]

Is the maf correction table alteration included with this one?

[pigga]

Hi Greg,
thanks for the work that you are putting into this!
I tried your FW this evening just out of curiousity. Unfortunately it seems like there was some buffer overflow of PWM idle on my installation? The PW idle number in TS jump between somewhat -32000 and sensible Values, Idle was acting weird as well. Probably wrong setting issue? But such large PW idle numbers seemed quite odd to my eyes...
Re-flashed to 3.3.0b alpha (as I have to get to work somehow tomorrow morning ;)
Regards,
Thomas

[gslender]

Hi Greg,
thanks for the work that you are putting into this!
I tried your FW this evening just out of curiousity. Unfortunately it seems like there was some buffer overflow of PWM idle on my installation? The PW idle number in TS jump between somewhat -32000 and sensible Values, Idle was acting weird as well. Probably wrong setting issue? But such large PW idle numbers seemed quite odd to my eyes...
Re-flashed to 3.3.0b alpha (as I have to get to work somehow tomorrow morning ;)
Regards,
Thomas

I assume you mean Grant ? Greg is the good chap who has been helping me with the testing (and I'm aware of how confusing this would be).

Wow, so you're having that much problem with the new FW - when you say PW idle you mean the PWM Idle - ie the idle air control valve ?? That could be due to bad/incorrect settings somewhere - can you post a MSQ of what was used to make it run that bad. Did you grab a log of when that happened too?

I can confirm that on my car and that of Greg's, it is working fine.

G

[Greg G]

Hey Thomas,

Gslender does the code, I just collect data and suggest/nag

Without seeing your msq, I would suggest double checking voltage correction settings. Did you try turning on the adaptive voltage correction? The correction curves may be off.

Greg

[gslender]

I just collect data and suggest/nag

Awww, you do way more than just that....

You take a bullet for every time I suggest the bugs are gone, only to find out you need to buy a set of spark plugs due to the excessive fuel and crap idle

[pigga]

*sigh*
I should get used to calling you the "two Gs"
Yes, the % duty of the idle valve in CL idle were acting weird in my case. [EDIT]Yes, I meant the CL idle duty %age not the pw of the injectors, sorry [/EDIT] I will have a closer look at it with more patience tomorrow. In my case (out of my experience) most of the MS "bugs" use to be sitting right in front of the laptop
Thomas

[gslender]

Yes, the pulse widths of CL idle were acting weird in my case.

I'm still not sure what you mean - as pulse width is normally associated with injector times - which is something totally different to the Duty % of the PWM Idle valve.... the values you see (Duty% or IAC Steps) isn't a Pulse Width value (at least not directly). I find the best thing to call it is Duty % (or IAC Steps). Obviously if you are talking about Injector PW then yes, please correct me and confirm that you're seeing way wrong PW values and fuel problems are present... (which isn't good).

G

[JasonC SBB]

G and G,

Nice work.
Could you post a screenshot of the setup screen so I can understand what you've done?

Thanks

[pigga]

Hi Grant, Greg and all the others,
I just gave it another go today and re-flashed your Gslender-Code v2.4.3 once again, but the results were the same.
The Idle Duty Cycle bounces up to 3.400% and I have no idea why.
Just have a look:

weird_idle.png (16.91 KiB) Viewed 2077 times

I played with many settings to find out what´s causing this weird behaviour, but unfortunately i could not find out the root cause. Probably someone of the experts might have a look? I am really looking forward towards the assymetric PID!
Thomas

[gslender]

I played with many settings to find out what´s causing this weird behaviour, but unfortunately i could not find out the root cause. Probably someone of the experts might have a look? I am really looking forward towards the assymetric PID!
Thomas

Zero out the Duty% in idle voltage compensation. If that fixes it then perhaps there is a bug in the older code that I've introduced.

[gslender]

Folks, I may have buggered up the original voltage compensation option in 3.3.0b - sorry about that (I don't regression test everything on the MS2 any rely on good folks like you to tell me when something related to what I've changed is broken).

I'm hopeful that within the next 12-24 hours I'll have another release with a fix out - probably renamed 2.4.4... but I will confirm once I know the bug is sorted.

G

[gslender]

Mmmm, I've checked and double checked and there is no real issue with the firmware. I've tested backwards and forwards on my own engine and couldn't really see any issues at all. I have updated the TS ini file to remove a potential issue, but I've never seen it cause problems (for me) so can't really say.

As such I've put the build back on the forum again and haven't updated anything other than the ini file in the zip.

So, please test again, and this time make sure you load the ini file included in the updated firmware on the 1st post. Also open and close TS with the new ini file to ensure it is updating all the new field correctly (it should be, but you never know).

Tricky to fix something that isn't broken in front of you

I'll make myself available on email if you need to chat via google talk - gslender (at) gmail (dot) com

G

[pigga]

Hi Grant.
I just tried again (isung the correct *ini 100% for sure) but no luck either
I tried many settings all across the board (use last known value instead of initial value table, zero out voltage correction %ages, deactivate Idle ignition stabilisation) but no luck.
The only way to get rid is to choose "PW warmup only" and power cycle MS.

But what I can say for sure now is that the RPM sliding window really makes a huge difference on my engine. I always have some slight "jitter" on my rpm signal at lower rpms (I am using a 60-2 wheel).
But I never had these issues with the stock hall sensor distributor. So I suppose the "jitter" seen by MS is caused by light flywheel.
The "new" MAP sampling strategy in combination with sliding window RPM filter really makes a huge improvement. Engine runs definitely "smoother", even with window size set to "2".

Thomas

[gslender]

Post the msq you just used that had these issues.

G

[pigga]

Hi Grant.
The MSQ still is the same as posted above. It works with 3.3.0b and with your 2.3 firmware mod as well (I just tried it).
Thomas

[gslender]

I'm at a loss as to what the issue is... I can't reproduce the bug nor can I find anything that would suggest a problem.

If you have the time to play with the Adaptive PWM Idle Voltage Compensation (and the issue goes away, then I can narrow down the problem to be specifically related to Voltage Compensation when not using Adaptive). I've attached my working MSQ so you can review and see if anything major different, and to help you see what typcial values are needed for Adaptive PWM Idle Voltage Compensation.

gs-16032012-CurrentTune.msq

(88.15 KiB) Downloaded 58 times

The really odd part is that it the normal/standard PWM Idle Voltage Compensation code in the firmware is identical from 330b and my 2.4.3 release - nothing has changed that would impact it behaviour... so I'm puzzled and thinking the issue isn't related to firmware or perhaps not even the Idle Voltage Compensation functions.

Finally, to avoid any odd/strange file copy/transfer issues, I've attached a few compile/build of the 2.4.3 firmware - please ensure you burn and work with this build's ini to validate that absolutely we are looking at the right code/build.

Any help in tracking this down would be appreciated.

G

[gslender]

Fixed it !!

Bug was in the default value for "Baseline battery response lag" (which was 60 when the max allowed value was 15) and because this value was wrong and way, way too large it was writing into memory all over the place and busting into other variables etc... that is why so many other things were breaking!!).

I've added a correct default value of 1 (with TS having a max of 15) and I've fixed the smoothing code to now only allow window sizes no bigger than the size of the array and this should stop this from ever occurring again.

As such, version 2.4.4 has been posted to the 1st page and for those good folks that have been testing, please roll up ya sleeves and try again.

This one should be good !!

G

[Greg G]

Well that bug was a real headscratcher!