Looking for DME BIN files

[johnb]

It apparently increments a counter -- maybe the counter for the cycling valve's PWM signal? Looking at other KLR performance chips back in the day, it looks like maxing out the overboost table and clearing that counter (maybe to force the cycling valve to full boost?) was one of the ways they'd use.

I think it's to override the error code. We have

0xf60 mov r1,#$33
0xf62 mov a,@r1
0xf63 jz $0F69
0xf65 add a,#$EF
0xf67 jnz $0F81
0xf69 mov a,r4

Location 33h contains the error code (if any). So if that's zero, we skip the next 2 instructions. At a glance it looks like those next 2 instructions check if the error code is something specific (i.e. whatever code would result in zero when added to 0xEF). For any other code, it skips to the end of the routine. This is probably how limp mode is implemented. Apparently there's one code that doesn't trigger it (not sure which one).

The Dinan bin file that I have replaces the conditional jz with

jmp $0769

(the address here is relative to the current bank so this can be read as 0xF69)

So it makes the CV PWM calculation ignore the error code.

[Tom]

And in contrast, the patch you did above just stops the error code from occurring in the first place? I see one after market BIN that jumps to a nearby location like that, and another that substitutes jz with CLR A (instruction E4), which I assume then is an attempt to clear any error code so that it will jump to the end with the next two instructions?

[johnb]

And in contrast, the patch you did above just stops the error code from occurring in the first place? I see one after market BIN that jumps to a nearby location like that, and another that substitutes jz with CLR A (instruction E4), which I assume then is an attempt to clear any error code so that it will jump to the end with the next two instructions?

Exactly, I zeroed out the boost error (i.e. actual current boost - target boost) in the error checking routine, so both high and low boost error conditions are unreachable.

The way they're doing it is crude because it prevents the KLR from entering limp mode no matter what the reason.

I think CLR A would work if it was placed at 0xf65. I think jumping to the end=limp mode, so having a=0 at that point would avoid that and make it continue to 0xf69 just like the Dinan one.

[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

@FTECH9 -- any update on the pull-down resistor?

[JHY]

Well, I may make a very simple XDF for the KLR. Although not needed if using an aftermarket boost controller, I still think it would be useful to let people do their own KLR without the overboost protection. I'm sure johnb's BIN above will do the trick, but I figure an XDF would give power to the people so to speak. Reviewing various aftermarket KLR BINS, it seems that the easiest thing to do is max out the overboost table at x0C00 with FF in every cell (much like in the DME overboost table). Assuming no issues there, @johnb do you know what the value at x0F63 represents? It's listed as Dinan mod in an old XDF I found, and is changed on some KLR chips.

I was under the impression that KLR had no say in the overboost cut, and that overboost cut was a DME response to variation in expected vs actual airflow:RPM. Do I have that wrong?

[johnb]

Well, I may make a very simple XDF for the KLR. Although not needed if using an aftermarket boost controller, I still think it would be useful to let people do their own KLR without the overboost protection. I'm sure johnb's BIN above will do the trick, but I figure an XDF would give power to the people so to speak. Reviewing various aftermarket KLR BINS, it seems that the easiest thing to do is max out the overboost table at x0C00 with FF in every cell (much like in the DME overboost table). Assuming no issues there, @johnb do you know what the value at x0F63 represents? It's listed as Dinan mod in an old XDF I found, and is changed on some KLR chips.

I was under the impression that KLR had no say in the overboost cut, and that overboost cut was a DME response to variation in expected vs actual airflow:RPM. Do I have that wrong?

They both have it. In practice you don't run into KLR boost protection much because the DME overboost protection kicks in first.

The DME responds with a fuel cut.

The KLR has both over and underboost error conditions. It responds to either one by putting the KLR into limp mode and triggering a blink code. In limp mode (no matter which code is triggered, even stuff unrelated to boost) the cycling valve goes to maximum boost reduction so the wastegate will open when you get to ~4psi or so.

[Tom]

The DME creates the notorious brick wall people hit when they overboost. If you max out/eliminate the overboost map in the DME, you can then trigger the KLR's limp mode. However, if you use your own boost controller, it renders the KLR's overboost moot for the most part. Back in the day, some performance chips would eliminate the DME overboost protection and bump the boost while still using the cycling valve (e.g., shimming the waste gate, restrictor in banjo bolt, drilling a hole in the cycling valve, etc.). That's really the only scenario where you'd need to worry about the KLR overboost. I can only imagine one scenario where that might still be appealing to someone -- i.e., cheating at Club Racing.

[JHY]

That makes sense, thanks for clarifying!

[Tom]

For the air temp signal (variable 12), is it safe to conclude they translate to temps with the same formula as the coolant temps (variable 13)? The maps are set up identically, and the same formula produces seemingly correct numbers, so that's what I used in the XDF...

Also, for the timing advance values in the BIN, is it possible to validate via the code alone that the timing advance equals (BIN-20)* .681818 -- i.e., a quarter tooth each less 5 teeth? All the older XDF's seem to do the same, including Rogue, the 3.2 Carrera, even the M3 of the era, and it lines up with my old ignition advance monitor, so I'm reasonably sure it's right, just curious where/how that's happening?

[johnb]

For the air temp signal (variable 12), is it safe to conclude they translate to temps with the same formula as the coolant temps (variable 13)? The maps are set up identically, and the same formula produces seemingly correct numbers, so that's what I used in the XDF...

Also, for the timing advance values in the BIN, is it possible to validate via the code alone that the timing advance equals (BIN-20)* .681818 -- i.e., a quarter tooth each less 5 teeth? All the older XDF's seem to do the same, including Rogue, the 3.2 Carrera, even the M3 of the era, and it lines up with my old ignition advance monitor, so I'm reasonably sure it's right, just curious where/how that's happening?

For the air temp, yes it's identical to coolant temp. I'm not sure about the timing question right now but I'll take look later.