New project - DME tester

[ischmitz]

It's been a while since I gobbled together a 3.2 DME bench tester. Back then I used a lame counter to generate a reference pulse from a speed signal that itself was an output from a simple VCO. not very elegant and not suitable to drive a later DME.

However, lately I get more and more 964 and 993 units and testing in the car isn't always practical. So I want to build a test stand for those as well.

First task: Come up with a flywheel simulator.. There are some options out there but none appealed to me. So here is what I came up with: a Freescale MC9S12 MCU off eBay for cheap and an LCD display I had floating around. With a some C programming I finally got a working prototype that accepts commands via one of its serial ports from the PC to adjust RPM and O2 sensor duty cycle. It puts out text with RPM and O2 status on the LCD display. C is an alien concept to say the least..... It was quite a struggle to understand its concepts and embedded programming in general. Fortunately Freescale offers a pretty powerful IDE for free.



The next shot shows 4 of the outputs when simulating a 964 running at 2000 RPM: from top to bottom,:

- The yellow trace is the flywheel signal with 60-2 pattern.
- The cyan trace is the Hall sensor going off ever other turn at 720 degrees
- The purple is the RPM signal
- The green trace is the TDC signal that can be used for triggering later



Next I need to build some driver and interface circuits to buffer the signals before hooking them up to a DME for testing.

Ingo

[jpnovak]

Looks like you are doing just fine...

Outside the library development C functional code is usually pretty easy to get trough. I still can't write a functional header or library file.

I thought of using a Megasquirt JimStim with the built in wheel coder as an interface. All the signals are present and you could jumper in a signal for the air meter. This might be easier than starting from scratch.

[ischmitz]

I need to look that JimSim up. We once did an MegaSquirt-II project and at the time there was a windows utility that uses the sound card to produce FW signals

[ischmitz]

I looked up the jimstim - pretty neat. It uses a small 8-bit Freescale MCU and play back a tooth file stored in flash. It a nice and elegant solution with an extremely small footprint. And it shines with its ability to reproduce all these different modern flywheels. Very cool indeed.

There is only one drawback: The resolution of this approach is one degree. Unfortunately, that won't work for the 3.2 flywheel with 129 teeth since its teeth transitions are not exactly multiples of one degree. I guess most modern flywheels are 60-2 or even lower tooth count with uneven gaps where the DME can decode absolute position.

I guess in comparison my solution is like shooting with the proverbial cannon at a sparrow: I just had that 16-bit MCU board and with silicon prices being so low these days it really doesn't matter. I count teeth and specify at what count a "missing tooth" or other signal (RPM, ignition, Hall) has to appear or disappear. With this it would be nearly impossible to do all these exotics like the jimstim but doing 129 (3.2 DME) or 130 (944 DME) or 132 (944 Turbo) is just changing a single number and recompile. Not as elegant but then, I just picked up that C business.

I created one library with its own header file to handle the LCD display output. Even a conditional pre-processor statement in the header. But there are still mysteries as to how some of my variables are handled internally. The compiler does some odd optimizations that sometimes lead to funny (read unpredictable) results in an embedded system.

[jpnovak]

Yes. the Carrera Flywheel tooth pattern creates some issues. There is an Audi (can't remember which one) that has the same count. There was talk about coding for this count but I am not sure if that ever worked out.

I guess we need to ask Sal how the Motronic handles the count. I know that the reference pin has a lot to do with the reset of the count and degree interpretation.

[ischmitz]

I know Sal disassembled the entire Motronic code for the 3.2. He really got to the bottom of things. He gave me a lot of great pointers when I did some disassembly on that and the 964.

My current 3.2 DME bench tester uses a simple ripple counter to produce the reference pulse by counting the speed pulses from a function generator IC. A set of DIP switches can set the count. It works but using an ICL8038 and DIP switches seems a bit outdated when all these embedded MCUs can be bought for a song and a dance.

That's why I wanted to do the programming rather than using something that already existed. This way I can modify and expand stuff to my needs.

Cheers,
Ingo

[scarceller]

Ingo,

Nice job on the pulse generator.
The motronic counts flywheel teeth over a give time window. In the code we have the speed sensor directly tied to an interrupt and every time the interrupt is generated it increments a RPM counter. Then we also have a timer that runs for an 11.628ms window so that every time the timer pops it grabs the RPM counter and sets that as the current RPM and then it resets the counter back to 0 and restarts the timer right before the timer routine returns.

The basic principle is that it just wants to know how many teeth it saw in a 11.628ms window and that's the current RPM. Basically the code updates the current rpm every 11.628ms.

The reason we use 11.628ms is because it's directly related to the number of teeth on the flywheel, the formula works out to this:
timer acquisition time = 60000ms\rpmMultiplier\numteeth

60,000 is the number of milliseconds in 1 minute.
Then in our cars the rpm multiplier is 40 and the tooth count is 129

so:
60,000/40/129=11.6279ms

Then one other interrupt is used for the ref sensor just so the code knows where the flywheel is just prior to TDC so it can then properly start dwelling the coil for the 3 spark events in every crank rev.