Looking for DME BIN files

Talk and Tech about turbocharged 924/944/968 cars
Rogue_Ant
Posts: 12
Joined: Thu Sep 25, 2025 3:04 pm
Been thanked: 2 times
Tom wrote: Fri Sep 26, 2025 1:27 pm ...timing advance equals (BIN-20)* .681818
This is correct.

The 944/951 stuff is really not fresh in my mind anymore. And I'm not going to comb through the previous 20 pages in this thread. But what else do you want to know?

#211

User avatar
Tom
Site Admin
Posts: 8568
Joined: Fri Jun 25, 2021 2:04 pm
Location: Silicon Valley, CA
Has thanked: 891 times
Been thanked: 3847 times
Contact:
Rogue_Ant wrote: Mon Sep 29, 2025 12:43 am
Tom wrote: Fri Sep 26, 2025 1:27 pm ...timing advance equals (BIN-20)* .681818
This is correct.

The 944/951 stuff is really not fresh in my mind anymore. And I'm not going to comb through the previous 20 pages in this thread. But what else do you want to know?
Well hello there and welcome to Carpokes! It's been a while!! We've been slogging through the various maps and and such and have a pretty good understanding of where the maps/variable are and how to adjust them. Part of the process has been to make an effort to reverse engineer the code (thanks to johnb, dave w, whalenlg, and the Open DME project) to provide a deeper community understanding of what's going on. That's why I was asking about the BIN-20 formula -- just trying to see where in the code (if anywhere) that happens -- mostly an academic, knowledge is power kind of question. :) I'm sure more questions will come up, but we've sorted out most of the things that were perplexing me previously (see for example the idle map discussion and the injector deadtime discussion). But if you are up for it, there also have been question about your m-tune we can't really answer, such as this one.

#212

Rogue_Ant
Posts: 12
Joined: Thu Sep 25, 2025 3:04 pm
Been thanked: 2 times
The bin-20 formula:

The subtraction is done at 0x1CB3.
The 0.681818 part is a bit deceiving. It looks like: 360 / (132 * 4) = 0.681818

Which would imply that the DME has quarter-tooth resolution...
It does not; it has half-tooth resolution.
The next ignition event is not 360° away, but rather 180°. So, it does a divide by 2 (RRC instruction), to take the "quarter-teeth" back to half-teeth. It can only fire (or start charging) the coil on one of these half-teeth, which are just the rising and falling-edge of the tooth.

#213

User avatar
Tom
Site Admin
Posts: 8568
Joined: Fri Jun 25, 2021 2:04 pm
Location: Silicon Valley, CA
Has thanked: 891 times
Been thanked: 3847 times
Contact:
Ah, thank you! Found it! I'll sleep better now. :angel:

Code: Select all

1cae:  lcall map_lookup   ; 
1cb1:  add   a,r5         ; add register r5 to accumulator A
1cb2:  clr   c            ; clear carry
1cb3:  subb  a,#14h       ; subtract immediate 0x14 (20 decimal) with borrow (carry=0, so simple subtract)
1cb5:  mov   r5,a         ; move result back into r5
1cb6:  ret                ; return
While we have you, maybe you can help me understand why you used (BIN*2)/5 in the deadtime tables of the XDF in your DIY bundle. I couldn't make sense of the resulting numbers shown in TunerPro (37 and 11), and starting here we came to believe the BIN represents time in MS*100....

And, at the risk of pressing my luck, I'm curious why you pointed your idle rpm table to 0x655? We had a long discussion about idle maps above, and there are clearly alternate idle maps depending on configuration, but none of them appear to be at 0x655 on the stock image? Any chance that was left over from a different map or from one or your proprietary code changes? Here's the upshot of what we found: "I tested on the car, and this theory seems correct. With a Bosch DME and the same chip image, the idle on my car is controlled via the 3-cell map Dave used (0x5FE, 0x5FF, 0x600). With the fTech DME, that map has no effect on idle and instead the 4 bytes starting at 0x5F5 controls the idle. This is consistent with johnb's code analysis, since it strongly appears that pin 28 no longer grounds that ADC in the ftech DME."

#214

User avatar
johnb
Posts: 314
Joined: Thu Jul 08, 2021 5:57 am
Has thanked: 108 times
Been thanked: 76 times
Tom wrote: Mon Sep 29, 2025 4:25 pm Ah, thank you! Found it! I'll sleep better now. :angel:

Code: Select all

1cae:  lcall map_lookup   ; 
1cb1:  add   a,r5         ; add register r5 to accumulator A
1cb2:  clr   c            ; clear carry
1cb3:  subb  a,#14h       ; subtract immediate 0x14 (20 decimal) with borrow (carry=0, so simple subtract)
1cb5:  mov   r5,a         ; move result back into r5
1cb6:  ret                ; return
While we have you, maybe you can help me understand why you used (BIN*2)/5 in the deadtime tables of the XDF in your DIY bundle. I couldn't make sense of the resulting numbers shown in TunerPro (37 and 11), and starting here we came to believe the BIN represents time in MS*100....

And, at the risk of pressing my luck, I'm curious why you pointed your idle rpm table to 0x655? We had a long discussion about idle maps above, and there are clearly alternate idle maps depending on configuration, but none of them appear to be at 0x655 on the stock image? Any chance that was left over from a different map or from one or your proprietary code changes? Here's the upshot of what we found: "I tested on the car, and this theory seems correct. With a Bosch DME and the same chip image, the idle on my car is controlled via the 3-cell map Dave used (0x5FE, 0x5FF, 0x600). With the fTech DME, that map has no effect on idle and instead the 4 bytes starting at 0x5F5 controls the idle. This is consistent with johnb's code analysis, since it strongly appears that pin 28 no longer grounds that ADC in the ftech DME."
I can add some context around the 0x655 map if this helps. I just finished going through and documenting the entire ISV routine and the logic for that map works like this (see 1BA9):

Code: Select all

if rpm > target but current load < the value from 0x655:
    do not allow the closed loop routine to reduce air (via 20h.4)   
 
This map is one of 3 chosen by by the code plug (there are 4 choices but 2 of them point to the same map). It's load values looked up by engine temp.

Given the way it's used my guess is it's emissions related? Still it's odd that it's only used to block negative correction in the closed loop routine. It never causes extra air to be added, so it doesn't really work as a "minimum load at idle" feature.

It seems like this functionality could have just been baked into the idle target rpm maps, which already use engine temp. Rogue if you can explain anything about this that would be great!

#215

Rogue_Ant
Posts: 12
Joined: Thu Sep 25, 2025 3:04 pm
Been thanked: 2 times
Regarding the Injector deadtime, the equation I have is (X * 5) / 500
So, it looks like you guys came up with the same.

For the DIY .xdf, likely I just didn't get that copied over correctly from my non-public xdf.

The idle stuff in the original DME is a mess. I have lost some of my notes / disassembly over the years. But one earlier disassembly I have this in my notes:
DME_Idle_code.PNG
DME_Idle_code.PNG (4 KiB) Viewed 348 times

I don't recall exactly why I chose that table, IIRC I tried to consolidate the multiple idle tables into one.

#216

User avatar
Tom
Site Admin
Posts: 8568
Joined: Fri Jun 25, 2021 2:04 pm
Location: Silicon Valley, CA
Has thanked: 891 times
Been thanked: 3847 times
Contact:
Rogue_Ant wrote: Mon Sep 29, 2025 7:45 pm Regarding the Injector deadtime, the equation I have is (X * 5) / 500
So, it looks like you guys came up with the same.

For the DIY .xdf, likely I just didn't get that copied over correctly from my non-public xdf.

The idle stuff in the original DME is a mess. I have lost some of my notes / disassembly over the years. But one earlier disassembly I have this in my notes:

DME_Idle_code.PNG


I don't recall exactly why I chose that table, IIRC I tried to consolidate the multiple idle tables into one.
Awesome, thanks for that. I had confidence in our approach for both, but in light of your prowess on this stuff, it's great to hear we weren't missing something. :)

#217

Rogue_Ant
Posts: 12
Joined: Thu Sep 25, 2025 3:04 pm
Been thanked: 2 times
@johnb

I took a look at your comments on my old ignition / coil tech thread. Your conclusion is wrong.
Using just V = L di/dt ignores resistances and other voltage drops, which in a 12v system is going to significantly change the result.

In particular, there is a significant voltage drop across the Darlington transistor driving the coil. There are connector and line resistances. There is also discrete resistors in the low-side path in the DME.

When I tested the coils, I tested them at the various voltages in the table's columns, 6.0 8.0 10.0 12.0 14.0 16.0 16.4 volts.
I even built an replica circuit in LTspice:
DME_Ignition.PNG
DME_Ignition.PNG (88.95 KiB) Viewed 335 times
This very closely matches with what I measured. I tried reducing the resistances, but it still won't charge as fast as your measurement.
My conclusion is that your coil has less inductance compared to what I measured for the stock coils.

Additionally, the time to charge is not 1/(2*rpm/60). This affords no time for the coil to actually discharge and the circuit to stop ringing. Typically, a 1mS 'blanking window' should be applied to account for this time.

#218

User avatar
johnb
Posts: 314
Joined: Thu Jul 08, 2021 5:57 am
Has thanked: 108 times
Been thanked: 76 times
Rogue_Ant wrote: Mon Sep 29, 2025 8:26 pm @johnb

I took a look at your comments on my old ignition / coil tech thread. Your conclusion is wrong.
Using just V = L di/dt ignores resistances and other voltage drops, which in a 12v system is going to significantly change the result.

In particular, there is a significant voltage drop across the Darlington transistor driving the coil. There are connector and line resistances. There is also discrete resistors in the low-side path in the DME.

When I tested the coils, I tested them at the various voltages in the table's columns, 6.0 8.0 10.0 12.0 14.0 16.0 16.4 volts.
I even built an replica circuit in LTspice:

DME_Ignition.PNG

This very closely matches with what I measured. I tried reducing the resistances, but it still won't charge as fast as your measurement.
My conclusion is that your coil has less inductance compared to what I measured for the stock coils.

Additionally, the time to charge is not 1/(2*rpm/60). This affords no time for the coil to actually discharge and the circuit to stop ringing. Typically, a 1mS 'blanking window' should be applied to account for this time.
Thanks for the reply! It's odd that my measurements don't match then - my coil (and entire car) are stock. I don't have the ability to measure the inductance, so maybe it is off.

But another thing that made me think something had to be wrong was the dwell times. If it takes 6.5ms to fully charge the coil, why doesn't the dwell map use that time when it's available? If I read the dwell map correctly, the time drops below that 6.5ms once you get above 500rpm or so, even though there's plenty of available time up to 4000rpm and beyond (for typical running voltages).

#219

User avatar
Tom
Site Admin
Posts: 8568
Joined: Fri Jun 25, 2021 2:04 pm
Location: Silicon Valley, CA
Has thanked: 891 times
Been thanked: 3847 times
Contact:
This discussion makes me realize I was lazy with the dwell table in our XDF, which shows raw BIN values instead of dwell times. I'll add in the math so we can see the stock dwell times in a convenient table. That may be my only contribution to this discussion, as my law school curriculum was quite lean on inductance formulas and the effect of resistance and voltage drops thereon. It's annoying that RL no longer shows the screen shots that went with the original post (!! pet peeve -- and makes me want to turn off the ability to post remotely-hosted pictures here on Carpokes -- all those pic-hosting services seem to go belly up or otherwise mess with links over time, but I digress). While I have no formal electronics education, I am handy with a scope, so mulling how I might go about recreating the charge-time test. Where do you get 9 amps of regulated 13.8 volts?

#220

Post Reply