JAPAEL – Jarda Pavlíček Elektronika

Pomocí Raspberry Pi Pico a nRF24L01+ jsme zachytili komunikaci ovladače Syma, získali z párovacího paketu jeho individuální adresu a na ní přijali 39 řídicích paketů se správným kontrolním součtem. Máme tak ověřený základ pro vlastní přijímač. Zbývá vysvětlit nízkou úspěšnost příjmu při párování, ověřit všechny provozní kanály a dokončit dekódování povelů.

Datum: 10. října 2026
Projekt: Reverzní analýza komunikace RC vysílače Syma
Použitá platforma: Raspberry Pi Pico (RP2040), nRF24L01+, Python
Stav projektu: Párovací a provozní komunikace částečně dekódována. Provozní adresa vysílače spolehlivě zjištěna. Zbývá vyřešit nízkou úspěšnost příjmu párovacích paketů a ověřit úplný mechanismus přeskakování frekvencí.

1. Účel a zadání

Cílem experimentů bylo porozumět bezdrátové komunikaci černého dálkového ovladače Syma, zejména jeho párovacímu mechanismu.

Zajímalo nás, zda lze pomocí běžného rádiového modulu nRF24L01+ zachytávat komunikaci vysílače, zjistit jeho individuální identifikátor a následně přijímat řídicí povely.

Nešlo pouze o jednorázové zachycení několika paketů. Cílem bylo získat takové znalosti protokolu, aby bylo možné vytvořit vlastní přijímač, který se s vysílačem automaticky spáruje a bude přijímat jeho řídicí povely.

Postupně jsme se zaměřili na pět otázek:

1. Na jakých frekvencích vysílač komunikuje?
2. Jaké rádiové parametry používá?
3. Jak vypadá párovací komunikace?
4. Jak se při párování předává individuální adresa a určují provozní frekvence?
5. Jak se liší párovací a běžný provozní režim?

Experimenty nám umožnily na většinu těchto otázek odpovědět. Současně odhalily problém s kvalitou nebo interpretací rádiového příjmu, který dosud není vysvětlen.

2. Experimentální vybavení

2.1 Hardware

Použili jsme:

Pro připojení rádiového modulu k RP2040 jsme použili rozhraní SPI0:

V průběhu pokusů jsme pracovali se dvěma rádiovými moduly, označovanými jako A a B.

Spolehlivé výsledky poskytoval modul B. Modul A se při našich pokusech jevil jako nefunkční nebo neschopný přijímat zkoumanou komunikaci. Příčinu jsme neurčili.

2.2 Software

Vytvořili jsme několik specializovaných Pythonových programů pro:

• zachytávání paketů na pevné frekvenci;
• přelaďování mezi několika frekvencemi;
• měření časového rozložení paketů;
• zkoušení různých délek payloadu;
• zkoušení hardwarového CRC8 a CRC16;
• kontrolu aplikačního checksumu;
• ukládání surových záznamů;
• zpětnou analýzu uložených dat;
• výpočet provozní adresy a frekvencí z párovacích paketů.

Mezi hlavní nástroje patřily:

Programy ukládaly zachycené pakety do textových souborů, aby bylo možné výsledky opakovaně analyzovat bez dalšího rádiového měření.

3. Metodika a průběh experimentů

3.1 První fáze: hledání rádiové komunikace

Nejprve jsme potřebovali zjistit, zda vůbec dokážeme vysílač pomocí nRF24L01+ zachytit.

Experimentovali jsme s různými rádiovými kanály a nastavením přijímače. V této fázi jsme ještě neznali přesný formát paketů ani jejich délku.

Důležitým zjištěním bylo, že vysílač nekomunikuje trvale na jediné frekvenci. Používá frequency hopping, tedy přeskakování mezi několika rádiovými kanály.

Tato vlastnost značně komplikuje příjem. Přijímač, který poslouchá pouze na jednom kanálu, zachytí jen část vysílání.

3.2 Druhá fáze: nalezení párovací adresy

Postupně jsme identifikovali univerzální rádiovou adresu používanou během párování:

AB AC AD AE AF

Tato adresa je dlouhá pět bajtů.

Na rozdíl od individuální provozní adresy není odvozena od konkrétního vysílače. Slouží jako společná adresa, na které může dosud nespárovaný přijímač zachytit párovací zprávy.

Při příjmu na této adrese jsme objevili dvě výrazně odlišné rodiny paketů.

Rodina A:

0A 1A 2A 3A 12 22 32 42 01 96

Rodina B:

A1 3A 18 07 E5 AA AA BB 01 30

Obě rodiny se vyskytovaly opakovaně.

V záznamech s vypnutým hardwarovým CRC se objevovaly také četné podobné, ale bitově pozměněné varianty těchto paketů.

Zpočátku nebylo jasné, které rozdíly představují skutečná data a které jsou důsledkem chybného příjmu.

3.3 Třetí fáze: časování párování

Při analýze časových záznamů jsme zjistili, že párovací komunikace používá čtyři rádiové kanály:

9 → 32 → 48 → 64

Při obvyklém značení nRF24L01+ odpovídají těmto kanálům frekvence:

Z časových měření jsme odvodili přibližné střídání frekvencí v intervalech odpovídajících dvěma čtyřmilisekundovým úsekům na kanál.

Celý cyklus čtyř kanálů tak vycházel přibližně na 32 ms.

V záznamech jsme současně pozorovali dvě rodiny párovacích zpráv s opakováním přibližně po 32 ms a celkovou strukturou přibližně 64 ms.

Důležitá výhrada: Jde o interpretaci časových měření, nikoli o kompletně rekonstruovaný časový diagram vysílače. Přesné pořadí jednotlivých zpráv a všechny časové intervaly dosud nejsou definitivně ověřeny.

3.4 Čtvrtá fáze: přechod z párování do provozu

Ovladač používá pro dokončení párování pohyb plynové páčky:

Dolů → nahoru → dolů.

Úspěšné provedení sekvence bylo možné poznat podle zvukové a světelné signalizace ovladače.

Při měřeních jsme pozorovali, že po dokončení párování přestávají být na univerzální párovací adrese dostupné původní pakety.

Současně začíná být dostupná komunikace na individuální adrese.

Důležitým poznatkem bylo také to, že vysílač může po přibližně 15 sekundách bez dokončeného párování změnit své chování.

Proto jsme následně zkracovali experimenty na několik sekund a snažili se zapínat ovladač až po zahájení záznamu.

4. Rádiové parametry protokolu

Po sérii pokusů jsme dospěli k následujícím parametrům.

Tyto parametry jsme ověřovali přímo konfigurací nRF24L01+.

Pro párovací příjem na kanálu 48 byla úspěšná následující konfigurace:

CONFIG      = 0x0F
EN_AA       = 0x00
EN_RXADDR   = 0x01
SETUP_AW    = 0x03
RF_CH       = 48
RF_SETUP    = 0x26
RX_PW_P0    = 10
DYNPD       = 0x00
FEATURE     = 0x00

Hodnota CONFIG=0x0F znamená mimo jiné zapnutý přijímací režim a dvoubajtové hardwarové CRC.

RF_SETUP=0x26 nastavuje rychlost 250 kb/s.

Provozní komunikaci jsme se stejným základním nastavením úspěšně přijímali na kanálu 15.

5. Struktura párovacích paketů

Nejdůležitější částí analýzy bylo zjištění, že vysílač během párování posílá nejméně dva typy desetibajtových zpráv.

5.1 Typ A: zpráva související s frekvencemi

Příklad:

Offset:  00 01 02 03 04 05 06 07 08 09
Data:    0A 1A 2A 3A 12 22 32 42 01 96

Prvních osm bajtů tvoří nápadnou posloupnost:

0A 1A 2A 3A 12 22 32 42

Z její struktury jsme odvodili hypotézu, že souvisí s výběrem provozních kanálů.

Při použití této interpretace dostáváme kanály:

15, 31, 47, 63

Tyto kanály odpovídají také výsledku nezávislého výpočtu z individuální adresy vysílače.

Shoda je významná, protože naznačuje, že obě rodiny párovacích paketů mohou nést vzájemně související informace.

Zatím však nemáme prokázáno, že právě tento paket přímo předává kompletní seznam provozních kanálů. Jde o silnou pracovní hypotézu.

5.2 Typ B: identifikační zpráva

Druhý typ paketu má následující podobu:

Offset:  00 01 02 03 04 05 06 07 08 09
Data:    A1 3A 18 07 E5 AA AA BB 01 30

Tento paket je pro automatické párování zásadní.

Jeho prvních pět bajtů představuje identifikační informaci, ze které lze sestavit provozní adresu.

A1 3A 18 07 E5

Po obrácení pořadí bajtů získáváme:

E5 07 18 3A A1

Právě na této adrese jsme následně úspěšně přijímali provozní pakety.

Tím jsme prakticky potvrdili, že identifikační zpráva umožňuje přijímači přejít z univerzální párovací adresy na individuální adresu vysílače.

Další bajty identifikační zprávy:

AA AA BB 01

jsme zatím úplně nerozebrali.

Dvojici AA AA používáme jako rozpoznávací znak identifikačních párovacích zpráv. Její přesný protokolový význam však dosud není plně ověřen.

Poslední bajt:

30

je aplikační kontrolní součet.

6. Aplikační kontrolní součet

Kromě hardwarového CRC obsahují desetibajtové pakety ještě vlastní aplikační kontrolní součet.

Zjistili jsme, že se počítá z prvních devíti bajtů.

Algoritmus je:

1. Provést XOR prvních devíti bajtů.
2. K výsledku přičíst konstantu 0x55.
3. Ponechat nejnižších osm bitů.

V Pythonu:

def syma_checksum(packet):
    value = 0
    for byte in packet[:9]:
        value ^= byte
    return (value + 0x55) & 0xFF

Paket je z hlediska aplikační kontroly platný, pokud:

syma_checksum(packet) == packet[9]

Například u identifikačního paketu:

A1 3A 18 07 E5 AA AA BB 01 30

výpočet poskytne 0x30, tedy přesně hodnotu posledního bajtu.

Je důležité rozlišovat dva nezávislé kontrolní mechanismy:

Hardwarové CRC16 kontroluje rádiový rámec. Je zpracováváno přímo čipem nRF24L01+ a běžně není součástí dat vracených z RX FIFO.

Aplikační checksum je desátým bajtem uživatelského payloadu a kontrolujeme jej vlastním programem.

Při zapnutém CRC16 přijímač předává aplikaci pouze pakety, které prošly hardwarovou kontrolou.

Teprve nad nimi provádíme aplikační kontrolu.

7. Určení provozní adresy a frekvencí

7.1 Provozní adresa

Z identifikačního párovacího paketu:

A1 3A 18 07 E5 AA AA BB 01 30

jsme získali adresu:

E5 07 18 3A A1

Tuto adresu jsme následně použili pro příjem provozní komunikace.

Na kanálu 15 jsme zachytili 39 paketů, z nichž všech 39 prošlo aplikačním checksumem. Všechny byly přijaty se zapnutým hardwarovým CRC16.

To je důležitý výsledek: individuální adresa není pouze teoreticky vypočítaná. Její správnost jsme ověřili skutečným příjmem řídicích dat.

7.2 Provozní frekvence

Podle známého algoritmu protokolu Syma jsme z identifikátoru vysílače vypočítali následující provozní kanály:

Výpočet kanálů používá transformační tabulku známou z implementací protokolu Syma.

Zajímavé je, že stejné čtyři kanály vycházejí i z naší interpretace druhého typu párovacího paketu.

Prozatím však nemáme záznamy, které by přímo potvrdily vysílání na všech čtyřech provozních frekvencích.

7.3 Princip frequency hoppingu

Protokol využívá přeskakování mezi rádiovými kanály.

To znamená, že vysílač neposílá všechny řídicí pakety na jediné frekvenci. Místo toho opakovaně střídá frekvence z předem určené sady.

Provozní přijímač proto potřebuje znát nejen individuální adresu vysílače, ale také jeho frekvenční sadu a časování přeskakování.

Pro náš vysílač předpokládáme cyklus:

2415 MHz
    ↓
2431 MHz
    ↓
2447 MHz
    ↓
2463 MHz
    ↓
2415 MHz
    ...

Přesné časování provozního hoppingu jsme zatím nezměřili. Pořadí uvedené výše odpovídá vypočítané sadě kanálů, nikoli úplně ověřené časové posloupnosti.

8. Struktura provozních paketů

Po dokončení párování vysílač přechází na individuální adresu a začíná vysílat řídicí povely.

Příklad zachyceného provozního paketu:

00 00 00 00 00 60 20 20 01 B6

Při změně ovládacích prvků jsme pozorovali změny jednotlivých bajtů.

Zejména jsme zjistili, že první bajt reaguje na polohu plynové páčky.

Provozní paket má stejně jako párovací zprávy deset bajtů a používá stejný aplikační checksum.

Zjednodušeně:

Zatím jsme neprovedli úplné mapování všech ovládacích prvků.

Pro takové mapování bude vhodné postupně měnit vždy pouze jeden prvek ovladače a porovnávat odpovídající bajty.

9. Největší komplikace: nízká úspěšnost příjmu párovacích paketů

Při experimentování jsme narazili na zásadní rozdíl mezi příjmem se zapnutým a vypnutým hardwarovým CRC.

9.1 Příjem s vypnutým CRC

Na párovací adrese a kanálu 48 jsme při vypnutém CRC běžně zachytávali přibližně 40–55 paketů za sekundu.

Například při délce payloadu 10 bajtů:

Channel:       48
Address:       AB AC AD AE AF
Payload width: 10
CRC:           OFF
Duration:      4 s
Received:      182 packets
Checksum OK:   6 packets

Přijímač tedy detekoval velké množství rámců, ale jen malá část z nich prošla aplikační kontrolou.

V mnoha případech přijatá data připomínala správné pakety s jednotlivými změněnými bity.

Například:

Správně:
0A 1A 2A 3A 12 22 32 42 01 96
Zachycené varianty:
1A 1A 2A 3A 12 22 32 42 01 96
0A 1A 2A BA 12 22 32 42 05 96
0A 1A 2A 3A 32 22 32 46 05 96

To naznačuje, že přijímač skutečně zachytává vysílání Syma, ale řada přijatých rámců obsahuje chyby.

Samotná podobnost paketů ovšem nedokazuje, že jde výhradně o náhodné bitové chyby. Některé změny mohou souviset se skutečnými daty nebo s nesprávnou interpretací rádiového rámce.

9.2 Příjem se zapnutým CRC16

Se stejnou adresou, frekvencí a desetibajtovým payloadem jsme při zapnutém CRC16 zaznamenali:

Received: 4 packets

Konkrétně:

2x 0A 1A 2A 3A 12 22 32 42 01 96
2x A1 3A 18 07 E5 AA AA BB 01 30

Všechny čtyři pakety prošly také aplikačním checksumem.

Tento výsledek je důležitý ze dvou důvodů.

Zaprvé dokazuje, že konfigurace přijímače s desetibajtovým payloadem a CRC16 skutečně dokáže párovací komunikaci správně přijímat.

Zadruhé nám poskytl dva nezávislé, bezchybně přijaté identifikační pakety.

Z nich jsme následně získali správnou provozní adresu.

9.3 Systematické testování délky paketu

Abychom vyloučili chybnou délku payloadu, provedli jsme sérii měření s délkami 4 až 16 bajtů.

Pro každou délku jsme zkoušeli:

• vypnuté CRC;
• CRC8;
• CRC16.

Výsledky byly velmi charakteristické.

Každé měření trvalo čtyři sekundy. Jednotlivé konfigurace se měřily postupně, nikoli současně.

Z výsledků vyplývá, že desetibajtový payload s CRC16 je správná konfigurace pro zachycené párovací zprávy.

Ojedinělé pakety při CRC8 a jiných délkách nejsou dostatečným důkazem, že vysílač používá více formátů. Mohou představovat náhodné průchody kontrolou.

9.4 Co se objevuje za desetibajtovým payloadem?

Při vypnutém CRC a nastavení delšího payloadu jsme pozorovali zajímavou věc.

Za prvních deset bajtů se často objevovaly opakující se hodnoty:

0A 1A 2A 3A 12 22 32 42 05 96 DD AE
A1 3A 18 07 E5 AA AA BB 01 30 B4 A3

U první rodiny se často vyskytovalo:

DD AE

U druhé:

B4 A3

Tyto dva bajty by mohly představovat hardwarové CRC16, které při vypnuté kontrole přijímač interpretuje jako pokračování dat.

Tuto hypotézu jsme však dosud neověřili přímým výpočtem CRC nad rádiovým rámcem.

Je to zajímavá stopa pro další analýzu.

9.5 Dosud nevysvětlený problém

V provozním režimu jsme dosáhli velmi dobrého příjmu: 39 paketů se správným CRC i aplikačním checksumem.

V párovacím režimu jsme naproti tomu běžně zachytávali jen jednotlivé bezchybné pakety.

To je zásadní rozdíl.

Možná vysvětlení zahrnují:

1. Odlišné podmínky rádiového příjmu během jednotlivých měření.
2. Chyby při dekódování nebo synchronizaci rámců.
3. Odlišnosti rádiového formátu, které jsme ještě nezjistili.
4. Vliv časování přelaďování a změn režimu vysílače.
5. Problémy konkrétního přijímacího modulu.

Z dostupných měření nelze určit, která z těchto možností je skutečnou příčinou.

Nízká úspěšnost příjmu proto zůstává hlavním otevřeným technickým problémem.

10. Závěrečné ověření dekódování párování

V poslední fázi jsme vytvořili program sniff_syma_bind_fixed.py.

Ten umožňuje jak přímý příjem, tak zpětnou analýzu uloženého záznamu.

Použili jsme soubor:

20261010T211135_syma-fixed-ch48-addrabacadaeaf-w10-crc16.txt

Analýza poskytla:

Total RX FIFO records: 4
Syma application checksum valid: 4/4
Validated binding-ID packets: 2
Other checksum-valid packets: 2

Z identifikačních zpráv program vypočítal:

Operational address:
E5 07 18 3A A1
Calculated channels:
15, 31, 47, 63
Calculated frequencies:
2415, 2431, 2447, 2463 MHz

Identifikační pakety byly zachyceny v časech:

t = 1.435 s
t = 2.075 s

Oba obsahovaly identická data:

A1 3A 18 07 E5 AA AA BB 01 30

Program současně porovnal dvě metody výpočtu provozních kanálů.

from_table = [15, 31, 47, 63]
from_type2 = [15, 31, 47, 63]
match = True

Tím jsme ověřili, že naše interpretace párovacích zpráv je vzájemně konzistentní.

Následný desetisekundový pokus se stejným nastavením zachytil pouze jeden platný paket typu A. Potvrdil tak funkčnost příjmu, ale současně znovu ukázal jeho nízkou úspěšnost.

11. Rekonstrukce fungování protokolu

Na základě dosavadních měření lze sestavit následující model komunikace.

Fáze 1: Zapnutí vysílače

Po zapnutí začne vysílač vysílat párovací zprávy.

Používá společnou adresu:

AB AC AD AE AF

Komunikace probíhá rychlostí 250 kb/s.

Vysílač střídá párovací kanály:

9, 32, 48, 64

Přijímač, který se chce spárovat, musí na těchto kanálech zachytit párovací zprávy.

Fáze 2: Vysílání párovacích informací

Vysílač opakovaně posílá nejméně dva typy zpráv.

Typ A:

0A 1A 2A 3A 12 22 32 42 01 96

Pravděpodobně souvisí s určením provozních frekvencí.

Typ B:

A1 3A 18 07 E5 AA AA BB 01 30

Obsahuje identifikační údaje vysílače.

Z nich přijímač získá individuální provozní adresu:

E5 07 18 3A A1

Z identifikátoru následně vypočítá provozní frekvence.

Fáze 3: Dokončení párování

Uživatel provede sekvenci plynovou páčkou:

DOWN → UP → DOWN

Ovladač dokončení signalizuje zvukově a světelně.

Podle našich pozorování pak přestává vysílat původní párovací komunikaci a přechází do provozního režimu.

Dosud nevíme, zda samotný vysílač při této sekvenci pouze mění svůj režim, nebo zda existují ještě další protokolové podmínky.

Fáze 4: Provozní komunikace

Vysílač nyní používá individuální adresu:

E5 07 18 3A A1

a provozní frekvenční sadu:

15, 31, 47, 63

Na těchto frekvencích odesílá desetibajtové řídicí pakety.

Přijímač je dekóduje a převádí jednotlivé hodnoty na ovládání zařízení.

První bajt podle našich měření odpovídá plynové páčce.

Ostatní ovládací hodnoty zbývá systematicky identifikovat.

Schematické znázornění

Tento přehled zachycuje náš současný model protokolu. Zejména role paketu typu A a přesné podmínky přechodu mezi režimy jsou stále částečně hypotetické.

12. Co jsme skutečně prokázali

Pro přehlednost rozlišuji výsledky podle míry jistoty.

13. Doporučený další postup

Získané znalosti už umožňují vytvořit první funkční verzi vlastního přijímače.

Není nutné pořizovat drahé SDR zařízení.

Navrhuji pokračovat ve třech etapách.

Etapa 1: Ověření provozních frekvencí

Nejprve přímo ověřit, zda vysílač skutečně komunikuje na kanálech:

31
47
63

Kanál 15 už máme potvrzený.

Tento experiment by měl být poměrně jednoduchý, protože provozní komunikaci dokážeme přijímat spolehlivěji než párovací.

Etapa 2: Vytvoření přijímače provozní komunikace

Vytvořit program, který bude:

• používat individuální adresu E507183AA1;
• přeskakovat mezi čtyřmi provozními frekvencemi;
• přijímat desetibajtové pakety;
• ověřovat aplikační checksum;
• vypisovat hodnoty jednotlivých ovládacích prvků;
• sledovat ztracené pakety a úspěšnost příjmu.

Tím získáme funkční základ přijímače.

Současně budeme moci systematicky dekódovat všechny ovládací prvky vysílače.

Etapa 3: Automatické párování

Nakonec doplnit automatické zachycení párovacího paketu.

Program bude:

1. Naslouchat na společné párovací adrese.
2. Zachytávat identifikační zprávy.
3. Ověřovat CRC a aplikační checksum.
4. Získávat individuální adresu.
5. Vypočítávat provozní frekvence.
6. Přecházet na provozní příjem.

V této fázi bude potřeba vyřešit nízkou úspěšnost příjmu párovacích zpráv.

Možným řešením může být i zpracování většího množství opakovaných zpráv s vypnutým hardwarovým CRC, pokud se podaří dostatečně spolehlivě rekonstruovat jejich správný obsah.

Takový postup by ale vyžadoval další analýzu, protože nelze automaticky předpokládat, že všechny rozdíly mezi zachycenými pakety jsou pouze náhodné chyby.

14. Celkové zhodnocení

Podařilo se nám udělat podstatný krok od pouhého zachytávání rádiových signálů k porozumění skutečnému komunikačnímu protokolu.

Na začátku jsme neznali párovací adresu, délku paketů, kontrolní mechanismy ani způsob získání individuální adresy.

Na konci experimentů už dokážeme:

• přijímat skutečné párovací zprávy;
• rozpoznávat jejich dva základní typy;
• ověřovat jejich integritu;
• získat z nich individuální adresu vysílače;
• vypočítat provozní frekvence;
• přijímat řídicí pakety na provozní adrese;
• sledovat změny vybraných ovládacích hodnot.

Nejcennějším výsledkem je prakticky ověřená vazba mezi párovacím paketem a následnou provozní komunikací.

Z paketu:

A1 3A 18 07 E5 AA AA BB 01 30

dokážeme získat adresu:

E5 07 18 3A A1

A na této adrese jsme skutečně přijímali řídicí pakety vysílače.

Tím jsme prokázali základní mechanismus, na kterém může stát vlastní přijímač.

Projekt zatím není dokončený, ale hlavní princip párování jsme rozluštili.

Zbývající práce se soustředí především na spolehlivost příjmu, přesné časování frequency hoppingu a úplné dekódování řídicích povelů.