Looking for DME BIN files

[Tom]

While we're waiting for that, Tom have you noticed any subtle changes besides the steady-state idle speed? I ask because reading the code, I noticed that there's a map that seems to be used for an rpm flare, for startup and possibly also for coasting with the throttle closed. These are higher rpm values that replace the normal idle target rpm, but are then decreased gradually until they get back down to the normal target level for the current temp.

Does you rpm flare up above idle now more than before when starting? Or when rpm is dropping with closed throttle, does it linger above idle a little before settling down? I haven't figured out the logic 100% but I think it's pretty close to what I'm describing here and it doesn't seem to be used the same way in the alternate path that your car was using.

I know of a similar parameter in the M-Tune called 'Idle Return Delay' that affects how quickly the ISV decrements down to idle speed once the idle switch is triggered. The stock chip uses 2, my stock APE chip uses 4 and the M-Tune uses 6. I have a lightweight flywheel with an aluminum clutch pressure plate which has very little momentum. Sometimes when I push in the clutch the idle speed would drop too quickly and undershoot the idle rpm, then surge back up a little. I tried adjusting this up to 10 and the idle was nice and smooth with no surging or hunting, but there were times when the idle would stick around 1500rpm and wouldn't drop lower. Right now I'm using 8 and it works well.

For the idle falling below target after boosting with a MAF, I found on my car that the MAF signal (DME pin 7) would take too long to return idle-friendly voltage levels. When I monitored the pin 7 voltage, I could see the MAF voltage was still up well over 1 volt as the rpm's dropped to 800, effectively flooding the motor. In bad cases, the motor would die if you'd stab the clutch after flooring it. It was a pretty common problem back in the day. The early MAFs were the worst, but the M-tune seemed to have its own unique set of idle issues -- I believe mostly from Josh trying to program around the voltage issue with delays etc. I ended up making an idle controller for my car (when I ran the MAF). It would watch the pin 7 voltage and the TPS, and would switch over to an idle friendly voltage anytime the TPS idle switch was closed shortly after exceeding boost-level voltage. It had two buttons to learn and store the cold-idle and hot-idle voltage levels, and would interpolate an idle voltage based on temp. Made for a rock solid idle with none of the quirks of m-tune. Ultimately, however, my propensity to make tack-on boxes for every little issue was probably what led me to my current electronics austerity program.

[Dave W.]

know of a similar parameter in the M-Tune called 'Idle Return Delay' that affects how quickly the ISV decrements down to idle speed once the idle switch is triggered. The stock chip uses 2, my stock APE chip uses 4 and the M-Tune uses 6. I have a lightweight flywheel with an aluminum clutch pressure plate which has very little momentum. Sometimes when I push in the clutch the idle speed would drop too quickly and undershoot the idle rpm, then surge back up a little. I tried adjusting this up to 10 and the idle was nice and smooth with no surging or hunting, but there were times when the idle would stick around 1500rpm and wouldn't drop lower. Right now I'm using 8 and it works well.

Interesting, thanks! In the code that uses this, the stock chip uses 2 in some cases and 1 in others. It's hard to figure out the meaning of the flags that control it but I'm pretty sure the other purpose of this routine is to make the engine flare on startup and then sink back down to the target idle. If you're interested in tweaking it for any reason it's the byte right after the 02 (i.e. 11F9=02 and 11A0=01).

Also, when it got stuck using 10, which chip was that? I'm not sure why that would happen.

I'm using a 1990 Autothority chip. It came with the car so all my chip mods are based on it.
I think the idle hang was due to a section of the map that had ideal timing and fuel values, so the ISV had to close more, plus it took longer to close. The 'ISV Base Value Map' commands ISV to open more as rpm goes up. I may have hit a step on that map that holds ISV too far open.

[Tom]

know of a similar parameter in the M-Tune called 'Idle Return Delay' that affects how quickly the ISV decrements down to idle speed once the idle switch is triggered. The stock chip uses 2, my stock APE chip uses 4 and the M-Tune uses 6. I have a lightweight flywheel with an aluminum clutch pressure plate which has very little momentum. Sometimes when I push in the clutch the idle speed would drop too quickly and undershoot the idle rpm, then surge back up a little. I tried adjusting this up to 10 and the idle was nice and smooth with no surging or hunting, but there were times when the idle would stick around 1500rpm and wouldn't drop lower. Right now I'm using 8 and it works well.

Interesting, thanks! In the code that uses this, the stock chip uses 2 in some cases and 1 in others. It's hard to figure out the meaning of the flags that control it but I'm pretty sure the other purpose of this routine is to make the engine flare on startup and then sink back down to the target idle. If you're interested in tweaking it for any reason it's the byte right after the 02 (i.e. 11F9=02 and 11A0=01).

Also, when it got stuck using 10, which chip was that? I'm not sure why that would happen.

I'm using a 1990 Autothority chip. It came with the car so all my chip mods are based on it.
I think the idle hang was due to a section of the map that had ideal timing and fuel values, so the ISV had to close more, plus it took longer to close. The 'ISV Base Value Map' commands ISV to open more as rpm goes up. I may have hit a step on that map that holds ISV too far open.

Yeah, probably a whole different issue than the MAF cars. I had an Autothority chip from that era, with banjo bolt. On my bone stock car at the time, I loved that chip -- perfect street manners with a massive seat of the pants power increase. Of course, I couldn't leave good enough alone....

[944m3]

My car came with that chip too and Powerhaus 27k hybrid turbo. First few days I drove it in the rain and I gunned it. Lost traction in a blink on an eye and fishtailed around a bend. Scared the hell out me but wow what a feeling.

Question around the idle code. For our Bosch ICV is the frequency in hertz mentioned in the code? Does it have a PID function with values?

[johnb]

My car came with that chip too and Powerhaus 27k hybrid turbo. First few days I drove it in the rain and I gunned it. Lost traction in a blink on an eye and fishtailed around a bend. Scared the hell out me but wow what a feeling.

Question around the idle code. For our Bosch ICV is the frequency in hertz mentioned in the code? Does it have a PID function with values?

The frequency is determined by the 8051's timer1 interval. The interval is chosen primarily to make engine speed measurement convenient (it counts the number of flywheel teeth that pass the sensor in one timer interval).

IIRC it's 87Hz.

First and foremost the valve is controlled by an open loop. There's a map of engine speed vs temperature and that map gives the baseline pwm duty cycle.

For idle and some other conditions, the baseline pwm is modified by a closed loop routine, but I would call it PI based on what I've seen (there doesn't seem to be a derivative term, unless I'm missing something).

First an error is calculated (target rpm - current rpm). That error is used as to lookup a gain map and the gain value is multiplied by the error to give the correction. The correction is added to the baseline value with a few other modifications (e.g. AC on). That's the proportional part.

But the error is also tracked over many cycles as a running total - this is the integral part. It does get reset under certain conditions but I haven't tracked them all down yet.

The units in the maps don't translate in a simple way to duty cycle. They get scaled various ways before ultimately getting turned into "how many timer ticks to count before toggling the valve from open to closed". I'll come up with a formula that translates the map units into % duty cycle eventually but for now I don't have it.

The thing about reading this kind of code is that you never really know anything until you know everything. There could always be some condition somewhere else in the code the negates what you're looking at or overrides it somehow. Many of the things I said in this thread before are like that.

For instance I previously said there are 2 gain maps for rpm-under-target correction, and one for over-target. That's true but it turns out that the code for 2 of them is unreachable. I also explained how the map from Rogue's XDF (0x655) worked as an idle load limit depending on temperature. That is true and the code is reachable, but its effect is later overridden by the main ISV routine so that it doesn't do anything. There's a lot of dead code in the ISV routine.

[Tom]

John, you are a treasure trove of info! Thank you for posting all of this! I am working to build a new XDF for the 951, which I'll post when done, mostly cobbling together tables from the other XDF's out there, but also correcting things like the idle thank to your help. I'm now trying to build an ignition dwell table. There is an XDF on the TunerPro site that shows 0x3FA as the start of a 2-axis dwell table with 7 voltage levels on one axis and 12 rpm levels on the other axis. Here's what it looks like with a stock BIN:

per TunerPro site.jpg (189.37 KiB) Viewed 344 times

Both the RPM and Voltage values are hard coded into the XDF (i.e., typed in by whoever made the XDF), and they differ from what other people (like @Dave W. ) have posted on other sites. Does this look like the right location for the dwell table? And are the actual axis values in the code? The other tables I've seen use 40, 80, 160, 320, 480, 640, 800, 1440, 2080, 2280, 3840, 5240, and 6480 for RPMs (all of which are multiples of 40, so seem more likely real); and 6, 8, 10, 12, 14, 16, 16.4 as volts. I've scanned the BIN for a string or matching RPMs to no avail...

[johnb]

John, you are a treasure trove of info! Thank you for posting all of this! I am working to build a new XDF for the 951, which I'll post when done, mostly cobbling together tables from the other XDF's out there, but also correcting things like the idle thank to your help. I'm now trying to build an ignition dwell table. There is an XDF on the TunerPro site that shows 0x3FA as the start of a 2-axis dwell table with 7 voltage levels on one axis and 12 rpm levels on the other axis. Here's what it looks like with a stock BIN:

per TunerPro site.jpg

Both the RPM and Voltage values are hard coded into the XDF (i.e., typed in by whoever made the XDF), and they differ from what other people (like @Dave W. ) have posted on other sites. Does this look like the right location for the dwell table? And are the actual axis values in the code? The other tables I've seen use 40, 80, 160, 320, 480, 640, 800, 1440, 2080, 2280, 3840, 5240, and 6480 for RPMs (all of which are multiples of 40, so seem more likely real); and 6, 8, 10, 12, 14, 16, 16.4 as volts. I've scanned the BIN for a string or matching RPMs to no avail...

This does seem to be the right location but you're correct the RPM values are wrong. The real ones are what you posted except 80 (you posted 13).

I found this note I wrote from when I looked at the dwell table before:

So for instance, for 800rpm and 14v I have the value 18.

Multiplying this by 1.363 (degrees per half-tooth) I get 24.54 degrees dwell time.

Now 800rpm is 75 milliseconds per rev, or 0.2ms per degree.

So that gives ~5.1ms dwell time.

Also a while back someone posted this and I remember checking it and coming to the conclusion that it was correct:

stock_dwell_map.jpg (24.35 KiB) Viewed 343 times

But it was a while back!


I'll put this on my list to double check. FWIW the way the map axis values are stored is hard to read directly. When a value is being looked up, the program takes the input variable and adds it to the rightmost axis value, then adds the next one to the left, and so on until the add results in an overflow. That's how it decides which column to read (but it ultimately does an interpolation to get more accurate in-between values).

So take the first one from the right for rpm in this map (5Eh = 94 decimal). You'd have to add 162 to that to get an overflow, so the right most map heading for the rpm axis is 162*40 = 6480

I'll have to take a closer look to see what the voltage axis values are.

[Tom]

Oh my -- you are divil from RL? Did I know that and forget? I should have known! I'll need to digest your answer and look at the BIN, and will then probably have a million more questions. Did you ever do a github datadump on the DME like you did for the KLR?

edit: yes sorry I added the 80 -- just a mental-o...

[johnb]

Oh my -- you are divil from RL? Did I know that and forget? I should have known! I'll need to digest your answer and look at the BIN, and will then probably have a million more questions. Did you ever do a github datadump on the DME like you did for the KLR?

edit: yes sorry I added the 80 -- just a mental-o...

Lol yeah that's me and I'm pretty sure you knew that at some point!

I never got into the DME code like I did with the KLR but I am doing it now because this thread piqued my interest again...it's time consuming though!

[Tom]

Sorry about that. My memory isn't what it used to be. I'm having hard time following the RPM axis structure. What cell does the 5E represent in your example? In the table I posts, the value in the table is 24 (decimal) for 4000 rpm at 14v. I'm not following how it gets to 4000? I guess that means there would need to be a 156 somewhere in order for 100 to be the overflow (since 100 * 40 = 4000). Just kind of lost.