[PSIG]

Most AE issues are light throttle movements, and mostly around idle/off-idle. I found it helpful to "fill-in" the AE weak areas with enrichments in the VE Table cells where MAP only momentarily goes during accel. Perhaps try some of that to smooth response in specific areas of accel. <shrug>

[bugster_de]

Is the problem @bugster_de with AE below 1000 rpm, as per thread title?

unfortunately not, it is in all RPM areas. Mapdot is always sitting at 0 while the map value works and using the calculated MAPdot in MLV shows a working MAPdot

remember MAP is sampled via a user specified algorithm and I think that will have quite an effect on mapdot at low RPM.

do you mean the filtering algorithm one has to select in Engine constants? I've tried "map average" and "instantaneous" but no difference in effect

Most AE issues are light throttle movements, and mostly around idle/off-idle. I found it helpful to "fill-in" the AE weak areas with enrichments in the VE Table cells where MAP only momentarily goes during accel. Perhaps try some of that to smooth response in specific areas of accel. <shrug>

correct, but my issue is earlier on: MAPdot always calculates to 0.
Increasing the VE value in low rpm areas where you are off-idle works well and I've done it on other megasquirt engines to support idle-the-hard-throttle-open engine reaction. However in higher rpm areas of the map I prefer not to do so, as this kills your fuel-milage. My Campervan is seeing 10.000+ kms/year and a good fuel efficiency pays off.

[pazi88]

I have had the same sluggish AE problem at lower RPM and I have made fix for it, in the Speeduino FW. The problem mainly is that the MAP value updates too slowly because of the averaging. Especially on the cycle-average mode in lower RPM, which otherwise gives the smoothest/best map reading. At higher RPM it's fine. The instantaneous MAP sampling method with filtering turned off or to very minimum, gives really good AE response on lower RPM. But at higher RPM the MAP reading has huge spikes, so it doesn't really work. That's why I added the instantaneous to selected MAP sample method RPM switch point to the FW.

map.png (29.34 KiB) Viewed 240 times

So that for example means that below 1400RPM "instantaneous" sampling method is used. And "Cycle Average" above that. Using that gives me really great throttle response to whole RPM range.

[PSIG]

The problem mainly is that the MAP value updates too slowly because of the averaging. … with filtering turned off or to very minimum, gives really good AE response on lower RPM. But at higher RPM the MAP reading has huge spikes …

We have debated reading frequency and filtering/averaging for a long time with single fixed values for each, and solutions seem to be workarounds. Any chance a pair of taper or table settings for a (any) single mode could be employed (like others we have)? Filtering or averaging is a single setting for all conditions. E.g., TPS Filtering > Filter Level MAP/TPS/RPM > x to y > off-low-med-high … or simple table, switches, or some such interface?

While your solution is certainly functional, if Cycle Average is simply too averaged at low speeds, we could adjust level at increments? Perhaps this could avoid the issues for each case, and allow the best mode or modifier for the functional results of any specific engine setup, I'm thinking? Thoughts?

[EDIT] I'm hoping this concept could be used to fit other IO, such as signal input, where one size (setting) does not fit all. We use strength, range and taper for other stuff like AE or WUE, why not for others?

[bugster_de]

I have had the same sluggish AE problem at lower RPM and I have made fix for it, in the Speeduino FW. The problem mainly is that the MAP value updates too slowly because of the averaging. Especially on the cycle-average mode in lower RPM, which otherwise gives the smoothest/best map reading. At higher RPM it's fine. The instantaneous MAP sampling method with filtering turned off or to very minimum, gives really good AE response on lower RPM. But at higher RPM the MAP reading has huge spikes, so it doesn't really work. That's why I added the instantaneous to selected MAP sample method RPM switch point to the FW.
map.png

So that for example means that below 1400RPM "instantaneous" sampling method is used. And "Cycle Average" above that. Using that gives me really great throttle response to whole RPM range.

That sounds awesome! my VW Boxer engine with central inlet plenum has pretty "jumpy" map signals around idle and hence "cycle average" gives me a far from ideal idling while it works fine above 1.200 rpm.
Any chance you can give me your code? I have branched my own code from 2023-10 late last night and modded the AE calculation in corrections.ino in order to remove everything that refers to TPS

[JHolland]

The problem mainly is that the MAP value updates too slowly because of the averaging. … with filtering turned off or to very minimum, gives really good AE response on lower RPM. But at higher RPM the MAP reading has huge spikes …

We have debated reading frequency and filtering/averaging for a long time with single fixed values for each, and solutions seem to be workarounds. Any chance a pair of taper or table settings for a (any) single mode could be employed (like others we have)? Filtering or averaging is a single setting for all conditions. E.g., TPS Filtering > Filter Level MAP/TPS/RPM > x to y > off-low-med-high … or simple table, switches, or some such interface?

While your solution is certainly functional, if Cycle Average is simply too averaged at low speeds, we could adjust level at increments? Perhaps this could avoid the issues for each case, and allow the best mode or modifier for the functional results of any specific engine setup, I'm thinking? Thoughts?

[EDIT] I'm hoping this concept could be used to fit other IO, such as signal input, where one size (setting) does not fit all. We use strength, range and taper for other stuff like AE or WUE, why not for others?

My experience with OEMs is that the switch from averaged MAP to instantaneous MAP is dependent on the rate of change of MAP. If you have big spikes at high RPM then the analogue filtering is probably not correct, most Speeduinos seem to have that all wrong.

[pazi88]

That sounds awesome! my VW Boxer engine with central inlet plenum has pretty "jumpy" map signals around idle and hence "cycle average" gives me a far from ideal idling while it works fine above 1.200 rpm.
Any chance you can give me your code? I have branched my own code from 2023-10 late last night and modded the AE calculation in corrections.ino in order to remove everything that refers to TPS

That has been in the FW for couple of releases already.

[pazi88]

We have debated reading frequency and filtering/averaging for a long time with single fixed values for each, and solutions seem to be workarounds. Any chance a pair of taper or table settings for a (any) single mode could be employed (like others we have)? Filtering or averaging is a single setting for all conditions. E.g., TPS Filtering > Filter Level MAP/TPS/RPM > x to y > off-low-med-high … or simple table, switches, or some such interface?

While your solution is certainly functional, if Cycle Average is simply too averaged at low speeds, we could adjust level at increments? Perhaps this could avoid the issues for each case, and allow the best mode or modifier for the functional results of any specific engine setup, I'm thinking? Thoughts?

[EDIT] I'm hoping this concept could be used to fit other IO, such as signal input, where one size (setting) does not fit all. We use strength, range and taper for other stuff like AE or WUE, why not for others?

Well yeah, everything could be always made better. But I stopped developing more complicated solution for that problem, when I noticed that the simple RPM switch point between cycle average and instantaneous worked great for all the engines I can test. I have driven like +20 000km with that simple mod (that is in the FW currently) and I haven't had AE problems since.

[PSIG]

Awesome, and it it is working for you very well. I'm thinking to keep this option in-mind for other applications that could benefit, or future interface, where the RPM switch or confusion of switching and filters may be frustrating for users. E.g., simplify to using only Cycle Average, and adjust your filter sliders at rpm points for best performance. Thanks for the first solution!

[bugster_de]

So I found very short time slot today to test things out.

Here's one example:

Bild_2024-04-24_171713372.png (19.57 KiB) Viewed 95 times

Engine is idling at ~800 rpm (upper red line) at ~60kPa of MAP (yellow line). In the center, I opened the throttle fast and hence MAP is going up. However MAPdot (whiteline) from the ECU doesn't see anything and stays at 0. MAPdot* from the MLV optional field (green line) did clearly see the spike. Consequently AE (lower red line) remains at 100 and AFR (lower white line) jumps up. The lambda probe is pretty much towards the end of the exhaust this is why you see the delay in AFR response

Settings are:

Bild_2024-04-24_172414062.png (33.4 KiB) Viewed 95 times

and

Bild_2024-04-24_172458953.png (27.79 KiB) Viewed 95 times

So from my understanding, below 1.500 rpm it uses instantaneous and the filter sitting at 5 is very low.

Note: I have a very similar engine with Megasquirt (MSExtra-2) up-and-running. Works fine and has done ~35.000 km so far. However I can't find the source-code for MSExtra to see the difference in MAP sampling