RomRaider

Hi - I'm tuning for a big turbo, Dom3XTR, and whilst I've been able to raise the Engine Load Limit A (Max) table above 4 (as I am definately exceeding 4 g/rev), I cannot raise the Engine Load Limit B (RPM) table values beyond 4 - and as a result, logging shows that I am capping out at 4 g/rev.

What am I missing - is 4 the maximum value which cannot be exceeded, or have I missed a dependency elsewhere? I've searched extensively, but cannot find a reason as to why this value cannot move beyond 4. Or will I need to 'hack' the injector scalar, and the entire MAF scale, down?

It's a '08 Sti, BTW.

Thanks

What's the table properties say?
Is it uint8 data with a formula that converts to a max hex value of 0xff ?
(I'm on the road so I can't check myself)

Hi, unfortunately I'm in a wholly different time zone (South Africa), hence the delay in response -

it's a uint16
Address: 0xc2d3c
Endian: Big

Here's a screen grab:



Thanks

I saw this on my LGT as well... It was just a quirk of the 2-byte load parameter, though.

The formula confirms 4 is the largest number you can save in the table in any cell.

Wow, that's good to know.

My LGT uses a float for the max load table, so it doesn't have the same limitation. I rescaled my injectors to get my peak loads below 4.0 anyways, just so that I can continue logging with the 2-byte load parameter...

But with the 08 STI, you probably run the risk of leaning out when load exceeds 4.0. You'll want to reduce your injector scaling by some percentage (10%, maybe 20%, whatever) and then re-scale the load axes by the same percentage, on all of the tables that have a load axis - fueling, timing, etc.

Thanks for confirming that - leaning out was exactly the problem that I was having. That's exactly the approach that I've taken - reduced the injection scalar by 15%, and correspondingly the MAF scale, busy with rescaling the load axis as well.

Thanks for the assistance, appreciated.

Very useful thread. Have the same problem. Now I'm good. Thanks.

Dale - I just had an idea, want to run it past you - the limitation on the table is the combination of it being a 2byte table, so a maximum of FFFF, and the multiplier being 0.000061035156, giving you a maximum of 4.

What if I just change the multiplier (and make sure that I'm using the corrected scaling in Romraider and Ecuflash)? That way I wouldn't need to hack the load axes (I'm beginning to think that my underscaling of the injector scaling that it could be a contributing source to low load hesitation / pulsing, due to AFR corrections swinging too wide).

Any likely issues from doing this? I wouldn't think so, as it's the multiplier specific to that table.

I was thinking the same thing just now when I was catching up on this thread. Now that we've had a bit more time to learn how tables work, it doesn't seem like such a big obstacle anymore.

I think it's worth trying. See if the code that calls Pull2D for this table also stores the result of the table lookup in RAM, so you can make a logger parameter for it, just as a sanity check. If the value in RAM tracks the numbers you put into into the table, then I think you've fixed it.

Yeah, I think I'll test it out using simsh, but I don't see it bring a problem. Just going to double the multiplier, and that gives me plenty headroom (as much as I'd love to, I don't think I'll be heading to 8 g/rev engine load anytime soon )

Awesome! Having run the code through simsh, I can confirm that by doubling the multiplier, 7.9998779 as opposed to 4, is loaded into FR1 as the engine load maximum B.

I highly recommend that people who have this problem like me in the '08's up rather change the table multiplier than 'hack' the load axes and lower the injector scalar artificially. I have always worried that whilst I have changed the key table axes (such as fueling, AVCS etc.) that I was aware of, there was probably a myriad of other tables that are significant, but not as yet defined, that were not being changed.

I will test drive this tomorrow, and give feedback on driveability. I suspect that this could be an important ingredient in crappy closed loop performance for those with 08's up who have upgraded to much larger injectors (I'm running 1200cc).

Also - if anybody wants, I'm happy to make definitions for this issue. I've defined this for myself in Ecuflash, very straighforward.

Aha, looks like OP is a man who has much time to do hacking.

Assuming the rom id is AZ1G202G(or AZ1G2021G), are you changing 0x38800000 to 0x39000000 at 8708c to fix it?

If you have enough time you may want to read my another post about realtime timing tune:

http://www.romraider.com/forum/viewtopic.php?f=25&t=6539

I was a C++ player, but I just have no enough time to learn java to integrate a realtime timing tool front end in romraider....

Yup, that's exactly it, works perfectly. Glad to hear that another hacker has the same ecu ID as me, handy

I'm out of town, but had a quick look through some of that thread looks exciting. I wish I had the ability to code Java at this stage, but unlike NSFW, Dale and others, I'm at a disadvantage - I'm not a coder, have been learning furiously about all this in the last 4/5 months...