Adding ALDL scanner support to MPGuino

[FalconFour]

*facepalm* You screwin' with the newbie's head here? Lol...

Okay, let me draw you a picture.

[car computer..] aldl "data" ------- 160 baud stream of info ------- [ arduino ]
or "ECM" ........] aldl "b" [ --v .. 10k .. v ]
....................] aldl "a" [ --^ resistor ^ ]

Rheeeeleeey not as difficult as it's being made to sound. Add 10k resistor to (separate) A and B pins, get 160 baud stream of data from the computer on the "data" pin (just one pin, grounds to car). There are 8192 baud variants, usually OBDII systems I think, but mine is 160 baud.

You mean you've never played with this stuff before, like, at *all*? =o

[dcb]

I am reading some contradictory information on the web is all, nothing insurmountable, might take some trial and error. If you know your vehicle is for sure 160 baud then good on ya

[toc]

Did this end up going anywhere?
I'm keen to give this a shot - but the VSS might prove problematic.

[FalconFour]

Not really... I haven't done much Arduino work lately, my half-baked car alarm design is still sitting on my desk at home after I basically got shat on by the Arduino community for posting my work-in-progress. Kind of uninspired to work with anything Arduino after that point. /sigh

[toc]

Ahh from the thread:
"The criticism was not directed at the code or the concept. It was directed at the "I haven't tested this, but I KNOW it will work" attitude."

As always, third parties have an opinion - I won't add one here.
Or will I. I like the idea, I want to do it.

I'll be giving it a go on my Hyundai Sonata, which has a 12 pin connector.
What I'm lost on and can never seem to find an answer to is the conflicting information out there.

This page mmcdlogger. sourceforge.net suggests the data is request / response. You must ask for data to get it.

But, I recall reading that there is a data stream, i.e. you simply listen and process the data that comes along the pin 1 - but the baud rate - I've seen 160-baud, 8192-baud and 1953-baud all mentioned as being the rate used.

I'm not sure what to expect - and I want to go to arduino.

Perhaps someone knows the answers ?
- What is the baud rate?
- Is there a data stream, or must all data be requested?
- Does pin 10 and 12 get shorted for data ?


I also did some checking yesterday too with my multimeter:
- Pin 1 and 12 - this bounces around between 11-13V and 0V with key and engine on.
- Pin 11 (Speed) and 12 stays at 4.69V with the engine on. I haven't checked for variations here.

This link mmcdlogger. sourceforge.net says the speed can be requested by ECU.
What's the point of the speed sensor PIN in the ALDL circuit? I think it's duplicated if that's the case, the ECU has speed sensor input, as does pin 11.

[FalconFour]

Well I can 110% completely and totally guarantee and verify that the 160-baud ALDL data on my '87 Fiero is a constant receive-only stream, the computer simply chugs out that data whenever a 10k resistor is put across the ALDL mode pin (open = normal operation; 10k = ALDL diagnostic stream; shorted = diagnostic mode, blinks codes & runs engine in timing mode). The ALDL cable used to read this data only uses one serial pin, Rx, and a simple TTL level-converter circuit (to bring it to proper serial signalling voltages). Then software samples the broken data at ~8192 baud (since 160-baud is non-standard), and interprets the data. Since the Arduino impementation would be all software, it would seem to be very simple to read the incoming data stream natively (at 160 baud, or hell, using interrupts, it could be any reasonable data rate) without needing to do any electrical conversions.

So I think that answers all the questions:
1) Baud rate is 160 baud, at least on my old OBD1 car. Yours may be completely different. OBD2 uses a completely different format and nothing about ALDL from OBD1 will be compatible.
2) It's a constant outgoing data stream, no data can be sent back to the computer; the computer doesn't have any facility to receive commands or any sort of data at all.
3) The pins - and I'm not sure what they're named/numbered (I believe they're referred to as "A and B") - need to be shorted with a 10k resistor.

But I think the key here is, what year is your car?

[toc]

1997 here. I was just reading about the 10k resistor requirement.
1997 in USA was definitely OBDii - however my vehicle is from Korea and has the older connector.
The 1995 Sonata seems to be a close match.

Engine in the car is a G4CP which equals a Mitsubishi 4G63 - which from my further reading is a 1G DSM.

Pin 10 - do I short to ground, or place a 10k resistor between it and ground?

[toc]

Digging further and further (and still not on any proven beaten track as yet), I've had a look at pocket logger's DSM cable installation steps where it's plain to see a jumper from 10 to 12 and data on 1.

There's no mention of the baud rate there, so that's still in the wind.

I've got some LCD displays coming, as I can't have the laptop, car and arduino connected at the same time (I think).

When they come, I'll put some code on the arduino to show on the LCD each baud rate and result - thus finding which baud rate is right.

[toc]

I tried to connect and use an arduino library for serial output to some wireless gear I have.

The wireless gear is receiving and sending data fine.

The connection to the car is - Pin1 to Arduino TX.
Pin 10 tied to pin 12 (ground), and this also goes to the arduino for ground (i.e. 10 goes to 12, 12 goes to GND on arduino).

I then set code to loop 30000 times waiting for data to be available on the serial port, so, Serial.begin(160), then loop 30000 times to see if any data came through. None. I tried 160, 8192, 1953, 1960, 1920 - none of these gave out any data.

As a last effort, I added Serial.print(0x21), just before each of the loops, to see if I had to ask for the data, and at the arduino, connected a jumper between TX and RX.

Still nothing.

But I think the problem there is I was using Serial.print, instead of Serial.write

Assuming what I've noted above is correct, then there is no data stream on those baud rates (else I would have got something output).

I'll try serial.write later, in which case, the data must be requested, and not the stream that I'd like to have!

Any recommendations on what else I could try ?

[dcb]

Originally Posted by toc

...

But I think the problem there is I was using Serial.print, instead of Serial.write

...

Perhaps something more like a serial read would be in order?