By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,630 Members | 1,166 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,630 IT Pros & Developers. It's quick & easy.

Help with pyserial and sending binary data?

P: n/a
Hello,

I am working on a python library for sending and receiving data from a Subaru's ECU (the fuel injection computer) via the OBD-II port and an OBD to USB cable, with the Subaru Select Monitor protocol. There are a few open source programs that do this already (http://romraider.com/ , http://jdash.sourceforge.net/ , http://tari.co.za/downloads/software/source/ ), but they are written in Java or C++. I have never done anything with serial before, and very little with binary data, so this is all new to me.

The SSM protocol is fairly simple - a request packet (all in binary, represented in hex) consists of a header (0x80), destination byte (0x10 for the ECU), source byte (0xf0 for the diagnostic tool - AKA your computer), Payload length in hex, the Payload, which is one of 6 known commands(0xA0 Read memory, 0xA8 Read single address, 0xB0 Write memory, 0xB8 Write single address, 0xBF ECU init) and addresses or address range, then the checksum byte, which is the 8 least-significant bits of the sum of the rest of the request packet.

A returned packet consists of a header, destination byte (your computer), source byte (ECU), payload size (all data between payload size and checksum byte), and the same checksum byte. Further reading (pretty good documentation on the protocol) is here: http://tari.co.za/downloads/documentation/ssm.pdf , but that is the basics to at least say hi to your car from your computer.

So I've been messing with it, and in as few lines as possible, this should in theory, send the init command to the ECU (0x80 0x10 0xF0 0x01 0xBF 0x40), and the ECU should return its ID to let you know that you can now chat (something like 0x80 0xF0 0x10 0x39 0xFF 0xA2 0x10 0x0F 0x1B 0x14 0x40 0x05 0x05 0x73 0xFA 0xEB ......):

#--------------------------
import serial, string
output = " "
ser = serial.Serial('/dev/ttyUSB0', 4800, 8, 'N', 1, timeout=1)
ser.write(chr(0x80)+chr(0x10)+chr(0xF0)+chr(0x01)+ chr(0xBF)+chr(0x40))
while output != "":
output = ser.read()
print hex(ord(output))
#--------------------------

The only problem is that when I send the ECU init command, it just echos back the data I sent it, which, from my understanding, means that I sent an invalid request packet. I'm guessing that there aren't many people on this list with OBD-II subarus and an open port cable ( http://www.tactrix.com/product_info.php?products_id=36 ) that could test this out, but in the off chance there is, perhaps you could help. I've been chatting with the RomRaider developers ( http://www.romraider.com/forum/topic3129.html ) on the subject, but they are Java guys, not Python guys. There is more encompassing code there, but something lies wrong in my basic implementation above.

My best guess I have heard is that chr() isn't encoding the hex value properly to a byte value the ECU understands (wrong endianness?), or chr() encoding isn't always representing hex as an 8-bit byte. chr() should always encode to an 8-bit byte (not 7-bit ASCII or anything, correct)? Is there any way to switch byte endianness, or ensure I am encoding 8-bit bytes? Any help is much appreciated. Thanks!

-rich

__________________________________________________ __________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i...Dypao8Wcj9tAcJ
Jun 27 '08 #1
Share this Question
Share on Google+
1 Reply


P: n/a
Rich <ri*********@yahoo.comwrote:
I am working on a python library for sending and receiving data
from a Subaru's ECU (the fuel injection computer) via the OBD-II
port and an OBD to USB cable, with the Subaru Select Monitor
protocol.
[snip]
So I've been messing with it, and in as few lines as possible, this
should in theory, send the init command to the ECU (0x80 0x10 0xF0
0x01 0xBF 0x40), and the ECU should return its ID to let you know
that you can now chat (something like 0x80 0xF0 0x10 0x39 0xFF 0xA2
0x10 0x0F 0x1B 0x14 0x40 0x05 0x05 0x73 0xFA 0xEB ......):
>
#--------------------------
import serial, string
output = " "
ser = serial.Serial('/dev/ttyUSB0', 4800, 8, 'N', 1, timeout=1)
ser.write(chr(0x80)+chr(0x10)+chr(0xF0)+chr(0x01)+ chr(0xBF)+chr(0x40))
while output != "":
output = ser.read()
print hex(ord(output))
#--------------------------
The code looks OK.

With a constructor which takes as many arguments as Serial does I tend
to name them to avoid mistakes, eg

serial.Serial("/dev/ttyUSB0", baudrate=4800, bytesize=8, parity='N', stopbits=1, timeout=1)

8N1 is documented as the default so you could then reduce it to the
following if you wanted

serial.Serial("/dev/ttyUSB0", baudrate=4800, timeout=1)
The only problem is that when I send the ECU init command, it just
echos back the data I sent it, which, from my understanding, means
that I sent an invalid request packet.
My experience with these sort of protocols is that if you make a
packet error (wrong address, wrong checksum, wrong start byte) you'll
get no reply at all.

If you make a command error (use a command that isn't understood in a
valid packet) you'll get a properly formatted reply with an error
message in. This should start 0x80 0xF0 0x10 .... (from and to
reversed).

I'd suspect that if you are just receiving the data back then you have
got your serial cable wrong and have somehow looped tx and rx. Did
you try your cable with the other programs? Or possibly you are using
the wrong serial port - are you sure you haven't any other USB
serials? ls /dev/ttyUSB* on a udev system will show you. lsusb (as
root) is useful as is dmesg immediately after plugging the port in.

I do a lot of this sort of thing at work (not with cars though with
satellite equipment) and it is always the first packet and the first
response which is the hard part. After that it is usually plain
sailing!

--
Nick Craig-Wood <ni**@craig-wood.com-- http://www.craig-wood.com/nick
Jun 27 '08 #2

This discussion thread is closed

Replies have been disabled for this discussion.