Cynics Soapbox

RF Controller - Part 2

david reid -

Looking at the data shows it to be nicely consistent, but how is it formatted?

Packet Format?

The SPIRIT1 datasheet gives details of 3 different packet formats that can be chosen.

  • STack
  • Wireless M-Bus
  • Basic

Wireless M-Bus packets would have a postamble but the packets being detected do not have a sequence of bytes that would indicate such a thing.

#Assumption #3 - It's not using Wireless M-Bus packets.

The preamble for both remaining packet formats is a number of bytes consisting of 10101010. Here are the first 41 bytes of the first 6 packets detected by URH.

0                                       40
-----------------------------------------
01010101010101010101010101010101010101010
01010101010101010101010101010101010101010
01010101010101010101010101010101010101010
01010101010101010101010101010101010101010
01010101010101010101010101010101010101010
01010101010101010101010101010101010101010

 10101010
         10101010
                 10101010
                         10101010
                                 10101010

This appears to be a 5 byte preamble.

Assumption #4 - There is a 5 byte preamble configured.

Both packet formats next specify a number (1 - 4) of sync words. Each is 1 byte, so looking at the next 32 bytes we see,

0                              31
--------------------------------
01011010010001110101001001010000
01011010010001110101001001010000
01011010010001110101001001010000
01011010010001110101001001010000
01011010010001110101001001010000
01011010010001110101001001010000

01011010                          = 0x5A
        01000111                  = 0x47
                01010010          = 0x52
                        01010000  = 0x50

These are stable for the messages which appears to suggest that they use a 4 sync words.

Assumption #5 - There are 4 sync words which are 0x5a475250.

Both packet formats next have an optional length parameter which is listed as between 0 and 16 bits. The next 16 bits we encounter are

0              15
----------------
0011110111101110
0011111111101001
0011111111101001
0011111111101001
0011110111101110
0011111111101001

For comparison, the lengths of the detected packets are

1: 552 bits = 69 bytes
2: 264 bits = 33 bytes
3: 264 bits = 33 bytes
4: 264 bits = 33 bytes
5: 552 bits = 69 bytes
6: 264 bits = 33 bytes

It doesn't look like we have those lengths contained in the 16 bits.

Assumption #6 - There is no length field.

Could this be an address field? We have a sender and receiver involved in the conversation so we could have 2 different addresses. Each would be 8 bits.

0      7
--------
00111101  = 0x3d
00111111  = 0x3f
00111111  = 0x3f
00111111  = 0x3f
00111101  = 0x3d
00111111  = 0x3f

We do appear to only have 2 values, so this could well be an address field. I will need to check with a different controller and receiver to see if there is any difference.

Assumption #7 - We have an address field.

If the packet format was STack we should have a destination address as the next 8 bits. Do we?

0      7
--------
11101110  = 0xee
11101001  = 0xe9
11101001  = 0xe9
11101001  = 0xe9
11101110  = 0xee
11101001  = 0xe9

Again we only have 2 values, but if these are source addresses then I would expect them to relate to the previous destination address, which they obviously don't. Additionally the STack packet format has 3 bits that would not fit with what we are seeing being an exact multiple of 8.

Assumption #7 - We have a Basic Packet format.

More to come...

Suggestions or assistance always welcome!