Open source Hybrid Speed Density

[xxBrun0xx]

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?

[ztan]

Originally Posted by xxBrun0xx

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.

[D-VO]

Originally Posted by ztan

Other ROM calibration users (A02C, A00C, A01C, B01C...) who are interested:

Can you log the following RAM addresses and let us know if they are actively used in your car (should log 0 for all values under all conditions if not):

paramname = MAF_Sensor
paramid = 0xFFF8D400
isfloat = 1

paramname = MAF_SD_Raw
paramid = 0xFFF8D404
isfloat = 1

paramname = MAF_SD
paramid = 0xFFF8D408
isfloat = 1

paramname = MAF_Final
paramid = 0xFFF8D40C
isfloat = 1

If the RAM hole is consistent across all existing calibration IDs, this and future hacks may be easier to run across different calibration ID's

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.

[ztan]

Originally Posted by D-VO

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?

paramname = MAF_Sensor 
paramid = 0xFFF8D410 
isfloat = 1  

paramname = MAF_SD_Raw
paramid = 0xFFF8D414
isfloat = 1

paramname = MAF_SD
paramid = 0xFFF8D418
isfloat = 1  

paramname = MAF_Final
paramid = 0xFFF8D41C
isfloat = 1

[D-VO]

Originally Posted by ztan

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?

paramname = MAF_Sensor 
paramid = 0xFFF8D410 
isfloat = 1  

paramname = MAF_SD_Raw
paramid = 0xFFF8D414
isfloat = 1

paramname = MAF_SD
paramid = 0xFFF8D418
isfloat = 1  

paramname = MAF_Final
paramid = 0xFFF8D41C
isfloat = 1

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.

[steve99]

Originally Posted by D-VO

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

[ztan]

Originally Posted by D-VO

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.

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.

[D-VO]

Originally Posted by ztan

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?

[ztan]

Originally Posted by Shiv@Openflash

I think keeping Ethanol scalars linear will work out fine. Conceptually, we just need to establish the max (E85) and min range (E10) and allow the feedback from the Ethanol sensor to slide between the two ranges. We would need to define these 2 ranges for the following tables:

-Injector Flow Scaling
-Base Timing B
-GDI pressure multipier A
-GDI pressure multipier B

There are also some other tables that would benefit from this approach (cranking and individual cylinder ignition trims for instance) but I think we may be able to compensate for that some other ways.

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?

[86drift]

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.

Originally Posted by ztan

...Modified A01G file (truncate the .zip for the .bin file)

[ztan]

Originally Posted by 86drift

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.

[86drift]

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):


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.

Originally Posted by ztan

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.

[Wayno]

Originally Posted by 86drift

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

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.

[86drift]

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

Originally Posted by Wayno

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.