[FW MOD] ms2extra 3.3.0b gslender v2.4.4

[spittybug]

I am so very ready to give this a try on the oddfire V6 Delorean! Just waiting to make sure I get the two other cars up and running nice before I jump back into the world of more trial and error. While I don't yet fully understand the full range of what you guys have been doing here, I'm coming up to speed and can't wait to wade into the pool! Great work.

[robs]

OK time to get this topic back on track with firmware development and not individual tuning issues

While I already raved about the excellent effect of the oversampled and averaged TPS data on TPSdot, the addition of robs' moving anchor filter resulted in a flat noise-free TPSdot line, at 100 lag factor (no lag filter applied). It's so flat it's creepy. But it is very responsive to throttle movements. Should allow even finer tuning of AE. There are no spikes to cause false triggers Compare it to MAPdot, which has only the oversampling/averaging done, also at 100 lag factor, but no robs filter. Perhaps MAPdot can get the same treatment in the future?

My own car is using the same moving anchor algorithm for mapDOT and it's similarly free of noise. I don't know exactly how Grant has implemented it, but my own code does the moving anchor on the raw values before lag averaging is done. This means that I can run a low lag value on MAP, giving smooth metering, while still getting a very responsive mapDOT. As for tuning, it was really easy. I set a very low mapDOT threshold and use MAP based AE for all gentle accel. I set a much larger tpsDOT threshold, targeting it for quick throttle movements. The resulting blend is very responsive, the AFR stays in a good range, and there's no false triggering.

Now that I'm back on deck, I'm very keen to try out the new MAP sampling combined with the moving anchor stuff. I don't think Grant has posted the source to this patch yet, so I'll apply my tweaks to the mainline.

Have fun,

Rob.

[gslender]

Now that I'm back on deck, I'm very keen to try out the new MAP sampling combined with the moving anchor stuff. I don't think Grant has posted the source to this patch yet, so I'll apply my tweaks to the mainline.

My implementation is mostly (if not excactly) your implementation Rob, just with ability to turn it off and adjustable variables etc. I've also based it off the raw sample (either oversampled or not).

I'll update the post with source soon... just need to clean up a few things before I do.

BTW - the mainline code 3.3.0b doesn't have the TPS oversampling, just the MAP oversampling.

I'm thinking I might add the MAP moving anchor option too... do you have something you can send me with that code (or is it in a prior diff)... and I might bang this out soon.

G

[robs]

I'm thinking I might add the MAP moving anchor option too... do you have something you can send me with that code (or is it in a prior diff)... and I might bang this out soon.

I did include the moving anchor MAP stuff in a patch a while back but, now that I've had a peek at the code (and not surprisingly), the improvements to MAP sampling conflict with those changes. I'll try to incorporate it again and post a patch in the Noisy tpsDOT thread after I've given it a test (day or two).

And while we're spelling out tpsDOT (or TPSdot...), I'll respond here to the question you posed in a separate thread. I don't have any strong opinion, but I agree MS's spelling is a bit of a jumble. If I were inventing it I might go for a "d" prefix to indicate derivative: TPS and dTPS, MAP and dMAP, etc., reasonably clear and concise. Newton probably wouldn't have bothered with his dot notation if he'd had to spell out the word DOT every time!

Have fun,

Rob.

[msegt]

would what your talking about remove the mapdot noise the way it did for tps? if so cool, i noticed mines smoother just with the tpsdot filters, my mapdot justs to -40/+40 at highest, and rpmdot i noticed has a slight bump too. so if that makes everything ever smoother im all for it

[robs]

I would like to ask a question in this context. What do the experts think: I noticed, that with 60-2wheel I had slight "jitter" on the rpm signal that I had never seen with stock hall sensor inside the distributor (which is a 2-tooth wheel if you wanna see it that way).
So...should the RPM sliding window size be related to the number of teeth? A 60-2 tooth wheel needs larger window than a 36-1 wheel for instance? And a stock distributor as mentioned above needs no RPM smoothing at all?
I am supposing this because the higher the number of teeth the more often the RPM signal will be updated. Am I thinking into the right direction?

If you're up for it, a while before I started the "Noisy" tpsDOT thread, I bored people silly with a "Noisy" RPM thread: http://www.msextra.com/forums/viewtopic.php?f=91&t=39155. It's a real page turner!

Executive summary is that I became keen on smoothing out the expected within-4-stroke-cycle jitter (pistons accelerating, lazy cylinders, etc.). Not hard to do: choose a few representative teeth, keep hold of times when they come up, calculate RPM based on every second reading. This engine speed value would be used for metering and advance calcs, you'd still want to use individual tooth time for spark timing and the like. Experiments based on the tooth logger let me eliminate about half the jitter in my RPM graph. The other half of the jitter was due to things like slightly out of round wheels, etc., where the momentum of the car actually does cause the engine speed to fluctuate.

Have fun,

Rob.

[gslender]

If you're up for it, a while before I started the "Noisy" tpsDOT thread, I bored people silly with a "Noisy" RPM thread: http://www.msextra.com/forums/viewtopic.php?f=91&t=39155. It's a real page turner!

Interesting read.

I've been wondering about the rpmDOT least-squares smoothing and why it was needed (to calc rpmDOT) and yet other DOT calcs didn't need it... but have now got improved filtering (TPS/MAP).

So me adding an RPM sliding window, is really adding code bloat and CPU tasks that is actually (to a degree) being duplicated by the pre-rpmDOT calc).

So perhaps the simpler (and more elegant) solution is to offer an option to extract the RPM from the least-squares smoothing ... certainly interesting.

G

[robs]

Interesting read.

Glad you thought so. I was pretty pleased with it myself -- obvious in hindsight, but it changed the way I think about how the engine interacts with the car.

I think it's worth considering using the LSQ estimate of the RPM. As you say, taking another approach to smoothing when the code already has the "Rolls Royce" doesn't feel right. At the very least it seems worth trying to use the LSQ line's estimate of the current RPM and seeing how that goes. Perhaps there will be issues of responsiveness, though you'd expect those to already be surfacing with rpmDOT.

Have fun,

Rob.

[piledriver]

I have a question as to MAP signaling with the new code.

With my setup until 3.3.0b, my MAP "wandered" from ~115KPA to 85 KPA in a few hundred RPM around pk tq, taking 5 degrees worth of samples at a fixed crank angle (needed to do this for idle/low speed signal consistency) then gradually coming back up to ~100 KPA near redline.

Of course this is why MS3 has a sample angle/RPM table.
Strangely, it ran great like this, with a lot of fiddling with the AFR map to accomidate the wavy "max map" line, and it was gradual enough not to trigger unintended accel event with reasonable settings.

In any case, the new sampling setup (oversampling//averaging)allows the car to idle fine and is rock steady ~everywhere/gives sane numbers, but near pk HP I now get a ~5KPA "squarewave" which may be related to some sort of beat with my very "happy" intake tract/MAP signal.

It has never run better, but I have to set my MAP accell threshold to someting like 400 to avoid getting unintended accell/decell events and AFR weird in this RPM range (EAE is a godsend here, barely driveable without it on)

It's the same effect as seen in my previous MSQ/log I posted,
...raising the threshold to ~400 "cures it" but makes setting a usable accel setup that works at low RPM/throttle settings pants, its too bad the accel couldn't be made inversely proportional with RPM, or log scaled so it's less sensitive up high ...or something.

So... Im going somewhere... Ah, can the sampling interval/pattern be easily randomized, and would that help??

I suppose a Ford MAF sensor would likely resolve the issue... I wanted to go there eventually but I would prefer to solve the issue, as any car with a well designed intake is likely to see similar issues, and they make a lot of those these days.


Hmmm...
I just tried setting the lag down to 80 and leaving the MAP threshold set to 400, almost perfect results, but tip in at low RPM still leaves something to be desired.

The squarewave seems gone at 80 lag, so I just probably need to play with it some and work on the accells again.

[Black99rt]

The code includes a provision for scaling AE with rpm.

[gslender]

Source code added to first post.

If you need/download the source, would you mind letting me know what mods you make as maybe others may benefit... no big deal, but wanted to know why 30+ people download the source and what they do with it??

G

[pigga]

Hi.
Probably a bit OT at this point, but yesterday I wondered if those Lockout-Settings are still active when I switch CL idle to "Use initial value table"?
Thomas

[gslender]

Hi.
Probably a bit OT at this point, but yesterday I wondered if those Lockout-Settings are still active when I switch CL idle to "Use initial value table"?
Thomas

Not sure what you mean, but PID Lockout-Settings tied to "Use initial value table" - so yes they are active, but at the time idle code is applying the initial value table, the use of lockout settings has past (as it has determined the IAC needs to be reset to an initial value ready for CL PID to control idle again).

G

[ol boy]

I got this version code loaded yesterday and I noticed today I was slightly rich across the hole VE table. I had turned on the MAP sampling for "lowest value". What does this actually do? I still have a MAP sampling window of 20* angle at a 10* sampling wide window. I thought I read through all 4 pages of this thread and the release notes posted on the first page but hadn't seen any explanation of how it works. I liked the sliding windows, in V2.3 alot. This versions works well without any changes to the tune. I flashed this version, reloaded the .msq, cleared the few errors with the previous .ini file, fired it up and drove to school without changing a thing.

Thanks Ryan

[gslender]

I got this version code loaded yesterday and I noticed today I was slightly rich across the hole VE table. I had turned on the MAP sampling for "lowest value". What does this actually do? I still have a MAP sampling window of 20* angle at a 10* sampling wide window. I thought I read through all 4 pages of this thread and the release notes posted on the first page but hadn't seen any explanation of how it works. I liked the sliding windows, in V2.3 alot. This versions works well without any changes to the tune. I flashed this version, reloaded the .msq, cleared the few errors with the previous .ini file, fired it up and drove to school without changing a thing.

Thanks Ryan

Mmm, this post is confusing - you say at the beginning you got this version and it was rich across the VE table, and then later you state... "I flashed this version, reloaded the .msq, cleared the few errors with the previous .ini file, fired it up and drove to school without changing a thing." - so which is it?

Also, there is no explanation of the two MAP Sampling settings as "Use lowest value" is the original MAP sampling method that requires a window/angle etc (it always has). The new method of averaging the MAP value between ignition events is enabled as "Use average" - no instructions as nothing is required further than enabling it ;-)

G

[pigga]

Not sure what you mean, but PID Lockout-Settings tied to "Use initial value table" - so yes they are active, but at the time idle code is applying the initial value table, the use of lockout settings has past (as it has determined the IAC needs to be reset to an initial value ready for CL PID to control idle again).

Hi G.
I was thinking about the RPMdot disable and PID lockout settings:

lockout2.JPG (16.24 KiB) Viewed 517 times

If I set them too lazy with the old (use last known value) CL Idle strategy, CL idle used to be activated although the main condition (RPM below target+adder) was not met, right? So I was wondering if some weird settings over there could have some strange side effects on the new CL idle control algorithm.
Thomas
P.S.: Regarding the "Use average" Map sampling strategy I can confirm that I noticed a slightly richer mixture as well (above all at low engine loads)

[robs]

I got this version code loaded yesterday and I noticed today I was slightly rich across the hole VE table. I had turned on the MAP sampling for "lowest value". What does this actually do? I still have a MAP sampling window of 20* angle at a 10* sampling wide window. I thought I read through all 4 pages of this thread and the release notes posted on the first page but hadn't seen any explanation of how it works. I liked the sliding windows, in V2.3 alot. This versions works well without any changes to the tune. I flashed this version, reloaded the .msq, cleared the few errors with the previous .ini file, fired it up and drove to school without changing a thing.

Thanks Ryan

Just to emphasise what Grant said, "lowest value" should be the old map sampling algorithm and you'd hope there'd be no change in tune if you used that setting (assuming you used the same window as before).

Recapping what the two algorithms are, lowest value uses the lowest MAP sample while the crankshaft is in the sampling window; averaging takes the mean of all samples though the engine stroke. Pretty much to be expected that the average will be greater than the minimum, so you will typically get a higher load value => greater PW => richer. On the plus side, the mean should give a more stable value, less subject to harmonic effects, so it should be worth the effort of retuning.

Have fun,

Rob.

[ol boy]

Okay, thanks. Sorry for the confusing post. I flash 2.4.4 then loaded the msq and drove it to school that night but then noticed the next day with the DMM hooked up to my O2 input that I was slightly rich across the hole VE table and had to pull a little bit of fuel out. No big deal, it's really close driving it around today.

[Perkele]

I've been using this code for a few days now and I love it.
With the average filter I can now use TPS lag factor of 100 and MAP lag factor of 95. Earlier had to use alot smaller lag factor for MAP and only now I realize how much the earlier big lag affected the drive and AFR.
Even when my VE table was good, AFR were all over the place in transitions, but now with much less lag AFR looks much better.


And now my idle is beautifull.

Only one thing I don't seem to fully understand is the dashpot decay.
My dashpot adder is 4.3% and decay is 10 and I'm using the IVT table.
But it doesn't seem to work as planned as you can see in the picture, it does add the dashpot adder but it drops back to IVT value right after. And most of the time it doesn't add the adder att all.
Still the RPM falls quite nice to idle but if someone can point my error in config to make it work even better.
Thank you.

[gslender]

Only one thing I don't seem to fully understand is the dashpot decay.
My dashpot adder is 4.3% and decay is 10 and I'm using the IVT table.
But it doesn't seem to work as planned as you can see in the picture, it does add the dashpot adder but it drops back to IVT value right after. And most of the time it doesn't add the adder att all.

Watch status4 as it will tell you when DP is being added (it should be 34 - which is PWMIDLE_RESET_JUSTLIFTED + PWMIDLE_RESET_DPADDED) and 16 when waiting for PID to take effect (PWMIDLE_RESET_CALCNEWTARG).

I've also seen that you have targ rpm clt curve that is 950rpm when 90deg and then 1200rpm when 100 deg ???? wtf !!

G