Overboost - DME & KLR
03-28-2020, 06:41 PM
#31
Three Wheelin'
It was the KLR overboost fault code, certain of it. Lost boost (limp mode) during practice sessions at the BIR club race last summer, and checked the blink code. Really surprised me, because I have never had the KLR throw an actual real world code before (only had it throw a code when I unplug the TPS to make sure the diagnostic system and my light tester work). And the car wasn't overboosting. So very likely the KLR had to have failed in some way, possibly the pressure sender. Swapped with another KLR and the problem did not return.
Testing the knock sensor was several years ago when I was trying to determine if my car had a bad knock sensor and was pulling timing. Yes, full boost, full throttle, full rpm range runs. I tried to things, I disconnected the knock sensor and I also unbolted the knock sensor from the block and wrapped it in foam to make sure it wasn't detecting knock counts. Neither had any impact on the car (DME/KLR).
The DME overload protection does not create a KLR blind code fault. But yes, cycling the ignition will reset the DME. Have had to do that on track before. But have also played with it on the street, and yes anything above 3/4 throttle will cause the DME to cut the fuel again. And after about a minute or so, it automatically resets.
>>>>>It's just I can't see how you it could have been intended to work if the KLR code is not logged before the DME overload protection.
I'm not sure I'm following what you're asking or saying here.
I've been driving or in at least 4 cars that have hit the DME overboost protection for somewhat slightly different reasons. An 86 turbo that had a k26/8 turbo installed but still had the stock DME chip, so it was boosting (air flow thru the AFM) above the intended limit at higher rpm. An 89 Turbo that had a control problem, waste gate sticking or cycling valve that was allowing it to overboost up to 13-14 psi with the stock DME chip. And a couple different 87 turbos that were running shims in the waste gate (maybe gaining 1 psi boost) but still using the stock DME chip. None of them ever generated a KLR limp mode or blink code fault. Some of these were very intermittent, occasional events. And nearly always at higher rpm in 4th gear, extended runs. So you do not see it much on the street. Generally only at the track.
Testing the knock sensor was several years ago when I was trying to determine if my car had a bad knock sensor and was pulling timing. Yes, full boost, full throttle, full rpm range runs. I tried to things, I disconnected the knock sensor and I also unbolted the knock sensor from the block and wrapped it in foam to make sure it wasn't detecting knock counts. Neither had any impact on the car (DME/KLR).
The DME overload protection does not create a KLR blind code fault. But yes, cycling the ignition will reset the DME. Have had to do that on track before. But have also played with it on the street, and yes anything above 3/4 throttle will cause the DME to cut the fuel again. And after about a minute or so, it automatically resets.
>>>>>It's just I can't see how you it could have been intended to work if the KLR code is not logged before the DME overload protection.
I'm not sure I'm following what you're asking or saying here.
I've been driving or in at least 4 cars that have hit the DME overboost protection for somewhat slightly different reasons. An 86 turbo that had a k26/8 turbo installed but still had the stock DME chip, so it was boosting (air flow thru the AFM) above the intended limit at higher rpm. An 89 Turbo that had a control problem, waste gate sticking or cycling valve that was allowing it to overboost up to 13-14 psi with the stock DME chip. And a couple different 87 turbos that were running shims in the waste gate (maybe gaining 1 psi boost) but still using the stock DME chip. None of them ever generated a KLR limp mode or blink code fault. Some of these were very intermittent, occasional events. And nearly always at higher rpm in 4th gear, extended runs. So you do not see it much on the street. Generally only at the track.
What I was getting at regarding how it's intended to work was just this: why does the KLR have codes for this in its software, if they can't be reached? That's why I was asking all those questions - in case there were codes coming up but you were just not seeing them for the reasons I suggested. But it sounds like you definitely would have seen the codes, and it must work a little differently to the way the documentation has led us to believe.
03-28-2020, 06:48 PM
#32
Rennlist Member
>>>>why does the KLR have codes for this in its software, if they can't be reached?
Yes, that's a good question.
The DME overload protection is a very distinct hard stumble, when the fuel cuts, and as you build boost again, it will stumble hard again, until it resets.
The KLR limp mode just makes no boost at all.
They don't both happen at the same time. Meaning the DME doesn't cut the fuel, and the KLR goes into limp mode at the same time. Even though that would make sense, I've never had that happen.
Yes, that's a good question.
The DME overload protection is a very distinct hard stumble, when the fuel cuts, and as you build boost again, it will stumble hard again, until it resets.
The KLR limp mode just makes no boost at all.
They don't both happen at the same time. Meaning the DME doesn't cut the fuel, and the KLR goes into limp mode at the same time. Even though that would make sense, I've never had that happen.
03-28-2020, 06:53 PM
#33
Rennlist Member
And yes, when I was chasing the problem on one of the cars (the intermittent DME overload fuel cut), I did check for the KLR fault code before shutting the car off, but never got one. In fact that was the reason that I made the little blink code light, was to try to diagnose that problem.
I thought that the KLR should be identifying the overload/overboost condition too. But it doesn't.
I thought that the KLR should be identifying the overload/overboost condition too. But it doesn't.
03-28-2020, 07:09 PM
#34
Three Wheelin'
Got it. I'll figure it out how it's supposed to work eventually from the code. But it's hard to say what will or will not happen definitively just by reading the code - nothing beats experience when it comes to this stuff.
Personally I would not expect the KLR to cut boost completely as a result of detecting overboost - that wouldn't make any sense to me. The KLR is responsible for controlling boost. So before it complains, it should already be doing everything it can to correct the situation. The only way the overboost condition should be possible is if something has changed mechanically from the stock setup so that the KLR physically can't prevent overboost. So I'm not surprised that boost was not cut before DME overload, but I'm surprised that there wasn't a code.
The only one I've ever personally seen is the TPS code, when I have unplugged it. My car is totally stock except for the exhaust, so it might be time for me to do some experiments...
Personally I would not expect the KLR to cut boost completely as a result of detecting overboost - that wouldn't make any sense to me. The KLR is responsible for controlling boost. So before it complains, it should already be doing everything it can to correct the situation. The only way the overboost condition should be possible is if something has changed mechanically from the stock setup so that the KLR physically can't prevent overboost. So I'm not surprised that boost was not cut before DME overload, but I'm surprised that there wasn't a code.
The only one I've ever personally seen is the TPS code, when I have unplugged it. My car is totally stock except for the exhaust, so it might be time for me to do some experiments...
03-28-2020, 07:22 PM
#35
Rennlist Member
If the KLR is limited to pulling timing and lowering boost, you have to wonder if the purpose of the KLR overboost code is pretty much just for diagnostics anyway. The only conditions the Technik mentions for the KLR code are broken parts that would make it futile to command less boost... and I kind of doubt they had endless mods and aftermarket maps in mind. Maybe that's why we see so few (if any) KLR overboost protection actually affecting the car -- i.e., anytime the KLR does throw a code, there's nothing it can do about it and it goes unnoticed. Unlike the DME overboost that can't be missed.... Might be a different situation if everyone drove around with KLR LEDs on their dash.
04-08-2020, 07:33 PM
#36
Three Wheelin'
If the KLR is limited to pulling timing and lowering boost, you have to wonder if the purpose of the KLR overboost code is pretty much just for diagnostics anyway. The only conditions the Technik mentions for the KLR code are broken parts that would make it futile to command less boost... and I kind of doubt they had endless mods and aftermarket maps in mind. Maybe that's why we see so few (if any) KLR overboost protection actually affecting the car -- i.e., anytime the KLR does throw a code, there's nothing it can do about it and it goes unnoticed. Unlike the DME overboost that can't be missed.... Might be a different situation if everyone drove around with KLR LEDs on their dash.
The required error count is lowered to 100 if the actual boost is 1 bar or more. So I suppose that below full boost, it could take a few seconds to trigger at lower rpm.
Regarding the KLR code for broken parts...that turned out to be pretty interesting. The 2-3 code ("Faulty unit; replace") took me a while to figure out, but I'm 99% sure it means that the knock sensor circuitry is not working. Every few hundred cycles, the KLR performs a self-test on the knock detection system. It injects a 5.7Khz signal into the knock sensor amplifier input, and then checks if knock is detected. If it's not, and this happens 6 times in a row, then the 2-3 code is set. Overall, the knock detection system is pretty clever.
04-08-2020, 08:20 PM
#37
Rennlist Member
Awesome info. What are you using to decompile it? What's the cycle speed to put those in perspective?
"Actual boost is not considered for this, only the difference between the current boost and the target." "Actual" boost is used to calculate the difference though I assume? Or are you using 'actual' and 'current' to mean different things?
"Actual boost is not considered for this, only the difference between the current boost and the target." "Actual" boost is used to calculate the difference though I assume? Or are you using 'actual' and 'current' to mean different things?
04-08-2020, 08:37 PM
#38
Three Wheelin'
Awesome info. What are you using to decompile it? What's the cycle speed to put those in perspective?
"Actual boost is not considered for this, only the difference between the current boost and the target." "Actual" boost is used to calculate the difference though I assume? Or are you using 'actual' and 'current' to mean different things?
"Actual boost is not considered for this, only the difference between the current boost and the target." "Actual" boost is used to calculate the difference though I assume? Or are you using 'actual' and 'current' to mean different things?
Yes the actual boost is used to calculate the error. The target boost is filtered through an exponential smoothing function so that sudden changes don't affect measurements, and then the actual boost read from the MAP sensor is subtracted from this value, and that's the error. When I said actual boost isn't used, what I really meant was that there isn't a fixed, absolute threshold for triggering those blink codes. It's not my fault, I think the isolation is getting to me
To disassemble the code I used asm48. For the actual binary image, I just got it from here. That thread provided a few useful starting points too, but I've gotten much deeper into it. I found pdfs of a few old documents that were absolutely essential:
The official 8048 series manual
MCS48 Assembly Language Reference Manual
I did a lot of tracing and probing of the pcb too, to find out which pins and ADC channels are connected to what.
I plan to post everything I found, but it'll be too much for a rennlist thread so I'll have to think of something else!
