Looking for DME BIN files

[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?

AHA! There it is! I couldn't find the button to attach a screenshot.
This is my modified Timing map. You can see how I changed the header values to expand the Load range and make the RPM breakpoints more linear, with good resolution at low rpm. I'm also relying on interpolation at high rpm and higher loads. I edited several other sections of code to integrate the WOT maps into the Part Throttle maps and skip the WOT portion of the original code.

Timing Map.jpg (121.36 KiB) Viewed 517 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.

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?

AHA! There it is! I couldn't find the button to attach a screenshot.
This is my modified Timing map. You can see how I changed the header values to expand the Load range and make the RPM breakpoints more linear, with good resolution at low rpm. I'm also relying on interpolation at high rpm and higher loads. I edited several other sections of code to integrate the WOT maps into the Part Throttle maps and skip the WOT portion of the original code.
Timing Map.jpg

Wow, you are in a league of your own Dave! Did you change the actual programming code in the lower ROM area?

[johnb]

I started writing some documentation on DME maps. This mostly covers the stuff we talked about the other day:

https://jhnbyrn.github.io/951-KLR-PAGES ... _info.html

Feedback is welcome!

I plan to add more details about how the temp sensor data is processed too.

I don't have a proper place for this stuff to live yet. That site^ is really all about the KLR and I'm only getting started on DME stuff now, but I wanted it somewhere I can't lose it!

Maybe we could have a sticky thread as an index to other threads to collect this kind of stuff?

[Tom]

I started writing some documentation on DME maps. This mostly covers the stuff we talked about the other day:

https://jhnbyrn.github.io/951-KLR-PAGES ... _info.html

Feedback is welcome!

I plan to add more details about how the temp sensor data is processed too.

I don't have a proper place for this stuff to live yet. That site^ is really all about the KLR and I'm only getting started on DME stuff now, but I wanted it somewhere I can't lose it!

Maybe we could have a sticky thread as an index to other threads to collect this kind of stuff?

I'd love for it to live here! I'm compiling a beginners how-to on chip tuning. If you are up for it, I could see opening a dedicated subforum for all-things tuning... I'll send you a PM...

[whalenlg]

I started writing some documentation on DME maps. This mostly covers the stuff we talked about the other day:

https://jhnbyrn.github.io/951-KLR-PAGES ... _info.html

Feedback is welcome!

I plan to add more details about how the temp sensor data is processed too.

I don't have a proper place for this stuff to live yet. That site^ is really all about the KLR and I'm only getting started on DME stuff now, but I wanted it somewhere I can't lose it!

Maybe we could have a sticky thread as an index to other threads to collect this kind of stuff?

Thanks for posting the document. Couple of questions on my interpretation of the temp vs rpm map. I tend to code things to understand, so here's my pseudo code and questions on how to calculate the idle RPM from temperature

(1) read the 1st value - that's a memory address to get my INPUT value. In the example map, this tells me to go to the memory location where the temperature is stored (13). In your example, I read back 177 as the INPUT value from this location.
(2) I read the 2nd value in the table and that tells me where the column headers end (+3 spots).
(3) Per your description, that means I need to get the 5th value (which is the 3rd header column position) in the table (77) and add it to my current input (177) = 254 and check for overflow (>255).
(5) Since no over flow, I look at the 4th value in the map (2nd header position) and add that to my running total (254). This gives me an overflow of 254+39=284 (>255), so I know the temperature is between the 2nd and 3rd columns.
(6) To get actual values for RPM/40, then I need to interpolate between the 8th and 7th values (2nd and 3rd column actual values) in the map.
In this map, those are 15 and 17. So I would likely get 16 hex (22 decimal) as the OUTPUT of the calculation.

If that's all correct, that would yield a target RPM of 40x22 = 880 which makes sense,

[johnb]

...

Thanks for posting the document. Couple of questions on my interpretation of the temp vs rpm map. I tend to code things to understand, so here's my pseudo code and questions on how to calculate the idle RPM from temperature

(1) read the 1st value - that's a memory address to get my INPUT value. In the example map, this tells me to go to the memory location where the temperature is stored (13). In your example, I read back 177 as the INPUT value from this location.
(2) I read the 2nd value in the table and that tells me where the column headers end (+3 spots).
(3) Per your description, that means I need to get the 5th value (which is the 3rd header column position) in the table (77) and add it to my current input (177) = 254 and check for overflow (>255).
(5) Since no over flow, I look at the 4th value in the map (2nd header position) and add that to my running total (254). This gives me an overflow of 254+39=284 (>255), so I know the temperature is between the 2nd and 3rd columns.
(6) To get actual values for RPM/40, then I need to interpolate between the 8th and 7th values (2nd and 3rd column actual values) in the map.
In this map, those are 15 and 17. So I would likely get 16 hex (22 decimal) as the OUTPUT of the calculation.

If that's all correct, that would yield a target RPM of 40x22 = 880 which makes sense,

You've got it, that's a perfect explanation. What I didn't cover yet (but I will) is the 3D maps. The idea is the same. After the process you described, it's repeated again for the second variable. That gives a column and a row...but I can't quite explain how the interpolation of the value works in this case yet.

[Tom]

As I work on populating a new XDF, I realize the existing XDF's only have FQS fuel. I'll start looking for the FQS timing locations (assuming it's that simple), but if either of you could point me to it, it would probably saves hours of blind-hog hunting...

Edit -- or is is just one number that reduces settings 4 - 7 only, and all by the same amount?

[johnb]

As I work on populating a new XDF, I realize the existing XDF's only have FQS fuel. I'll start looking for the FQS timing locations (assuming it's that simple), but if either of you could point me to it, it would probably saves hours of blind-hog hunting...

Edit -- or is is just one number that reduces settings 4 - 7 only, and all by the same amount?

I'm attaching a file you might find useful. It's not really a png I just renamed it to get past the filter. It's really the disassembled bin file with lots of comments from the opendme project. I've been using this to get hints for figuring things out and it's a big head start.

I don' t have time to go looking for the FQS stuff in detail just now but I think you can find it in this. There's a couple of locations marked with FQS related names and explanations of what they are.

Let me know if you don't get what you need from that.

EDIT: ok the file disappeared after I posted so it sounds like my trick didn't work. I'll email it to you instead.

[johnb]

If anyone was wondering how we can figure out what the engine temp values in the maps really mean, here's my explanation: https://jhnbyrn.github.io/951-KLR-PAGES/ntc_info.html

I ended up with a formula that I'm pretty happy with:

temp = (8-bit value - 62.6) / 1.52

The details are in the link above!

[Tom]

If anyone was wondering how we can figure out what the engine temp values in the maps really mean, here's my explanation: https://jhnbyrn.github.io/951-KLR-PAGES/ntc_info.html

I ended up with a formula that I'm pretty happy with:

temp = (8-bit value - 62.6) / 1.52

The details are in the link above!

Awesome -- that was on my list. As a sanity check, I computed the break-points for the three temps shown in the 'normal' path idle map. Those values were 0x6D, 0x27, 0x4D (left to right at locations 0x1FB - 0x1FD). Using the bucketizing routine you explained earlier in this thread, plus your new best fit formula, I get:

Warmed up bucket: 0x100 − 0x4D = 179. Using your formula (179-62.6)/1.52 = 76.6c or 169.8F. So as a practical matter, the idle rpm would stay in the high temp column if the temp is above 170F, which seems about right. (That's just below the first hash on the gauge and just below the thermostat temp -- so sanity check passes with flying colors.)

Warming up bucket: 0x100 − (0x4D+0x27) = 140. With your formula, that 50.9c or 123.7F. So that seems plausible as a Bosch warm-up range -- over 124F and under 170F

Cold engine bucket: 0x100 − (0x4D+0x27+0x6D) = 31 which goes to 20.8c or −5.4F. Not really sure the significance of this number though since the routine would overflow and kick it to this column's rpm at once the temp is less than 123.7F. Since there is no column further left, I wonder the point of having the 4D entry? Seems like that number is irrelevant since there is not another left-most column to overflow into...?