Reversing serial RS485 half duplex bus protocol understanding

Question

I have a master & slaves setup in which the slaves only respond when spoken too. I can snoop & record an existing master/slaves conversation. I have an extra slave device that I would like to have my own conversation with, but have so far failed miserably. I suspect that each device has its own unique ID, but have no idea what my extra slave devices ID is.

What I know from a logic analyzer & days worth of studying:

• messages start with 0x10
• prior to message end is a 2 byte CRC-16/MCRF4XX, little endian (thanks: reveng!)
• messages end with 0x1003

Suspicions:

• first byte is a message type identifier, I've observed ~12 unique message types based on this. Each message 'type' based on this has the same length.
• second byte might ??? be a destination device id ???. Based on this suspicion I took the first 20 unique messages, inserted 255 different ID's into this byte, and sent each of them (correctly packetized with start + data + crc + end) - it did not respond to any of them.

Data sample from the bus during startup, I removed the start, crc & end bytes:

0xff020300010400
0x09510000
0xff01030002ffff
0xff020300013c03
0x01000000
0x350d0000
0xff01030002ffff
0xff020300020200
0x02007400...big packet with lots of text from a slave A...
0x340d7400...big packet with lots of text from a/the master?...
0xff010300010000
0xff020300010800
0x09510000
0xff01030003ffff
0xff020300030200
0x02007400...big packet with lots of text from a slave A...  (exactly the same as prior 2 big packets)
0x340d7400...big packet with lots of text from the master or yet a third slave?... (exactly the same as prior 2 big packets)
0x0952040000000080
0xff010300010000
0xff02030001101000
0x09510000
0xff01030004ffff
0xff020300040200
0x02007400...big packet with lots of text from a slave B...
0x340d7400...big packet with lots of text from the master or yet a third slave?...
0x0952040000000080
0xff010300010000
0xff020300012000
0x09510000
0xff01030005ffff
0xff020300050200
0x02007400...big packet with lots of text from a slave B...  (exactly the same as prior 2 big packets)
0x340d7400...big packet with lots of text from the master or yet a third slave?... (exactly the same as prior 2 big packets)
0x0952040000000080
0xff010300010000
0xff020300010400
0x09510000
0xff01030002ffff
0xff020300020200
0x0952040000000080

Answer 1

Sounds a lot like my recent CAN bus sniffing. Ha! That's funny, RS485 is a popular alternative to CAN. :P

A few quick thoughts:

• You're not terminating your "RE" master node properly.
• You need to check the very first comms to see if there is an opening sequence, such as to establish privilege.
• I see numbers incrementing in your output. That's definitely not on accident.
• Are the big packets all the same size? If not, there will be a length value somewhere in the packet. You'll need some kind of program to go through each packet checking if any byte or word matches the length of the total packet or length following (and also with / without CRC+0x1003).

Googling for RS485 half duplex bus protocol crc 0x1003 led me to a few interesting PDFs about protocols. Unless the makers are hideously paranoid, they'll be using something "normal" on the RS485 bus:

• Modbus (can have ASCII or TCP frames). I haven't studied TCP frames, but wouldn't surprise me if that could be source of the incrementing values.
• CANopen maybe? Why not it's a protocol... :P
• This PDF result from the google above lists all kinds of different protocols I haven't heard of before.

I'd set up a chipKIT uC32 with multiple UARTs in the middle with a "master" side and a "slave" side. You'll probably need the "driver" or "transceiver" ICs for each circuit. Oh, an Arduino might work, but the 80MHz PIC32 in the chipKIT rocks. Once you can relay messages and the system keeps working, you'll know a lot more about what's going on. Physically and signal-wise.