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.