Carpokes

Tom wrote: Sat Sep 13, 2025 11:00 am

johnb wrote: Fri Sep 12, 2025 8:06 pm 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...?

johnb wrote: Sat Sep 13, 2025 11:10 am

Tom wrote: Sat Sep 13, 2025 11:00 am

johnb wrote: Fri Sep 12, 2025 8:06 pm 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...?

Yes except that should be -20.8c (also I need to update the temp values I used in the map reading article I wrote because I had a rougher formula then). I'm not sure if I follow your last question though - the -20.8 would apply to all temperatures up to that point (with no interpolation) if that sheds any light on it?

JHY wrote: Thu Sep 18, 2025 1:38 pm Incredible thread. You guys are doing the lord's work!

I actually just picked up an 86 951 (nearly 20 years since my last 86 951) and am working on sorting it out. It has an LR M-Tune setup but it does not run well, which led me down a quick but steep decent into DME/tuning developments over the past few decades.

Does anyone happen to have an XDF for the LR M-Tune setup offhand? I hope that doesn't come across as trying to pilfer IP—I actually have the product and just want to dive for diagnostic assistance/future optimization

I'm about to buy an Ostrich Tuner (and considering one of F9's DMEs) but want to be sure I can read my current files, first.. and I'm *assumung* a standard 951 DME XDF wouldn't translate the M-Tune bin—given the apparent MAF transfer recoding and MAP sensor integration, etc...

Thanks all, looking forward to following along and hopefully jumping in!

JHY wrote: Thu Sep 18, 2025 1:38 pm Incredible thread. You guys are doing the lord's work!

I actually just picked up an 86 951 (nearly 20 years since my last 86 951) and am working on sorting it out. It has an LR M-Tune setup but it does not run well, which led me down a quick but steep decent into DME/tuning developments over the past few decades.

Does anyone happen to have an XDF for the LR M-Tune setup offhand? I hope that doesn't come across as trying to pilfer IP—I actually have the product and just want to dive for diagnostic assistance/future optimization

I'm about to buy an Ostrich Tuner (and considering one of F9's DMEs) but want to be sure I can read my current files, first.. and I'm *assumung* a standard 951 DME XDF wouldn't translate the M-Tune bin—given the apparent MAF transfer recoding and MAP sensor integration, etc...

Thanks all, looking forward to following along and hopefully jumping in!

Dave W. wrote: Fri Sep 19, 2025 8:59 am
Here's some good info on the LR M-Tune. https://www.lindseyracing.com/LR/Parts/M-TUNE.html
Basically, the chip holds 14 different and complete ROM images, the dip switches select which section of the chip to use.
I'd recommend that you start with the tune that matches your mods, then use the FQS switch to adjust the tune. I'd recommend that you have a wideband O2 sensor installed for accurate feedback. If that doesn't give good results, extensive chip hacking can be done using an Ostrich, TunerProRT and a chip burner to upload the chip file to your laptop to view with TunerPro. Then you'll need to use the map tracer function in TunerPro to find which one of the 14 tunes you're using. This can be tedious. Once you find which section of the chip you're using, then you can begin manually searching the raw hex file for individual maps. By the time you're done, you'll be a pro! (hint: this may take a long time).

JHY wrote: Fri Sep 19, 2025 1:58 pm

Dave W. wrote: Fri Sep 19, 2025 8:59 am
Here's some good info on the LR M-Tune. https://www.lindseyracing.com/LR/Parts/M-TUNE.html
Basically, the chip holds 14 different and complete ROM images, the dip switches select which section of the chip to use.
I'd recommend that you start with the tune that matches your mods, then use the FQS switch to adjust the tune. I'd recommend that you have a wideband O2 sensor installed for accurate feedback. If that doesn't give good results, extensive chip hacking can be done using an Ostrich, TunerProRT and a chip burner to upload the chip file to your laptop to view with TunerPro. Then you'll need to use the map tracer function in TunerPro to find which one of the 14 tunes you're using. This can be tedious. Once you find which section of the chip you're using, then you can begin manually searching the raw hex file for individual maps. By the time you're done, you'll be a pro! (hint: this may take a long time).

Thanks Dave!

I've found that the "newer" version of the LR M-Tune is a bit different than Josh's OG version (and LR's initial version). The original used a daughterboard with the 4 dip switches beneath, whereas the newer version is just a 28pin chip with no daughterboard/dip switches. There is a jumper wire you can use (in the DME harness, external to the DME) to activate a second tune on the later version (not sure if the original used this jumper wire feature or not).

What I have no idea of, is how different the control strategy/calibration is between the two versions—but I'm assuming the XDF/BIN is different for each version.

I think deciphering the Hex file is within my curiosity, but beyond my skills Particularly because I suspect that a lot of the M Tune code is completely different and not just "rescaled" or manipulated tables (i.e. 3+ WOT inputs compared to stock 2 axis table, WOT timing outputs, etc.)

Anyway, looking forward to learning more, this is all super interesting. Thanks again for the huge baseline of work you guys have all done here!

JHY wrote: Sat Sep 20, 2025 6:44 am Regarding hardware/software for bin extracting/writing—any issues with Moates Burn2+ TunerPro for 28 pin?

Open to any suggestions or recommendations!