MalibuJack

iTrader: (5)

Anyway.. The point of my post..

There was a thread awhile back that Martin from AMS, Myself, and a few others were discussing something that felt like misfire, or fuel cut, or whatnot, and we thought it might have been something related to jumping off one of the maps.. This might be the map it was jumping out of.


The ECU internally doesn't use floating point math, everything is obviously represented as a word of data, and everything we are looking at has been "Scaled" to human readable form.. So this had been making this relationship difficult for me to comprehend.

In any case, I was/am able to reproduce the event by scaling my blowthrough sensor to read over 3000hz much lower than it would do it typically, and when it did, guess what happened? At around 2900hz I would get what felt like misfire/stumbling/fuel cut, now admittedly this is VERY VERY unscientific, and is likely not entirely accurate, but it does seem to fit into this information.

JohnBradley

iTrader: (30)

So if I am understanding this correctly that the g/s converts nicely to the observed limits of the stock MAF. 357.5 g/s * 6.29 = 2248.675. Would this be the ideal max of the stock MAF then, or have I misunderstood what youre saying? I am just trying to see how the relationship works as far as rescaling for a larger MAF (such as SVO, GM, Z32, etc.)

MalibuJack

iTrader: (5)

I haven't done any experiments on what it would take to alter it, since I haven't figured out the relationship of that value with how all the scaling (conversion) relates yet.

However, the ECU will handle values much higher, it just has to be scaled accordingly. Without scaling that MAF value, it'll still handle a higher value, it just all seems to conveniently fit together.

I've been using an aftermarket maf, but the great thing about the aftermarket MAF is I can get it to fit within the values I have to, and then tune accordingly. So it has not been necessary to do any sort of rescaling.

This would change should the ROM itself be modified to use a different type of MAF sensor (analog for instance) But that would also likely change those tables.

MalibuJack

iTrader: (5)

I don't think the 6.29 value is used directly with the MAF size value, I used it to convert the digital representation of 16356 (or whatever it was the last cell of the column) to a MAF reading, which seemed to correlate nicely with what Nick calculated earlier from his flow bench.

I got the number from the byte to MAF Hz MUT conversion from the DSM Disassembly project (and My Mitsulogger requestID.xml file) It just seemed to fit..

JohnBradley

iTrader: (30)

After I altered the scaling as you had, I noticed that the smoothing table (I think thats the one it was) showed a value of 237 at 1900 +/- and then tapered down to 232 by 2600. I guess its time to spring for ECU+ so I can do some more accurate logging than I have been.

awdgsx91