ODB1 serial protocol

Hello. I previously posted a Q over in TunerPro and got a good answer, but in reality I don't want to just read the log file, I'd rather read the data coming off the ECU. So I googled the web, and there are tons of dead links. What I did find was an explanation of the two ODB1 modes - streaming data, or the later version where you request the data and it sends it back.

I am looking for technical information on how to read that data. I already have a serial connector that works with TunerPro. So I'm just interested in the software layer. Thanks!

160 baud cars send data without being polled for data, or you might have to place a 10k resistor across pins a-b to get the data flowing. They send about 25 bytes every second. 8192 baud cars require a poll/request for data, then will respond with around 60 bytes of data. Most 1980 vehicles were 160 baud, most 1990 vehicles were 8192 baud, but there are many exceptions. Google search for 'ALDLstuff.zip' to find the archive of all the protocol definitions. Look at the 'index' file for your application. Chew on those files a little bit and then ask here for more help!

Found it, chewed on it. It is very close to what I need. The only part missing is the packet format. There was some talk given, but not enough. Like it specified a length, say 0x57, but no packet format to tell me how to lay it out. It only gave a handful of values... Not enogh to fill 0x57 (87) bytes worth. I also need to know the codes to request things like RPM, MAP, etc. And how to calc the checksum.

Hi Scorp! What is the vehicle application? Did you figure out which Axxx file to use yet? You won't get back 87 bytes. There is an offset you must subtract for the 87 (can't remember what it is, but it is easy to figure out; not really important if you know the Axxx file). In the Axxx file for your application, it will tell you specifically the packet to send, like F4,57,01,01,XX, where XX is the checksum, and 01, 01 is the mode and message number. The Axxx file will also tell you what the response will be; something like F4,95,01,(63 data bytes), XX. The Axxx file will tell you what each of the 63 bytes in the packet mean (RPM, temp, speed, etc.). Some of the 8192 cars need special messages sent to them to disable comms before you start asking for messages. Let everyone know what you need help with to get started.

Quote:

---

Originally Posted by Scorp1us

Found it, chewed on it. It is very close to what I need. The only part missing is the packet format. There was some talk given, but not enough. Like it specified a length, say 0x57, but no packet format to tell me how to lay it out.

---

that depends entirely on the vehicle, you'll have to tell us what ecm and mask you're working with. there's no standard.

Quote:

---

It only gave a handful of values... Not enogh to fill 0x57 (87) bytes worth.

---

probably an incomplete list. again, what mask are you working with?

Quote:

---

I also need to know the codes to request things like RPM, MAP, etc.

---

there's likely no way to accomplish that in your mask. usually you request an entire packet of data. that is unless it's a 160 baud ecm. 160 baud ecms do not recieve data, only send it. but since you mention checksumming, it's probably 8192, it seems most 160 baud ecms didnt even use a checksum.

Quote:

---

And how to calc the checksum.

---

here's what i wrote in c to do it, you can easily translate to whatever language

Code:

---

unsigned char checksum_generate(unsigned char *buf, int len) {
  int x = 0;
  unsigned int sum = 0;
  for(x=0;x<len;x++) sum += buf[x];
  return ( 256 - ( sum % 256 ) );
};

int checksum_test(unsigned char *buf, int len) {
  int x = 0;
  unsigned int sum = 0;
  for(x=0;x<len;x++) sum += buf[x];
  if(( sum & 0xFF ) == 0) return 1;
  return 0;
};

---

Thanks. C is fine.

I have an A297.


Oh, so I only request the packet, I don't get to specify what is in it?

Hi Scorp-
So do you mean you are trying to implement the A297 protocol? 1995 Corvette CCM?

If so, you would want to send (Mode 8 disable comms):
$F1, $56, $08,CHECKSUM

Then you would want to verify you received:
$F1, $56, $08,CHECKSUM

Keep doing the above until you receive the message back. It may take a few times, because your message may collide with another message on the bus.

After that, send Mode 1, Message 0 request:
$F1,$57, $01,$00,CHECKSUM

The CCM will reply back with:
$F1,$7A, $01, 36 data bytes, CHECKSUM

The 36 data bytes will contain the data specified in A297.

that pretty much sums it up for 8192 baud stuff

keep in mind that the first byte in a request or reply is the 'device address' on the bus you're requesting the data from (obviously 0xF1 in this case)

the second byte is the message length byte, which is (mysteriously) the actual message length in bytes plus 0x52 (some kinda gm magic number)

then the mode byte then message byte then blah blah then checksum.

there's there rest of my codebase if you want to play with it, there are more functions to abstract aldl communications a little bit? my data acquisition event loop has lots of features for stream stability and error checking, and generally maxes out throughput

https://github.com/resfilter/aldl

Oops I meant A219 It's a 94/95 5.7L auto c/k 1500. BJYL

Cool, with this info, I should be all set!