MS2/extra alpha 3.3.0b (2012/02/27)

[piledriver]

Loaded and works well on my setup, took a long spirited drive for little other reason than to test it.

Using the adaptive idle timing the table still looks blank for some reason.
It actually started showing the curve when I tweaked some values when using 330a but no dice this time, still WORKS great.

Even with the same settings fuel seemed a quite fat in certain areas, I've been running VeAL on "very hard" for awhile.

What should I expect from the MAP averaging?
(I switched back to grabbing same 5 degrees of sample at a same angle before the drive, but I'm open to try new things)

Pulled the BT/hooked my real 16550a serial port back up to get it to burn FW properly, left it hooked up
Forgot how fast it is by comparison, was able to set it back to max sample rate .(at least under Linux)

[gslender]

Using the adaptive idle timing the table still looks blank for some reason.
It actually started showing the curve when I tweaked some values when using 330a but no dice this time, still WORKS great.

Not sure what you mean by blank? post ya msq

[gslender]

I was able to get a steady RPM reading as my trigger wheel might not be as square and evenly spaced as needed. This also made tuning closed PID idle better with less up and down swinging. On the MAP side I got my load steady within one percent load range while idling.

The new map averaging has removed the need for any type of filters (Lag, Median or others) for MAP - in my tests it really is that good!

As for TPS, I'm still of the view something needs to be done (and Ken has hinted that something might be) - so far Rob's TPSdot filter produces the best results and I've now tested a range of different options.

I'm unsure about the need for RPM filtering but concede that indeed either Lag or Median would be worth having - in my book, median (window of 3) does a better job of noise removal than Lag factor 50 and about the same response lag.

G

[ol boy]

Could RPM be averaged as each tooth comes by for each crank revolution? A running average of times between each tooth would mask poorly designed crank trigger wheels like mine. I'm having to use a lag factor of 75 and a window of 11 to get some what steady rpm output. Unless the code is already doing that...

[piledriver]

Using the adaptive idle timing the table still looks blank for some reason.
It actually started showing the curve when I tweaked some values when using 330a but no dice this time, still WORKS great.

Not sure what you mean by blank? post ya msq

I phrased that wrong---the table is populated when you click the pulldown, but the graph shows nothing.
Idle works perfect, probably a glitch in TS, running the latest beta.

[jsmcortina]

Post a screenshot of what you mean. I wouldn't immediately suspect a TS problem.

James

[piledriver]

Post a screenshot of what you mean. I wouldn't immediately suspect a TS problem.

James

As requested... Looks like the data is absolute and the graph is delta from something?
Perhaps operator error, but the #s aren't far from default.
I only use the idle timing and a CIS warmup valve for idle control, it's rock steady at ~975 RPM once warmed up.
Much faster than the older code for idle advance, which would cause a uuuup/ddooooown oscillating effect.
The new code/slope seems to easily "keep up".

emptygraph.png (12.59 KiB) Viewed 586 times

and showing data, which appears out of range, but works well.

emptygraph2.png (16.86 KiB) Viewed 586 times

[jsmcortina]

None of the points are on the graph. The X axis goes up to 250, but the minimum value is 800.

James

[piledriver]

None of the points are on the graph. The X axis goes up to 250, but the minimum value is 800.

James

Correct, caught that, but what is proper usage?
The numbers are close to default IIRC...

Where is the magic missing setpoint number set that the delta chart is referenced to?
Remember--- I'm ONLY using idle timing for idle speed stability, not CL idle with a IAC.

---Edit--- If I set "idle advance on" "RPMS" in the settings, table changes context and shows as expected.
Setr to "load" also changes and graph displays.

If I set to "adaptive" you get the noreferenced delta graph, there should be a setpoint somewhere, right?

[jsmcortina]

Correct, caught that, but what is proper usage?
The numbers are close to default IIRC...

Sounds more likely it is an ini error then with the axes set to the wrong default numbers.

James

[piledriver]

I edited//posted what it's doing in all 3 modes as you posted.

In RPM and LOAD modes, it works fine.

The "adaptive" mode has no setpoint I can see...
If there was a way to "anchor" the delta table for adaptive at 975 RPM it would be ~all in range.

If the adaptive depended on CL idle it would make sense, but should be grayed out.
Regardless, it idles FAR better than it ever has set as it is, I'm just curious what "adaptive" means specifically in this case...

[Greg G]

I edited//posted what it's doing in all 3 modes as you posted.

The "adaptive" mode has no setpoint I can see...
If there was a way to "anchor" the delta table for adaptive at 975 RPM it would be ~all in range.

If the adaptive depended on CL idle it would make sense, but should be grayed out.
Regardless, it idles FAR better than it ever has set as it is, I'm just curious what "adaptive" means specifically in this case...

Adaptive mode uses the CLT based target as the reference RPM, or your "anchor". Since this target changes with CLT, it's better to use idle advance as an adder rather than absolute values.

As an example--this is what I'm currently using:

[gslender]

Correct, caught that, but what is proper usage?
The numbers are close to default IIRC...

Sounds more likely it is an ini error then with the axes set to the wrong default numbers.

James

James, this ends up being a user unable to understand or figure out the defaults. I did have this explained in prior PDF docs.

Was thinking is it possible to get TS to push defaults Itself by getting Phil to add a "Suggested Defaults" button on every dialog. This would add some extra ini weight, but often feel the defaults provided by the ecu seem a little restrictive, plus sometimes it's nice to config away from the ecu when trying new features.

G

[jsmcortina]

plus sometimes it's nice to config away from the ecu when trying new features.

Just load in the default MSQ ?

James

[gslender]

plus sometimes it's nice to config away from the ecu when trying new features.

Just load in the default MSQ ?

James

I don't think that helps for just exploring a new single feature like the example above - there is just no easy way to update the project config and obtain project defaults. In the case above, even connecting to the ecu won't help, as the bins are shared and whereby for one config they are relative delta from target idle rpm, for the other they are absolute.

G

[jsmcortina]

Perhaps sharing the bins isn't the best approach?

James

[piledriver]

OK, perhaps intent is to replace or enhance cold idle as well?
Still haven't found a CLT .vs RPM setting other than the rev limiter...

[gslender]

Perhaps sharing the bins isn't the best approach?

James

In the land of memory and space free MS3 that probably is... but alas I tried to limit the growth of new bytes for a config that essentially is exclusive anyway (both can't be enabled at the same time).

Anywho, as long as people know what to do, all is good. I personally think the older idle advance should be deprecated anyway, as many of the later features are better with no downside.

G

[piledriver]

... this ends up being a user unable to understand or figure out the defaults. I did have this explained in prior PDF docs.

Digging back to your threads, I assume you mean this?
gslender.mod.application_notes.pdf
download/file.php?id=21425

Well written.

It does work much better/faster than the old idle timing routine.
I tweaked my RPM lags to ~45 to make it very stable, using RPM based.
Unfortunately I'm ONLY using idle advance for control, cannot set the target value to use adaptive, but this is likely only short term as I'm partway through and AC install.

Also got MUCH better results with the MAP averaging than the old code, my WOT VE line no longer snakes 30KPA through the table, and it still idles well, was using a narrow/timed sampling window before to get decent results at ~idle, but got huge variations at some RPMs likely due to resonance as the tradeoff. IIRC the old code did some funky things too, I got best results previously from the timed sample.

[pigga]

Hi.
Encouraged by the two dynamic G's ( ) I went from Gslender-FW Mod to this latest Alpha today.
What I can confirm that the map over-sampling method seems to give much (much) more consistent load signal than the "old" method.
This would be conform with physics, as I discussed with Ken in some other thread: The "peak" of the shock-wave running through the inlet is caused by the air running again the closed inlet valve and bouncing back. As a matter of fact this peak will "move" through the inlet (if you see Map Sampling as a momentary point of view like an ignition strobe light) and it will move depending in the RPMs. So I am really happy with this and can confirm that map over-sampling obviously did the trick.
But I can also confirm that the sliding window obviously did a really good job. At least on the engine with the very light flywheel it gave improvements during startup and at low/mid RPMs, fast revving down etc. Lambda control was much less "nervous", and no negative side-effects to CL idle so far.
At that point I would agree with one of the Gs who said that median sliding window could be a usable method to smoothen RPMs. The speed of RPM-change will never be infinite (as there is always some flywheel mass as "damper"). So most likely RPM will never run out of the "sliding window" if you choose sensible presets for this filter. To my eyes it would be worth a try to put it into another alpha and let the people play with it and see what happens.
For TPS and median sliding window I followed the noise-filter-god-mode-tutorial (viewtopic.php?f=91&t=42233) with high interest. I can confirm that the actual lag factor filter with 6db/oct is not sufficient for this: You can choose between "Do not filter enough" and "Filter enough noise but the signal as well". I think the 12db/oct by cascading two lag filters (as it was suggested AFAIR?) would at least be worth a try.
As it's no release but highly experimental alpha at the moment, I think it was worth a try as well?

Further more thanks to the two Gs for explaining the idle enhancement options.
At least regarding the voltage compensation I have another theory: You should not only think about the momentary (relative) voltage change, but that the absolute voltage applied to the PWM valve makes it move as well. I equipped a car with a MS where the generator kicks in 1/2 second after the engine fires up. At that moment you have a jump in voltave from let's say 12V to 13.8V. Without voltage correction this always made the engine rev up (as the valve opens). This engaged lockout detection and so on. Or, if you dial in matching PW values for 13.8V, the engine will stumble around until the generator delivers voltage... With the correction it now starts silky smooth as the idle valve remains in its position...
Thomas