>>> Just a thought - I'm assuming you're sniffing using a baud rate of 9600 with no parity & 8 data bits. Have you tried using using parity and 7bit?
Ah good point.
I'm a bit slow in keeping the thread updated but a fair amount of progress has been made and I'm now successfully faking up some sensor replies.
When I started out, being impatient, I waved the scope at it for 5 secs and it seemed to show A & B the right way round at 10KHz frequency so I thought '9,600 baud, probably TRU, off we go....' and fired up some serial code and started logging.
Well, while I could see some polls and responses at 1 sec intervals, the data that came back looked a bit rubbish. In particular it varied too much. Barring some wacky encryption scheme, I expected the sensors to send back mostly the same temperature data from second to second - which is, of course, what they do.
OK so I fired up the scope for a more careful look around:
So, there's the 1 sec poll and response I saw before (screen dump #1), then every 6 secs an extra little poll and response is done (screen dump #2). I disconnected all the sensors (as suggested) and saw only 7 byte polls - all are 7 bytes long and each starts with 0x1104 except for the extra little poll which starts with 0x1204 (screen dump #3). Also, by looking at enough packets I saw that they're probably 8 / N / 1, although nali's point is noted.
I measured the frequency a bit more accurately and came up with (screen dump #2) ... 19,690 Hz. Actually, if I use 19,200 baud I get dodgy data and if I use 19,690 everything is good.
The clincher came when I checked the last two bytes of each packet against a modbus CRC calc ... and good data...
OK so that left me the slowish job of twiddling the options on the sensors, observing the packets and seeing where the data was. It's a mess, all sorts of stuff tucked away on odd byte and bit boundaries and with odd lengths. Definitely not RTU. But decoded nevertheless.
Result.
Thanks everyone for your useful comments and suggestions.
Alan