RC Ultimate

Aktuální stav hlavního RC protokolu a navázaných vrstev
Wire protocol v13 · TX Lolin S3 Mini + RX Lolin S3 Mini V2 · aktuální beta · stav k 8. 9. 2026

RC protokol je pevný obousměrný wire kontrakt pro real-time řízení, telemetrii a potvrzenou servisní komunikaci. Každých 5 ms odešle TX jeden řídicí paket a RX ve stejném RF spojení vrátí ACK payload. Čtyřbajtový servisní podprotokol je součástí těchto paketů, ale jeho stavové automaty jsou oddělené od hlavní řídicí cesty.

Současný stav: beta TX 20260907-200420-152 + RX S3 Mini V2 20260907-200537-697, STM8 0.8. Prakticky potvrzené jsou obnova nRF, I2C hot-plug a světelná integrace, profily, reconnect, Wi-Fi konfigurace, bateriové rozhodování a OTA okraje. Otevřený zůstává thermal test, kontrola CSV a oprava OTA nabídky po pozdním příchodu RX. RF wire formát se touto integrací nemění.

1. Vrstvy systému

Aplikační logika
TX supervisor + TFT/web · RX supervisor + výstupy/telemetrie
Servisní stavové automaty
Requester na TX · Responder a dispatch na RX
Wire kontrakt
RcTxPacket 18 B · RcAck 13 B · software CRC
Postak
atomický ping-pong mailbox mezi aplikací a RF taskem
nRF24 transport
250 kb/s · dynamic payload · ACK payload · hardware CRC/retry

Každá vrstva má jednoznačný úkol. Aplikace nerozebírá rádio, RF task nerozhoduje o funkcích vozidla a Postak neinterpretuje obsah paketů. Servisní vrstva používá wire slot, ale neobchází hlavní transport.

TX cesta

tx_io → TX supervisor → RcTxPacket → Postak → rf_nrf24 → nRF24

RX cesta

nRF24 → rf_nrf24 → Postak → RX app/supervisor → rx_io → fyzické výstupy
                                  │
                                  └→ RcAck → Postak → ACK payload → TX

2. Časování a fyzický přenos

ParametrAktuální hodnotaVýznam
RF rychlost250 kb/sRobustní nRF24 režim s delší dobou na jeden bit.
TX RF perioda5000 µs / 10000 µs při ručním PA MAXRF task vlastní nezávislý rytmus 200 Hz, případně 100 Hz; zmeškané periody nedohání burstem.
RX aplikační wakevalidní RF batch / timeout 20 msRF task po publikaci platného batch probudí řídicí task; bez eventu pokračují safety a pomalé stavy nejpozději po 20 ms.
RX MCPWM perioda5000 µs STEER/THROTTLEAktivní S3 RX vyhrazuje timer 0 pro 200Hz řízení a plyn; pomocná diff/gear/winch serva na timerech 1/2 zůstávají na 50 Hz. Běžné řízení a základní failsafe jsou prakticky ověřené end-to-end a dále sledované.
RX IRQ safety poll20 msZáložní přečtení nRF24 při chybějícím IRQ; samo o sobě nevyvolává aplikační failsafe.
TX RF payload18 BŘízení, switches, service request a CRC16.
RX ACK payload13 BTelemetrie včetně RX core teploty, ACT stav, service response a CRC8.
RX link-loss detekce1000 msČasové okno pro ztrátu obousměrného linku před navazující 1s rampou, 1s neutral hold a servo hard-disarmem.
TX TFT SIGNAL LOSTdebouncovaný LinkFs, drop 250 msPrezentační hláška používá autoritativní LinkFs a v AUTO MAX/MAX režimu respektuje ještě nejvýše 250ms RF grace. Stáří jedné ACK telemetrie není trigger hlášky.
TX ACK/UI agesaturace záporného rozdílu na 0Pokud vyšší prioritní RF task publikuje timestamp novější než dříve zachycený čas supervisoru, nevznikne unsigned podtečení ani jednorázové falešné stáří. STATS LINK používá autoritativní bidirLink; čerstvost telemetrie zůstává samostatná.
Service session64 paketů / 1500 msSdílený TX/RX limit rozpracované servisní transakce.
Service link reset2000 msKompletní reset RX responderu bez nového přijatého RF paketu; výpočet elapsed používá stejnou saturaci budoucího mezitaskového timestampu, takže nevyvolá falešný reset.
RF retrydelay 5, count 1 (fast-fail 0)Hardwarové opakování nRF24 pod aplikačním protokolem; při fast-fail režimu TX dočasně vypne retransmise, aby neprodlužoval blokující RF pokus.

ACK payload znamená, že odpověď RX přichází jako součást potvrzení běžného TX přenosu. Není potřeba samostatné vysílací okno RX. Dynamic payload dovolí používat přesné velikosti struktur.

3. Wire paket TX → RX

0flags
1 B
1seq
1 B
2–3steer
i16
4–5throttle
i16
6–7aux1
i16
8–9aux2
i16
10–11switches
u16
12–15service
4 B
16–17CRC16
u16
PoleÚloha
flagsFailsafe/setup/link/welcome stav a řízení PA výkonu.
seqOsmibitový cyklický čítač RF paketů pro diagnostiku. Je záměrně vynechán ze software CRC16.
steer, throttleHlavní proporcionální řídicí kanály jako signed 16-bit hodnoty.
aux1, aux2Další proporcionální kanály. Pouze během megatransferu v aktivním FS jsou spolu se steer/throttle dočasným osmibajtovým datovým prostorem.
switchesREQ bitová maska požadovaných diskrétních funkcí.
serviceJeden čtyřbajtový request servisního podprotokolu; nuly znamenají idle.
crc16CRC16-CCITT aplikačních dat paketu; při výpočtu se seq nuluje.

4. Wire paket RX → TX

0motor temp
u8
1ESC temp
u8
2RX core temp
u8
3VBAT
u8
4–7service ACK
4 B
8–9switches ACT
u16
10flags
u8
11debug
u8
12CRC8
PoleKódování a význam
Teploty motoru/ESCCelé stupně Celsia; nula také reprezentuje nepřiřazené nebo neplatné externí čidlo.
rx_core_temp_u8Interní teplota ESP v celých stupních Celsia; 255 znamená nedostupné nebo neplatné měření.
vbat_u8Napětí ve voltech × 16. Rozlišení je 1/16 V.
service_ackSymetrická čtyřbajtová odpověď servisního podprotokolu.
switches_actACT maska: skutečný stav funkcí na RX, ve stejném bitovém prostoru jako TX REQ.
flagsStav RX linky, setupu, failsafe a PA.
debugObsahuje příznaky RX battery cutoff, thermal warning a západkového thermal tripu.
crc8CRC8 všech předchozích bajtů ACK paketu.

5. Flags a diskrétní funkce

Společný byte flags

BitJménoVýznam
0FSFailsafe stav.
1SETUPSetup/config režim.
2LINKPeer link je aktuálně platný a čerstvý.
3WELCOMEDiscovery/identifikační režim. RX přikládá CRC-validní 10B jméno nejen bez linku, ale ještě 2 s po vzniku nové link session, aby TX spolehlivě zachytil skutečnou identitu peeru i po prvním řídicím paketu.
4RezervaUvolněno přesunem navijáku do servisního kanálu.
5–6PA levelMIN, LOW, HIGH nebo MAX.
7PA requestRozlišuje informativní PA status od žádosti o změnu.

REQ/ACT switches

TX odesílá požadavek switches, RX vrací skutečnost switches_act. Díky tomu TX pozná stav „požádáno, ale ještě neprovedeno“ i „požadováno vypnutí, ale RX stále hlásí aktivní stav“.

BityDefinované funkce
0–2Přední diff, zadní diff, gear high.
3–5Světla, dálková světla, parkovací brzda.
6–7Rezerva; nejde o proporcionální pole aux1/aux2.
8–12Výstražná světla, maják, naviják dovnitř/ven, lightbar.
13–15Rezerva pro budoucí real-time switch funkce.
Setup příkazy se nemají přidávat do rezervovaných switch bitů. Patří do servisního podprotokolu, kde dostanou transaction ID, explicitní status, kontrolu parametru a ochranu proti opakovanému provedení.

6. Integrita a přijetí paketu

Transport používá dvě kontrolní úrovně:

  1. nRF24 hardware CRC a RF ACK/retry chrání fyzický přenos.
  2. Software CRC16/CRC8 chrání přesný aplikační wire kontrakt.

TX CRC16 pokrývá celý RcTxPacket kromě samotného CRC pole, přičemž diagnostické seq se před výpočtem nuluje. RX ACK CRC8 pokrývá všech 12 bajtů před polem CRC. Service request i response jsou proto zahrnuté v aplikačním i hardwarovém CRC.

Teprve přijatý a ověřený paket je publikován aplikaci přes Postak. RF task tedy neposkytuje aplikační logice rozpracovaný nebo nevalidní frame. Po vyprázdnění celého RX FIFO pošle za batch s alespoň jedním platným paketem jednu task notification; aplikace zpracuje poslední atomický snapshot.

7. Postak: hranice mezi RF a aplikací

Postak je atomický ping-pong mailbox. Pro směr IN i OUT drží stabilní publikovanou kopii a oddělený buffer pro právě připravovaná data.

RF task zapisuje nový paket ↓ ověření CRC a přijetí ↓ atomické publish ↓ aplikační task čte stabilní snapshot

Stejně opačně aplikace připraví další výstupní paket, provede commit a RF task si převezme kompletní stabilní kopii. Tím se omezuje riziko, že jedno jádro nebo task čte strukturu ve chvíli, kdy ji jiné místo zrovna mění.

RolePostak INPostak OUT
TXRcAckRcTxPacket
RXRcTxPacketRcAck

8. Čtyřbajtový servisní podprotokol

Servisní slot má v obou směrech stejný footprint:

ByteRequest TX → RXResponse RX → TX
0horní nibble TID, dolní nibble operationhorní nibble stejné TID, dolní nibble status
1task IDpotvrzený task ID
2parameter IDpotvrzený parameter ID
3hodnota nebo řízení streamuvrácená hodnota nebo řízení streamu

Nulový frame znamená idle. Transaction ID používá hodnoty 1 až 15 a cyklicky se protáčí. TX přijme odpověď pouze při shodě TID, tasku a parametru.

Stop-and-wait pravidla

  1. TX zveřejní jeden request.
  2. Stejný request zůstává v každém hlavním RF paketu.
  3. RX jej provede a vrátí odpověď.
  4. TX čeká na přesně odpovídající terminální status.
  5. Po dokončení zveřejní nulový idle request.

RX si pamatuje poslední request a odpověď. Opakovaný identický RF frame proto neprovede povel znovu, pouze vrátí cache. To zajišťuje idempotenci například při NVS zápisu.

Recovery po ztrátě TX

RX zpracuje service request jen při skutečně nové publikaci vstupu z Postaka; mezi novými pakety drží poslední ACK. Opuštěný upload nebo download autonomně expiruje po 1500 ms nebo po rozpětí 64 hlavních packet sequence čísel. Expirace smaže stream i duplicate-response cache. Po 2000 ms bez nového RF paketu proběhne kompletní reset responderu. Restartovaný TX proto může otevřít novou transakci bez restartu RX a správnost nezávisí na tom, zda stihl odeslat wire CANCEL.

Limity transakce

9. Operace servisního podprotokolu

OperaceÚčel
GETNačtení skutečné aktuální hodnoty z RX.
WRITEZměna runtime/RAM hodnoty.
WRITE_SAVEZměna s persistentním uložením, pokud ji konkrétní task povoluje.
EXECUTEJednorázová akce, například ping nebo explicitní save.
STREAM_BEGINZahájení logického vícebajtového přenosu.
STREAM_DATA_0..3Čtyři možné pozice fragmentu.
CANCELZrušení rozpracovaného streamu.

Response status rozlišuje mimo jiné OK, ERROR, BUSY, UNKNOWN_TASK, BAD_OPERATION, BAD_VALUE, FORBIDDEN, NOT_SUPPORTED a TRANSACTION_MISMATCH. TIMEOUT a RETRY_LIMIT vznikají lokálně na TX.

10. Vícebajtový přenos v pevném 4B slotu

Jedna fyzická výměna má jen jeden datový byte, ale vrstva umí logickou hodnotu dlouhou až čtyři bajty. Jednobajtové hodnoty používají rychlou kompaktní cestu. Širší hodnota se rozdělí na potvrzované fragmenty.

WRITE dvoubajtové hodnoty

TX: STREAM_BEGIN (semantická operace WRITE, délka 2)
RX: STREAM_BEGIN potvrzen

TX: STREAM_DATA_0 + první byte
RX: fragment 0 potvrzen

TX: STREAM_DATA_1 + druhý byte
RX: OK; teprve nyní RX validuje a aplikuje celou hodnotu

GET dvoubajtové hodnoty

TX: GET
RX: STREAM_BEGIN, délka odpovědi 2

TX: žádost o fragment 0
RX: první byte

TX: žádost o fragment 1
RX: druhý byte + OK

TX: sestavení výsledné little-endian hodnoty

Celý stream drží stejné TID, task a parameter. Existuje vždy jen jeden nepotvrzený fragment. Při opožděném nebo špatně seřazeném fragmentu se vrátí BUSY a očekávaný fragment se zopakuje.

Teoretický prostor čtyřbajtového slotu při 200 Hz je 800 B/s v každém směru. Skutečný aplikační datový tok je nižší kvůli hlavičkám, ACK krokům a stop-and-wait. To je záměrné: prioritou je jednoduchost a spolehlivost pomalých příkazů, ne maximální throughput.

11. Aktuální servisní tasky

TaskIDAktuální použití
System0x00Ping, výběr TX AP nebo společné client Wi-Fi pro další RX setup.
Smart drive0x10Automatické blinkry a jejich střed od steering trimu.
Light control0x11Pomocné světelné povely a GET/WRITE runtime LIGHTBAR PWM.
Servo setup0x12GET/WRITE pozic předního/zadního diffu a převodovky, explicitní NVS save.
Winch control0x13GET/WRITE podepsané runtime rychlosti navijáku −100 až +100 % a potvrzovaný arm/disarm jeho servo signálu.
Battery control0x14GET/WRITE_SAVE stavu RX battery guardu a potvrzený sleep během kritického cutoff okna.
Brake ABS0x15GET/WRITE základních parametrů pulzní brzdy v RX RAM a explicitní NVS save.
Log control0x16GET/WRITE_SAVE persistentního RX loggeru a potvrzené smazání RX incident logů.
Megatransfer0x20Potvrzovaný velký přenos; nyní client Wi-Fi profil pro prázdné RX.

Megatransfer a Wi-Fi provisioning

MEGATRANSFER (0x20) je vyhrazená výjimka z obecného čtyřbajtového service payloadu. Čtyřbajtový service rámec zůstává řídicí částí stop-and-wait přenosu; během MEGA_DATA nesou pole steer, throttle, aux1 a aux2 osm datových bajtů. Velikost hlavního paketu zůstává 18 B.

OperaceKódHodnota požadavkuPodmínka úspěšného ACK
MEGA_BEGIN0xBCelkový počet bajtů payloaduREADY (2) až po fyzickém servo LOW
MEGA_DATA0xCIndex 8B chunku od nulyACK vrátí přesně přijatý index
MEGA_END0xDCelkový počet chunkůCOMMITTED (6) až po aplikaci, získání IP a NVS save
CANCEL0xA0Uvolnění session; rollback pouze před commitem

Celý přenos drží stejné transaction ID, task 0x20 a parameter. ACK rámec neobsahuje operaci, proto TX každou nově publikovanou ACK zpracuje pouze jednou a navíc kontroluje hodnotu očekávanou v aktuální fázi: READY, index chunku nebo COMMITTED. Staré OK ponechané v Postaku z předchozí fáze proto nemůže vyvolat falešný stav SYNCED.

Přenos je povolen pouze z TFT Wi-Fi setupu a RX jej přijme jen s aktivním RC_FLAG_FS. RX nejprve přes stávající servo-disarm politiku dokončí rampu, neutral hold a hard-disarm signálů LOW. Teprve potom potvrdí připravenost. Prvním objektem je client Wi-Fi profil o maximálně 103 B: verze, délky, SSID, heslo a CRC32, rozdělené do nejvýše 13 osmibajtových chunků.

RX přijatý profil nejprve zařadí pouze do RAM a počká, až se deferred konfigurace skutečně stane živým client profilem. Potom bez spuštění HTTP serveru ověří připojení a přidělení IP a teprve po úspěchu uloží NVS. Apply, Wi-Fi probe a commit posouvá asynchronní poll RX aplikačního tasku, takže dokončení nezávisí na přijetí dalšího RF požadavku. Krátký RF výpadek způsobený Wi-Fi asociací drží již disarmovanou session; chyba, cancel před commitem nebo vypršení 45s lease vrátí předchozí RAM konfiguraci. Potvrzeně uložený profil se již nevrací.

Datové požadavky odcházejí podle 5ms TX send tiku. RX asynchronní stav apply/connect/save kontroluje při každém validním RF batch eventu a bez RF nejpozději po 20ms safety timeoutu; timeout není rychlostí přenosu chunků. Receive-progress timeout je 3 s, celková lease 45 s a Wi-Fi probe timeout 20 s. Payload má vlastní CRC32, navíc jej chrání stávající packet CRC a hardwarové CRC nRF24. Záměrně není šifrovaný.

Servo setup

Šest pozic OFF/ON používá rozsah −150 až +150 % kolem středu 1500 µs:

pulse_us = 1500 + percent × 5

Rozsah −120 až +120 se vejde do kompaktního jednoho bajtu. Hodnoty mimo něj používají dvoubajtový little-endian int16. WRITE mění pouze RAM a fyzický výstup. Long-click na TFT odešle potvrzený EXECUTE/SAVE_CONFIG; SAVED se zobrazí až po úspěšném NVS zápisu na RX.

Winch control

TFT mění rychlost navijáku po 5 % a odesílá absolutní podepsanou hodnotu. Záporná hodnota znamená OUT, kladná IN a nula STOP. RX převádí procenta přímo na nakonfigurovaný WINCH_PWM servo pulz pouze v době, kdy je otevřené TFT menu navijáku. Otevření odešle potvrzovaný arm při nulové rychlosti. Zavření nejprve dokončí potvrzený STOP a potom potvrzený disarm, který drží pouze tento signál trvale LOW. Failsafe, setup, restart RX nebo aplikace konfigurace rychlost vynuluje a výstup disarmuje. Proporcionální AUX pole hlavního paketu zůstávají volná.

Battery control

BATTERY_CONTROL (0x14) odděluje autonomní RX ochranu od potvrzeného rozhodnutí uživatele. GET/GUARD_ENABLED čte uložený stav guardu, WRITE_SAVE/GUARD_ENABLED jej mění a ukládá a EXECUTE/SLEEP_NOW potvrzuje deep sleep pouze během aktivního cutoff rozhodovacího okna.

Po potvrzeném kritickém podpětí RX drží failsafe a servo-disarm sekvenci nejvýše 15 s. TX může potvrdit okamžitý sleep nebo po vědomém dlouhém držení guard trvale vypnout. Bez rozhodnutí, po ztrátě service linku nebo při nouzovém napěťovém flooru RX usne autonomně. Service odpověď nikdy nenahrazuje lokální RX ochranné rozhodnutí.

Brake ABS

BRAKE_ABS (0x15) zpřístupňuje přes TFT Adjust/ABS režim OFF/LINEAR/FIXED, frekvenci 5–50 Hz, lineární duty min/max a pevné duty 0–100 %. Otevření karty automaticky sekvenčně provede GET všech pěti skutečných RX hodnot do existující TX RAM cache; klik na načtený řádek proto může rovnou otevřít editaci bez druhého GET. Při první chybě se dávka zastaví, aby nedostupný RX nevyvolal řetězec timeoutů. Potvrzení používá RAM-only WRITE; dlouhý stisk odešle jediný EXECUTE/SAVE_CONFIG a dirty stav se smaže až po úspěšném NVS ACK. Změna parametru resetuje ABS stavový automat do bezpečného čekání na uživatelský neutrál. Čtyřbajtový service slot a velikosti paketů 18/13 B se nemění.

Log control

LOG_CONTROL (0x16) obsluhuje TFT kartu Setup/Logs. GET/ENABLED načte skutečný uložený stav RX loggeru, WRITE_SAVE/ENABLED jej persistentně zapne nebo vypne a EXECUTE/ERASE smaže uložené RX incident logy. Stav TX loggeru je lokální; společné Erase all nejprve čeká na OK z RX a až potom smaže TX failsafe a crash logy. BUSY, timeout nebo nedostupný RX proto nezpůsobí jednostranné smazání TX. Celý read/toggle/ erase průchod byl prakticky potvrzen na aktuální stable v3 dvojici. Wire rámce ani velikosti paketů se nezměnily.

12. Oddělení real-time a servisní cesty

Real-time částServisní část
steer, throttle, AUXsetup a konfigurace
switch REQ/ACTGET skutečného nastavení
failsafe a link flagspotvrzené RAM změny
základní telemetrieexplicitní NVS save
každý RF cyklusjedna stop-and-wait transakce

Čekání, retry nebo více fragmentů běžné servisní transakce nepozastaví hlavní ovládání. Vyhrazený megatransfer je vědomá výjimka: běží pouze v aktivním FS po servo hard-disarmu, nuluje switches a osová pole dočasně používá jako data.

RX profile backup/restore není další RF service objekt. Velký verzovaný JSON jde v setup režimu cestou prohlížeč → TX WebSetup → RX HTTP API. Schema-v2 přidalo parametrický battery profil a schema-v3 top-level konfiguraci pulzní brzdy; Wi-Fi hesla, API klíč, live telemetrie, logy a OTA stav se záměrně neexportují.

13. Typická úplná servisní cesta

Uživatel otevře vzdálenou servo nebo ABS kartu na TFT ↓ TX menu zneplatní cache karty a požádá supervisor o první GET ↓ Requester přidělí TID a vytvoří service request ↓ Supervisor vloží request do RcTxPacket ↓ Postak publikuje stabilní TX snapshot ↓ RF odešle celý 18B paket ↓ RX ověří CRC16 a publikuje paket přes svůj Postak ↓ Responder ověří TID / operation / task / parameter ↓ RX service runtime načte skutečnou konfiguraci ↓ Responder vytvoří 4B service ACK ↓ RX vloží odpověď do 13B RcAck a spočítá CRC8 ↓ nRF24 vrátí RcAck jako ACK payload ↓ TX ověří CRC8 a publikuje ACK přes Postak ↓ Requester přijme pouze odpověď se shodným TID/task/parameter ↓ TFT uloží skutečnou hodnotu do existující RAM cache ↓ TX sekvenčně zopakuje cestu pro zbývající parametry karty ↓ Po dokončení jsou všechny hodnoty viditelné a klik otevře editaci bez dalšího GET

14. Kompatibilita a pravidla dalšího růstu

TX a RX se nesmějí aktualizovat nesourodými wire verzemi. Současný systém nemá handshake, který by bezpečně přeložil starší ACK a 13B aktuální ACK. Pro změnu wire formátu se proto nasazují oba firmware společně.

15. Lokální I2C linka a světelný modul

RF kontrakt zůstává 18 B TX / 13 B základní ACK / 4 B service. I2C je samostatná lokální HW hranice na RX. Výsledný logický stav světel vlastní RX supervisor, adresovou dostupnost a Wire recovery vlastní i2c_devices, protokol modulu přenáší rx_light_i2c. Obě strany používají sdílený i2c_light_module/lib/light_i2c_protocol.

RX supervisor → konfigurace + latest-wins světelný stav
  → rx_light_i2c → LightI2cMaster → Wire / I2C 100 kHz → STM8
i2c_devices → dostupnost adres + generace obnovy sběrnice
HraniceSoučasný kontrakt
Elektrická vrstva RX V2GPIO35 SDA, GPIO36 SCL; STM8 PB5 SDA, PB4 SCL; společná zem, 3,3V pull-up, adresa 0x30.
DiscoverySTM8 kontrola 250 ms, odpojení po dvou NACK; jedna MPU6050 na 0x68 nebo 0x69, kontrola dostupné/nedostupné 500/1500 ms, tři NACK.
Recovery sběrniceOpakovaný bus error/timeout → odložené Wire.end(), nejvýše devět SCL pulzů a STOP, Wire.begin(). Samotný address NACK ani CRC/short-read klienta zdravou sběrnici neresetuje.
INFO protokol v3CRC, magic, verze, schema, 1–16 kanálů, velikost konfigurace a dvě 16bitové PWM masky. STM8 0.8: 11 kanálů, config 82 B, HW 0x0607, PWM 0x07FF.
KonfiguraceVelikost 3 + N × 6 + 13 B; bloky dat nejvýše 16 B, atomický CONFIG_COMMIT a potvrzení CONFIGURED se správnou generací.
RuntimeI2C task s 20ms průchody; STATE po 150 ms a STATUS přibližně po 1 s. Výběr čteného registru a čtení jsou oddělené STOPem.
Změna / návrat moduluNulový STATE před reconfig; živá data až po potvrzení generace. Reconnect, reset modulu či generace bus recovery opakují handshake. Modul autonomně hlídá timeout a failsafe duty.
Profil / UI16 External pozic v RX NVS v11, JSON schema v6 (import v1–v6); skutečné kanály a funkce řídí INFO. FRONT/REAR jen HW PWM, LIGHTBAR PWM, digitální kanály jen 0/255 bez fade.

Lokální bindingy se při připojení modulu nepřepisují. Shodná lokální/externí funkce sdílí autoritativní parametry. Žádný I2C krok neblokuje RX control task; adresa s ACK sama o sobě nepotvrzuje kompatibilitu ani aktivní konfiguraci modulu.

Obnova místního nRF

Po 200 ms bez platného řídicího paketu (RX) nebo ACK payloadu (TX) RF task ověří STATUS a aktuální CONFIG, kanál, rychlost, PA, retry, ACK/dynamic payload registry a adresy. Zdravý čip pokračuje bez reinitu. Při chybě proběhne begin(&SPI), obnova konfigurace a readback bez restartu SPI, objektu nebo tasku. Další kontrola/pokus je nejdříve 1 s od dokončení předchozího. Pošťák, čas posledních platných dat a safety se neresetují. Diagnostika: [RF][health] a čítače kontrol/pokusů/úspěchů.

Současný výsledek

Aktuální RC protokol kombinuje tři vlastnosti:

  1. Deterministické real-time řízení ve 200Hz pevně strukturované výměně.
  2. Skutečný stav RX přes ACK telemetrii a REQ/ACT masky.
  3. Spolehlivé pomalé služby přes symetrický 4B stop-and-wait podprotokol s fragmentací, deduplikací a explicitní persistencí.

Výsledkem není druhá paralelní radiová linka. Je to jedna RC výměna, nad kterou běží dvě logické cesty: nepřetržité řízení a potvrzovaná servisní komunikace.