Reverse-engineering RS-485 communication

Question

I've been trying to reverse engineer the communications protocol used by my home domotics, which I was able to determine uses a RS-485 implementation.

I'm using a USB RS-485 serial dongle and an oscilloscope and it's not been easy so far (I've ordered a cheap logic analyzer to see if I can get further).

So far I've determined that it uses 38.400k baud rate (26 µs cycles on the DSO) and 8 bit data (7bit on the serial analyzer makes no sense EDIT: haven't tried 9 bit when wrote this, maybe it's 9 bit... full edit below).

At this stage I'm dumbfounded on which kind of parity, significance and stop bits it is using.

---EDIT---

(for clarification of the question(s) being asked, premature data dumps were removed and added new data from the logic analyzer that arrived in the meanwhile):

(full-time stamp dump link)

this is the start of what I'm sure it's a timestamp that's sent every minute (that ASCII string will read space-yymmdd.... so we know those 3 bytes must always read ' 19'). Messing around with the settings on the logic analyzer software I seem to conclude that:

• there is no parity bit (parity errors with either odd/even)

• 8 bits per transfer always results in framing errors (regardless of 1, 1.5 or 2 stop bits) unless I use "special mode multidrop bus" which frames the extra bit as the address for the first byte and everything seems to fit (those are the settings of the screen dump above: 8b/2stopbits/MDB)

• I can also "fit" everything without framing errors if I interpret it as 9 bits per transfer without MDB.

what I'm trying to figure out: data bits per transfer (8? 9 bits?) stop bits (1, 1.5, 2?) and could this be a multi-drop bus communication protocol?

Answer 1

data bits per transfer (8? 9 bits?)

Looks like 9. Unusual, but this happens sometimes.

stop bits (1, 1.5, 2?)

This actually looks like 3 or 4 stop bits to me -- but it does not really matter. As long as you only receive data, set your receiver to "1 stop"; any extra bits will be just an idle line.

and could this be a multi-drop bus communication protocol?

Quite possible -- the last bit does look kinda like address select. But it should not matter that much for packer reception.

It seems that now you have enough information to start collecting the data. You'd want to collect at least 20 data packets, then put it into spreadsheet and stare at them for a while. Here is a good example: Reverse Engineering the Maverick ET-732. It is about RF device, but once you got the bits, it does not matter where they come from.

You'd want to record all 9 bits of data, and depending on your dongle, this can be hard. On Linux, you can set PARMRK,INPCK,PARENB,CMSPAR flags together to get your bit 9 info via special escapes in the input stream (see termios(3) for details). However, this requires support from your usb-serial chipset, and in generally, quite a pain. You may be better off scripting your DSO, making a converter from fast Arduino, or just manually saving lots of traces.