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
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 <nick@xxxxxxxxxxxxxx> -- http://www.craig-wood.com/nick
.



Relevant Pages

  • Re: Help Interpreting data from Wireshark
    ... What concerns me is that the packet seemed to have a source address of 192.168.1.1 but later in the packet you see the dest as 84.160.95.226 ... Protocol Info ... DENVER.local ICMP Destination unreachable (Port unreachable) ... Fragment offset: 0 ...
    (comp.os.linux.security)
  • Sygate Firewall warning
    ... Ethernet II (Packet Length: 76) ... Internet Protocol ... Header checksum: 0x76cd ... Source port: 1161 ...
    (alt.computer.security)
  • Re: mystery martian source from 127.0.0.1 - more details
    ... 2005 22:33:57.-11226009 Time delta from previous packet: 0.000000000 seconds Time since reference or first frame: 0.000000000 seconds Frame Number: 1 Packet Length: 60 bytes Capture Length: 60 bytes Protocols in frame: eth:ip:tcp ... Bad: False Source: 127.0.0.1 Destination: 80.219.238.182 Transmission Control Protocol, Src Port: http, Dst Port: ...
    (comp.os.linux.security)
  • FW: IANA Reserved IP Source scans 55808
    ... same Source Port and Same destination port. ... Time delta from previous packet: ... Protocol: TCP ... Header checksum: 0x4f0b ...
    (Incidents)
  • Re: Unknown Data Sent After Initial IP Connection
    ... mechanisms of the windoze browser model. ... It ends with a 'Microsoft Windows Browser Protocol ... > Time delta from previous packet: ... > User Datagram Protocol, Src Port: nbdatagram, Dst Port: ...
    (comp.security.firewalls)