Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende ÜberarbeitungNächste ÜberarbeitungBeide Seiten der Revision |
hardware:vaillantvrt340f [2017/05/03 19:57] – reinhold | hardware:vaillantvrt340f [2017/05/05 16:34] – reinhold |
---|
- [[hardware:vaillantvrt340f|Part 1: The physical layer - Reading the wireless signal and extracting the bytes]] | - [[hardware:vaillantvrt340f|Part 1: The physical layer - Reading the wireless signal and extracting the bytes]] |
- [[hardware:vaillantvrt340f_protocol|Part 2: Decoding the protocol]] | - [[hardware:vaillantvrt340f_protocol|Part 2: Decoding the protocol]] |
- __(Part 3: Including a wireless receiver in OpenHAB - Yet to be done)__ | - //[[hardware:vaillantvrt340f_implementing|Part 3: Including the device in rtl_433 and potentially in RFLink or OpenHAB]]// |
| |
| |
During my tests of the wireless control, I collected various different signals. Trying to group them into octets for bytes, except for one nonet 101111101 (the second part will reveal that this is the only grouping that makes sense!): | During my tests of the wireless control, I collected various different signals. Trying to group them into octets for bytes, except for one nonet 101111101 (the second part will reveal that this is the only grouping that makes sense!): |
| |
| ''00000000\ 00000000\ 01111110\ 10110110\ 01101111\ 00000000\ 00000100\ 00000000\ 00000000\ 00010001\ 00101101\ 00000000\ 101111101\ 10000010\ 11111111\ 000000000'' | | | ''00000000\ 00000000\ 01111110\ 10110110\ 01101111\ 00000000\ 00000100\ 00000000\ 00000000\ 00010001\ 00101101\ 00000000\ __101111101__\ 10000010\ 11111111\ 000000000'' | |
| ''00000000\ 00000000\ 01111110\ 10110110\ 01101111\ 00000000\ 00000100\ 00000000\ 10000000\ 00010001\ 00101101\ 00000000\ 101111101\ 00000010\ 11111111\ 000000000'' | | | ''00000000\ 00000000\ 01111110\ 10110110\ 01101111\ 00000000\ 00000100\ 00000000\ 10000000\ 00010001\ 00101101\ 00000000\ __101111101__\ 00000010\ 11111111\ 000000000'' | |
| ''00000000\ 00000000\ 01111110\ 10110110\ 01101111\ 00000000\ 00000100\ 00000000\ 00000000\ 00010001\ 00000000\ 00000000\ 101111101\ 10101111\ 11111111\ 000000000'' | | | ''00000000\ 00000000\ 01111110\ 10110110\ 01101111\ 00000000\ 00000100\ 00000000\ 00000000\ 00010001\ 00000000\ 00000000\ __101111101__\ 10101111\ 11111111\ 000000000'' | |
| ''00000000\ 00000000\ 01111110\ 10110110\ 01101111\ 00000000\ 00000100\ 00000000\ 10000000\ 00010001\ 00000000\ 00000000\ 101111101\ 00101111\ 11111111\ 000000000'' | | | ''00000000\ 00000000\ 01111110\ 10110110\ 01101111\ 00000000\ 00000100\ 00000000\ 10000000\ 00010001\ 00000000\ 00000000\ __101111101__\ 00101111\ 11111111\ 000000000'' | |
| ''00000000\ 00000000\ 01111110\ 10110110\ 01101111\ 00000000\ 00000100\ 00000000\ 00000000\ 00000001\ 00000000\ 00000000\ 101111101\ 10111110\ 11111111\ 10000000000'' | | | ''00000000\ 00000000\ 01111110\ 10110110\ 01101111\ 00000000\ 00000100\ 00000000\ 00000000\ 00000001\ 00000000\ 00000000\ __101111101__\ 10111110\ 11111111\ 10000000000'' | |
| ''00000000\ 00000000\ 01111110\ 10110110\ 01101111\ 00000000\ 00000100\ 00000000\ 00000000\ 00000001\ 01111100\ 00000000\ 010111110\ 11111011\ 01111111\ 110000000'' | | | ''00000000\ 00000000\ 01111110\ 10110110\ 01101111\ 00000000\ 00000100\ 00000000\ 00000000\ 00000001\ 01111100\ 00000000\ __010111110__\ 11111011\ 01111111\ __11__0000000'' | |
| ''00000000\ 00000000\ 01111110\ 10110110\ 01101111\ 00000000\ 00000100\ 00000000\ 10000000\ 00000001\ 01111100\ 00000000\ 010111110\ 10111110\ 01111111\ 110000000'' | | | ''00000000\ 00000000\ 01111110\ 10110110\ 01101111\ 00000000\ 00000100\ 00000000\ 10000000\ 00000001\ 01111100\ 00000000\ __010111110__\ 10111110\ 01111111\ __11__0000000'' | |
| |
The first four observations were among the most frequent signals. | The first four observations were among the most frequent signals. |
| |
In this table, I already split the binary signal into octets, i.e. bytes. Since the full signal has 129-131 bits, some extra bits need to be included somewhere. | In this table, I already split the binary signal into octets, i.e. bytes. Since the full signal has 129-131 bits, some extra bits need to be included to form 9-bit parts somewhere. |
| |
Somehow that is strange... As my reasoning in part 2 shows, that extra byte must be before the final three bytes, but after the fifth-to-last one. So we have the 9-bit sequence 101111101 that we must make sense of. Even worse, the last two observations appear to be shifted by one additional bit after a bit sequence of 01111100. | As my reasoning in part 2 shows, that extra byte must be before the final three bytes, but after the fifth-to-last one. So we have the 9-bit sequence 101111101 that we must make sense of. Even worse, the last two observations appear to be shifted by one additional bit after a bit sequence of 01111100. |
| |
After some googling, I stumbled upon the [[https://en.wikipedia.org/wiki/High-Level_Data_Link_Control#Framing|framing approach in the High-Level Data Link Control]], where the frames start with 0x7e=01111110 and the bit stuffing in the data part means that after five consecutive 1 bits, an extra 0 bit is included, which must be removed at the receiving end. Indeed, the 101111101 bit sequence is the only appearance of five consecutive 1 bits in the first few examples. Some other signals also contained sequences of 5 (but not more) consecutive 1 bits, followed by a seemingly spurious zero... Bit stuffing would explain this spurious 0 bit and even demand to remove it before interpreting the signal. If we do bit unstuffing on our signals, suddenly the signal aligns perfectly into octets to form bytes: | After some googling, I stumbled upon the [[https://en.wikipedia.org/wiki/High-Level_Data_Link_Control#Framing|framing approach in the High-Level Data Link Control]], where the frames start with 0x7e=01111110 and the bit stuffing in the data part means that after five consecutive 1 bits, an extra 0 bit is included, which must be removed at the receiving end. Indeed, the 101111101 bit sequence is the only appearance of five consecutive 1 bits in the first few examples. Some other signals also contained sequences of 5 (but not more) consecutive 1 bits, followed by a seemingly spurious zero... Bit stuffing would explain this spurious 0 bit and even demand to remove it before interpreting the signal. If we do bit unstuffing on our signals (again, using a little helper utility [[https://github.com/kainhofer/vaillant-calormatic340f/blob/master/Vaillant_decode_bitstuff.c|Vaillant_decode_bitstuff.c]]), suddenly the signal aligns perfectly into octets to form bytes: |
| |
| ''00000000\ 00000000\ 01111110\ 10110110\ 01101111\ 00000000\ 00000100\ 00000000\ 00000000\ 00010001\ 00101101\ 00000000\ 10111111\ 10000010\ 11111111\ 00000000'' | | | ''00000000\ 00000000\ 01111110\ 10110110\ 01101111\ 00000000\ 00000100\ 00000000\ 00000000\ 00010001\ 00101101\ 00000000\ 10111111\ 10000010\ 11111111\ 00000000'' | |