Possibly a bug in the auto_analyse_raw_data.py LSB

[danielegobbetti]

Version/revision of the library used

master

Describe the bug

The LSB output of auto_analyse_raw_data.py inverts also the byte order: the last bytes in the message are the first in the LSB line.

To Reproduce

1. invoke

python ../auto_analyse_raw_data.py 4831, 2322, 674, 526, 676, 499, 700, 500, 700, 1701, 649, 527, 673, 527, 673, 552, 648, 526, 647, 553, 646, 555, 644, 557, 617, 558, 642, 1759, 642, 532, 642, 558, 642, 559, 642, 1733, 642, 1760, 642, 1734, 641, 559, 641, 559, 615, 559, 641, 559, 641, 559, 641, 533, 641, 1760, 641, 559, 615, 559, 642, 559, 641, 559, 641, 533, 641, 559, 641, 559, 641, 559, 615, 559, 642, 559, 642, 559, 641, 533, 641, 1761, 641, 559, 615, 559, 641, 559, 641, 559, 642, 1734, 641, 559, 641, 559, 615, 560, 641, 560, 641, 1735, 640, 560, 640, 560, 640, 1735, 641, 560, 640, 560, 640, 534, 641, 560, 640, 560, 640, 560, 614, 560, 641, 1761, 641, 1735, 640, 560, 640, 560, 614, 560, 640, 1761, 640, 534, 640, 560, 641, 560, 640, 560, 614, 560, 641, 560, 641, 560, 640, 534, 640, 560, 641, 1761, 614, 1762, 639, 560, 641, 534, 640, 1762, 639, 561, 613, 561, 640, 560, 640, 561, 640, 534, 640, 561, 640, 560, 640, 561, 613, 561, 640, 561, 640, 560, 640, 535, 639, 561, 639, 561, 640, 561, 613, 561, 640, 561, 640, 561, 639, 535, 639, 561, 640, 561, 639, 561, 613, 561, 640, 561, 639, 561, 640, 535, 639, 561, 640, 561, 639, 561, 613, 561, 640, 561, 639, 561, 640, 535, 639, 561, 639, 561, 640, 1736, 639, 1762, 639, 535, 640, 1763, 638, 1737, 638, 1763, 639, 535, 639, 561, 640, 1763, 612, 562, 639, 562, 639, 1737, 638, 1763, 639, 1737, 639, 1763, 638, 1737, 638, 562, 638, 1737, 638, 562, 639, 562, 639, 1737, 638, 562, 638

Output:

kHdrMark+kHdrSpace+0001000000001000111000000100000000000010000100001001000000011000100000000011001000000000000000000000000000000000001101110010011111010010
  Bits: 136
  Hex:  0x1008E040021090188032000000003727D2 (MSB first)
        0x4BE4EC000000004C011809084002071008 (LSB first)
  Dec:  5456316067435403463698198552088411580370 (MSB first)
        25825466884167960157015528131029681770504 (LSB first)
  Bin:  0b0001000000001000111000000100000000000010000100001001000000011000100000000011001000000000000000000000000000000000001101110010011111010010 (MSB first)
        0b0100101111100100111011000000000000000000000000000000000001001100000000010001100000001001000010000100000000000010000001110001000000001000 (LSB first)

2. Notice how the last 8 bits of MSB are correctly reversed in the LSB representation, but are also at the beginning of the string! This is true also in the HEX lines

Example code used

Nothing else as written above

Expected behaviour

The LSB representation should reverse the bits in each byte, but the byte should remain in its position.

As a side note, I noticed this strange behavior while reversing the IR protocol of my York AC device. I found the structure and am now working on the checksum. It seemed strange to me that the checksum bytes were at the beginning (the protocol uses LSB) . Perhaps this is a know behavior and not a bug, but I found no notice in the source file.

[NiKiZe]

This should be consistent with how the library works.
Protocols might not be byte based.

What you say makes sense for this protocol, but maybe not for every protocol.

[crankyoldgit]

@danielegobbetti Sorry, but this is working as intended.
The code/program is reversing the bit order of an integer, not an array. In your example, an 136 bit integer is correctly displayed in MSB and LSB. The more appropriate structure to store said integer may be as a byte array, but that is not what the tool offers or smart enough to work out.

It's provides a first approximation, not a definitive "This is how you should structure this data" etc.

[crankyoldgit]

Oh, and FYI:
0x1008 (16bit MSB) is also 0x1008 (16bit LSB)
e.g.
0b0001000000001000 is 0b0001000000001000 when reversed.

[danielegobbetti]

Many thanks for the clarification and sorry for the noise. I am used to reversing BT/BLE messages and in that case the byte endiannes is a variable but the bits on the wire are always kept as they are. Of course those are all byte-based protocols so to each their own :-)
I hope to figure out the checksum bytes soon and contribute this protocol.