Also, correct me if you guys found different but the high and low range on these tables are 0.000 to 2.032
0-1.999999991808 per DAMOS conversion, but the conversion you use, how many decimal places or rounding off determines what you will see in xdf. Hex is the only true value. Converted values may be marginally different in xdfs if everyone uses slightly different conversions, but FFFF is the real max (unsigned) no matter what decimal value it's converted to.
I originally set it to FFFF and saw 2.0. I got curious and extended the high range to 100 for the table and put arbitrary value in. I put a 5 in one of the cells , saved it and opened the table back up and it showed 2.032 (999A). We'll never run a value like this but i wanted to see what it would show. Perhaps you hex guys can educate.
Something went wrong if you're talking about that happening on divisor tables. If a 2 byte FFFF is converted to be equal to 1.9999, you coud put 1,000,000 or 5 in the xdf and it will max at FFFF value no matter how high the xdf limits are set. 999A = 2.032 would be a conversion of about 0.000051676. Correct factor on the divisor Z cells is 0.000030517578 or 0.000031 for short.
Conversion rounding output differences:
FFFF * 0.000030517578 = 1.999999991808
FFFF * 0.00003052 = 2.00015872
FFFF * 0.000031 = 2.031616
That last one would be 2.032 when limited to 3 places in TP, exactly what max hex would be and exactly what you said you saw. If the conversion in the definition you have is 0.000031, either the hex wasn't accurately displayed or you accidentally looked at a different cell/table, but the conversion value you was correct for FFFF.
Just depends who's defining and if they truncate/round early. For me, depends how lazy I am at the time and how big the XDF is getting. As you can see above, they're all FFFF, the converted value just slightly changes depending how far out it goes. For comparison purposes, the same yardstick should be used, but difference out to the hundredths or greater isn't going to make any real world difference on these. If the XDF were limited to 1-2 places displayed, the conversion place count is even less noticeable.@RSL, I figured out what i did. On the IJE0S and INA0S tables above, the conversion factor for the Z data is X*0.000030517578. On the IKM0S ROM attached above, the conversion factor in the defined tables is X*0.000031.
Im wondering if we should update the conversion factor for the IKM0S ROM....
Whats interesting about this is the 1M's did always spool much faster than other ROM's. This is probably one of the reasons. I need to look at it further
Edit, i pulled an IKM0S ROM and took a look at it. Definitely different.
Edit 2: I just realized RSL posted the picture of the 1m ROM already. Sorry for the double pic
Also, on a side note... be careful using these 1m values. The car will make 19+psi extremely quickly at lower RPM. You may run into a situation where the car will see knock due to the rapid onset of boost at really low rpm.
You can see why Im confused here. @all4bspinnin is saying that by using the 1M values the car will make 19+ psi extremely quickly.. whereas you’re saying regardless the values are maxed at spool. Who should I believe ?This table will not effect the spool speed at all since typically people have their wastegates operating at the WGDC ceiling during spool.
The cause of restricted boost targets at lower RPMs will be caused by volumetric efficiency tables. The 1M has lower values in the Boost Request Offset table which is probably what allows you to target more lower down. Same story with the other high output N54 bins.
@RSL, I figured out what i did. On the IJE0S and INA0S tables above, the conversion factor for the Z data is X*0.000030517578. On the IKM0S ROM attached above, the conversion factor in the defined tables is X*0.000031.
Im wondering if we should update the conversion factor for the IKM0S ROM to make it standard across all ROM's....
Ive attached a pic with the values with an updated conversion.
I've been lazy, but would save a lot of space and any conversion variation. I'll go back and do a find/replace on all multis at some point.Get the decimal places out of here and use X/32768![]()
I've been lazy, but would save a lot of space and any conversion variation. I'll go back and do a find/replace on all multis at some point.