Adding ALDL scanner support to MPGuino

[FalconFour]

Anyone ever thought of this? Pulling in the 160 baud data from the computer and interpreting its sensor and error code data?

I know it'd be a relatively large undertaking, but with the framework already in place in the MPGuino's code (interrupts and such), I think a lot of the work is already done... electronics won't be too complicated since the whole protocol would be implemented in interrupt instead of using a dedicated serial interface (most ALDL interfaces use a complicated signal-conversion to read the non-standard 160 baud data). I think, at least...

I know code is already pretty tight, but maybe more room can be found in a custom firmware by removing some of the personally-unneeded features like metric values and features for other homebrew MPGuinos (I have a prebuilt one bought just a few weeks ago).

Figure it's worth throwing the idea out there, maybe get some input

[dcb]

only briefly, seen any source code for a PC based ALDL reader lately?

[FalconFour]

Not exactly, although I can pretty closely theorize as to how the program works. Most of it is putting the data in the GUI, and another good part of it is adapting the broken data from the serial interface running at 9600 baud to the data coming in at 160. I'd take some references to figure out what parameters are what bytes in the stream and how to interpret them, but for the most part it would have to be entirely custom to this Arduino platform.

I'd figure this flow of the system:
In an interrupt, or at some timed part of the program, check that the appropriate timing for 160 baud has passed (count loops based on the system used for injector timing, maybe?). When it has, and a new bit needs to be read, read the bit and add it to the end of the current "data set" stream - the set of parameters that gets looped every second or so by the car's computer. When the data set is completed and it starts to loop again (there's got to be something in the stream that indicates the end?), parse the interesting values in the data stream and move them into their appropriate variables (RPM, temp, error codes, etc). Rinse and repeat. In the routine that interprets data and draws the display, these values would be used.

Oversimplifying? :/

[dcb]

I might start with an arduino and maybe some bitbanging on the aldl port and leave the uart port for debugging w/a laptop. The obduino code has some 300 baud bitbanging (at least for output) in it, fyi.

found a little data here on the aldl protocol:
Information on GM's 160 baud ALDL data stream

160 baud is slow enough that a firmware only solution sounds very possible.

[FalconFour]

That definitely sounds like an idea. I've got a Duemilanove that first got me interested in Arduino projects, that I haven't really done much of anything with. I imagine I can use the same sort of signal-filtering setup used in the MPGuino for VSS to "safe up" the signal? I'm really not that familiar with the electronics side of things, although I've been dinking with electronics projects all my life, I never had any formal education on the matter... I'm more a computer programming/repair kind of guy. So I can probably do the code once I put my nose to the grind-keyboard

But I take it 160 baud ALDL isn't all that popular, even for GM... if I did end up doing it, it might have to be a one-off thing for each car's computer, since the different ECMs put out different bits of data in different ways, and to keep the code small, the value positions and interpretations (such as reading some gibberish integer as 95.4 degrees F) would have to be hard-coded for each system.

Sure would be nice to have, though. Definitely gotta go pick up my Arduino from my friend's place... been sitting in a box over there for months

[dcb]

actually reading looks pretty straightforward. If you use the external interrupts, one on the rising edge and one on the falling edge and keep track of the time between them, the 1's will be short blips and the zeros will be longer, just need to figure out a threshold in between them.

then stream the bits received into some thing to keep track of the messages. It can do things like "oh, I got 9 ones in a row, this must be a new message block"

you can set both pins to input and gang them together and protect with a resister and 5v zener, like the guino.

The output pin basically needs to drive a transistor to toggle 12v to the aldl port.

A timer interrupt to stream the output bits to aldl might simplify timing, or complicate it.

[FalconFour]

Well, the best part is, the computer accepts no inputs, so it's all reading, no writing It just takes a 10K resistor on the "mode" pin to make the computer start rambling 160-baud data, in a simplex stream, then it's up to the receiver to figure out what the gibberish says. That's why I think it wouldn't be too difficult to implement, since it's basically just another timing-and-computation sort of thing, similar to reading the VSS.

Thanks for the tip on the zener, though, that'll definitely help simplify things, I wasn't sure how the system would interpret approximately zero volts for a "low" signal, but a zener sounds like just the trick.

[dcb]

I'm confused about where 160 baud is used and whom is talking to whom in the aldl exchange. But the attached circuit should be a good starting point, set one pin for the rising trigger and the other for the falling, and manually use a jumper for start the aldl spewing data.


There is also a pulsein function, but I don't know if arduino supports it, or if you can reset it in time. I think it blocks program execution by default as well. arduino programmers are generally not accustomed to the quasi-threaded environment of interrupts.

[FalconFour]

COOL, thanks for the schematic! May sound silly but that really helps, simple as it is.

As for the ALDL data exchange, what I mean is, it's not really so much an "exchange" as much as a simplex data stream that goes on even with nothing plugged in to interact with the computer (as long as that 10k resistor is installed in the "A-B" positions to tell it to start spewing). So there's no data the Arduino needs to send back, it just needs to listen

Think I've got all the info I need to get started, at least until I get my Arduino board back. Thanks!!

[dcb]

oops, looks like a 5v signal? use a 10k resistor if it is 5v I guess. Sorry, not the aldl expert

according to the connector pics, it looks like 160 baud is australian?
GM 8192/160 Baud ALDL Interface and the 12 pin is US @ 8192 baud? 5 volts?

also: "Early ECUs produced a fixed 8192 ALDL data stream when the user placed a 10k ohm resistor between ALDL connector pins A and B. Later ECUs added internal receive circuitry"

so still some unknowns about baud and voltage levels and the directionality of the exchange in my head.