Commit Graph
12 Commits
Author SHA1 Message Date
goebish 91199e146e Compute xn297 whitening instead of using an hardcoded array (#1201)
* 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
2026-10-25 16:57:07 +01:00
Raphael Coeffic d3293afdab HoTT, XN297 emu: compute the hop and CRC xorout tables (-1.2 KB) (#1199)
* 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.
2026-10-23 12:02:20 +02:00
pascallanger 496c07943f KAMTOM new surface protocol
Missing low batt telem
2025-02-21 21:46:18 +01:00
pascallanger 2918e63fb4 XN297Emu add ReSendPayload 2025-02-19 11:54:29 +01:00
pascallanger 756af87ec1 SGF22 Flags trial 2025-01-25 11:31:21 +01:00
pascallanger 2e1d763d54 V761 telemetry
A1 (4.4V -> 2.2V), RSSI equal to 100 means that all telem packets are received and TQLY indicates the number of lost telem packets.
2023-09-26 20:04:35 +02:00
Pascal Langer 246e808cb4 Xerall protocol 2021-09-01 01:21:38 +02:00
Pascal Langer 9356e7654e XN297EMU: allows to send and receive 0 payload length in enhanced mode 2021-08-25 19:07:36 +02:00
Pascal Langer c52ac2cefc Fix XN297Dump enhanced payload detection 2021-06-28 18:04:17 +02:00
Pascal Langer 37e029c612 Bug fix in XN297 emu layer when address is 3 bytes and CC2500 in use 2021-03-17 19:24:42 +01:00
Pascal Langer 4a626eaf14 Change XN297 emulation layer
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.
2021-03-17 17:05:42 +01:00
Pascal Langer 0844ec2efd Add more protocols which can run with the CC2500
Use CC2500 only when emulating NRF250K/XN297_250K
2021-02-16 19:06:23 +01:00