For anything you'd like to see added to Speeduino
User avatar
By iltheo84
#57998
I was looking through my logs last evening, trying to collect data to better tune my TPSdot based AE, but I noticed some inconsistencies in its behaviour.
TS logs data at around 15Hz (one sample every 0,066s), and I was checking how much my throttle can move in one single sample.
Note that my TPS has ZERO noise, I have my AE threshold set to 0 and have absolutely NO false triggering, but my engine (1.6 Mx-5 NA) is really sensitive to small, low-throttle transients, spiking lean if AE does not come into play to keep AFRs in range.

I could see in the logs TPS moving from 0 to 3% from one sample to another (3% / 0,066s = 45%/s TPSdot) and triggering AE, and then later moving from 2 to 5% again in one sample: this should give the same TPSdot, but AE is not triggered.

Maybe I'm not grasping how AE and TPSdot work, but I can't understand the point of coverting TPS movement to %/s instead of just using "deltaTPS" between one ADC sample and the previous value.
This would give the same resolution, but be sensitive to every small movement of the throttle (that one can filter out with the threshold if not needed) and have a defined range (0-100%/sample).

Would it be possible to add a "Delta TPS" AE mode to the existing TPSdot and MAPdot ones?
It would retain the same options (threshold, RPM taper, cold enrichment and taper...) but save some calculations since converting to %/s would not be needed.

I don't know if TPSdot calculations and %/s based AE are used for some sort of compatibility among different hardware/boards, but since AE must be individually tuned on each car anyway, I find some simpler approach would be helpful.

Another nice feature would be "Tip-in AE", that adds a little more enrichment when moving from 0% TPS, since some engines are prone to swinging lean in this situation.

Thanks!
By ric355
#57999
iltheo84 wrote: Thu Aug 04, 2022 7:16 am Maybe I'm not grasping how AE and TPSdot work, but I can't understand the point of coverting TPS movement to %/s instead of just using "deltaTPS" between one ADC sample and the previous value.
This would give the same resolution, but be sensitive to every small movement of the throttle (that one can filter out with the threshold if not needed) and have a defined range (0-100%/sample).
%/s is a "rate of change". A high rate of change typically requires a bigger addition of fuel than a low rate of change. If you were only to use a deltaTPS, you'd would not get the same scaling because it does not account for the timeframe the change has occurred in. The sample times being quite small make this less of an issue, and some sort of additional delta based AE for low throttle angles could potentially add something useful in some circumstances, but you'd have to be careful that the two strategies didn't compound each other resulting in too much fuel. However I believe most people probably compensate for this using the transient cells in the VE table, possibly without even realising it as it will have just come about through general tuning.

It's a common comment that AE doesn't activate properly for slower throttle movements. Behaviour here is firmware version dependent; firmware released before 2022 has a minimum TPSDot of around 30%/s. Firmware released on or after 2022 has a minimim TPSDot of 15%/s. If you are on earlier firmware, it's possible that your 2-5% change was just the wrong side of integer values to generate a high enough %/s. If you are on earlier firmware, simply upgrading might be enough.


Note that the data logging rate of TS is not relevant to the calculation of TPSdot. It's the resolution of the TPS that is important, and that is what changed in 2022. It went from 1% to 0.5% resolution. The TPS sample rate plays a part but only in the sense that the sample rate is part of the calculation.
User avatar
By iltheo84
#58001
ric355 wrote: Thu Aug 04, 2022 9:39 am %/s is a "rate of change". A high rate of change typically requires a bigger addition of fuel than a low rate of change. If you were only to use a deltaTPS, you'd would not get the same scaling because it does not account for the timeframe the change has occurred in.

Why not? The current code (I'm using the latest firmware) just translates deltaTPS to %/s by multiplying it by the sampling frequency:

TPS_change = (currentStatus.TPS - currentStatus.TPSlast);
TPS_rateOfChange = (TPS_READ_FREQUENCY * TPS_change) / 2; //This is the % per second that the TPS has moved, adjusted for the 0.5% resolution of the TPS
    if(TPS_rateOfChange >= 0) { currentStatus.tpsDOT = TPS_rateOfChange / 10; } //The TAE bins are divided by 10 in order to allow them to be stored in a byte
And being the sample frequency a fixed value (currently 30Hz if I'm not mistaken) the two values are directly proportional, thus the deltaTPS already is accounting for the time the variation has occurred (the time between the two ADC readings).
I just find the conversion to %/s redundant, as it adds no resolution nor flexibility to the whole algorithm.
Please correct me where I am wrong on this.

ric355 wrote: Thu Aug 04, 2022 9:39 am It's a common comment that AE doesn't activate properly for slower throttle movements. Behaviour here is firmware version dependent; firmware released before 2022 has a minimum TPSDot of around 30%/s. Firmware released on or after 2022 has a minimim TPSDot of 15%/s. If you are on earlier firmware, it's possible that your 2-5% change was just the wrong side of integer values to generate a high enough %/s. If you are on earlier firmware, simply upgrading might be enough.

I'm using the latest firmware, but I saw no improvement when going from 1.0% to 0.5% resolution.

I also noticed there is an hardcoded filter in the source, that zeroes out any change under 2% and I guess it is why my AE is not responding to small movements:
//Also check for only very small movement (Movement less than or equal to 2% is ignored). This not only means we can skip the lookup, but helps reduce false triggering around 0-2% throttle openings
      if (TPS_change <= TPSAE_ABSOLUTE_THRESHOLD)
      {
        accelValue = 100;
        currentStatus.tpsDOT = 0;
      }
TPSAE_ABSOLUTE_THRESHOLD is set to 4 in the current firmware, and this actually limits the lower %/s that is detected by the ECU to (TPS_READ_FREQUENCY * 5) / 2 = (30 * 5) / 2 = 75%/s .

I understand this was included to prevent unnecessary lookup to the table, but it severely affects the behaviour of AE at low TPS delta.
ric355 wrote: Thu Aug 04, 2022 9:39 am Note that the data logging rate of TS is not relevant to the calculation of TPSdot. It's the resolution of the TPS that is important, and that is what changed in 2022. It went from 1% to 0.5% resolution. The TPS sample rate plays a part but only in the sense that the sample rate is part of the calculation.

True, I was assuming TPS sampling occurred at 15Hz (same data logging rate) but since it went up to 30Hz, I cannot rely on logs to calculate TPSdot from the data.
User avatar
By PSIG
#58004
This issue has been around since the beginning, with some improvement but no complete or integrated solutions. We have multiple different factors at-play, not the least of which is interface with the humans. For example, %/s is a term humans can relate-to, as a magnitude versus time. Not that there aren't better options; but that's the one the developer grabbed for us to relate-to.

No, it does not capture other factors, such as the impact on pressure and airflow at different speeds or MAP (e.g., your "tip-in" issue), fuel atomization, condensation or wall-wetting, etc, and was the basis for other systems using stuff like X-tau (e.g., here and here). I am assuming this is one reason for conversion to %/s, although other reasons and options remain.

IMO this topic needs a better solution (for a long time), and an examination of all potential options and their benefits should be examined for suggesting the path forward. We cannot stall by chasing one squirrel, and selection would be a process. That said, thanks for bringing it up yet again, and here we go, it's being brought up… again. :lol:

:arrow: PS: If anyone can find the old video on X-Tau by Dr. J.Cowart, please post it.
User avatar
By iltheo84
#58006
PSIG wrote: Thu Aug 04, 2022 2:13 pm This issue has been around since the beginning, with some improvement but no complete or integrated solutions. We have multiple different factors at-play, not the least of which is interface with the humans. For example, %/s is a term humans can relate-to, as a magnitude versus time. Not that there aren't better options; but that's the one the developer grabbed for us to relate-to.
Thanks PSIG, maybe it's my engineering background talking, but to me, one could avoid the series of operations that are performed to calculate TPSdot, and still have a value that can be read and understood by the operator.

Assume a 5.0% (10 units in 0.5% resolution) change in TPS position in 1/30th of a second:
TPS_change = 10
TPS_rateofchange = (30 * 10) / 2 = 150
TPSdot = 150 / 10 = 15

I dont get why use a table with large values (basically TPSdot multiplied by 10) when it would be straightforward to use TPS_change in a range from 0 to 200 since it STILL is magnitude-versus-time.

Anyway, any range-related issues are easily bypassed: the main problem here is that arbitrary hardcoded filter under 2% TPS_change, I think it's what is preventing AE to help on tip-in.

Next week I will have some free time, I will try dusting off my (low) coding skills and customize the algorithm a little, and I will try to report back how it works.
User avatar
By pazi88
#58009
That 2% limit is bit stupid indeed. I don't think it's really needed and even change to 1% tps could need some ae in some engines. We already have the dotTPS limit that is adjustable to "filter out noise" or just limit of how small movement gets ae, so the hardcoded 2% is not needed.

But anyways the use of TPS% rate of change to define ae is there because it's easy to understand for tuners and it's how basically all other aftermarket ecus do ae (or have it option to do like that). Only like ancient ms1 megasquirt uses raw adc values for ae. And it's sometimes really confusing to tune, compared to 0-100% tps range. Yes the conversion is not needed, but it helps tuning. A lot.
User avatar
By iltheo84
#58012
pazi88 wrote: Thu Aug 04, 2022 6:30 pm Yes the conversion is not needed, but it helps tuning. A lot.
OK, I assume I do not find it useful because I'm a total noob at tuning :D

I edited corrections.ino to use TPS_change as the basis for AE, removed the hardcoded filter and added a very simple Tip-In Adder that adds another percentage if the previous TPS reading was zero.
Code: Select all
bool TPS_TipIn = false;
Code: Select all
else if(configPage2.aeMode == AE_MODE_TPS)                    // RAW TPS AE TEST
  {
    TPS_change = (currentStatus.TPS - currentStatus.TPSlast);   // TPS change rate
    if(currentStatus.TPSlast == 0) { TPS_TipIn = true; }        // Activate TipIn Adder
    else { TPS_TipIn = false; }
    if(TPS_change >= 0) { currentStatus.tpsDOT = TPS_change; }  // Positive TPSdot values only
    else { currentStatus.tpsDOT = 0; }                          
  }
Code: Select all
else if(configPage2.aeMode == AE_MODE_TPS)            // RAW TPS AE TEST
    {
      
        //If TAE isn't currently turned on, need to check whether it needs to be turned on
        if (currentStatus.tpsDOT > configPage2.taeThresh)
        {
          BIT_SET(currentStatus.engine, BIT_ENGINE_ACC);  //Mark acceleration enrichment as active.
          activateTPSDOT = currentStatus.tpsDOT;
          currentStatus.AEEndTime = micros_safe() + ((unsigned long)configPage2.aeTime * 10000); //Set the time in the future where the enrichment will be turned off. taeTime is stored as mS / 10, so multiply it by 100 to get it in uS
          accelValue = table2D_getValue(&taeTable, currentStatus.tpsDOT);

          if( TPS_TipIn )                                 // TIP-IN ADDER
          {
            accelValue += configPage2.maeThresh;          // We are using MAETHRESH to store the Tip-In Adder value
            TPS_TipIn = false;
          }

          //Apply the RPM taper to the above
As I wrote in the comments of the code, to avoid corrupting the data structures I quickly edited the .ini file and told TunerStudio to use the MAP-based AE Threshold to store the Tip-In Adder Value:

Image

The code does compile, we will see if it works :?
User avatar
By iltheo84
#58018
First tests and logs show some good results, the "new" table obviously needs some tuning but the engine feels a lot more smooth and responsive.

The Tip-In Adder might not be as useful as I thought, given that without the hardcoded filter the AE can now be fully configured as one needs.

I made sure not to modify the data structures, but I get some random errors while saving the configuration to the ECU in TunerStudio; I don't know if the issue is related to my firmware customization, I might revert back to standard firmware and just edit the code, without touching the TS part :?
User avatar
By iltheo84
#58428
I noticed that the hardcoded filter has been removed and replaced with a configurable value in a recent commit to the master branch (on Aug 30) :D

Hi, I am trying to assign Signed values to the x-a[…]

Vr Conditioner Noise when cranking

New version 202305 don't fix the issue. Now after[…]

blitzbox

I've finally figured out why MAP and Lambda weren'[…]

Hello, I bring news!! Let me tell you that after […]

Still can't find what you're looking for?