NefMoto

Has anyone else noticed that mrfa input wraps around to 0% column in LAMFA?

I've noticed that if my 0% column is set to 1 then when mrfa reaches ~95% it returns 1.

If I set 0% column to .8 then mfra > 95% it returns .8

Anyone else?

My axis is 50-100 in increments of 10 and behaves normally.

Why have a zero column?

Axis was screwed in stock bin. I'll try non zero first column and see if behavior persists.

Thanks,
Rey

for driver requested the FR sugests no zero row.

I use a zero row but have experienced no issues.

Row 1 is 0 not 50

Nick

No, stock axis is 0.5-1.0, which is probably a typo.

The correct "stock" values should be 50-100.

Stock should be 0   ;)

change your 50 row to .85 then log lambda.

I alway thought it was 50 until it started to use ols300, and now use 0

Nick

or another way to put it is 50 will = 0

but the correct way to read it in the map is 50 to 100

maybe I am confusing,  lol

hmm. can you explain your reasoning? granted, mine is pretty half assed, i just assumed the typo is an off by 100x thing (% vs correction factor)

In map packs it seems the scale 50-99% is correct but I alway thought LAMFA lambda would start at 50%, but when using live logging linked with OLS300 on 1.8T maps, I found the first row 50 is being used as a look up for idle conditions, and during coast off throttle its being read from.   

I will try and make a youtube video of what I have been seeing.


I have not logged direct mrfa_w to see what its reading a idle.

I thought a lot about this weird lamfa configuration.

The point in stock files having axis values of 0.5 to 1.0 is, that it does not matter. This is because stock they are set to 1.0 Lambda.

So if driver requested  torque is over 1.0%, Lamfa value is used from the last coloumn wich is always 1.0.

Only if you want to change your Lambda / AFR in req tq areas higher 1.0%, you have to change the values for 1% coloumn.

Example:

So i you want to have Lambda from 50% to WOT at 0.75, you only have to set the last coloumn to 50.00 and the map values of this coloumn to 0.75...
Lambda will follow the last coloumn of lamfa from 50% on to WOT..
 

Yes, that is because 50 really means 50 and below.

I.e. you don't want it to behave differently between 0 and 50, then once it is >50, interpolate between the 50 line and the next one

If mrfa is <=50, always use the 50 line.

All lookups work this way.

All I can say is when my first column = 0%, WOT = first column values. I'll post logs of this behavior. I confirm it by changing lambda for first row and WOT lamfa reflected my new values. But it was a small margin that was affected. ~>96% is where it would jump back to using first column.

Logs to come.

make sure you log mrfa :)

I did.

ARGH sorry i accidentially edited a post that wasn't mine again :/
somebody needs to move that button away from the quote area :/

I'm so sorry, it doesn't keep a record of the original post

-nye

png export from ecuxplot please..

or at least the raw .csv :)

raw csv and screenshot from similar file.

(http://creativeion.com/rey/vw/help/first_col_lamfa.gif)

So this is with mrfa axis data 0-100 or 0-1.0?

Perhaps some sort of fencepost/sign error.

Could be an actual bug in the code?

My map factor is 0-100% but let me see what the actual hex values are.

I guess decimal values would make more sense:

stock MFRA axis HiLo:

0
16589
19507
29594
31089
32000

What I see via map scale of 0.003052

stock:

0.0000
50.6296
59.5354
90.3209
94.8836
97.6640

I see that stock is 0xa4 - 0x148 (0.5 - 1.001) in mbox

or are we talkign about a differnent box?

also, it should be LoHi (little endian)

log filename says it, 032HS

Ah. No wonder. Don't know anything about that ecu :/

Same here but the other way around... aint got a clue about the S4 ecu lol

I might have an idea. I had some confusion with defining LAMFA correctly as well, especially since it seemed misdefined in one of the DAMOS floating around.

I will use the 2.7 K-Box for this example.

Here is the data for the LAMFA table:
0F 06 19 4B 4F 52 55 58 5E 61 64 6B 71 7D 84 8A
96 00 A4 00 C3 00 E4 00 05 01 26 01 48 01 80 80
80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
80 80 80 80 80 80 80 80

Okay, so the first two numbers in red are the axis lengths. The first axis is 0F or 15 data points. This is the RPM axis, highlighted in blue.
The second axis is the mrfa_w axis, which is six 16 bit data points highlighted in purple.
The map starts after that, and is highlighted in green.

Now comes the interesting part, and I think this is where you could be going wrong.
After the 1st axis, there is a "00". This is not part of anything, perhaps it was there to simply accommodate a 16th value, or perhaps it is used for something else I don't know. I have seen this defined wrong, so that the axis was set to LSB first, and the map was being moved 1 cell as well.

Let's see what happens when the map is defined correctly in TunerPro:
(http://gm.mainframe.no/stuff/correct.png)

And what happens if you define it incorrectly:
(http://gm.mainframe.no/stuff/incorrect.png)

One of the DAMOSes I had actually had it incorrectly defined. This was so confusing, that I had no other choice than to look at the code.
In my file this segment starts at 0x1CAC8, so:
0x1CAC8 - nmot axis length
0x1CAC9 - mrfa_w axis length
0x1CACA - nmot axis
0x1CADA - mrfa_w axis
0x1CAE6 - map values

This is confirmed by the code:
(http://gm.mainframe.no/stuff/lamfacode.png)

You can see how mrfa_w and nmot are loaded as arguments.
Then the map location is loaded - 0x1CAE6, not 0x1CAE5!
After that the nmot axis location is loaded, followed by the length - LAMFA_RPM_AXIS_LEN is 0x1CAC8 (or 0x81CAC8).
And now the mrfa_w axis is loaded the same way, by first loading the location and then the length of the axis.
Finally the map reading function is called.

Make 100% sure that you have this defined correctly, because if you don't, this is the behaviour you would get. Don't trust the DAMOS, trust the code.

Yes, I've said this several times, there are a LOT of bad damos files around with unaligned axis addresses.

If you EVER see a location that isn't 16-bit aligned (especially if the data is 16-bit), you know something is wrong.

The error, in this case, is the m-box, where LAMFA is *disabled* AND the axis data is wrong (yes, I have the correct offset).

The data is off by a factor of 100.

See for yourself. Get an mbox, and look at 0x1C382 (6x1, LoHi, 16-bit)

 http://nefariousmotorsports.com/forum/index.php/topic,141.msg9068.html#msg9068

No, I know that.
But you know, the way OP was pointing out that his stuff "wraps around" made me think that this could be exactly his problem.
Anyway, since I know where the table is read in the code now, I can now locate LAMFA correctly on any ME7 ECU :)

I realised something was up with the damos when it was defined as 16bit HiLo!

I'll take a look at the hex for that specifically. Thanks!!! The only difference I see is that I was getting a LAMFA of 1 @ WOT. Your example maps wouldn't do that. I see <1 values.