DME real time stuff

[johnb]

I'm working on documenting the details of the real-time part of the DME program.

I don't know if we have gotten into this here before, but you can think of the DME software as being divided into 2 main parts - the real-time part and what you might call the main loop. The main loop does the calculations, reads inputs, looks up maps etc. The real time part generates the actual timing-critical output signals.

The real time part is interrupt driven and the main loop just runs whenever it's not being interrupted. That's a very rough generalization that I'll explain in more detail in future. But so far everything I've posted here has been map related stuff from the main loop part. And there's still a ton to do on that side of things. I'm not finished covering that stuff by any means, but I decided to change tack for a little while and get into the real time side of things. Broadly speaking the real time part is much shorter and simpler than the main loop stuff.

Here's my high level overview of the crank sensors and what the DME does with the signals it gets from them.

https://jhnbyrn.github.io/951-KLR-PAGES ... dware.html

I have a detailed code walkthrough for the same stuff, but I wanted to drop this first because it lays the groundwork for understanding the code. There won't be a lot of pictures in the code walkthrough!

This is almost all the real time stuff. There's a bit more that happens just after ignition, including some last-minute fuel calculations and dithering, and other than that it's just the very simple PWM signal for the idle stabilizer. I'll cover those some other time.

I hope this helps someone, and as always feedback is welcome, whether you think there are mistakes or you just have ideas for how it could be clearer.

[whalenlg]

Great work John!

I’m working on 2 related projects:
-An XDF parser written in Python (that can also merge in the 80+ new maps we’ve been discussing that are not in the normal XDFs).
It generates Excel files, json files and XDF files. This is almost complete.

-A DME simulator - still very early exploration. Back in the late 80s I designed real time 8751 based laser printer controllers/video processors that had very similar main loop/interrupt routine assembly code to what you describe, so it will be interesting to start recovering those memories. Your work will be a key reference for that effort.

[spacecad3t]

This is all very cool, keep it coming!

[Evan]

Great overview. The high-level explanation of the real-time interrupt handling versus the main loop is very clear. Your site is a fantastic resource for understanding these DME systems. Looking forward to the code walkthrough.

[johnb]

OK here's the code walkthrough: https://jhnbyrn.github.io/951-KLR-PAGES ... _code.html

It's hard to know if this is a good explanation or not. It's accurate, but this code didn't make complete sense to me until I had read it a few times, thought about it a bit etc. So I hope my explanation makes it easier and not harder to understand.

An interesting thing I realized when I first started reading the ignition stuff: the engine needs both sensors to start, but once started, it will keep running with only the speed sensor.

The reason is actually pretty simple - it always had to be capable of generating the timing for the second cylinder in the rotation without a reference sensor pulse, since there's only one such pulse per revolution. So it had to have the logic to calculate the timing for the second cylinder relative to the first. But once you have that logic, the simplest thing to do is just let it run all the time. Thus the engine will use the ref sensor to re-sync on every revolution, but as long as the speed sensor signal is consistent, it's not necessary. If the speed sensor drops the occasional pulse for one reason or another, then a working ref sensor signal will stop things from drifting too far.

Once I realized this I tested it and sure enough, my car keeps running when I unplug the ref sensor, and it drives normally.

[Tom]

OK here's the code walkthrough: https://jhnbyrn.github.io/951-KLR-PAGES ... _code.html

It's hard to know if this is a good explanation or not. It's accurate, but this code didn't make complete sense to me until I had read it a few times, thought about it a bit etc. So I hope my explanation makes it easier and not harder to understand.

An interesting thing I realized when I first started reading the ignition stuff: the engine needs both sensors to start, but once started, it will keep running with only the speed sensor.

The reason is actually pretty simple - it always had to be capable of generating the timing for the second cylinder in the rotation without a reference sensor pulse, since there's only one such pulse per revolution. So it had to have the logic to calculate the timing for the second cylinder relative to the first. But once you have that logic, the simplest thing to do is just let it run all the time. Thus the engine will use the ref sensor to re-sync on every revolution, but as long as the speed sensor signal is consistent, it's not necessary. If the speed sensor drops the occasional pulse for one reason or another, then a working ref sensor signal will stop things from drifting too far.

Once I realized this I tested it and sure enough, my car keeps running when I unplug the ref sensor, and it drives normally.

Been busy the last few days, but looking forward to studying your latest write-ups. Pretty interesting to learn the car runs without the ref sensor. I guess that means if the car dies intermittently when running, it's more likely the speed sensor.

[whalenlg]

-An XDF parser written in Python (that can also merge in the 80+ new maps we’ve been discussing that are not in the normal XDFs).
It generates Excel files, json files and XDF files. This is almost complete.

This is now ready to go

https://github.com/whalenlg/xdf_parser

It takes an XDF file, a map file (manually created, but I provide 24 pin and 28 pin examples) and a bin file.

Will create
-merged .xdf file that takes the original xdf and adds in new maps/constants/scalars from the map file
-Excel files and JSON files that have extra tidbits like the Results of calculating XDF Math functions with input from the bin file provided - which gives us all the XDF maps + Extracted Bin Values + Calculations in 1 file without having to run TunerPro.

Also - there are a number of sample bin and XDF files (including the CarPokes ones) in the download and a run_all script that runs 5 different .XDF files through

Thanks to Tom and others for providing the bread crumbs I needed to get this working.

Adding an example output - can be loaded into TunerPro