Open source Hybrid Speed Density
 

Hybrid speed density implementation. This has worked for me; use at your own risk. Each SD table will need to be scaled individually for your own unique intake/FI/engine/AVCS/exhaust profile. I'm happy to share my work, but am not a software engineer, pro tuner, or automotive engineer.

My implementation works on the A01G ROM (not the OFT ones, as the ROM hole is used in the OFT ROMs with FFS/LC). Addresses I use are specific to this ROM - don't apply to yours if you don't know what you are doing. Someone who knows how to patch ROMS or use HEW properly may be able to use this info to develop more elegant code or incorprate into Merp's Merpmod work.

I have come up with the following SD implementation. The sensors on the 86/BRZ are read in batches, the subroutine which sends the MAF voltage to the 54x1 MAF sensor scaling table is clumped in with reading of other sensors (IAT, ECT, etc...). To find out how this was processed, I looked at the ROM using IDA and HEW tools - lots of info on the RomRaider site on how to use them from dschultz, merp, Td_d, NSFW and others.

Data on how our Renesas SH72531 works downloadable from their site: http://www.renesas.com/products/mpum...umentation.jsp

If you find this useful, please consider contributing back to open source tuning efforts by sharing your SD maps with data on your car as well as AVCS/VVT timing details as these affect VE significantly. I would prefer that this code is not incorporated into locked tunes.

Now to making the hack:
Finding the MAF lookup subroutine. Looking in the ROM for where the MAF sensor scaling table is addressed is the first step. The MAF table pointer is located at 0B86E0 which is in turn listed in a cluster of pointers at 010DF8. This last list is referenced in the subroutine at 02B0D6.

Looking at the stock subroutine at 2B0D6:
Tracing this back to a subroutine where the sensor data is originally polled (2AEF0), MAF sensor data is pulled when the value in register 13 (r13) = 0x08.

Because the sensor data is pulled in a batch, we need to put a hook into the subroutine. Unfortunately, the data is all indirectly referenced and you can't simply divert a subroutine by address just in case the address value is also referenced by another subroutine. My solution was to take out the block of code at 2B0D6 and move it into a ROM hole.

Replacement code at 2B0D6:
This jumps out to a hole in the ROM. I used B91B0 as it was just a bit beyond the normal program space in the ROM and has sufficient space for code and tables.

The next bit of code is essentially the original code from 2B0D6 which looks up all the values from the appropriate sensor tables then continues on to the speed density code if r13 = 08 and returns directly if not with the return value stored in fr0 and fr9:
I used 4 extra RAM spaces: FFF8D400-FFF8D40C. These were addresses a bit beyond the OBD return data in RAM and I verified that they were not used by logging the addresses with my Tactrix OP2 and verifying that they were never used over a few days. They may or may not work for you...

The next section operates in the following way:
MAF sensor data from the MAF sensor scaling table written to FFF8D400.
SD data (in g/s) looked up from a 3D table using MAP as an x-axis and RPM as a y-axis, stored in FFF8D404.
I used a straight RPM/MAP to mass flow conversion table rather than full VE conversion to simplify code.
SD data (in g/s) compensated for IAT and stored in FFF8D408.
MAF sensor checked against 2 thresholds and stored in FFF8D40C:
100% MAF applied below threshold A
100% SD applied below threshold B
a Blend of MAF and SD between the values based on how far between the thresholds the sensor value is.

The ROM value at 9B242 is then checked. If that does not equal 1, we assume test mode is being run and the MAF sensor value is returned to the program. If the value is 1, SD is active and the value returned is the final value stored in FFF8D40C:

You can run this code and log all the addresses between FFF8D400-FFF8D40C in test mode to build your own SD map based on MAF voltages up to 5V and make sure that your values are sane before applying them in real life. SD map values over 5V MAF sensor limit will need to be scaled by looking at AFR error in your logs with respect to a table scale. I've got some MatLab scripts available to help with SD table building which normalize MAF sensor data with closed loop trims and open loop AFR error data to 20 Celcius before calculating a new table. PM me if interested in collaborating.

RomRaider def additions:
Modified A01G file (delete the .zip to get the .bin file)

Early test with low threshold set at 40, high threshold set at 160, best guess figures based on data from Bill from Delicious Tunings SD thread.

First plot is MAF sensor (FFF8D400) vs raw table output (FFF8D404). Values a bit high between 100-225 g/s.

Second plot is MAF sensor vs value compensated for IAT (FFF8D408). Slightly better, but still a bit high between 125-200 g/s and low over 200 g/s.

Third plot is the value for hybrid blended MAF (FFF8D40C). You can see the interpolation working over 40g/s but due to the errors low in the range for this map, would be better having a low threshold at 120 or 160.

This is done in test mode so final figure can be logged and SD map built without actually applying it.

Using a SD Map building script, thresholds are settable for how many data points are needed per MAP/RPM cell to make sure data is not highly skewed:

First plot is MAF sensor data which has been put into MAP/RPM bins and nomalized to 20 degrees Celsius based on IAT sensor data.

Second and third plots are closed loop and open loop trims respectively.

Last plot is final SD map values having applied an average of the CL and OL trims. Due to the nature of logged data, some of the values will not make sense and need to be discarded.

Awesome work ztan! Any plans to work on open source flexfuel code?

Not yet, availability not so good where I live, and I'd probably to full time E85 rather than flexfuel if I did.

However, what I would anticipate being needed:

E% read

Hooks being put into port injector scaling, GDI pressure multiplier, timing table, and fuel table reads.

Interpolatation between normal gas and E85 tables for all the above.

Means to compensate for cranking fuelling based on E% - probably a simple multiplier rather than interpolating all the tables.

If there is anything I can do to assist with your flexfuel code, let me know. I'm sure others would be equally thrilled by your work :)

What would you recommendations be for scaling fuelling and timing against E%? Are the relationships linear, or would there be a more complex relationship requiring more than one set of tables to interpolate against?

For example, can we just use one table for E0 and one for E85 and interpolate (linear or otherwise) timing for E20 at all load/RPM cells, or would we need to look up in a 3D matrix of E%/load/RPM for timing?

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.

This is exciting stuff! Your a huge resource ztan!

I love these open-source projects. Really shows what these ECU's are capable off.
I'm very interested in seeing your further developments.
Keep up the good work ztan :)

I've also added your tables to Kodename47's definitions.
If anyone wants to open up your rom in RomRaider.
Download them Here.
Too bad I don't know anything about programming or tuning.

Had a quick look in IDA.

Base Timing B and Pressure multipliers are easier: they only get looked up once directly.

PI Injector Flow Scaling is more complex, as it gets referenced quite a few times in different subroutines. Possibly the way to get around that is to change all the flow scaling references to point to a RAM address for scaling and make subroutine to store the PI flow scaling calculation to RAM at the end of a GDI scaling or timing interpolation routine.

The tables will only work on the modified A01G_SD Stock (not OFT at this stage) ROM that I uploaded above or if you've gone through and patched your own ROM with a .hex editor after verifying the appropriate ROM and RAM holes.

Please do not apply tables to different ROM calibrations especially if the tables don't look like they make sense.

I would also highly recommend that you log all the new RAM variables in test mode and build your own SD map for your own car and AVCS settings before touching the real life switch.

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

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

For the cranking pulse widths their is a table for cranking pulse widths vs temperature.
It looks like it could be rescaled to be more usefull. Then a simple multiplier applied to that table based on ethanol percent, should be easier than adjusting the whole set of cranking pulse tables.

Yes, I know. I just made them to open your rom. It's not meant to be used with the OFT OTS tunes.

This is the point where my knowledge stops, I only have an OFT, no tactrix. Would love to try it though.

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.

thanks a lot , @ztan.

I apply this to my car today. and it works great . (Korea 6MT A01E rom )

Left graph is Air g/s from MAP sensor by ztan's SD method,

and Right one is Air g/s from existing maf sensor.

less variance , smoother line.

I will install forged short block next month, and crank up boost slightly,

and this SD will help me alot.

I think no one cares about SD tuning with OFT platform now .

but it works flawlessly !

this is my final SD table & log of WOT 3-4-5 gear.

stock motor
SBD500x
DW450 injector


https://datazap.me/u/yobiwan/sbd-v58...zoom=2239-2474

That's great Yobiwan,
is it a pure SD so? or hybrid?

I hate SD on ecutek, the volumetric efficiency table is annoying to tune, and that SD MAF table you have would be a lot better


a little off topic, i see you keep -0,5 of minimum pull timing for flkc and knock correction
Do you think is safe enough?
i tend to keep -0,7 minimum for NA, and -1,05 for FI

yes , it's hybrid SD that ztan made above.

under 120g/s 100% MAF
120~200g/s MAF + SD blending
above 200g/s 100% SD

this SDMAF table is very easy to tune. almost same as MAF scale.
boost , AFR , Command AFR WOT log are all that needed for scale.
We can ignore under 120g/s area because MAF will cover that area.

It's 100% street car. and I set fine correction retard value at -0.5 after turbo installation.
so -0.5 flkc is minimum value.
I pull timing when any flkc is on 3rd gear WOT or -1 FLKC on any gear WOT.

Really?? I think the EcuTek VE table is rather simple as it works in VE % rather than a MAF translation. The calculations you need to tune it are no different to those you would need for the table above.

It's more like the sort of tables you would find on an aftermarket ECU, so most tuners are used to those....

you know what, kodename... i tune using a lot your maf scaling tool :)) now i'm supposed to thank you, and I do
and i haven t found a way yet to import the SD VE map to your tool from ecutek :)
So when I use SD i manually adjust the VE table and the result is always kinda sloppy specially under 0.9 of manifold pressure (for NA, in this example) and it takes so much time

an SD MAF like ztan's one just seems more familiar to me sorry

With ecutek SD try enabling full time closed loop fueling, then observe the closed loop fuel correction in the area if its positive add that percent to the SD VE table if it negitive subtract. Ie use the cl correction like you would with ltft correcting maf scale


Assuming your injector scaling is correct and your 02 sensor is rescaled to read rich enough

i already do this way, actually if you enable CL fuel correction all the time even at low engine loads, you would need to zero Af#1 correction or the STFT works against it and it become an impossible mess... anyway it s just time consuming the correction of the sd ve map
Any easy method to import SD VE table from ecutek to the maf scaling tool of vgi and kodename?
when i paste it it just gives error

Yes when. Suabaru closed loop and ecutek closed loop on togeather they tend to fight with each other, usually set ecutek closed loop like @Tor to bot work till 0.7 load

i prefer 0.9 with hysteresis of 0.1, with 0.7 i had moments in closed loop with stft working and CL ecutek fighting against it

I don't know what is causing the error on the SD tab, I haven't tried it for a while - have you downloaded a more up-to-date version as I know Vgi occasionally updates it for bu fixed?

I do all these calculations manually by adding in a coupe of manually calculated columns (dV/dt and error %) and then use the Log Stats tab to give me the error outputs and a spreadsheet to make the changes. That way I have more control over some of these outputs using the filters than the default tabs allow.

Actually, I am, but I have yet to completely figure out how to implement it, I don't suppose you'd be willing to assist me?

Right now I am being held back by the limitations of not having sd, so :respekt:

FYI my rom is a01d us auto