Dnes si ukážeme implementáciu senzorového uzla pre LoRa PPP (Point-to-Point) komunikáciu, ktorý bude postavený na DPS 433_LoRa_Lolin32. Tento senzorový uzol bude merať napätie trakčnej batérie (12V), ktorá napája elektrický oplotok, resp. zdroj impulzov, ktorý do oplotku generuje krátke vysokonapäťové pulzy o energii okolo 1J, ktoré odradia zver pri pokuse o prekročenie plota, čo by malo za následok spôsobenie škôd na poli. 
Trakčná batéria je zároveň dobíjaná vlastným kontrolérom zo solárneho panelu, ktorý je doň pripojený. Samotný kontróler má aj vlastný relé výstup, kde je možné napojiť záťaž a spínať ju pri určitom rozsahu napätí trakčnej batérie, alebo len počas dobíjania solárnym panelom, či s použitím časovačov, vďaka čomu je možné spúšťať záťaž iba napríklad cez noc, alebo v pravidelných intervaloch.
Častokrát sa stalo, že zver stiahla plot a zvalila ho po elektrickom šoku, čo spôsobilo prebíjanie oplotku do zeme, prípadne aj cez mokrú trávu po dažďi, ktorá sa dotýkala oplotku a násobne rýchlejšie došlo k vybitiu batérie, niekedy aj len počas 24 až 48 hodín na nebezpečné hodnoty, bežne aj pod 8V, čo má z dlhodobého hľadiska zlé účinky, najmä na kapacitu batérie. Senzorový LoRa uzol tak bude mať za úlohu v pravidelných intervaloch posielať údaje o aktuálnom napätí batérie, ktorej napätie zistí skrz napäťový delič a následným prepočtom si vyráta vstupné napätie deliča, ktoré odpovedá napätiu trakčnej batérie.
Pôvodne som riešenie chcel vytvoriť na doske XIAO_LoRa, avšak pájkovanie batérie priamo na pady zo spodnej časti XIAO dosky sa mi veľmi nepáčilo, zvlášť, keď som nemal JST XH konektor (v SMD verzii) s roztečou 2,54 mm, teda v obdobnom prevedení ako to má PH 2.0 verzia na Lolin32 devkite. Baterku som nechcel natvrdo pájkovať bez možnosti odpojenia.
Doska 433_LoRa_Lolin32 obsahuje možnosti pripojiť:
V porovnaní s XIAO_LoRa doskou, 433_LoRa_Lolin32 nediposnuje miestom pre spájkovanie rezistorov priamo na DPS. Z toho dôvodu ich bolo nutné napájkovať priamo na kábel, ktorý ide k batérii. Použil som rezistory, ktoré šuflík dal. Pri výbere som dbal nato, aby som pokryl celé možné napätie batérie, ktorá je dobíjaná samostatným systémom. Štandardne môže mať až 14,8 V (pre ľahšie výpočty zaokrúhlime na 15V).
Nakoniec som sa rozhodol pre 470K rezistor na vstup a 100K rezistor do zeme na napäťovom deliči. Z takéhoto pomeru rezistorov vzniklo to, že výstupná napätie deliča je 5,7-krát menšie od vstupného. Nevyužije sa tak celý 3V3 rozsah ESP32 a jeho ADC pinu, pri napätí batérie 15V bude na výstupe deliča 2.63V, teda je tam ete viac ako 0,6V rezerva na zvyšovanie vstupného napätia ešte o viac ako 3V.
Samotná spotreba deliča sú nízke desiatky uA, ktoré sú ťahané z batérie. Pri 12,6V je to niečo cez 20 uA, čo je zanedbateľný prúd, ktorý prakticky ani neovplyvňuje výdrž trakčnej batérie, keďže denná spotreba (za 24 hodín) bude niekde na úrovni 480 uAh až 600 uAh v závislosti od vstupného napätia meranej trakčnej batérie, ktoré sa mení, nakoľko je batéria nabíjacím obvodom dobíjaná počas dňa a slnečného žiarenia, teda v danom čase je napätie vyššie v porovnaní napr. s nocou, kedy solárny panel negerenuje napätie pre nabíjanie.
Túto formulu používa aj senzorový uzol po meraní mV na ADC pine na prepočet vstupného napätia. Vysielač vysiela ADC napätie a aj vypočítané vstupné napätie deliča v preddefinovanej štruktúre, ktorú pozná aj prijímač, aby dokázal dáta dekódovať. Pri meraní ADC pinom mikrokontroléra ESP32 sa vykonáva jedno skúšobné meranie, ktoré ma za úlohu eliminovať šum, či naindukované napätie a následne sa vykonáva 5 priemerovaných meraní, ktorých výsledok sa berie za finálnu hodnotu napätia deliča. Z tejto hodnoty sa počíta aj vstupné napätie deliča.
Ako vidíme na blokovej schéme riešenia, vysielač neposiela dáta do databázy. To robí až LoRa prijímač, ktorý má k dispozícii WiFi AP v dosahu, cez ktorý sa môže pripojiť na internet a po HTTPS poslať dekódované dáta na cloud. Umiestnenie prijímača voči vysielaču tak bude mať prioritu pre spoľahlivé prijímanie dát.
Vysielač bol umiestnený do elektrikárskej krabice s rozmermi 100x100x38 mm, vrátane napájacej Li-pol batérie s kapacitou 1000 mAh a ochranným obvodom. Na predný kryt krabice som dopasoval solárny panel 100x100 mm. Tento panel má 5V výstup a dokáže dodávať špičkový výkon až 3W, štandardne 1,2W, čo je dostatočné, nakoľko Lolin32 funguje v režime hlbokého spánku, do ktorého uspáva aj LoRa modul RA-02 (AI-Thinker). Prebúdza sa v pravidelných intervaloch iba pre účel merania a odoslania dát na prijímač.
Celkový uptime vysielača v aktívnom stave je pod 2 sekundy, keďže meranie trvá prakticky niekoľko nanosekúnd a samotný prenos dát okolo 1,2 sekundy. Spotreba v režime spánku je pre tento Node bude niekde nad 2 mA. Je to dané najmä integrovanými LED diódami, trvale napájaným USB-UART prevodníkom CH340. Vzhľadom na dobíjanie batérie nie je problémom ani táto spotreba, ktorá sa môže zdať vysoká pre LoRa zariadenie. Ak by sme prešli na XIAO, spotreba by bolo niekde okolo 50 uA.
Prijímač ale musí byť trvale napájaný, teda u neho je vyššia požiadavka na prevádzku na batériu. Z toho dôvodu som tu siahol po 2000 mAh Li-Ion batérii z dôvodu, že spotreba môže byť od 17 mA po 80 mA v závislosti od nastavenia Lolin32 devkitu. Devkit, resp. jeho procesor Xtensa môže spať, ale musí predtým urobiť niekoľko vecí. RA-02 musí byť nastavený do režimu posluchu (RX), čo má za následok jeho spotrebu 15 mA, aby dokázal prijať prichádzajúci paket. Toto môže čekovať ESP32, alebo je možné využiť aj interrupt pin DIO0 na RA-02 (SX1278) module. Tento pin zmení stav pri prijatí dát, čo dokáže ako externý interrupt prebudiť aj mikrokontróler ESP32 z režimu spánku.
Sú tu ale určité úskalia... Prijímač môže byť maximálne v light sleepe, čo znamená vyššiu spotrebu v porovnaní s deep sleep režimom u vysielača. Je to práve z dôvodu, že pri prebudení z light sleepu mikrokontróler pokračuje v programe tam, kde skončil (od bodu, kde bol uspatý). Ak by šlo o deep sleep, mikrokontróler by musel byť reštartovaný a tak musí znova nastaviť aj LoRa modul, teda dáta sa stratia. Aby ich dokázal prečítať, musí to byť naozaj maximálne light sleep, ktorý má mať spotrebu okolo 0,8 mA (z datasheetu), Lolin32 devkit bude mať minimálne 2,5 mA v tomto režime + treba rátať do celkovej spotreby aj 15 mA modulu RA-02., teda budeme niekde na úrovni 17 až 18 mA.
Prijímač vyzerá následovne:
- má anténový výstup pre pripojenie ľubovoľnej antény do SMA konektoru (OMNI, smerová)
- v krabičke je batéria, ktorá sa pripája priamo do Lolinu32 skrz batériový konektor JST PH 2.0
- 433_LoRa_Lolin32 doska s hardvérom
- solaŕny panel dobíja batériu maximálnym prúdom až 500 mA, zároveň môže napájať aj samotné zariadenie
- 2000 mAh batéria typu Li-Ion
Vysielač vyzerá identicky, ako prijímač s dvoma rozdielmi, že má z krabičky okrem antény vyvedené aj vodiče s nalisovanými očkami, ktoré sa pripájajú k svorkám trakčnej batérie pod skrutku, nakoľko trakčná batéria napája aj generátor impulzov a je zároveň pripojená aj do svorkovnice. kontroléra, ktorý ju nabíja. Pre generátor impulzov sa nevyužíva relé výstup kontroléra, nakoľko v tomto prípade je trvale napájaný a nie je potrebné spínať ho. Druhým rozdielom je použitie Li-pol batérie, ktorá sa pripája identicky, no má navyše aj ochranný obvod. Ako som sa presvedčil, obvod by mal fungovať najmä proti skratu a prebitiu. Ochranu proti vybitiu batérie nemá, nakoľko ako som sa už skôr presvedčil, vybilo batériu až do 0V.
Kritickým bodom bolo umiestnenie prijímača voči vysielaču. Vysielač už bol stacionárny a prišlo k problému s nepriamou viditeľnosťou pri prvom plánovanom osadení prijímača. Vysielač a prijímač boli od seba asi 662 metrov. Nedošlo k priamej viditeľnosti, čo potvrdzuje model prepočtu HeyWhatsThat Path Profiler, alebo UISP Design Center. Druhý model je presnejší, nakoľko umožňuje nastavenie výšky antén nad zemským povrchom voči sebe, čo umožňuje dostať presnejší výstup. Ani jeden z modelov ale nepočíta s budovami, stromami vo výhľade. Ich prepočet je relevantný iba k povrchu ako takému pre overenie "priamej viditeľnosti".
Takéto umiestnenie vysielača a prijímača malo za následok nekonzistentnosť v prijatých paketoch a značnú variáciu pomeru signálu voči šumu (nižšia hodnota je horšia). RSSI je možné vyhodnotiť ako dosť zlé, až takmer nedostatočné (i keď LoRa má nato rezervu až niekde k -137 dBm, možno až -141 dBm) s takýmito podmienkami prenosu dát bez priamej viditeľnosti. Rovnako tak občas prijímač nebol schopný prijať paket, alebo dekódovať ho v dôsledku čoho bol zahodený.
Signál v takomto posadení vysielača a prijímača prechádza prakticky po takmer jednu tretinu cesty skrz kopec a blízko prijímača ešte aj cez asi 3 strechy budov a veľký listnatý strom. Do budúcna bude treba poupraviť pozíciu prijímača, prípadne zvýšiť výšku antény na vysielači. V aktuálnej konštalácii je väčší problém s parametrom SNR, ktorý reprezentuje pomer signálu voči šumu. Hodnoty by mali byť od +20 dB do -5, čo sa už považuje za nekvalitný signál. V našom prípade máme hodnoty SNR, ktoré kolíšu a sú blízko k -20 dB, čo reprezentuje veľmi nekvalitný signál, prakticky plný šumu.
Keď pomer presiahne -20 dB, je to prakticky nedekódovateľný signál. -20 je to ale iba pre Spreading Factor 12, u iných spreading factorov je to bližšie smerom k 0 dB. Ako môžeme vidieť aj variáciu SNR za poslednú hodinu, dosť sa mení, čo je spôsobené najmä tým, že sa signál nechytá na prijímači priamo, ale iba z odrazov. Stáva sa tak, že občas prjímač nie je schopný dekódovať paket, inokedy je zase X minút ticho, kým sa prijímaču opäť podarí prijať dáta.
Ako môžeme aj z grafu vidieť, loguje sa napätie trakčnej batérie a posiela sa do databázy. Môžeme vidieť, že pred šiestou hodinou ráno začína byť aktívny aj solárny panel, ktorý túto batériu dobíja a stará sa o jej power management. Po štvrtej hodine poobede klesá prúd z panela, čím sa znižuje napätie na batérii, až neskôr nie je batéria nabíjaná vôbec a počas noci dosahuje napätie niekde na úrovni 12,6 až 12,5V, čo značí takmer plne nabitú batériu aj počas tohto obdobia.
Systém dokáže pri nízkom napätí batérie zaslať aj email s informáciou o stave napätia, teda nie je nutné sústavne monitorovať webovú vizualizáciu s grafom. Aby emaily neboli otravné, pošle sa maximálne 1 e-mail za 6 hodín a aj to iba v prípade, že napätie batérie kleslo pod 11V, čo už indikuje značné vybíjanie, keď maximálne prípustné vybíjanie olovenej batérie je do 10,5V a pod túto hodnotu by nemal klesnúť, teda notifikácia je včasná a s meraním v XX minútovom intervale dokáže upozorniť tak, aby obsluha mohla vykonať obhliadku, či meranie batérie.
Čo sa týka LoRa komunikácie, vysielač a prijímač používa rovnakú prednastavenú nosnú (strednú) frekvenciu, šírku pásma, rovnaký spreading factor, coding rate, alebo čo je najdôležitejšie, spoločný sync word, vďaka ktorému môžem mať viacero PPP LoRa komunikácii, ktoré budú iba logicky oddelené sync wordom, ktorý filtruje pakety. Vďaka tomu prijímač bude reagovať iba na pakety od určeného vysielača, ktorý používa identický sync word a iný odignoruje (resp. odfiltruje).
V praxi je tu super napríklad pre produkčnú verziu LoRa aplikácie a testovaciu, kedy sa nemusíte báť, že by vám prijímač v produkcii zachytil aj testovacie dáta, i keď pracujete blízko neho. Využíva sa iný sync word, hoci stredná frevencia, i šírka pásma je rovnaká. Všetky zariadenia tak budú používať identickú frekvenciu, šírku pásma t.j. kanál, ale budú rozdelené len logicky na základe iného sync wordu (môžeme to nazvať aj inou podsieťou). Existujú aj špecifické sync wordy, ktorým by ste sa mali vyhnúť, napríklad 0x34, ktorý je vyhradený pre verejné LoRaWAN siete. V tomto prípade najde o LoRaWAN sieť, ale o vlastnú LoRa PPP (Point-to-Point) aplikáciu s dátami, ktoré sú prakticky verejné a ak si niekto vhodne nastaví prijímač a vie dekódovať aj obsah, ktorý sa prenáša, dokáže vidieť to, čo sa tam posiela.
Pre túto kontrétnu aplikáciu používam "striktný" vysielač a prijímač. Samozrejme je možné zariadenia prepínať aj medzi režimami vysielania, alebo prijímania dát. Nedokážu ale prijímať a vysielať v reálnom čase, vždy je nutné navoliť režim. Z toho pohľadu označujeme takúto komunikáciu ako half-duplex. V podobnej aplikácii by príjem na vysielači mohol slúžiť na prijímanie konfiguračných dát, zmenu parametrov, napr. časovača početnosti vysielaní a podobne. Režim prijímania by ale na vysielači musel byť aktívny napr. po vysielaní po určitú dobu a samozrejme modul by spotrebuvával 15 mA len na RA-02 module. V snahe o low power end-node ide iba o striktný vysielač, ktorý je neaktívny a zobudí sa iba v preddefinovaný čas na krátke vyslanie informácie, po ktorom opäť prechádza do režimu hlbokého spánku. Aj keby sa niečo po jeho sync worde posielalo, nepríjme nič, lebo je "hluchý".
Chceli by ste podobné riešenie aj pre Váš oplotok, či obdobnú aplikáciu? Možné prispôsobiť na mieru a prenášať aj senzorové dáta, či dáta z vyššieho systému založeného na RS485, či inej priemyselnej zbernici. Rovnako tak je možné takýto senzorový uzol integrovať aj do LoRaWAN siete s použitím LMIC knižnice.
V prípade záujmu, či otázok mi napíšte na: martin.ch.youriot@gmail.com
PRIHLÁS SA
3 