Wstęp
E32-TTL to rodzina modułów łączności radiowej dalekiego zasięgu firmy EBYTE. Działają na częstotliwości 433 MHz, ale dostępne są też wykonania na inne pasma ISM (868 w Europie i 915 w USA). Występują wersje o mocach 100mW, 500mW do 1W. Jest to transceiver LoRa (energooszczędny, dalekodystansowy) - może odbierać i wysyłać dane na odległość do 3km, a przy mocy 1 W do 8 km (halfduplex). Proste testy bez wyszukanej anteny pozwoliły na łączność na odległość około 1 km z mocą 100mW, przy czym wykorzystywane były domyślne ustawienia transmisji (prędkość 2400 bps), oraz odbiornik był schowany w plecaku. Komunikacja modułu z mikrokontrolerem odbywa się za pomocą interfejsu UART TTL.
Moduł E32-TTL-100. Źródło: https://electrosparks.com/product/wireless-transceiver-module/
Specyfikacja:
napięcie zasilania od 2.3V do 5.5V
napięcie logiki 3.3V
wzmocnienie 10 do 20 dBm (max 100mW) dla E30-433T20D
pobór prądu w stanie uśpienia 5μA
pobór prądu w trybie odbioru danych 15mA
temperatura pracy od -40 do 85°C
wymiary 21 mm x 36 mm
cena od około 20zł za sztukę (bez anteny) przy zakupie w Chinach.
Co siedzi w środku?
Moduł wykorzystuje układ modemu radiowego SX1278 lub SX1276 oraz kontroler STM8L151.
Źródło: https://fccid.io/images/device/2ALPH/-E32-TTL-100/Internal-Photos-85DC724C.jpg
Kontroler STM8 jest zablokowany i nie da się ściągnąć istniejącego firmware (http://qczek.beyondrc.com/qczek-lrs-433mhz-1w-lora-rc-link/qczek-lrs-build-guide/ http://qczek.beyondrc.com/qczek-lrs-433mhz-1w-lora-rc-link/qczek-lrs-flashing-new-firmware/)
Sposób transmisji danych w E32-TTL
W Internecie można spotkać kilka zapytań bez odpowiedzi, jakie są parametry transmisji zapewniające współpracę modułu z „gołym” modemem SX127x. Jeśli są odpowiedzi, to tylko stwierdzające, że EBYTE stosuje własny protokół, w dodatku z kompresją i szyfrowaniem (gdzieś miałem link). Jednak jak to w opiniach na forum, nie było żadnych szczegółów na poparcie tych twierdzeń.
Postanowiłem sprawdzić jak to jest naprawdę z tymi modułami. Kilka razy podchodziłem do tematu, wykorzystując jeden E32-TTL-100 jako nadajnik oraz płytkę Heltec WiFi LoRa ESP32 jako odbiornik. Przestudiowałem dokumentację E32-TTL-100 (np. http://forum.arduino.cc/index.php?action=dlattach;topic=502618.0;attach=228256 lub na stronie producenta) a także modułu SX127x. Początkowo próbowałem oprzeć się tylko na dokumentacji, aby przez porównanie podanych parametrów (np. czułości) wydedukować użyte parametry transmisji LoRa. Jednak w zależności od wersji dokumentacji produktu EBYTE, występują rozbieżności w podawanej czułości układów przy najniższej prędkości transmisji, brak też podanej szerokości pasma. W raporcie FCC także nie doszukałem się pomocnych informacji. Miałem zatem dwa wyjścia: albo rozebrać jeden moduł i podłączyć się analizatorem sygnałów logicznych do magistrali SPI (lub nawet próbować wyciągnąć firmware z STM8) lub jeszcze popracować nad „miękkim” sposobem, opartym o analizie transmisji. Postanowiłem zacząć od miękkiego podejścia.
Postanowiłem sprawdzić jak to jest naprawdę z tymi modułami. Kilka razy podchodziłem do tematu, wykorzystując jeden E32-TTL-100 jako nadajnik oraz płytkę Heltec WiFi LoRa ESP32 jako odbiornik. Przestudiowałem dokumentację E32-TTL-100 (np. http://forum.arduino.cc/index.php?action=dlattach;topic=502618.0;attach=228256 lub na stronie producenta) a także modułu SX127x. Początkowo próbowałem oprzeć się tylko na dokumentacji, aby przez porównanie podanych parametrów (np. czułości) wydedukować użyte parametry transmisji LoRa. Jednak w zależności od wersji dokumentacji produktu EBYTE, występują rozbieżności w podawanej czułości układów przy najniższej prędkości transmisji, brak też podanej szerokości pasma. W raporcie FCC także nie doszukałem się pomocnych informacji. Miałem zatem dwa wyjścia: albo rozebrać jeden moduł i podłączyć się analizatorem sygnałów logicznych do magistrali SPI (lub nawet próbować wyciągnąć firmware z STM8) lub jeszcze popracować nad „miękkim” sposobem, opartym o analizie transmisji. Postanowiłem zacząć od miękkiego podejścia.
Widmo dla prędkości 300bps, zdjęcie własne.
Dzięki tunerowi RTL-SDR pracującemu jako analizator widma, udało się ustalić szerokość widma BW (Bandwidth) dla każdej z dostępnych prędkości transmisji w module E32. Dzięki wzorowi z dokumentacji układu SX127x daje się prosto wyznaczyć parametr SF (Spreading Factor). Rs=BW/2SF. Dopuszczalne wartości SF są w przedziale 6-12, zatem np. dla prędkości transmisji 300bps i szerokości pasma 125kHz SF powinno wynosić 12.
Problemem, który znacznie opóźnił poznanie transmisji z modułu E32-TTL, były używane przeze mnie biblioteki do obsługi układu LoRa w płytce Heltec LoRa. Dostarczone przez Heltec biblioteki nie zapewniają wystarczającej kontroli nad układem SX127x. Dopiero użycie biblioteki https://github.com/jgromes/RadioLib pozwoliły tak wysterować układ, że stało się możliwe odebranie pierwszych bajtów nadawanych z prędkością 300bps.
Nadajnik z E32-TTL-100 (z lewej) i odbiornik Heltec WiFi LoRa ESP32. Zdjęcie własne.
Do badania sposobu transmisji wykonałem dwa programy: nadajnik, pracujący na płytce Arduino z prototype shield z połączonym modułem E32-TTL-100 (pracujący w oparciu o bibliotekę https://github.com/KrisKasprzak/EBYTE) oraz odbiornik, pracujący, jak już wspominałem, na płytce Heltec WiFi LoRa ESP32 ze wspomną biblioteką RadioLib. Oba programy posiadają prosty interfejs, pozwalający przez konsolę szeregową na zmianę podstawowych parametrów pracy modułów radiowych bez potrzeby przeprogramowywania kontrolerów.
A co z szyfrowaniem?
Nadawane bajty są poddawane w E32-TTL kilku zabiegom: szyfrowaniu i kodowaniu kanałowemu (FEC – Forward Error Correction). Problem kodowania kanałowego można pominąć, wyłączając w module E32-TTL używanie korekcji FEC. Nadal jednak bajty odebrane nie miały postaci tekstu jawnego. Łatwo daje się tylko rozróżnić nagłówek 4 bajtowy (zawierający bajt długości pakietu danych, bajt „klucza” i dwa 0). Oczywiście, że klucz jest kluczem udało się odgadnąć po wielu próbach. Szyfrowanie stosowane w niektórych prędkościach transmisji wykorzystuje przekształcony klucz z nagłówka do wykonania funkcji XOR na kolejnych bajtach danych. Te prędkości to 300, 2400, 4800 bps. Dla nich nagłówek ma opisaną wyżej postać. Dla innych prędkości (1200, 9600, 19200) nagłówek zmienia się, dwa zera zastępowane są przez inne wartości. Pozostaje bez zmian tylko pierwszy bajt określający długość pakietu danych. Reszta danych jest niemalże losowa. Czyżby dla różnych prędkości transmisji było stosowane inne szyfrowanie?
Optymalizacja nie tylko dla małych prędkości
Dokumentacja SX127x mówi o ustawieniu LowDataRateOptimize, który musi być ustawiony tak samo na obu końcach transmisji. Logika i dokumentacja podpowiada, że ta optymalizacja powinna dla prędkości wyższych wyłączona. Jednak postanowiłem to sprawdzić. I okazało się, że ustawienie LowDataRateOptimize nie ma dużo wspólnego z prędkością, ponieważ ustawione jest losowo dla najniższych i najwyższych prędkości transmisji. Po przeprowadzeniu testów utworzyłem tablicę z ustawieniami SF, BW i LowDataRateOptimize dla odpowiadających prędkości ustawionych w module E32-TTL.
Parametry transmisji w E32
Ostatecznie, dla trybu bez FEC, parametry transmisji są następujące:
|
Prędkość transmisji |
Bandwidth [kHz] |
Spreading Factor |
LowDataRateOptimize |
|
300 |
125 |
12 |
1 |
|
1200 |
250 |
11 |
1 |
|
2400 |
500 |
11 |
0 |
|
4800 |
250 |
8 |
0 |
|
9600 |
500 |
8 |
1 |
|
19200 |
500 |
7 |
1 |
Co dalej?
Na tym etapie pozostają problemy do rozwiązania:
1. Z transmisją kodowaną FEC; (znaleźć gotową bibliotekę lub wykonać własną implementację FEC).
2. Z transmisją do modułu E32-TTL; wstępne próby nie zakończyły się powodzeniem. Zdaje się, że pakiet zawiera jeszcze na końcu sumę kontrolną. Z bardzo wstępnych ustaleń wydaje się, że to suma jedno bajtowa. Temat rozwojowy ;-)
3. Czy w innych wersjach E32 jest takie samo kodowanie?
1. Z transmisją kodowaną FEC; (znaleźć gotową bibliotekę lub wykonać własną implementację FEC).
2. Z transmisją do modułu E32-TTL; wstępne próby nie zakończyły się powodzeniem. Zdaje się, że pakiet zawiera jeszcze na końcu sumę kontrolną. Z bardzo wstępnych ustaleń wydaje się, że to suma jedno bajtowa. Temat rozwojowy ;-)
3. Czy w innych wersjach E32 jest takie samo kodowanie?
