Open source Hybrid Speed Density

[ztan]

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:

ROM:0002B0D6 loc_2B0D6:                              ; CODE XREF: sub_2B0A2+28j
ROM:0002B0D6                 mov.l   #off_10DF8, r2  ; Sub at 2B17E in A01C
ROM:0002B0D6                                         ; MAF:
ROM:0002B0D6                                         ; r13 = 08
ROM:0002B0D6                                         ; fr4=MAF_V
ROM:0002B0D8                 shll2   r6              ; r6=2 SHLL r6=8
ROM:0002B0DA                 mov     r6, r0          ; Move Data
ROM:0002B0DC                 mov.l   @(r0,r2), r4    ; r2=10df8
ROM:0002B0DC                                         ; r0,r2=10e00
ROM:0002B0DC                                         ; r4=b86e0
ROM:0002B0DC                                         ; A01C: r4=d0560
ROM:0002B0DE                 movi20  #Pull2D, r2     ; Pull2D at 11388
ROM:0002B0DE                                         ; A01C: 1139C
ROM:0002B0DE                                         ; MAF_G_S value returned in fr0
ROM:0002B0E2                 jsr/n   @R2 ; Pull2D  ; Jump to Subroutine with No delay slot
ROM:0002B0E4                 bra     loc_2B100       ; Branch
ROM:0002B0E6                 fmov    fr0, fr9        ; Floating-point move

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:

ROM:0002B0D6             ; ---------------------------------------------------------------------------
ROM:0002B0D6
ROM:0002B0D6             loc_2B0D6:                              ; CODE XREF: sub_2B0A2+28j
ROM:0002B0D6 D2 02                       mov.l   #h'B91B0, r2
ROM:0002B0D8 42 4B                       jsr/n   @R2 ; sub_B91B0
ROM:0002B0DA A0 11                       bra     loc_2B100
ROM:0002B0DC F9 0C                       fmov    fr0, fr9
ROM:0002B0DC             ; ---------------------------------------------------------------------------
ROM:0002B0DE FF FF                       .data.w h'FFFF
ROM:0002B0E0 00 0B 91 B0 off_2B0E0:      .data.l sub_B91B0       ; DATA XREF: sub_2B0A2:loc_2B0D6r
ROM:0002B0E4 FF FF FF FF                 .data.l h'FFFFFFFF

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:

ROM:000B91B0
ROM:000B91B0             ; =============== S U B R O U T I N E =======================================
ROM:000B91B0
ROM:000B91B0
ROM:000B91B0             sub_B91B0:                              ; CODE XREF: sub_2B0A2+36p
ROM:000B91B0                                                     ; DATA XREF: sub_2B0A2:off_2B0E0o
ROM:000B91B0 4F 22                       sts.l   pr, @-r15
ROM:000B91B2 02 10 0D F8                 movi20  #off_10DF8, r2
ROM:000B91B6 46 08                       shll2   r6
ROM:000B91B8 60 63                       mov     r6, r0
ROM:000B91BA 04 2E                       mov.l   @(r0,r2), r4
ROM:000B91BC 02 10 13 88                 movi20  #Pull2D, r2
ROM:000B91C0 42 4B                       jsr/n   @R2 ; Pull2D
ROM:000B91C2 60 D3                       mov     r13, r0
ROM:000B91C4 88 08                       cmp/eq  #8, r0
ROM:000B91C6 8B 39                       bf      Return

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.

ROM:000B91C8 D6 1E                       mov.l   #h'FFF8D400, r6
ROM:000B91CA F6 0A                       fmov.s  fr0, @r6
ROM:000B91CC D2 21                       mov.l   #h'FFF893EC, r2
ROM:000B91CE F5 28                       fmov.s  @R2, fr5
ROM:000B91D0 D2 21                       mov.l   #h'FFF87C60, r2
ROM:000B91D2 F4 28                       fmov.s  @R2, fr4
ROM:000B91D4 02 10 14 0C                 movi20  #Pull3D, r2
ROM:000B91D8 D4 25                       mov.l   #SD_to_MAF_table, r4 ; Pull3D
ROM:000B91DA 42 4B                       jsr/n   @R2 ; Pull3D
ROM:000B91DC D6 1A                       mov.l   #h'FFF8D404, r6
ROM:000B91DE F6 0A                       fmov.s  fr0, @r6
ROM:000B91E0 D2 1E                       mov.l   #h'FFF87C64, r2
ROM:000B91E2 F4 28                       fmov.s  @R2, fr4
ROM:000B91E4 D2 20                       mov.l   #h'43929333, r2
ROM:000B91E6 42 5A                       lds     r2, fpul
ROM:000B91E8 F2 0D                       fsts    fpul, fr2
ROM:000B91EA D2 20                       mov.l   #h'43889333, r2
ROM:000B91EC 42 5A                       lds     r2, fpul
ROM:000B91EE F1 0D                       fsts    fpul, fr1
ROM:000B91F0 F1 40                       fadd    fr4, fr1
ROM:000B91F2 F2 13                       fdiv    fr1, fr2
ROM:000B91F4 F0 22                       fmul    fr2, fr0
ROM:000B91F6 D6 15                       mov.l   #h'FFF8D408, r6
ROM:000B91F8 F6 0A                       fmov.s  fr0, @r6
ROM:000B91FA             SD_Blending:
ROM:000B91FA D2 12                       mov.l   #h'FFF8D400, r2
ROM:000B91FC F4 28                       fmov.s  @R2, fr4
ROM:000B91FE D2 18                       mov.l   #h'42200000, r2
ROM:000B9200 42 5A                       lds     r2, fpul
ROM:000B9202 F1 0D                       fsts    fpul, fr1
ROM:000B9204 F4 15                       fcmp/gt fr1, fr4
ROM:000B9206 89 01                       bt      MAF_over_Blend_MAF
ROM:000B9208 A0 10                       bra     Return_final_MAF_blended_SD_value
ROM:000B920A F9 4C                       fmov    fr4, fr9
ROM:000B920C             ; ---------------------------------------------------------------------------
ROM:000B920C
ROM:000B920C             MAF_over_Blend_MAF:                     ; CODE XREF: sub_B91B0+56j
ROM:000B920C D2 15                       mov.l   #h'43200000, r2
ROM:000B920E 42 5A                       lds     r2, fpul
ROM:000B9210 F2 0D                       fsts    fpul, fr2
ROM:000B9212 F4 25                       fcmp/gt fr2, fr4
ROM:000B9214 8B 01                       bf      MAF_blended
ROM:000B9216
ROM:000B9216             MAF_over_Blend_SD:
ROM:000B9216 A0 09                       bra     Return_final_MAF_blended_SD_value
ROM:000B9218 F9 0C                       fmov    fr0, fr9
ROM:000B921A             ; ---------------------------------------------------------------------------
ROM:000B921A
ROM:000B921A             MAF_blended:                            ; CODE XREF: sub_B91B0+64j
ROM:000B921A F5 2C                       fmov    fr2, fr5
ROM:000B921C F5 41                       fsub    fr4, fr5
ROM:000B921E F2 11                       fsub    fr1, fr2
ROM:000B9220 F5 23                       fdiv    fr2, fr5
ROM:000B9222 F2 9D                       fldi1   fr2
ROM:000B9224 F2 51                       fsub    fr5, fr2
ROM:000B9226 F4 52                       fmul    fr5, fr4
ROM:000B9228 F4 2E                       fmac    fr0, fr2, fr4
ROM:000B922A F9 4C                       fmov    fr4, fr9
ROM:000B922C
ROM:000B922C             Return_final_MAF_blended_SD_value:      ; CODE XREF: sub_B91B0+58j
ROM:000B922C                                                     ; sub_B91B0:MAF_over_Blend_SDj
ROM:000B922C D6 08                       mov.l   #h'FFF8D40C, r6 ; Send final MAF value to fff8d40c
ROM:000B922E F6 9A                       fmov.s  fr9, @r6

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:

ROM:000B9230
ROM:000B9230             Check_SD_Mode:
ROM:000B9230 90 07                       mov.w   #0, r0
ROM:000B9232 88 01                       cmp/eq  #1, r0
ROM:000B9234 F0 9C                       fmov    fr9, fr0
ROM:000B9236 89 01                       bt      Return          ; branch to return if SD_Mode = 01
ROM:000B9238
ROM:000B9238             Load_MAF_Sensor:
ROM:000B9238 D6 02                       mov.l   #h'FFF8D400, r6
ROM:000B923A F0 68                       fmov.s  @r6, fr0        ; return MAF sensor value in r0
ROM:000B923C
ROM:000B923C             Return:                                 ; CODE XREF: sub_B91B0+16j
ROM:000B923C                                                     ; sub_B91B0+86j
ROM:000B923C 4F 26                       lds.l   @r15+, pr
ROM:000B923E 00 0B                       rts
ROM:000B9240 F9 0C                       fmov    fr0, fr9
ROM:000B9240             ; End of function sub_B91B0
ROM:000B9240
ROM:000B9240             ; ---------------------------------------------------------------------------
ROM:000B9242 00 00       SD_Mode:        .data.w 0               ; DATA XREF: sub_B91B0:Check_SD_Moder
ROM:000B9244 FF F8 D4 00 MAF_Sensor:     .data.l h'FFF8D400      ; DATA XREF: sub_B91B0+18r
ROM:000B9244                                                     ; sub_B91B0:SD_Blendingr ...
ROM:000B9248 FF F8 D4 04 SD_Table:       .data.l h'FFF8D404      ; DATA XREF: sub_B91B0+2Cr
ROM:000B924C FF F8 D4 08 SD_Final:       .data.l h'FFF8D408      ; DATA XREF: sub_B91B0+46r
ROM:000B9250 FF F8 D4 0C SD_Blend:       .data.l h'FFF8D40C      ; DATA XREF: sub_B91B0+7Cr
ROM:000B9254 FF F8 93 EC RPM:            .data.l h'FFF893EC      ; DATA XREF: sub_B91B0+1Cr
ROM:000B9258 FF F8 7C 60 MAP:            .data.l h'FFF87C60      ; DATA XREF: sub_B91B0+20r
ROM:000B925C FF F8 7C 64 IAT:            .data.l h'FFF87C64      ; DATA XREF: sub_B91B0+30r
ROM:000B9230 42 F0 00 00 Blend_MAF:      .float 120.0            ; DATA XREF: sub_B91B0+4Er
ROM:000B9264 43 34 00 00 Blend_SD:       .float 180.0            ; DATA XREF: sub_B91B0:MAF_over_Blend_MAFr
ROM:000B9268 43 92 93 33 flt_B9268:      .float 293.14999        ; DATA XREF: sub_B91B0+34r
ROM:000B926C 43 88 93 33 flt_B926C:      .float 273.14999        ; DATA XREF: sub_B91B0+3Ar
ROM:000B9270 00 0B 92 80 SD_Table_address:.data.l SD_to_MAF_table ; DATA XREF: sub_B91B0+28r
ROM:000B9274 FF FF FF FF                 .data.l h'FFFFFFFF
ROM:000B9278 FF FF FF FF                 .data.l h'FFFFFFFF
ROM:000B927C FF FF FF FF dword_B927C:    .data.l h'FFFFFFFF      ; DATA XREF: sub_B91B0+2r
ROM:000B9280 00 18 00 17 SD_to_MAF_table:.data.l h'180017        ; DATA XREF: sub_B91B0+28o
ROM:000B9280                                                     ; ROM:SD_Table_addresso
ROM:000B9284 00 0B 92 A0 X_axis_Pressure:.data.l h'B92A0
ROM:000B9288 00 0B 93 00 Y_axis_RPM:     .data.l h'B9300
ROM:000B928C 00 0B 93 60 SD_data:        .data.l h'B9360
ROM:000B9290 08 00                       .data.w h'800
ROM:000B9292 00 00                       .data.w 0
ROM:000B9294 3C 00 00 00                 .float 0.0078125
ROM:000B9298 00 00 00 00                 .data.l dword_0

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:

<table name="Speed Density MAF" storageaddress="B9360">
      <table type="X Axis" storageaddress="B92A0" />
      <table type="Y Axis" storageaddress="B9300" />
    </table>
<table name="Speed Density Blend" storageaddress="B9260" />
<table name="Speed Density Mode" storageaddress="B9242" />

<table type="3D" name="Speed Density MAF" category="Speed Density" storagetype="uint16" endian="big" sizex="24" sizey="23" userlevel="4">
      <scaling units="Air Mass g/s" expression="x*.0078125" to_byte="x/.0078125" format="0.00" fineincrement=".5" coarseincrement="5" />
      <table type="X Axis" name="MAP" storagetype="float" endian="big" >
      <scaling units="kPa" expression="x*.133322368" to_byte="x/.133322368" format="0" fineincrement="1" coarseincrement="10" />
      </table>
      <table type="Y Axis" name="Engine Speed" storagetype="float" endian="big">
        <scaling units="RPM" expression="x" to_byte="x" format="0" fineincrement="100" coarseincrement="500" />
      </table>
      <description>Speed density 3D lookup: combined VE/R map</description>
    </table>
<table type="2D" name="Speed Density Blend" category="Speed Density" storagetype="float" endian="little" sizey="2" userlevel="4">
      <scaling units="MAF g/s" expression="x" to_byte="x" format="0.0" fineincrement="5" coarseincrement="10" />
      <table type="Static Y Axis" name="Mode Determination (MAF SD Blend)" sizey="2">
        <data>MAF Max/Blend Min</data>
        <data>Blend Max/SD Min</data>
      </table>
      <description>These are thresholds based on MAF - below the lower value, MAF is used; above the upper value, SD is used.  In between, a blend of MAF and SD is applied based on an interpolated figure.</description>
    </table>
    
<table type="Switch" name="Speed Density Mode" category="Speed Density" sizey="2">
      <description>Speed density switch: Test mode calculates all figures, applies MAF sensor reading, Speed Density mode applies blended speed density.</description>
      <state name="Test" data="00 00" />
      <state name="Speed Density" data="00 01" />
    </table>

Modified A01G file (delete the .zip to get the .bin file)

[ztan]

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.

[ztan]

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.

[Shiv@Openflash]

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

[ztan]

Originally Posted by Shiv@Openflash

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.

[Shiv@Openflash]

Originally Posted by ztan

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

[ztan]

Originally Posted by Shiv@Openflash

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?

[Shiv@Openflash]

Originally Posted by ztan

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!

[elBarto]

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.

[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

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.

[ztan]

Originally Posted by elBarto

I've also added your tables to Kodename47's definitions.

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.

[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

[steve99]

Originally Posted by ztan

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.

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.

[elBarto]

Originally Posted by ztan

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.

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

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.

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