I've been playing around with this for a few days. Idle is very smooth. The change to RPM input smoothing from idle valve output smoothing is something that helps quiet PID down near target. The initial value tables for idle duty does allow for a more consistent return to idle target on throttle release. But be aware this table needs to be populated with the correct values.

The battery correction table is spot on! Much better that the previous duty adder, because I can now shape the curve (mild on initial engagement (can simulate adder for headlights), and stronger for bigger voltage droops (transitional electrical loads like fan activation). Like so:The bottom bin sets the floor above which no correction is made. The next bin is where I incorporate the "headlight idle up"--thats the amount of drop when my headights are on. The rest of the bins ramp up aggressively to counter any transient electrical loads (fans).

RPM based idle advance adder- I cannot rave about this enough. Smoooooooth.

Based on this:

I set it up like this:

That plus the AC idle up, gets me this:

Look at the yellow RPM trace glued to the blue target rpm trace! Note the fuschia spark advance oscillating to keep the RPM flat despite various loads being applied. The idle valve only responds to big loads.

Thanks to gslender for working so hard on this! The extra memory page is a huge thing! And thanks to the devs for their help.

muythaibxr wrote:I'm going to spend a few hours coding tomorrow as well to see about improving this and a few other features further.

Cool. There's two things I've been thinking about how to improve...

1) add a floating base voltage learnt from the past X number of avg voltages taken during a sample. This would allow the voltage compensation table to be automatically rebaselined as load is added or removed.

2) add a cold starting/warmup version of the idle advance rpm tables - either rebaseline the input rpm used by the table so it can be used during warmup, or change to a with a 3d table that can be used during lower clt temps.

Let me know if you don't progress on these as I'll probably give 2) a go with the 3d table, maybe only 3 or 4 clt columns would be needed.

For #2 you could just make the curve target-based. So as the target changes it automatically 'rebaselines.' This is what I will be doing in MS3 under the name CL idle timing assistance (since it is going to be based on the CL idle targets).

I am not sure i really see the point of #1. What observed problem are you trying to solve?

Ken

Megasquirt is not for use on pollution controlled vehicles. Any advice I give is for off road use only.

jsmcortina wrote:That's a cut/paste from the ms3 ini file and won't work as-is on MS2/Extra. The {rpmhigh} needs changing to a fixed number, such as 9000.James

James, can you elaborate further....why won't that work on ms2 ? With latest TS it produce no error?

It won't work on MS2 because there aren't any parameters defined to set the {rpmhigh} variable. They only work in the latest beta TS. So for MS2 I would suggest just changing that to 9000 (only takes 5 seconds right?) and use release TS 1.004.

jsmcortina wrote:It won't work on MS2 because there aren't any parameters defined to set the {rpmhigh} variable. They only work in the latest beta TS. So for MS2 I would suggest just changing that to 9000 (only takes 5 seconds right?) and use release TS 1.004.

James

Ahhh, yup. Well, I've not tested any of this with TS 1.004 so this might not be the only stuff that doesn't work.

As I've brought stuff down from ms3, and it targets the very latest beta TS, and there is no docs to explain all this, I'm just assuming anything in those TS versions is correct to take forward.

Gslender, regading this table. What do you think if x axis would be MAT, y - CLT instead of RPMs? Rpms are unattached value to DC. With same DC we can get full variety of rpms. Depending on some circumstances as oil temperature, electrical load etc.

So tuner then have to construct DC table what in usual operation gives rpms little above target. Just with keeping rpm target in mind, not in table.

In addition CLT vs MAT table would be usable for those users eho do not want bothers with PID settings. Open loop.

muythaibxr wrote:I am not sure i really see the point of #1. What observed problem are you trying to solve?

Ken

That would be me. I notice that the average voltage changes by a few tenths when the engine is hot (compared to average voltage when cold). So if I set the floor too aggressively, I would get a bit of unwanted duty correction during steady state idle. If I back off, then it would have less than perfect response (well we got this far, why not go for perfect )

Gslender, regading this table. What do you think if x axis would be MAT, y - CLT instead of RPMs? Rpms are unattached value to DC. With same DC we can get full variety of rpms. Depending on some circumstances as oil temperature, electrical load etc.

So tuner then have to construct DC table what in usual operation gives rpms little above target. Just with keeping rpm target in mind, not in table.

In addition CLT vs MAT table would be usable for those users eho do not want bothers with PID settings. Open loop.

Or another sense for RPMs being there?

Gints

I think that the CLT correction is already factored in via the CLT vs target rpm table. And the mat vs rpm vs duty 3d table accounts for the effects of intake temperature.

Doing it your way- you mean we would eliminate the clt vs target rpm table, and just have a fixed target? Then the clt vs mat vs duty table would just adjust accordingly? Could you elaborate? I would imagine it would not be as straightforward to collect data to populate the table, compared to the present setup.