Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- hardware:vaillantvrt340f_protocol [2017/05/05 16:19] – reinhold
+++ hardware:vaillantvrt340f_protocol [2017/05/11 19:26] – reinhold
@@ Zeile 84: / Zeile 84: @@
 Why least significant bit first? That took me a while, too, and it stems from the way the checksum is calculated.
-Our sixteen base signals from above now become:
+Our sixteen base signals from above now become (again using a [[https://github.com/kainhofer/vaillant-calormatic340f/blob/master/Vaillant_decode_bitstuff_hex.c|little self-written utility]]):
 ^Heat.^Wat.^Rep.^Bat.| ''Byte1\ 2\ \ 3\ \ 4\ \ 5\ \ 6\ \ 7\ \ 8\ \ 9\ 10\ 11\ 12\ 13\ 14\ 15\ 16'' |
@@ Zeile 150: / Zeile 150: @@
 ==== UPDATE: Making sense of the 0xFD byte 13 ====
-The byte 13 with unknown constant value 0xFD kept bothering me, and a few days after I understood the checksum byte I figured out its meaning too: As I mentioned, bytes 4-12 together with the checksum byte 14 summed up always yielded 0x0300. It seemed strange to me that the 0x03 byte of the sum was somehow ignored, until I realized that 0xFD is actually the binary complement of 0x03, i.e. the checksum is actually just byte 14, but the two-byte value of bytes 13 and 14. So, our assumption that bytes 13 with a value of 0xFD is some kind of End-Of-Data or separator byte was simply wrong, and it being constant is just a coincidence.
+The byte 13 with unknown constant value 0xFD kept bothering me, and a few days after I understood the checksum byte I figured out its meaning too: As I mentioned, bytes 4-12 together with the checksum byte 14 summed up always yielded 0x0300. It seemed strange to me that the 0x03 byte of the sum was somehow ignored, until I realized that 0xFD is actually the binary complement of 0x03, i.e. the checksum is actually not just byte 14, but the two-byte value of bytes 13 and 14. So, our assumption that bytes 13 with a value of 0xFD is some kind of End-Of-Data or separator byte was simply wrong, and it being constant is just a coincidence.
-In short, bytes 13 and 14 are simply the binary negative of the sum of bytes 4-12, with most significant byte first, i.e. bytes 13+14 interpreted as a signed integer is -sum(byte 4-12). As we are summing up only 9 bytes, there will be no overflow, either (which was what was bothering me with the 0x03 when one understood only byte 14 as the checksum).
+In short, bytes 13 and 14 are the binary negative of the sum of bytes 4-12, with most significant byte first, i.e. bytes 13+14 interpreted as a signed integer is -sum(byte 4-12). As we are summing up only 9 bytes, there will be no overflow, either (which was what was bothering me with the 0x03 when one uses only byte 14 as checksum).
@@ Zeile 238: / Zeile 238: @@
 Each signal is first sent with byte 9 set to 0x00 and shortly afterwards repeated with byte 9 set to 0x01 (and the checksum updated correspondingly).
+==== Setup Mode: RF detection ====
+Playing around with the operator and installation modes of the Vaillant VRT340f, all signals I found fit perfectly well into the protocol described in the last section, except for one signal: RF detection:
+''0x00 00 7E FF FF 00 FF 00 F0 FF FF 6D F6 20 00 02 00 F8 90 FF 00\\
+x00 00 7E FF FF 00 FF 00 F1 FF FF 6D F6 20 00 02 00 F8 8F FF 00''
+As one can see, the signal is longer, but it still follows the same pattern of the begin and end of frame bytes. Also, bit-stuffing is still used, and the checksum is calculated just like in all other packets. However, there are some differences: the Device ID does not appear at the beginning of the data, but somewhere in the middle. Instead the device ID is 0xFF FF, which probably indicates a broadcast. All other values are completely unknown to me, as they never change.
+^Byte ^^ Value ^Description ^
+^1-2  || 0x00 00 | Preamble (square wave to synchronize clocks with the receiver) |
+^3    || 0x7E    | Begin of frame/data (Constant) |
+^ 4-19 || Data content of the frame with 2-byte checksum attached ||
+| ^4-5  | 0xFF FF | Indicates broadcast |
+|::: ^6-8  | 0x00 FF 00 | Unknown (constant) |
+|::: ^9    | 0xF0/F1 | Repeat: 0xF0 for original signal, 0xF1 for repeat signal (bit 1, bits 5-8 always set) |
+|::: ^10-11  | 0xFF FF | Unknown (constant) |
+|::: ^12-13  | 0x6D F6 | Device ID of searching control (Constant for each device) |
+|::: ^14-17  | 0x20 00 02 00 | Unknown (constant) |
+|::: ^18-19 | 0xF8 .. | 2-byte Checksum (signed integer): negative of the sum of bytes 4-17 |
+^20 || 0xFF | End of Signal indicator |
+^21 || 0x00 | Epilogue (no data any more) |
 ====== Implementing support for the device in rtl_433, rflink and/or OpenHAB ======
 Now that we understand both the physical layer of the signal, as well as the structure of the protocol, we can go on to [[hardware:vaillantvrt340f_implementing|implementing support for it in applications like rtl_433 (part of GNUradio), rflink or OpenHAB in part 3 of our series]].