Chamberlain 8 bit code encoding drops 3rd bit (counted from LSB)

[FalcoGer]

Describe the bug.

Related: https://github.com/derskythe/flipperzero-subbrute/issues/2

When generating a signal with the brute force application, 9 and 7 bit signals have 11 symbols each. 8 bit signals only have 10 symbols. Recording and playing back the radio waves is accepted by the flipper's SubGHz reader. However bit 3 is completely ignored, making it a 7 bit code. The signal that is encoded from 0x4 (0000 0100) is exactly the same as the signal encoded from 0x0 (0000 0000).

From what I understand the brute force application uses the same library as the SubGHz reader, so the cause is probably here. The fact that the SubGHz reader accepts the malformed package is further proof of that.

Reproduction

1. Send and record a 8bit chamberlain signal from the brute force application with code 0x4 (004/255)
2. Start the SubGHz reader
3. Play it back
4. Receive Chamberlain signal '0'

Target

Flipper Zero

Logs

No response

Anything else?

Signals for 000/255 and 004/255, recorded with hackrf. Both played back result in signal '0' received

For flipper zero accepted chamberlain encoded signals, 8 bit is out of place because it's missing a symbol for data bit 3.

Probable correct encoding

9bit: S D8 D7 D6 D5 D4 D3 D2 D1 D0 S

Probably either of those:
8bit: S D7 D6 D5 D4 D3 D2  S D1 D0 S
8bit: S D7 D6 D5 D4 D3 D2 D1  S D0 S

7bit: S D6 D5 D4 D3 D2 D1  S  S D0 S

Current, probably incorrect encoding

9bit: S D8 D7 D6 D5 D4 D3 D2 D1 D0 S
8bit:    S D7 D6 D5 D4 D3  S D1 D0 S, D2 dropped
7bit: S D6 D5 D4 D3 D2 D1  S  S D0 S

[derskythe]

Sub files for example, both of them shows value 0x03 on second Flipper

Filetype: Flipper SubGhz Key File
Version: 1
Frequency: 390000000
Preset: FuriHalSubGhzPresetOok650Async
Protocol: Cham_Code
Bit: 8
Key: 00 00 00 00 00 00 00 03

Filetype: Flipper SubGhz Key File
Version: 1
Frequency: 390000000
Preset: FuriHalSubGhzPresetOok650Async
Protocol: Cham_Code
Bit: 8
Key: 00 00 00 00 00 00 00 07

[Skorpionm]

packet format is different

even in the decoder there is a comment that in 8 bit, in fact, only 7 DIP (bit) data are used, nothing is missing in the decoders, everything is decoded correctly. and what is written in the carters was written by people in whose hands, as I understand it, not when there were no real devices. and the question to them is why they did it

[FalcoGer]

So the 8 bit key is in fact a 7 bit key. Why is it labeled 8 bit then? Are you telling me there is a dip switch in the remote, that does nothing. At the same time there is a 7 bit version with 7 dip switches that all do something? And they use completely different message formats?

That English is very broken. What was written by who?

[Skorpionm]

I can't tell you. I wrote the protocol on the remote control https://aliexpress.ru/item/4000510675855.html?gatewayAdapt=glo2rus&sku_id=10000002489390591

and the protocol itself is called so.

[skotopes]

@FalcoGer I think what @Skorpionm is trying to say is that some dip switches are unused and protocol expects some those bits always be high.

[skotopes]

It will be nice if someone will test it with real remotes

[skotopes]

Long time no activity, please reopen if you have new data.