So, if I understand this right, you're trying to implement a system that uses both MAF readings and vehicle speed to improve afr accuracy?

Vehicle speed does not come into it. Engine speed does.

Speed density uses engine speed and manifold pressure to calculate (after compensating for temperature and volumetric efficiency) the mass of air flowing into an engine. The amount of air mass flowing in to the engine determines load (grams of air/rev) and thus everything that uses load as an input (fuelling, timing, AVCS, everything).

At the top end of the MAF scale, resolution gets poor and under forced induction conditions, can easily exceed the maximum figure (MAF sensor capped) - this leads to the ECU thinking that a certain amount of air is going in but really much more air is going into the engine => leans out under high load/RPM (bad).

Speed density gets rid of the resolution problem up high as well as the problem of having a capped MAF sensor.

Hey @ztan . I logged those params for the B01C. The param labeled "MAF_SD" is showing 2.37E-38 for the whole data log. I forget what that means. The other params show zero's.

If the RAM values in a log read anything other than 0 under any conditions, they have been modified at some stage by the ECU and I would not use them with a patch.

For B01C (are you using a stock ROM, or an OFT 2.xx ROM?), can you log the following to see if the addresses are clean?

I think I'm using a modded B01C ROM for LC and FFS and its not an OFT. FFF8D418 is clean for MAF_SD, the rest are showing data.

it doesnt matter which device flashed the rom its the code patch for lc\ffs thats the problem

I had a look at the file you sent me:

Last memory address referenced in A01G is FFF8D304 and in B01C is FFF8DC50.

Can you try logging FFF8DC80 and up in steps of 4? I suspect they will be clean.

I logged
FFF8DC80
FFF8DC84
FFF8DC88
FFF8DC8C
FFF8DC90
FFF8DC94
FFF8DC98
FFF8DC9C
FFF8DCA0
FFF8DCA4
FFF8DCA8
FFF8DCAC
All are clear and showing zero's like you said. How far up do you want me to go?

I've been thinking about this a little more.

Fuelling:

There is an engine load multiplier value in the ROM which is applied to engine load before the pulse widths are calculated for DI and PI systems - I wonder if we could just scale this value according to E% rather than adjusting each fuelling system seperately. Would need to do some testing.

Do there need to be different OL tables to interpolate between on the basis of E%? The primary OL fuelling additive gets added in progressively on the basis of IAM, and could be redefined to add on basis of E%

Cranking fuelling:

There is a ECT/RPM compensation table that is zeroed. That could be used as a ECT/E% compensation table.

Timing:
Base Timing A does not get used much - there is already code that interpolates between Base Timing A and Base Timing B based on a value (I am led to believe related to AVCS activity). This one would be quite easy to hijack.

E% sensor:
Where would you wire this into, and how would you deal with the dropped signal for that input?

Could be just me but I can't open the zip. Looks like it's corrupt.

"I used a straight RPM/MAP to mass flow conversion table rather than full VE conversion to simplify code."

What do I need to do to convert VE to g/s? I'll most likely do it in excel.
Another question. Is there anything stopping me running full SD? Ie. maf-less.

P.S. love your work. If you haven't seen the Aussie "86 Drivers Club" FB group jump on it. We love tech stuff.

It's not a .zip file - I just couldn't upload a .bin file. Delete the .zip from the end and it's all good.

You'll also need the .xml file additions in posts above, or I can send you my .xml (though it has been modified to how I think) and latest ROM including FlexFuel code.

You don't need any conversion - the table holds a mass flow value in g/s per RPM/MAP cell that gets input into the ECU instead of the MAF flow and the ECU does the conversion to g/rev - you can run full SD if you want, though there is quite a lot of variation at low load/RPM in the final SD value that I'm not sure would run smooth - probably anywhere above 40-60 g/s flow would run well.

If you do go MAFless, let us know how it goes.

I know I don't need a conversion, it's more that I'd like to do it. Rather than explain what I'm trying to do, here's a picture (numbers are garbage):
http://i539.photobucket.com/albums/f...psvblyvcxx.jpg

This seems like a common formula.
VE = (3456 x CFM) / (CID x RPM)

Though it doesn't take into account air temp or baro pressure. There's enough info out there (like this), it's just a matter of me finding the time to implement it.

The amount of harassment people get whenever they mention anything open source on facebook from ignorant Australian online super-heros that blindly follow their tuners and unquestionably swallow all the horse shit said tuners feed them, is astounding. I'd advise anyone in Australia to stay away from facebook groups as much as possible if they want to discuss anything tuning related, I know for a fact this group is one spoiled by these hateful minions.

This forum is a much better for tuning discussion where those people get banned and you can reach your audience of one or two people with their heads on straight, instead of facebook where there's thousands of useless fucktards whose sins are constantly removed and forgiven or rewarded due to the overwhelming mob mentality.

I suspect ztan knows this full well already though.

People don't get harassed in the 86 Drivers Club. It's all love and rainbows.