Looking for DME BIN files

[johnb]

Sorry about that. My memory isn't what it used to be. I'm having hard time following the RPM axis structure. What cell does the 5E represent in your example? In the table I posts, the value in the table is 24 (decimal) for 4000 rpm at 14v. I'm not following how it gets to 4000? I guess that means there would need to be a 156 somewhere in order for 100 to be the overflow (since 100 * 40 = 4000). Just kind of lost.

Yeah it's hard to do it without taking notes. What confuses things is that the map locations that TunerPro seems to use start at the list of values. I have never used it but I suppose that's all people are usually interested in changing, so it makes sense. But to read the map from the raw .bin data, and get the axis values, you need to look at the real start of the map.

You only need to know this stuff if you want to double check the axis values. And even with this info, you still need to know how the units map to numbers the code in order to document it fully. With rpm it's easy, we know it's 1 unit=40rpm. The battery voltage one should be easy too, I'll look it up when I get a chance. The NTC temp is a bit more complicated (I'm working on it).

Every map begins with a memory location of some important variable. Dave W posted them earlier. The ones I know off the top of my head:

37 - rpm
49 - load
13 - engine coolant temp (NTC II)
11 - battery

This map begins at location 13DC, where we have 37 (rpm). The next byte is the length of the axis - C (12 decimal). The next 12 values are the rpm axis values as seen by the map read routine in the code. But they are not simply stored as values that we can make sense of. The routine starts at the far right and starts adding them to the value in RAM location 37h and stops when it gets an overflow. That's how it determines which rpm range to use. I used the first one it would add (5e) as my example.

If it's a 2d (1-axis) map then the next bytes after those 12 would be the actual values (the length varies of course but the length of the axis always matches the number of values). This one is a 3d map so after the 12 rpm values (in their obscure form) we have the same thing for the next variable - 11 (battery voltage location in RAM) followed by 7 ( there 7 voltage values on this axis). After that are the 84 actual values.

I think (from my earlier notes) that the dwell values are stored in angular units, since that's the only way the DME can measure it - it uses the number from the map as the number of flywheel teeth to count, hence the calculations I showed.

Does that help at all?

Screenshot_2025-09-10_16-40-26.png (39.74 KiB) Viewed 414 times

EDIT: just to add I had a quick look at the voltage reading, and it seems the DME supply voltage is divided by 3.5 before going to the ADC (which has a 5v reference). This should correspond to 1 unit in the code = 0.0686v.

[Tom]

Got it! Only machine language engineers could come up with that.

For the humans in the room, and to test (and document for posterity) my understanding, the BIN values in decimals reversed to read from left to right:

94, 31, 35, 39, 5, 16, 16, 4, 4, 4, 4, 3


And then if each entry were the sum of itself and all values to the left:

94, 125, 160, 199, 204, 220, 236, 240, 244, 248, 252, 255

And then if you subtracted those from 256, i.e., the first overflow value:

162, 131, 96, 57, 52, 36, 20, 16, 12, 8, 4, 1

Then that times 40 gives the table values:

6480, 5240, 3840, 2280, 2080, 1440, 800, 640, 480, 320, 160, 40

And based on the logic, that would mean a column is used if the rpms are at or above that column's number and below the next. In other words, the first column (shown as 40) is really for rpms from 40 to 159; and the 2280 column is really for RPMs from 2280 to 3839. I imagine the DME reports any meaningful movement as a 1, meaning 40 rpms, such that the first column applies to just about any movement up to 159 rpm? And the upper end must be 6480 up to 10,200 (255*40)?

If that's all correct (?), I'm trying to back into the voltages shown in those same xdf maps -- i.e., 6, 8, 10, 12, 14, 16, 16.4 using the same logic. The 7 entries in BIN order in dec are 29, 30, 29, 30, 29, 7, 14. The rightmost entry is 14 (0Eh), which would suggest the 255-14=241 equates to 16.4 volts. 16.4/241 = ~.06805 volts per count. But if you map the voltages used in that table (assuming they are correct) you don't get a slope of .06805, it's more like .0674 plus a fixed .0164... All of which makes me wonder if the same logic is applied to the volts...

[johnb]

Got it! Only machine language engineers could come up with that.

For the humans in the room, and to test (and document for posterity) my understanding, the BIN values in decimals reversed to read from left to right:

94, 31, 35, 39, 5, 16, 16, 4, 4, 4, 4, 3


And then if each entry were the sum of itself and all values to the left:

94, 125, 160, 199, 204, 220, 236, 240, 244, 248, 252, 255

And then if you subtracted those from 256, i.e., the first overflow value:

162, 131, 96, 57, 52, 36, 20, 16, 12, 8, 4, 1

Then that times 40 gives the table values:

6480, 5240, 3840, 2280, 2080, 1440, 800, 640, 480, 320, 160, 40

And based on the logic, that would mean a column is used if the rpms are at or above that column's number and below the next. In other words, the first column (shown as 40) is really for rpms from 40 to 159; and the 2280 column is really for RPMs from 2280 to 3839. I imagine the DME reports any meaningful movement as a 1, meaning 40 rpms, such that the first column applies to just about any movement up to 159 rpm? And the upper end must be 6480 up to 10,200 (255*40)?

If that's all correct (?), I'm trying to back into the voltages shown in those same xdf maps -- i.e., 6, 8, 10, 12, 14, 16, 16.4 using the same logic. The 7 entries in BIN order in dec are 29, 30, 29, 30, 29, 7, 14. The rightmost entry is 14 (0Eh), which would suggest the 255-14=241 equates to 16.4 volts. 16.4/241 = ~.06805 volts per count. But if you map the voltages used in that table (assuming they are correct) you don't get a slope of .06805, it's more like .0674 plus a fixed .0164... All of which makes me wonder if the same logic is applied to the volts...

Yeah that's it. Generally the DME doesn't directly use the value from the matching column - it calculates how far between the 2 columns the actual input value was, and then calculates the best possible in-between value, i.e. interpolation. For the endpoints, it works exactly as you said, i.e. all values up to the lowest one are treated the same and likewise for all values higher than the highest one.

There are a few maps that don't work this way but most do. This is partly why the overflow technique (weird as it is) is handy - the overflowed value is a measure of how far past the matching column the input was.

The voltage axis works the same way but maybe I made a mistake with the 0,0686 thing...that seemed to give me the right numbers but I'll double check later.

[Tom]

I hadn't seen your edit when I posted above. If the dme dvides by 3.5, then that would suggest an upper voltage of 5*3.5 of 17.5 and .0686 per step as you say. If the values are indeed .0686 and the actual voltage cut off are not clean as shown in the XDF. By my math, they'd be 5.97, 7.96, 10.02, 14.07, 16.06, 16.54 ??

That would make the XDF a fairly accurate rounding, expect for the last 16.4 entry.

[johnb]

I hadn't seen your edit when I posted above. If the dme dvides by 3.5, then that would suggest an upper voltage of 5*3.5 of 17.5 and .0686 per step as you say. If the values are indeed .0686 and the actual voltage cut off are not clean as shown in the XDF. By my math, they'd be 5.97, 7.96, 10.02, 14.07, 16.06, 16.54 ??

That would make the XDF a fairly accurate rounding, expect for the last 16.4 entry.

That looks right to me except you're missing something around 12v. With resistor tolerances and everything I doubt that the number I came up with is the right nominal value but anyway those look to be a near perfect match for the pic I posted earlier.

[Dave W.]

Once you understand how it works you can change it.
What do you think of these header numbers? This is from my Fuel and Timing maps. I rescaled the RPM and Load axis many years ago when I was tuning my hybrid stroker. The goal was to make it more linear and intuitive.

37 0E 05 06 07 08 09 0A 0A 0C 0D 0C 0F 10 11 5F
49 0C 07 07 0D 0D 0F 11 12 13 14 1F 26 26

[Tom]

Ok, thanks to your help, I think I have the dwell map sorted in the XDF. The one posted in the TunerPro database was off on multiples fronts. It had the RPMS and volts wrong, and was missing the first row of the table (it was 7 x 11). Here's the corrected version (I believe), showing the entire map (7 x 12) starting at 0x3F3. Looks like Dave W had figured this out already based on the map he posted previously, but I'll be sure to include this version in the XDF I plan to post once done. @FTECH9 had asked on RL about the dwell map posted in the TunerPro database in connection with his wasted spark project, and never got an answer in that thread, so I'm tagging him here in the event he's still looking for this info. When he tried to adjust the idle dwell times, using the idle rpm ranges shown in that XDF, he was really changing the dwell in the 160 to 320 rpm range, so no surprise it didn't work.

true dwell amp.jpeg (205.43 KiB) Viewed 384 times

[Tom]

Once you understand how it works you can change it.
What do you make of these header numbers? I rescaled the RPM and Load axis many years ago when I was tuning my hybrid stroker. The goal was to make it more linear and intuitive.

37 0E 05 06 07 08 09 0A 0A 0C 0D 0C 0F 10 11 5F
49 0C 07 07 0D 0D 0F 11 12 13 14 1F 26 26

Posted crossed, but see my post just now. Pretty sure I have the XDF pointing correctly at the entire table now, with the right column and row header values.

[Dave W.]

Once you understand how it works you can change it.
What do you make of these header numbers? I rescaled the RPM and Load axis many years ago when I was tuning my hybrid stroker. The goal was to make it more linear and intuitive.

37 0E 05 06 07 08 09 0A 0A 0C 0D 0C 0F 10 11 5F
49 0C 07 07 0D 0D 0F 11 12 13 14 1F 26 26

Posted crossed, but see my post just now. Pretty sure I have the XDF pointing correctly at the entire table now, with the right column and row header values.

I just edited my post for clarity. I posted my changes to the header info on the part throttle fuel and timing maps. IMHO the breakpoints on the stock RPM axis were very uneven. Perhaps the Porsche/Bosch engineers were following a best-fit curve?

[Tom]

Once you understand how it works you can change it.
What do you make of these header numbers? I rescaled the RPM and Load axis many years ago when I was tuning my hybrid stroker. The goal was to make it more linear and intuitive.

37 0E 05 06 07 08 09 0A 0A 0C 0D 0C 0F 10 11 5F
49 0C 07 07 0D 0D 0F 11 12 13 14 1F 26 26

Posted crossed, but see my post just now. Pretty sure I have the XDF pointing correctly at the entire table now, with the right column and row header values.

I just edited my post for clarity. I posted my changes to the header info on the part throttle fuel and timing maps. IMHO the breakpoints on the stock RPM axis were very uneven. Perhaps the Porsche/Bosch engineers were following a best-fit curve?

Yes, some of the break points are a mystery to me. I assume Bosch had its reasons, but I dunno... Did you find the need to adjust the part throttle maps? On my 3 liter, I scaled the FQS for the injectors and pressure, and the car felt factory perfect, so I haven't touched the part throttle fuel or timing. I just tuned the WOT maps for AFR and knock. I guess on a dyno, one could tune part throttle for and extra few horsepower, but using the wideband, knock counter and seat of the pants, I'm thinking I'm thinking it would be 50/50 whether I gain or lose power and/or street manners?