* Compute xn297 whitening instead of using an hardcoded array
* Add function to scramble byte for XN297 interface
* Refactor XN297 scrambling logic to use a global LFSR and improve byte generation
* Add technical specification and implementation details for XN297 whitening and CRC
* HoTT: compute the hop table from the hop value (-1 KB)
The 16 hop tables are generated from the 16 bit value sent in packet[0..1]:
the C library rand() LCG (low 16 bits: x = x * 0x4E6D + 0x3039) seeded with
it drives forward Fisher-Yates shuffles, first of the order of the 5 bands of
15 channels, then of the channels of each band, hop i being in the band at
position i%5. This gives back the 16 tables bit for bit, and for any seed a
75 channel permutation with the same band structure.
* XN297 emu: compute the CRC xorout instead of the 4 tables
The XN297 CRC is CRC-16/CCITT with init 0xFFFF and xorout 0xFFFF over the
unscrambled address, pcf and payload, sent scrambled. The emulation computes
it from 0xB5D2 over the bits as sent, so the xorout for a CRC over n bits is
CRC(init 0xFFFF^0xB5D2) of n scramble (or zero) bits, xor 0xFFFF, xor the 16
scramble bits at the CRC. The scramble bits come from the LFSR behind
xn297_scramble[] (1110001, then s[i] = s[i-7] ^ s[i-3]), which also covers
the last enhanced entries, past the end of that table. It is the generator
Goebish gave for the scramble sequence in a comment on
https://mcumix.blogspot.com/2016/07/reverse-engineering-24ghz-rf-chip-xn297.html
(seed 0x71, feedback bit 6 ^ bit 2, MSB first).
All the entries of the 4 tables are given back but two: entry 0 (3 byte
address, no payload) was a 0 placeholder, and scrambled entry 1 (3 byte
address, 1 byte payload) was 0x3448 where the formula gives 0xE348.
Loads of protocols have been touched by this change. Some testing has been done but please test on all your models.
The XN297 emulation selects in this order:
- the CC2500 if it is available and bitrate=250K. Configure the option field automatically for RF tune.
- the NRF for all bitrates if it is available
- if NRF is not available and bitrate=1M then an invalid protocol is sent automatically to the radio.
CC2500 @250K can now receive normal and enhanced payloads.
OMP protocol supports telemetry on CC2500 and is also for NRF only modules including telemetry.
Separation of E016H (new protocol) from E01X due to different structure.
MJXQ, MT99XX, Q303 and XK: some sub protocols available on CC2500 only.
Automatically:
- find XN297L packet -> bitrate, scrambling, enhanced...
- use address to filter incoming packets
- find all frequencies
- determine channel order (basic)
- help to find out the changes by only displaying packets when there is a change in the packet
Protocol number: 63
Sub protocols: 0=250Kb, 1=1Mb, 2=2Mb
Option: -1=scan RF channels, 0-84=RF channel
DEBUG_SERIAL must be enabled
If a valid frame is received the frame will be sent on the serial port.
goebish
Raphael Coeffic
pascallanger
Pascal Langer