Testování telemetrie pomocí UART simulátoru a CP2102

Navrhnout telemetrický systém je jen polovina práce. Ta druhá – často podceňovaná – je důkladné testování. V prostředí CanSat projektu nemáme prostor na chyby. Let trvá krátce, podmínky jsou nepředvídatelné a jakákoli chyba v komunikaci znamená ztrátu dat.

V tomto článku si ukážeme, jak efektivně testovat client-side telemetrii bez potřeby finálního hardware – pomocí UART simulátoru a USB–UART převodníku (např. CP2102).

Cílem je vytvořit testovací prostředí, které:

→ simuluje reálné chování mikrokontroleru
→ umožňuje generovat chyby a edge-case scénáře
→ pomáhá odhalit problémy ještě před integrací
→ šetří čas během vývoje i ladění

Proč vůbec simulovat telemetrii

Testování pouze s reálným mikrokontrolerem má několik problémů:

→ omezená kontrola nad daty
→ obtížné generování chyb
→ pomalejší iterace vývoje
→ závislost na hardware

Simulátor naopak umožňuje:

→ plnou kontrolu nad datovým tokem
→ opakovatelné testy
→ rychlé ladění parseru
→ testování extrémních scénářů

Jinými slovy: simulátor ti dovolí rozbít systém kontrolovaně – a to je přesně to, co chceš.

Hardware setup

Základní zapojení je velmi jednoduché:

PC→USB–UART převodník (CP2102)→ Raspberry pi

Propojení:

→ TX (CP2102) → RX (Raspberry Pi)
→ GND → GND

Důležité:

→ nepřipojovat TX ↔ TX
→ hlídat logické úrovně (většinou 3.3V OK)

Tímto vznikne virtuální „mikrokontroler“, který posílá data do Raspberry Pi.

Co vlastně simulujeme

Simulátor generuje kompletní binární packety:

→ timestamp
→ senzorová data
→ CRC
→ ukončovací sekvenci

Navíc umožňuje:

→ náhodné hodnoty (realističtější data)
→ simulaci selhání senzorů
→ záměrné poškození CRC

To je zásadní rozdíl oproti jednoduchému „posílání stringů“.

Typy testů, které bys měl dělat

1. Základní funkčnost

Cíl:

→ ověřit, že parser funguje

Test:

→ spustíš simulátor bez chyb
→ kontroluješ, že:

• všechny packety jsou [valid]
• data dávají smysl
• log roste správně

2. CRC fail test

Cíl:

→ ověřit detekci poškozených dat

Simulace:

→ zvýšíš pravděpodobnost CRC chyby

Očekávání:

→ systém NEuloží data (bez toho bys ukládal garbage)
→ místo toho zapíše [corrupt]

3. Sensor fail test

Simulace:

→ některé hodnoty jsou nahrazeny invalidními (např. max int)

Testuješ:

→ jestli parser správně:

• rozpozná nevalidní hodnotu
• necrashne
• stále uloží packet jako validní/částečně validní

Rozdíl:

→ CRC fail = poškozený packet
→ sensor fail = validní packet, ale špatná data

Tohle je důležité rozlišovat.

4. Long-run test (stabilita)

Cíl:

→ ověřit dlouhodobou stabilitu

Postup:

→ necháš běžet simulátor desítky minut až hodin

Sleduješ:

→ únik paměti
→ zpomalování
→ velikost logu
→ integritu souboru

Tohle často odhalí bugy, které krátké testy neukážou.

5. Desynchronizace streamu

Reálný problém UART:

→ ztráta bajtu → posunutí packetu

Test:

→ simulátor generuje chyby
→ sleduješ, jestli se parser:

• znovu „chytí“ na END sekvenci
• nezačne generovat nesmysly

Dobrý parser:

→ se vždy vrátí do synchronizace

Špatný parser:

→ produkuje nekonečný chaos

Proč je tento přístup lepší než testování jen na HW

1. Rychlost vývoje

Simulátor:

→ okamžité změny
→ žádné flashování MCU

HW-only:

→ pomalé iterace
→ závislost na firmware

2. Kontrola nad chybami

Simulátor:

→ přesně nastavíš, co se rozbije

HW:

→ chyby jsou náhodné a špatně reprodukovatelné

3. Reprodukovatelnost

Simulátor:

→ stejný scénář můžeš spustit znovu

HW:

→ „nějak se to pokazilo“ → hodně štěstí

4. Debugging

Simulátor:

→ přesně víš, co jsi poslal

HW:

→ musíš hádat, kde vznikla chyba

Shrnutí

Použití UART simulátoru s CP2102 ti umožní:

→ testovat telemetrii bez finálního hardware
→ generovat realistická i chybová data
→ ladit parser rychle a efektivně
→ výrazně zvýšit spolehlivost systému

Nejdůležitější myšlenka:

→ systém není hotový, dokud jsi ho pořádně nerozbil

A přesně k tomu tenhle přístup slouží.