Looking for DME BIN files

[johnb]

I don't know anything about standalone ECUs and how much you have to do yourself...but I can definitely help to get the details of how it's handled in the stock software.

There are many maps that play a role in this and maybe you guys would like to have the ability to play around with them?

When the idle rpm error is calculated (i.e. target rpm - current rpm) it's used to lookup a series of gain maps. The idea here is that the error needs to be multiplied by a gain factor to come up with the ISV adjustment, and the gain factor depends on the size and direction (+ or -) of the error.

There are 2 such gain maps for under-target and 1 for over-target.

There's an another ISV adjustment map for coasting fuel cut (depends on rpm).

All these things are used as + or - adjustments to a base ISV setting that depends on rpm and engine temp. This base ISV setting is independent of idle.

There's also a max load map we discussed earlier that limits the ISV adjustment (the limit depends on engine temp).

And that's just the ISV control. There are still timing adjustments for fuel cutoff coasting and idle target rpm, with their own maps.

As you can see Porsche took getting a stable idle very seriously. As time allows I'll document these maps, what they're used for, and what the values mean if anyone is interested.

[944m3]

I’m definitely interested, so thanks for the info.

I’ve just scratched the surface on my standalone and have tons to still learn. I’ve gotten lots of help reading threads and actively by fellow contributors. My running tune is in better shape than my idle tune. Almost seems like a dark art, but I’m learning. I figured that if a 30+ year old ECU can manage perfect idle in all kinds of conditions, a modern ECU should be able to do it too, just a matter putting in the right information.

Looking forward to all future posts on this thread.

[Tom]

Awesome work, thank you! I have a theory that I'll test tomorrow. The DME harness does ground pin 28, I've confirmed that in the past. However, when Vitesse Racing first designed his MAF conversion, he repurposed pin 28 to accept a MAP sensor signal. He would have you would cut the harness wire going to pin 28 and send the MAP sensor signal into that DME via the cut wire. When Rogue Tuning introduced its MAF, it did the same thing. I have a Focus 9 DME in my car right now from @FTECH9, who worked closely with Rogue when developing the Ftech9 DME. I suspect the grounded harness wire on pin 28 is not connected inside the Ftech DME, so that that ADC input could be used to connect a MAP sensor. Just a more elegant way to hook up the map sensor without cutting harness wires. If so, it would explain why that signal is pulled high on my car, and low on Dave's...

From a Rennlist post by Ftech9 while developing this DME...

MAP Sensor Support
By convention, the unused analog input on pin 28 (ADV28) of the DME system connector is used as a MAP sensor input. I will follow this convention and default this input for that purpose.

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.

For people using MAP-enabled DME's from Ftech, but without the map sensor, this would seem to mean that idle is effectively lowered to 800 rpms at all temps since the 4-cell map is a string of 20's (14 hex) from the factory, which translates x40 to 800 RPM. A quick solution might be to install the MAP pigtail and ground the sensor signal input. @FTECH9 -- any concerns with that before I try it? For those who have a MAP installed, I assume its signal would always be under the 2.5v threshold at idle, so would effectively allow the idle to run off the 'correct' 3-cell map with factory idle levels.

When pin 28 is grounded and the idle is controlled by the 3-cell map on the Bosch DME, I can bump the idle RPM when the a/c is on by using the parameter found in Rogue's XDF (which adjusts location 0x199). Curiously, the idle only goes up when the compressor actually kicks on, and otherwise reverts to the base idle, giving an idle that jumps up and down as the compressor cycles. The factory didn't have to worry about that since they set both targets to 840.

Now another code question: when using the ftech DME without Pin 28 grounding the ADC, the a/c adjustment at 0x199 doesn't alter the idle at all. Hopefully, we can just ground the MAP signal on that DME and use it like a Bosch DME, but if there is reason not to do that, I'm curious if the code gives any clues where the a/c idle adjustment lives for DME's using the 4-cell map at 0x5F5 for base idle...?

[johnb]

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.

....

Now another code question: when using the ftech DME without Pin 28 grounding the ADC, the a/c adjustment at 0x199 doesn't alter the idle at all. Hopefully, we can just ground the MAP signal on that DME and use it like a Bosch DME, but if there is reason not to do that, I'm curious if the code gives any clues where the a/c idle adjustment lives for DME's using the 4-cell map at 0x5F5 for base idle...?

Nice work...I love a good mystery with a satisfying resolution!

To answer your question about the AC, I need to correct what I said the other day. The updated target rpm for AC-on is only in the normal path, not the alternate one.

Both paths later include an ISV correction for AC-on, but the alternate one has a 0 for this value.

All 3 AC-on constants are in consecutive locations, and they are (assuming a 4k offset as used in the XDF file):

0x199 - 15 (min rpm target, normal path)
0x19a - 18 (add to idle stabilizer PWM, normal path)
0x19b - 0 (add to idle stabilizer PWM, alternate path)

Screenshot_2025-09-05_16-16-54.png (10.48 KiB) Viewed 401 times

[FTECH9]

Awesome work, thank you! I have a theory that I'll test tomorrow. The DME harness does ground pin 28, I've confirmed that in the past. However, when Vitesse Racing first designed his MAF conversion, he repurposed pin 28 to accept a MAP sensor signal. He would have you would cut the harness wire going to pin 28 and send the MAP sensor signal into that DME via the cut wire. When Rogue Tuning introduced its MAF, it did the same thing. I have a Focus 9 DME in my car right now from @FTECH9, who worked closely with Rogue when developing the Ftech9 DME. I suspect the grounded harness wire on pin 28 is not connected inside the Ftech DME, so that that ADC input could be used to connect a MAP sensor. Just a more elegant way to hook up the map sensor without cutting harness wires. If so, it would explain why that signal is pulled high on my car, and low on Dave's...

From a Rennlist post by Ftech9 while developing this DME...

MAP Sensor Support
By convention, the unused analog input on pin 28 (ADV28) of the DME system connector is used as a MAP sensor input. I will follow this convention and default this input for that purpose.

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.

For people using MAP-enabled DME's from Ftech, but without the map sensor, this would seem to mean that idle is effectively lowered to 800 rpms at all temps since the 4-cell map is a string of 20's (14 hex) from the factory, which translates x40 to 800 RPM. A quick solution might be to install the MAP pigtail and ground the sensor signal input. @FTECH9 -- any concerns with that before I try it? For those who have a MAP installed, I assume its signal would always be under the 2.5v threshold at idle, so would effectively allow the idle to run off the 'correct' 3-cell map with factory idle levels.

When pin 28 is grounded and the idle is controlled by the 3-cell map on the Bosch DME, I can bump the idle RPM when the a/c is on by using the parameter found in Rogue's XDF (which adjusts location 0x199). Curiously, the idle only goes up when the compressor actually kicks on, and otherwise reverts to the base idle, giving an idle that jumps up and down as the compressor cycles. The factory didn't have to worry about that since they set both targets to 840.

Now another code question: when using the ftech DME without Pin 28 grounding the ADC, the a/c adjustment at 0x199 doesn't alter the idle at all. Hopefully, we can just ground the MAP signal on that DME and use it like a Bosch DME, but if there is reason not to do that, I'm curious if the code gives any clues where the a/c idle adjustment lives for DME's using the 4-cell map at 0x5F5 for base idle...?

This is an interesting issue, I am surprised it has not come to my attention before. You can ground the MAP sensor input; there is no issue with this. However, there is also a provision on the OBD+ Sport DME to mount a pull-down resistor to this input. If the value was high enough, it would not interfere with the MAP sensor signal. However, when no MAP sensor is connected, it would effectively ground the input form the ADC's perspective. I will look into determining an appropriate value then start mounting it by default. Let me know if this is a modification you would like done to your OBD+ Sprot DME. I can provide instructions if you are handy with a soldering iron, or we can work something out.

Joe

[Tom]

Awesome work, thank you! I have a theory that I'll test tomorrow. The DME harness does ground pin 28, I've confirmed that in the past. However, when Vitesse Racing first designed his MAF conversion, he repurposed pin 28 to accept a MAP sensor signal. He would have you would cut the harness wire going to pin 28 and send the MAP sensor signal into that DME via the cut wire. When Rogue Tuning introduced its MAF, it did the same thing. I have a Focus 9 DME in my car right now from @FTECH9, who worked closely with Rogue when developing the Ftech9 DME. I suspect the grounded harness wire on pin 28 is not connected inside the Ftech DME, so that that ADC input could be used to connect a MAP sensor. Just a more elegant way to hook up the map sensor without cutting harness wires. If so, it would explain why that signal is pulled high on my car, and low on Dave's...

From a Rennlist post by Ftech9 while developing this DME...

MAP Sensor Support
By convention, the unused analog input on pin 28 (ADV28) of the DME system connector is used as a MAP sensor input. I will follow this convention and default this input for that purpose.

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.

For people using MAP-enabled DME's from Ftech, but without the map sensor, this would seem to mean that idle is effectively lowered to 800 rpms at all temps since the 4-cell map is a string of 20's (14 hex) from the factory, which translates x40 to 800 RPM. A quick solution might be to install the MAP pigtail and ground the sensor signal input. @FTECH9 -- any concerns with that before I try it? For those who have a MAP installed, I assume its signal would always be under the 2.5v threshold at idle, so would effectively allow the idle to run off the 'correct' 3-cell map with factory idle levels.

When pin 28 is grounded and the idle is controlled by the 3-cell map on the Bosch DME, I can bump the idle RPM when the a/c is on by using the parameter found in Rogue's XDF (which adjusts location 0x199). Curiously, the idle only goes up when the compressor actually kicks on, and otherwise reverts to the base idle, giving an idle that jumps up and down as the compressor cycles. The factory didn't have to worry about that since they set both targets to 840.

Now another code question: when using the ftech DME without Pin 28 grounding the ADC, the a/c adjustment at 0x199 doesn't alter the idle at all. Hopefully, we can just ground the MAP signal on that DME and use it like a Bosch DME, but if there is reason not to do that, I'm curious if the code gives any clues where the a/c idle adjustment lives for DME's using the 4-cell map at 0x5F5 for base idle...?

This is an interesting issue, I am surprised it has not come to my attention before. You can ground the MAP sensor input; there is no issue with this. However, there is also a provision on the OBD+ Sport DME to mount a pull-down resistor to this input. If the value was high enough, it would not interfere with the MAP sensor signal. However, when no MAP sensor is connected, it would effectively ground the input form the ADC's perspective. I will look into determining an appropriate value then start mounting it by default. Let me know if this is a modification you would like done to your OBD+ Sprot DME. I can provide instructions if you are handy with a soldering iron, or we can work something out.

Joe

Thanks for weighing in Joe. I'm not that surprised this hasn't come up. Most people probably have a MAP, making it a moot point for them by my math. For those who don't, most probably didn't notice the slightly lower RPM, and those who did (like me) had no way to know about the alternate idle maps and how they interact with that ADC line. This thread is all breaking news, thanks in huge part to the work by dave w and johnb. We aim higher here. I'll go ahead and ground the map signal on the pigtail on my car (presumably just connecting the black and orange wire) for now. If you have instructions on how to add a pull-down resistor that won't interfere with a MAP sensor, please post that here. I'm handy with a soldering iron, and we can't leave the thread hanging.

p.s., Your DME may differ, but it looks like a relatively low-value pull-up resistor on that signal in the Bosch DME. If that proves problematic, I'm thinking it's perfectly reasonable to install either a MAP sensor OR a little shorting plug or shunt in lieu of the sensor. Either way, it's a super obscure little detail and doesn't detract at all from the great work you've done on this DME.

[Tom]

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.

....

Now another code question: when using the ftech DME without Pin 28 grounding the ADC, the a/c adjustment at 0x199 doesn't alter the idle at all. Hopefully, we can just ground the MAP signal on that DME and use it like a Bosch DME, but if there is reason not to do that, I'm curious if the code gives any clues where the a/c idle adjustment lives for DME's using the 4-cell map at 0x5F5 for base idle...?

Nice work...I love a good mystery with a satisfying resolution!

To answer your question about the AC, I need to correct what I said the other day. The updated target rpm for AC-on is only in the normal path, not the alternate one.

Both paths later include an ISV correction for AC-on, but the alternate one has a 0 for this value.

All 3 AC-on constants are in consecutive locations, and they are (assuming a 4k offset as used in the XDF file):

0x199 - 15 (min rpm target, normal path)
0x19a - 18 (add to idle stabilizer PWM, normal path)
0x18b - 0 (add to idle stabilizer PWM, alternate path)


Screenshot_2025-09-05_16-16-54.png

I assume you mean 0x19B (not 18b) but either way editing that value didn't do anything to the a/c idle while on the alternate path. The 0x199 location changes the idle when the a/c is on, but only on the normal path idle map. Probably not worth figuring out if there is an equivalent to 0x199 for the alternate path, since it seems like a fairly trivial matter to divert the fTech 9 back to the normal path and there is no known use for the alternate path (yet anyway).

[johnb]

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.

....

Now another code question: when using the ftech DME without Pin 28 grounding the ADC, the a/c adjustment at 0x199 doesn't alter the idle at all. Hopefully, we can just ground the MAP signal on that DME and use it like a Bosch DME, but if there is reason not to do that, I'm curious if the code gives any clues where the a/c idle adjustment lives for DME's using the 4-cell map at 0x5F5 for base idle...?

Nice work...I love a good mystery with a satisfying resolution!

To answer your question about the AC, I need to correct what I said the other day. The updated target rpm for AC-on is only in the normal path, not the alternate one.

Both paths later include an ISV correction for AC-on, but the alternate one has a 0 for this value.

All 3 AC-on constants are in consecutive locations, and they are (assuming a 4k offset as used in the XDF file):

0x199 - 15 (min rpm target, normal path)
0x19a - 18 (add to idle stabilizer PWM, normal path)
0x18b - 0 (add to idle stabilizer PWM, alternate path)


Screenshot_2025-09-05_16-16-54.png

I assume you mean 0x19B (not 18b) but either way editing that value didn't do anything to the a/c idle while on the alternate path. The 0x199 location changes the idle when the a/c is on, but only on the normal path idle map. Probably not worth figuring out if there is an equivalent to 0x199 for the alternate path, since it seems like a fairly trivial matter to divert the fTech 9 back to the normal path and there is no known use for the alternate path (yet anyway).

You're right that was a typo, should have been 19. I fixed it. But anyway yes those locations are not used for the rpm target - they're only used to add to the ISV PWM signal. In other words they are open loop values, added based on the assumption that hitting the rpm target will require this correction anyway, so why wait for the closed loop to catch up? But they apparently decided that it wasn't needed on the alternate path and set it to zero.

There's no equivalent to 0x199 on the alternate path.

[Tom]

Nice work...I love a good mystery with a satisfying resolution!

To answer your question about the AC, I need to correct what I said the other day. The updated target rpm for AC-on is only in the normal path, not the alternate one.

Both paths later include an ISV correction for AC-on, but the alternate one has a 0 for this value.

All 3 AC-on constants are in consecutive locations, and they are (assuming a 4k offset as used in the XDF file):

0x199 - 15 (min rpm target, normal path)
0x19a - 18 (add to idle stabilizer PWM, normal path)
0x18b - 0 (add to idle stabilizer PWM, alternate path)


Screenshot_2025-09-05_16-16-54.png

I assume you mean 0x19B (not 18b) but either way editing that value didn't do anything to the a/c idle while on the alternate path. The 0x199 location changes the idle when the a/c is on, but only on the normal path idle map. Probably not worth figuring out if there is an equivalent to 0x199 for the alternate path, since it seems like a fairly trivial matter to divert the fTech 9 back to the normal path and there is no known use for the alternate path (yet anyway).

You're right that was a typo, should have been 19. I fixed it. But anyway yes those locations are not used for the rpm target - they're only used to add to the ISV PWM signal. In other words they are open loop values, added based on the assumption that hitting the rpm target will require this correction anyway, so why wait for the closed loop to catch up? But they apparently decided that it wasn't needed on the alternate path and set it to zero.

There's no equivalent to 0x199 on the alternate path.

The Bosch programmers did so much with so little. So much more impressive to me than today's modern bloatware. I wonder if anyone kept records/notes on all the development decisions that went into it or if any of the engineers are still around? Would be a shame to lose all that history forever. That said, your disassembly work and Dave's deep tuning knowledge is an absolute Godsend. Thank you!! Pretty sure you guys unlocked a tuning parameter that had not yet been hacked or exploited. If APE or those guys sorted the idle control back in the day, they never seemed to do much with it, and it certainly hadn't made it's way in the hive-mind until now. Kudo's!

Any interest in looking at other functions? No pressure if you've have enough for now, but I'm curious what the DME's overboost table starting at 0x6EE is comparing itself to? In practice, it seems that maxing out the table with all FF's essentially disables the overboost, so I assume the compare values are single bytes too that can never exceed the FFs. I'm wondering if it compares to the raw airflow meter readings or something more complex?

[johnb]

Oh yeah I'm interested in all of it! I'll definitely take a look. I know from the old Bosch DME mailing list on yahoo (now gone sadly) that the AFM signal processing is somewhat more complicated than the other sensors because its not linear. Ultimately it ends up as a single byte in memory though.

I would love to hear from someone who worked on this stuff back then, but I never have. I did have a brief conversation with the guy who created the J&S knock control computer, which I know has been used by some people in 944s. He saw my KLR stuff and said the KLR design inspired his design back in the day.