rtl_433
rtl_433 copied to clipboard
merbanan
Add support for Schrader MRXBC5A4 / MRXBMW433TX1 (BMW)
Based on BMW partnumbers MRXBMW433TX1 replaces MRXBC5A4 and they seem to have the same protocol
S: sync 1 wake bit, 13 sync bit, 1 start bit
is that 10...01 then?
TT should be TTTTTTTT right?
Are there really no checksum bits at the end? How strange.
Correct about TT. It is indeed strange. There are one or two bits between pressure and temperature that may be some kind of checksum or parity. Needs to be tested. BTW i captured the packet using URH and the captured files are .complex16s is this compatible with any of the formats supported by rtl_433? It is detected as 'Input format: CU8 IQ (2ch uint8)' but does not decode. other formats failed.
The raw format of the RTL-SDR is CU8, which URH has as complex16u, the complex16s is a signed conversion, rtl_433 currently does not support this.
Got my hands on an RDC test Tool and was able to do more digging. Turns out there are 2 bits for data integrity just before temperature byte. Temperature looks like it is not validated Pressure is at 2kPa/bit, verified by sending data via SDR to vehicle Tested all combinations of flag bits (first 3 bits), value 010 seems to be an ACK that sensor has gone to sleep mode. Trying now to figure out data integrity methode. Here is some sample data that are validated by the tool:
| Data | Integrity | Note |
|---|---|---|
00000100010010000000001010000000001 |
11 | Sensor data |
11100100010001101010010011001101010 |
10 | Sensor data |
11100100010001101010010011000000000 |
01 | Sensor data |
00000100010001101010010011000000000 |
01 | |
00100100010001101010010011000000000 |
00 | |
01000100010001101010010011000000000 |
11 | |
01100100010001101010010011000000000 |
10 | |
10000100010001101010010011000000000 |
00 | |
10100100010001101010010011000000000 |
11 | |
11000100010001101010010011000000000 |
10 |
Looking at the data in a BitBench it seems strange: 2nd and 3rd row are the same but different "checksum"? And ordering the values doesn't seem to count in the checksum. edit: updated to corrected codes
Looking at the data in a BitBench it seems strange: 2nd and 3rd row are the same but different "checksum"?
There was a typo in copy paste of values. Fixed
The second check bit could be (odd)parity on even numbered bits. Count the 1s with the format string 1b1x and compare.
I am thinking whether the serial number is excluded from parity since if it has error it will not be picked up at all
The second check bit could be (odd)parity on even numbered bits. Count the
1s with the format string1b1xand compare.
This seems correct
Digging further in the error checking, it is almost certain that the second check bit (C2) is parity. The first check bit (C1) seems to be affected by the actual number of ones on all bits. Flipping 2 odd bits does not change C1 but if 2 odd bits go from 0 to 1 C1 changes
| Odd | C2 | Even | C1 |
|---|---|---|---|
| 7 | 0 | 7 | 1 |
| 7 | 0 | 8 | 0 |
| 8 | 1 | 7 | 0 |
| 8 | 1 | 7 | 0 |
| 8 | 1 | 8 | 1 |
| 8 | 1 | 8 | 1 |
| 9 | 0 | 7 | 0 |
| 9 | 0 | 8 | 1 |
| 7 | 0 | 8 | 0 |
| 8 | 1 | 8 | 1 |
| 9 | 0 | 8 | 1 |
| 10 | 1 | 8 | 0 |
| 10 | 1 | 9 | 1 |
| 10 | 1 | 10 | 0 |
At this point C2 parity check is implemented in code
Wild guess, C1 then could be the upper bit of a 2-bit counter? Or generally some bit of a counter/sum.