MS AFR target gauge doesn't match target table
 

I saw a thread on this who knows when, but now i can't find it.

In megatune, my AFR target gauge reads 13.83 but for all of the cells in my target table it's 14.7...

FWIW i've been wrestling with my MS for a while now, and just now I almost passed inspection.. i was only over on Hydrocarbons, 104 vs 100..

I'm trying to enable EGO correction so it 'fine tunes' on the spot during inspection, hopefully that extra little bit will get me through.. but for now, the EGO just tries to push the AFRs down to 13.83, no idea why.

-Tomaj

I ended up finding this thread: https://www.miataturbo.net/forum/t30502/ where the guy has pretty much the same issue as me, but there was no solution..

Has no-one else had this problem since?

-Tomaj

What kind of wideband do you have and what settings are you using in megatune?

i have an uego.. the AFRs show up correct on the AFR gauge, just not the 'target afr' gauge.

i did the instructions on switching from volts to AFR by making changes in the ini file etc... i'm very confused... What does the MS deal in ? Volts or AFRs? If volts, then i certainly understand where some problems could arise..

You're essentially entering AFRs into megatune, which i guess would convert them to volts, and send them to the MS. Then the MS will interpolate between those volts and spit then back out to the 'target afr' gauge which is then turned back into AFRs by megatune?

If the above is correct, then wouldn't there have to be two different formulas in use to switch between V and AFR, otherwise this issue woulnd't arise right? (In other words, use formula #1 to encode to volts, then formula #2 to decode for the tgarget afr gauge?)

From the "Super Important MegaSquirt Threads" sticky: https://www.miataturbo.net/forum/t28005/

Instructions on how to correct discrepancies between gauge and MT are in there too.


Internally, it deals in binary numbers from 00000000 to 11111111 (that's 0 to 255 in humanspeak), representing the output of an 8 bit analog to digital converter. At the user level, it can deal either directly in volts or in AFR units correlated to volts as per a couple of scaling factors that are shown in the above linked post.

Hello Joe, thanks for the info. I did follow the instructions in the link you just provided. My physical uego gauge matches the gauge in megatune. I haven't taken a picture to get a perfect still snapshot, but eyeballing it looks to be good.

Regarding my question on volts vs. afr, in retrospect it seems a little stupid, I am used to programming C# and PHP where we don't think in packing data into bits and bytes :(

so in short, i just want to clarify that the physical gauge and megatune agree... but megatune doesn't agree iwth itself, specifically the target table has all 14.7s in a given area, so you'd imagin interpolation between any two cells owuld allso yield 14.7... But no, on the target afr gauge in megatune, i see 13.83..

I don't mean to be a broken record but i think we're not talking about the same thing.

Heh. That's actually one of the things I love about reading assembly code. There's no mucking about with libraries and variables and all that complexity. You read a memory location, you get bits. You look at the bits, and you can see exactly what's going on in the hardware. Especially on the GPIO ports, where each bit corresponds to a physical pin. Wanna turn a pin on? Write a 1 into it. No muss, no fuss.

It makes reading the source code pretty easy, compared to the stuff for the MS2.



Ok, took me a minute to realize what you were talking about. I don't think I've ever used the "Target AFR" gauge in Megatune. I'd forgotten there was one until you mentioned it. :D

The AFRTarget gauge in MegaTune is based upon an 8 bit raw ADC number that the MS sends out as byte #25 of the realtime datastream. In this regard, it's like all of the other analog values- they come out of MS as raw ADC data, and MegaTune then decodes them into something meaningful. (This is done because it requires only one byte to be transmitted per variable, instead of four or five bytes each, allows the data to be interpreted in different ways (such as °F vs °C) and also places the burden of decoding the data out on the host PC which is much more powerful and not doing critically time-sensitive things like firing spark plugs.)


In C:\program files\megasquirt\MegaTune2.25\mtCfg there is a file called lambasensors.ini. In it, there are entries of several lines each for all the various predefined sensors. Here's the one for AEM_Linear:

#elif AEM_LINEAR
afr = { 9.72 + egoADC * 0.038666 }
lambda = { afr / 14.7 }
TargetAFR = { 9.72 + afrtarget * 0.038666 }
TargetLambda = { TargetAFR / 14.7

The first line (afr) scales MegaTune's interpretation of the actual AFR data (which, again, comes in as a raw 8 bit ADC value) and thus the AFR Target table, which MegaTune sends out to the MS as an array of raw 8 bit ADC values.

However, the TargetAFR line is the one which scales the incoming TargetAFR value that MT receives in the realtime stream from the MS, and thus drives the "Target AFR" gauge.

So, if you have made a change to the formula (either the 9.72 or the 0.038666) on the "afr" line, and yet you have not also made the exact same change to the "TargetAFR" line, then the AFR Target table that MT sends to the MS will be correct, however when the live data comes back from the MS into MT, it will be misinterpreted.

Check that.

(irrelevant posts deleted)

A bit of explanation is probably in order here as to how this whole thing works.

First off, understand how an A/D converter works. On the input side, it takes in an analog voltage and on the other side, it outputs a number from 0 to 255. As the voltage goes up, the number goes up. 0 represents the smallest possible input voltage (zero volts) and 255 represents the highest possible input voltage. Just what is the highest possible voltage? That gets a bit technical, but the short version is that the way the MegaSquirt is configured, the highest possible voltage is Vref, which is 5 volts. So 5 volts produces an output value of 255.

Now, we'll take the first line of an entry in lambasensors.ini as an example:

afr = { 9.72 + egoADC * 0.038666 }

See where it says egoADC? That's the 0-255 output of the ADC.

So let's say that we want to solve for 14.7:1, which assuming a default calibration on the AEM should be represented by 2.5 volts. Given that 2.5 volts is exactly halfway between 0 and 5 volts, the output of the ADC is going to be 128.

So, bearing in mind that the order of operations for arithmetic is that multiplication happens before addition, we have the following: AFR = 9.72 + (128 * 0.038666) which gives us a result of 14.67.

So, you put 2.5 volts into the MS on its AFR pin. It decodes that to a value of 128, and sends that value out to MegaTune, which then references the calibration, runs that equation, and produces an answer of 14.67, which rounds to 14.7, and that's what gets displayed on the gauge on your laptop.


The same thing happens in reverse when you send an AFR Target to the MS. Say you want to aim for 12:1 at a certain cell. Megatune flips the equation around so that it now reads:
egoADC = ((AFR - 9.72) / 0.03866)
It then solves for AFR = 12 to get a result of egoADC = 59. So it knows that in order to achieve a target of 12:1, it needs to aim for an ADC value of 59, and so that's what it sends out to the MS for whatever specific cell you happen to be in.


So, why the modifications to the equation? Well, it's not a perfect world. Calibrations can be off, resistor values can have variance, voltage drops occur, and ground offsets happen. The first number in that formula, 9.72, can be thought of as a linear offset. Increasing it shifts the whole table upwards, and decreasing it shifts the whole table downwards. So let's say that for whatever reason, all of your WBO2 readings are being shifted up by half a volt, with the result that the display in megatune always reads lean by about 0.9 relative to the gauge itself. 0.5v is about 23 on the ADC scale, so a 14.7:1 AFR would be interpreted as 151 on the ADC. If you change the 9.72 to 8.87, you will find that ADC = 151 now produces AFR = 14.7, which now makes MT agree with the AEM display.

Likewise, the 0.038666 sets the scale of the equation, or put visually, the slope of the graph. If your error is constant but non-linear, you'd change that part of the equation.

Etc.

hey Joe,

thanks for the very detailed explanation. I checked the file in my mtcfg directory, and unfortunately both the target and afr lines read the same. I did change the offset from 9.72 to 9.00, but they're both like that, and the multiplier hasn't been changed so that's not the issue..

Also, the situation is that the MS is trying to actually hit the 13.83 target AFR (or at least i think it is..) So -- given that -- it's probably not just a display issue within megatune, but rather that the MS is somehow misinterpreting where it should be going?

ORRRRRRR even better! what if the conversion from entering AFR into the target AFR table is incorrect, and what is sent down to the MS is actually 13.83 instead of 14.7??

I am going to double check your "howto" on switching from volts to AFR in megatune, to see if I did something wrong there.

-Tomaj

Is there any chance that within MegaTune config you have selected the wrong sensor?

http://img30.picoodle.com/img/img30/...am_686b39c.gif

hey, i checked, it's set to AEM_LINEAR

Joe,

Where's the formula that converts from the AFR target table to the ADC value (im guessing here) that is sent down to the MS when you burn the table?

I checked your howto, and i have this under AEM_LINEAR:
afrBins1 = array, U08, 0, [8x8], "AFR", 0.038666, 255.0, 10.0, 20.0, 1

so i see the .038666, but where's the "offset" added? If it's not taking into consideration my specific offset amount, wouldn't all AFRs be incorrectly calculated?

In other words, like you said above, a 14.7 AFR should be 2.50 volts.. but in MY specifc case lets say it's 2.3 volts or something... when I enter 14.7 into hte afr table, and it converts to the ADC value of 128, wouldn't that be an incorrect target?

-Tomaj

the manual for the AEM suggests 14.7:1 = 2.375v

since the AEM outputs 10-18.5:1 AFR @ 0-4.25v

I must ponder this.

I've always assumed that it was derived from the lambdasensors.ini, and had forgotten about the redundancy in the msns-extra.ini file's AFR Target Table config.

Research is needed.

Interesting.. so if it *IS* taken from the lambdasensors.ini, then I should really take my formula 9.00 + 0.038838683 * xyzabcdef and put that into excel and make a NEW lamdasensors.ini?

I assume then I will have to reflash the MS?

-Tomaj

OK so here's what i've figured out..

1) I made the following table by editing the relevant cells in the target afr table, then viewing result in the target afr gauge.

afr target gauge reading difference
10 9.15 0.85
11 10.12 0.88
12 11.13 0.87
13 12.13 0.87
14 13.14 0.86
15 14.14 0.86
16 15.15 0.85
17 16.15 0.85
18 17.16 0.84
19 18.13 0.87

More or less, we're looking at a 0.85 static shift in AFR..

2) As mentioend in a post above, i changed my AFR equiation in the lambdasensors.ini file to read 9.0 instead of 9.72 as the base value for both equations. If i set just hte target equation to 9.85 (adding the static shift amount), then the target gauge reads what I think it should read, i.e. the numbers that are in the cells. However, EGO correction still brings it down to 13.83, which means the MS clearly thinks that it belongs at 13.83...

I ended up putting the 9.85 back to 9.0, and adding the .85 shift to each of the cells in the target afr table. SO if it used to say 14.7, the cell would now say 15.55. This seemed to do the trick in that the GEGO corrects to 14.7 on the AEM WBo2 gauge.

Question is -- how the hell do i fix this so that the MS interprets the voltages correctly? I think i'm very close to figuring this out... it must be one of those flat tables which gets sent down to the MS during burning.. right??

i could just use excel (open office calc in my case) to calculate the new values, and then be done with it??