NefMoto

For those running this fueling strategy, have you modified the X (load) axis?  I have a few cars that I did edit this on, scaled it to where the last column was 191 as opposed to 140.  Some of these vehicles exhibit wavy power once into full boost and higher rpms.  The requested AFR stays solid but there is a faint, but noticeable fluctuation in power that you can feel in the seat.  This isnt picked up in logs of timing, boost, throttle or really anything else that I can see.  It is obviously detectable when acceleration Gs are calculated.  When I edit the axis to stock values this issue goes away.  On cars with the edit that dont hit over 191 load this doesnt happen, so it leads me to believe on cars that do it travels to the next cell.

Onto my actual question, do we have this map wrong?  The map is 6x6, yet it seems the axis data being used is larger when you look at it by itself.  I referenced PRJs autogenerated xdf and this axis is listed as SRL12ESUB, which may be wrong but is irrelevant to this question.  That axis is shown as significantly larger.

If you expand the map by 2 columns and make it 6x8 it seems to make sense.  I have attached some more shots to show what the maps that have issues look like when the axis is expanded to show what we normally dont see.

Can someone with more knowledge shed some light on this?

The axis is SRL06GKUB and it's referenced at 0x18291. The length for the lookup is 6.

So you are saying, when you disassemble, it only calls for 6 cells in reference to kflamkrl?  Any ideas on why there are tangible numbers before and after the section we use?  Is this axis used by another map that uses the rest of it?  If so that could explain the strange behavior when it is edited.

Directly before it is a 4 byte rl axis and directly after it is a 6 byte rl axis.

The axis is shared by KFLAMKRL, KFLAMKR, and KFLAFWL.

Sorry but now I am even more confused, because kflamkr and kflamkrl have different values in that axis, so they arent shared from where i am sitting.  The addresses I have are different, yet the same in every XDF I can find and discussion on this subject.  I am using a widely used XDF from Nyet.

These are what I have for the axis addresses:
KFLAMKR - 0x18292

KFLAMKRL - 0x100F6

If I am reading what you are saying right, and believing you (I always do, fwiw) then everyone has their knock based fueling set up wrong.

Uh. Ya. If my map pack is wrong, it would be good to know.

The more I look at it, its wrong.  Would also explain why when I edit that axis the fueling still works as expected (since im not even actually editing the associated one) but I get other ghost in the machine type behavior from whatever that axis i am editing does do.  I doubt many people felt the need to change it so they likely never felt it.

If you were wrong, dont feel bad, every reference until now has been the same.  I found the addresses long ago when we all first started down this path in a post from tony.  For all i know I shared that and it became standard.

Confirmed my previous statement. They all share SRL06GKUB at 0x18292.

0x100F6 is part of SRL12ESUB which begins at 0x100F2 and is used in KFFWLW and KFWLHO.

This explains a lot.  Thanks Phila as always your a big help.  I will makes some changes and report back.

I wonder if im the only one who bothered to change that axis, thus no one else ever felt the dips in power delivery and never started tracking it down.

All major Mbox XDF versions out there as of now are defined incorrectly on KFLAMKRL from what I can gather so I am glad I had this issue.

I defined these in the M-box myself using the R-box, I already had the right addresses :P

Uh. Can somebody confirm that my latest xdf is ok :/

Actually...

the ddillenger map pack i have is wrong, the one you posted here last year  ;D  Every single definition I can find has this error, all the way back to before the functions discovery.  There is only one mention until now of the correct address and that is by tony in an xdf thread.  Its the post I was thinking of, but I had referenced it at the time for the conversion factors only, over looking the addresses.

some notes about how this happened... 

when we all stumbled upon this stuff in early 2012, berttos was the first to ever post a definition with it, titled 8D0907551M-valentinesDay.xdf and this one is is what started it, not sure where he got the address but I have a .kp file that is also off and i believe its one of the oldest ones we have kicked around, I think most of us have referenced these M and G box ols files for stuff. Additionally, phila posted a screen grab of his maps here http://nefariousmotorsports.com/forum/index.php?topic=141.msg15920#msg15920 that somehow had the bad info, at the same time, possibly from that VD xdf.  This screen grab is what many of us used in the process of defining our maps and spot checking data that should be displayed, so it never got questioned.

How ironic is it that I randomly had this annoy me enough to dig into and discovered what was up exactly two years later because the same guy had the right info.  Only realizing this cause berttos labled his xdf that way.  Regardless, this axis change fixed the issue.  I dont even understand what that axis change was doing, it was so slight it was hard to even detect.

Thanks for the help Phila!  Makes me wonder what else we have wrong.

The auto generated XDF's are wrong on many occasions.
They were just done using an algorithm that uses heuristics to locate maps based on a similar other binary.

They are there to save time, and help to locate maps quickly. I would just copy-paste the found stuff into a different project, but please never blindly use them - just as a word of warning.

Back when I used TP, I just modded the xdf everyone was using. Once I made the transition into OLS I started doing my own defining. Now, I won't even use someone elses, I would just be constantly questioning if everything was correct.

Well yours was still technically right.  It doesnt have kflamkrl defined at all, so it doesnt have it incorrect.

Exactly, I define from scratch or confirm all of my definitions prior to implentation.

Good to know all those smart people didn't bother to let me know the mappacks I've been diligently maintaining for the benefit of everybody (and not just myself) are wrong. Big ups to SnowTrooper for giving a shit.

Some of us are not skilled in finding maps, defining maps, confirming maps, finding axis data, confirming axis data, disassembly, assembly, code injection or even looking at HEX...

So as much as I would like to build my own definitions, I literally don't know how, I put a lot of faith in what I am willing to bet 99% of users use.  One time I was so proud of myself because I stared at hex long enough to figure out where some native LC maps where on a less than common file.

Sorry Nye, I didn't realize yours were wrong until I read this thread and confirmed mine were right :(

You know I'd have fixed it.

You're not the guy claiming to be smarter than Jesus.

Wait. is Jesus the right comparee for this?

Is comparee even a word?

No, it would be God.  He was all knowing.  Jesus was just a dude with a beard and long hair who got in over his head apparently.

Just picture me, but instead of a cross, its just 0s and 1s and stuff.

I'm not claiming to be anything if you're referring to me and I posted this a few years ago also.

http://nefariousmotorsports.com/forum/index.php?topic=2547.msg24507#msg24507

Sorry for not putting out a PSA, but I don't have time to search out and create a thread for all of the definition errors floating around.

My point was the same as PRJ's, DD's, and the same that you've preaching for years, trust nothing you get off the internet.

I'm not sure why your trying to crucify me for helping.

Phila:

I don't think Nye was addressing anyone in particular.

Just venting frustration. Ignore me, been a bad week.

I'm just glad we figured it out.  Maybe a note in the wiki is in order.

Will be updating my definitions. Good find.

well, oddly, only one of TWO KFLAMKRL tables in my map def were wrong... I have two because one is lambda and one is AFR.

G-box KFLAMKR KFLAMKRL seems to use torque instead of load

wrong pic

How to convert AFR values?

They aren't AFR to begin with.

I do not get a value AFR.

What conversion do?

*14.7

One more time: NOTHING THERE IS AFR RELATED WHATSOEVER.

You can't multiply and add multiple AFR values and expect the result to make sense. You don't seem to understand how the knock enrichment path works at all :/