Mirrors/knx
1
0
Fork 0
mirror of https://github.com/thelsing/knx.git synced 2025-10-26 10:26:25 +01:00
Code Issues Packages Projects Releases Wiki Activity

Make RF docs online readable by using markup

Browse Source
This commit is contained in:
nanosonde 2019-12-05 15:26:47 +01:00 committed by GitHub
parent 27be7caa6d
commit 99f74002ff
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 31 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

48
doc/knx_rf_notes.md
View File

@ -5,45 +5,53 @@ Implementation Notes
--------------------
* KNX-RF E-Mode (pushbutton method) is NOT supported!
* KNX-RF S-Mode is implemented as KNX-RF READY (KNX-RF 1.R) which means only one single channel and no fast-ack is used.
-> KNX RF Multi (KNX-RF 1.M) would be required for this. However, implementation is way more complex as frequency hopping (fast and slow channels) is used and fast-ack
* KNX RF Multi (KNX-RF 1.M) would be required for this. However, implementation is way more complex as frequency hopping (fast and slow channels) is used and fast-ack
is based on a TDMA-like access scheme which has very strict timing requirements for the time slots.
-> summary: KNX-RF 1.R does NOT acknowledge packets on the air (data link layer). So standard GROUP_VALUE_WRITE messages in multicast mode could get lost!
* summary: KNX-RF 1.R does NOT acknowledge packets on the air (data link layer). So standard GROUP_VALUE_WRITE messages in multicast mode could get lost!
Connection-oriented communication for device management is handled by the transport layer and uses T_ACK and T_NACK.
* the driver (rf_physical_layer.cpp) uses BOTH signals (GDO0, GDO2) of the RF transceiver C1101
-> GDO0 is asserted on RX/TX packet start and de-asserted on RX/TX packet end or RX/TX FIFO overflow/underflow
-> GDO2 is asserted is the FIFO needs to read out (RX) or refilled (TX)
* GDO0 is asserted on RX/TX packet start and de-asserted on RX/TX packet end or RX/TX FIFO overflow/underflow
* GDO2 is asserted is the FIFO needs to read out (RX) or refilled (TX)
* the driver (rf_physical_layer.cpp) uses both packet length modes of the CC1101: infinite length and fixed length are switched WHILE receiving or transmitting a packet.
* the edges of the signals GDO0 and GDO2 are detected by polling in the main loop and NOT by using interrupts
-> as a consequence the main loop must not be delayed too much, the transceiver receives/transmitts the data bytes itself into/from the FIFOs though (max. FIFO size 64 bytes each (TX/RX)!).
-> KNX-RF bitrate is 16384 bits/sec. -> so 40 bytes (Preamble, Syncword, Postamble) around 20ms for reception/transmission of a complete packet (to be verified!)
-> another implementation using interrupts could also be realized
* as a consequence the main loop must not be delayed too much, the transceiver receives/transmitts the data bytes itself into/from the FIFOs though (max. FIFO size 64 bytes each (TX/RX)!).
* KNX-RF bitrate is 16384 bits/sec. -> so 40 bytes (Preamble, Syncword, Postamble) around 20ms for reception/transmission of a complete packet (to be verified!)
* another implementation using interrupts could also be realized
* the driver does not use the wake-on-radio of the CC1101. The bidirectional battery powered devices are not useful at the moment.
-> wake-on-radio would also require the MCU to sleep and be woken up through interrupts.
-> BUT: UNIdirectional (battery powered) device could be realized: one the device has been configured in bidirectional mode.
* wake-on-radio would also require the MCU to sleep and be woken up through interrupts.
* BUT: UNIdirectional (battery powered) device could be realized: one the device has been configured in bidirectional mode.
The device (MCU) could sleep and only wake up if something needs to be done. Only useful for transmitters (e.g. sensors like push button, temperature sensor, etc.).
ToDo
----
* Packet duplication prevention based on the data link layer frame counter if KNX-RF retransmitters (range extension) are active (should be easy to add)
* KNX-RF 1.M (complex, may need an additional MCU, not planned for now)
-> maybe with a more capable transceiver: http://www.lapis-semi.com/en/semicon/telecom/telecom-product.php?PartNo=ML7345
* maybe with a more capable transceiver: http://www.lapis-semi.com/en/semicon/telecom/telecom-product.php?PartNo=ML7345
it could handle manchester code, CRC-16 and the whole Wireless MBUS frame structure in hardware. Also used by Tapko for KAIstack.
* KNX Data Secure with security proxy profile in line coupler (e.g. TP<>RF). See KNX AN158 (KNX Data Secure draft spec.) p.9
-> KNX-RF very much benefits from having authenticated, encrypted data exchange.
-> Security Proxy terminates the secure applicationj layer (S-AL) in the line coupler. So the existing plain TP installation without data secure feature
* KNX-RF very much benefits from having authenticated, encrypted data exchange.
* Security Proxy terminates the secure applicationj layer (S-AL) in the line coupler. So the existing plain TP installation without data secure feature
can be kept as is.
Development Setup
-----------------
Development is done on a cheap Wemos SAMD21 M0-Mini board with a standard CC1101 module (868MHz) from Ebay. Beware of defective and bad quality modules.
The SAMD21 MCU is connected via SWD (Segger J-Link) to PlatformIO (Visual Studio Code). Additionally the standard UART (Arduino) is used for serial debug messages.
The USB port of the SAMD21 is not used at all.
* Development is done on a cheap Wemos SAMD21 M0-Mini board with a standard CC1101 module (868MHz) from Ebay.
* Beware of defective and bad quality modules!
* The SAMD21 MCU is connected via SWD (Segger J-Link) to PlatformIO (Visual Studio Code). Additionally the standard UART (Arduino) is used for serial debug messages.
* The USB port of the SAMD21 is not used at all.
Connection wiring:
------------------
Signal SAMD21 CC1101
----------+-------------+---------------
Signal | SAMD21 | CC1101
----------|-------------|--------------
SPI_nCS | D10(PA18) | CSN
SPI_MOSI | D11(PA16) | SI
SPI_MISO | D12(PA19) | SO
@ -53,8 +61,11 @@ GDO2 | D9(PA07) | GDO2
Arduino MZEROUSB variant needs patching to enable SPI on SERCOM1 on D10-D13.
If you do not want to patch variant files, use a compatible board that provides SPI on D10-D13.
variant.h
---------
```
/*
* SPI Interfaces
*/
@ -66,9 +77,11 @@ variant.h
#define PERIPH_SPI sercom1
#define PAD_SPI_TX SPI_PAD_0_SCK_1
#define PAD_SPI_RX SERCOM_RX_PAD_3
```
variant.cpp
-----------
```
// 18..23 - SPI pins (ICSP:MISO,SCK,MOSI)
// ----------------------
{ PORTA, 19, PIO_SERCOM, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER, EXTERNAL_INT_12 }, // MISO: SERCOM1/PAD[3]
@ -77,3 +90,4 @@ variant.cpp
{ PORTA, 16, PIO_SERCOM, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER, EXTERNAL_INT_10 }, // MOSI: SERCOM1/PAD[0]
{ NOT_A_PORT, 0, PIO_NOT_A_PIN, PIN_ATTR_NONE, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER, EXTERNAL_INT_NONE }, // RESET
{ NOT_A_PORT, 0, PIO_NOT_A_PIN, PIN_ATTR_NONE, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER, EXTERNAL_INT_NONE }, // GND
```