Jedním z problémů, který jsem řešil během práce na samostatném projektu v rámci studia na univerzitě bylo vybudování bezdrátové sítě, která by umožňovala propojit moduly používající IEEE 802.11 (Wifi) na druhé vrstvě, tj. adresovat pomocí mac adres a informace balit do ethernet framů. A následně změřit vlastnosti, které takto vybudovaná infrastruktura bude mít.

Příprava prostředí pro měření

Použitý hardware

K práci jsem využíval moduly od firmy Espressif, konkrétně ESP32-S2-pico a ESP32-S2-LCD-0.96inch s displejem pro účely debuggování. Jedná se o Wifi vývojové desky s základními periferiemi jako je ADC převodník, I2C a SPI komunikace či UART. Deska integruje low-power Wifi System on Chip (SoC). Oproti od ESP32, které má 2 jádra procesoru, ESP32-S2 má pouze jeden Xtensa singlecore 32-bit procesor, označován jako ESP32-S2FH4, který podporuje frekvenci hodin až do 240 MHz.

Vývojové prostředí

MCU z rodiny ESP32 a EPS8266 lze programovat v podstatě 2 způsoby, respektive 2 frameworky. Já se rozhodl postavit základ na Arduino frameworku, který je pro počáteční konfiguraci méně náročný a používat knihovny z ESP-IDF frameworku. Jako vývojové prostředí jsem si vybral VS Code s PlatformIO. Dle mého se jedná o uživatelsky přívětivé prostředí. Navíc má vysokou podporu komunity a disponuje již spoustou připravených balíčků a konfigurací pro vývojové desky.

; Konfigurace platform.io projektu
[env:esp32dev]                   ; podmínka prostředí
platform = espressif32           
board = esp32-s2-saola-1         ; vývojový bord se sejným procesorem
framework = arduino              ; volba framweorku
board_build.mcu = esp32s2        ; volba typu procesoru
upload_protocol = esptool        ; nástroj pro stahování softwaru do zařízení
board_build.f_cpu = 240000000L   ; definování frekvence
board_build.flash_mode = dio     ; rychlostní mód nahrávaní do paměti

Protokol

Při průzkumu knihoven, které bych mohl využít použít právě pro takovýto přístup, jsem objevil protokol ESP-NOW. Jedná se o protokol, který je určený především pro ovládání IoT zařízení, například v aplikaci ovládání LED světélek či přenos dat mezi sezory. Protokol je open-source a díky pouze základní implementaci je široce modifikovatelný, respektive pro komplexnější využití je nutné ho modifikovat.

Protokol podporuje:

• šifrovanou a nešifrovanou unicast komunikaci nastavitelnou pro každé zařízení individuálně,
• přenosovou kapacitu 250 bajtů,
• odesílání callbacku, které slouží jako potvrzení o úspěšném přijetí zprávy.

Nejvýraznější limity protokolu dle mého jsou:

• neefektivní implementace broadcastu (lze si povšimnout na naměřených hodnotách)
• a limitace počtu připojených zařízení.

Program použitý pro měření

Vytvořil jsem jednoduchý program, který v podstatě testuje round-time trip.

Funguje tak, že:

1. zaregistruje USB callback a spustí sériovou komunikaci,
2. inicializuje struktury nutné pro správné fungování protokolu ESP-NOW ^[1] a zaregistruje callback pro příchozí a odchozí komunikaci.
3. V případě veze MCU s displejem, inicializuje displej a vypíše na něj vlastni MAC adresu.
4. Ukončí inicializační metodu. V případě MCU bez displaje ohlásí konec konfigurace bliknutím červené LED diody, která je vestavěné na desce.
5. Spustí měření, které má za úkol simulovat reálný provoz. Zde je možné konfigurovat základní parametry. Program měří round-time trip. Respektive dobu, poslání informace ze zařízení A, jejího uložení do patřičné struktury v zařízení B, odeslání zpět do zařízení A a uložení do patřičné struktury v zařízení A. Pokud se informace nevrátí ze zařízení B do určitého deadlinu, zařízení A registruje zprávu jako chybovou a odesílá rovnou další. V případě použití MCU s displejem, je proces měření zobrazován ve formě progress baru.
6. Po ukončení měření, se data vypíšou do konzole pro následné zpracování.

Veškeré kódy jsou dostupné v repozitáři na mém GitHubu.

Měření

Aby bylo možné otestovat různé parametry v různých prostředích, rozhrnul jsem měření na několik scénářů.

Při měření byly sledovány následující parametry:

• prostředí, v němž bylo měření prováděno,
• překážka mezi zařízeními,
• vzdálenost mezi zařízeními,
• velikost zprávy (payload), ^[2]
• počet odeslaných zpráv,
• typ odesílání (broadcast/unicast),
• počet chybných zpráv. ^[3]

Scénář A

V scénářích typu A se snažím otestovat to, jak změna parametru typu odesílání, tj. přepínání mezi brodacastem a unicastem, ovlivní round-time trip v závislosti na velikosti zprávy. Měření se odehrává v prostředí bytu v činžovním domě, kde dochází k rušení několika okolními Wifi sítěmi.

Broadcast

Unicast

Výsledky měření těchto scénářů si je možné prohlédnout v následujících. Odesílání se chová dle očekávání. Zprávy větší velikosti trvají déle než zprávy menší. Zajímavé je srovnání broadcastu a unicastu. Broadcast je nepatrně pomalejší.

Také je zajímavé si povšimnout nakumulovaných odpovědí v jeden čas. Tuto skutenčost si vysvětluji implementací broadcastu v prokolou ESP-NOW.

Scénář C

Sadou scénářů Cx se snažím pozorovat vlastnosti v signálově čistém prostředí  v  závislosti na vzdálenosti a typu vysílání. Nejedná se o laboratorně čisté prostředí. Měření bylo prováděno v prostředí lesa, který je od nejbližší obce vzdálen asi 5 km a v okolí mého bydliště nejvíce čisté od 2,4 GHz rušení.

Výsledky měření těchto scénáře si je možné prohlédnout v grafu. Zde se opět prokol chová dle očekávání. Nedochází k takovému zpoždění, jako například při měření scénářů typu A. Také si je možné povšimnou toho, že se jednou za čas nějaká zpráva opozdí.

Při tomto měření jsem zaznamenával také chybovost počet chybných zpráv. ^[4] Jejich četnost si ji možné prohlédnout v tabulce s C scénáři.

Během tohoto měření jsem zjistil, že je důležité, aby na větší vzdálenosti (25 m a více), nestála signálu v cestě žádná překážka.

Zajímavé je také srovnání scénáře A a C. Můžeme pozorovat, že vliv vzdálenosti ovlivňuje především ztrátovost paketů. Naopak velikost ovlivňuje rychlost přenosu.

Scénář D

Scénář D byl oproti ostatním měřením odlišný v tom, že jsem se nejprve snažili stanovit hranici, kdy je zařízení ještě schopno přijímat zprávy a kdy už ne. Experimentálně jsem dospěl k hranici 580 m. Následně jsem odeslal 1000 zpráv s cílem zjistit, jak je veliká ztrátovost. Měření bylo realizováno na poli, přes které může procházet signál na 2,4 GHz.

Při měření jsme zjistil, že při odesílání na velikou vzdálenost je třeba dbát na orientaci čipu. Pokud nebylo zařízení správně natočeno, nešlo odeslat žádné zprávy.

Výsledek měření je vizualizován grafem D1. Při tomto scénáři bylo ovšem mnohem zajímavjěíš pozorovat četnost úplné ztráty dat. Při odeslání 1000 zpráv, se ztratilo 50. Můžeme tedy jednoduchým výpočtem zjistit, jaká je procentuální ztrátovost na dlouhé vzdálenosti.

$$loss=\frac{err}{sent}$$

V našem případě se při odeslání 1000 zpráv objevilo 50 chyb. Pro chybovost tedy platí:

$$\frac{50}{1000}=0,05=loss$$

Závěř

Veškerá naměřená data se skripty pro vyrenderováni grafů je možné najít v repositáři.

Uvědomuji si, že měření nebylo prováděno za ideálních podmínek. Přesnost měření mohlo ovlivnit především to, že:

• se jeden čipů měl větší odběr proudu a mírně se při měření přehříval,
• větší vzdálenosti byly měřeny s přesností na jednotky metrů a největší vzdálenosti s přesností na 10 m,
• les nebyl absolutně odstíněný od 2,4 GHz,
• během měření různých scénářů jsme upravoval kód,
• v některých scénářích by větší množství dat, mohlo říci více.

Zajímavé jsou ještě 2 výše zmíněné poznání. Konkrétně to, že při přenosu na delší vzdálenost je nutné, aby signálu nebránilo nic v cestě a aby byly moduly správně orientovány.

Výsledky mi prokázali, že protokol ESP-NOW splňuje očekávané požadavky a je vhodný pro použití v budoucí implementaci.

Všechna data tohoto článku, jsou vytažena z části mé bakalářské práce, respektive samonstatného projektu, který je dostupný na mém GitHubu.

---

1. Jako je například ESP_NOW_HANDLER. ↩︎

2. Maximální velikost je 250 bajtů. ↩︎

3. Tento parametr nebyl sledován u scénáře A, jelikož zde nedocházelo k ztrátě zpráv. ↩︎

4. Chybnou zprávou se myslí taková zpráva, která nedorazí do specifikovaného deadlinu, tedy mimo graf. ↩︎