Re: Help with pyserial and sending binary data?

Rich <richietommy@xxxxxxxxx> wrote:
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
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)
while output != "":
output =
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

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

Nick Craig-Wood <nick@xxxxxxxxxxxxxx> --