3
\$\begingroup\$

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):

logic analyzer

(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?

\$\endgroup\$
  • \$\begingroup\$ It's unclear what exactly you are asking here. But one very practical thing you can do to check assumptions is disconnect from the test system and transmit with your PC and compare how that looks on the scope. Asynchronous serial data as your PC serial gadgets can handle is LSB first and depending on where in what circuit your are looking at, a logic "1" could be either high or low. \$\endgroup\$ – Chris Stratton Apr 7 at 16:05
  • \$\begingroup\$ @ChrisStratton at this stage I was asking how could I determine which kind of parity that DSO signal has and why would the serial analyzer be able to interpret it regardless of the parity setting. But I like your suggestion, I will send some ASCII from the USB-RS485 dongle and try to interpret it on the DSO and maybe that will shed some light on the incoming data :) \$\endgroup\$ – xfze Apr 7 at 16:13
  • \$\begingroup\$ please add a data dump to your post (the data seen at bottom of first picture) ..... add as much as you can ....... some of those bytes appear to be field length and possibly field type \$\endgroup\$ – jsotola Apr 8 at 4:17
  • \$\begingroup\$ Try to recognize patterns and split things by line there. Histogram of byte values may help you find likely headers, time gaps could work too (logic analyzer view will make those obvious). Personally I'd work with hex dumps not mixed. \$\endgroup\$ – Chris Stratton Apr 11 at 15:56
  • \$\begingroup\$ @ChrisStratton I got the logic analyzer and figured out I should take some steps back before trying to interpret data bytes. As I am now thinking maybe it's not 8 bit so all those bytes previously dumped could have been wrong. \$\endgroup\$ – xfze Apr 13 at 18:59
1
\$\begingroup\$

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.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.