Internet Rzeczy jest zbiorem czujników, sterowników i temu podobnych urządzeń, które są podłączone do Internetu po to, by korzystać z zasobów obliczeniowych serwerów przeznaczonych do akwizycji danych czy wykonywania poleceń sterowniczych. Najczęściej te zasoby są umieszczane w chmurze, po to by użytkownicy mieli do nich nieskrępowany dostęp z dowolnej lokalizacji. Przy olbrzymiej ilości urządzeń IoT (szacuje się, że w najbliższej przyszłości będzie to ponad 45 miliardów) i ciągłej tendencji wzrostowej, podłączenie ich bezpośrednio do Internetu za pomocą protokołów z rodziny IP wydaje się niemożliwe do zrealizowania. W rzeczywistości wiele tych urządzeń nie ma takiego połączenia z siecią z różnych powodów. Są takie zastosowania, w których połączenia z Internetem nie są konieczne. Jeżeli jednak połączenie jest wymagane, to w przypadku małych czujników zasilanych bateryjnie barierą może być koszt obsługi połączenia opartego na protokole IP. W takim przypadku potrzeba sporych zasobów sprzętowych i programowych. Potrzeba stosowania wydajnych mikrokontrolerów kłóci się jednak z ideą tanich, prostych czujników z małym poborem mocy. Sporym problemem może być również brak bezpośredniego połączenia internetowego w słabo zaludnionym miejscu instalowania urządzeń IoT. Można próbować temu zaradzić na różne sposoby. Jednym z nich jest rozwiązanie nazwane LoRaWAN.

LoRaWAN

LoRaWAN jest radiowym protokołem komunikacyjnym, który pozwala łączyć się z Internetem urządzeniom IoT wyposażonym w łącze radiowe. Połączenie nie jest realizowane wprost, ale za pomocą specjalnych stacji bazowych nazywanych koncentratorami. Bardzo ważną cechą standardu jest możliwość uzyskania relatywnie dużych zasięgów liczonych w kilometrach przy bardzo ograniczonej mocy nadawania (20 dBm), a co za tym idzie małym poborze prądu. Technologia LoRaWAN bazuje na otwartym standardzie i wykorzystuje otwarte pasmo ISM – w Europie 868MHz. To ma daleko idące konsekwencje, bo umożliwia tworzenie własnych, tanich sieci bez konieczności uzyskiwania administracyjnych zgód i ponoszenia opłat za wykorzystanie pasma. Tą technologią interesują się również operatorzy telekomunikacyjni na przykład Orange, SK Telecom. Niestety w naszym kraju jak na razie pokrycie sieciami LoRaWAN jest bardzo małe i to głównie w dużych miastach.

Standardem LoRaWAN zarządza grupa LoRa Alliance skupiająca ok. 500 członków. Uczestnicy skupieni w LoRa Alliance wspierają rozwój protokołu i tworzą zgodne z nim komponenty, gotowe produkty i usługi. Ze znanych firm wspierających LoRAWAN można wymienić Microchip, ST, CISCO, czy ARM.

Do transmisji w kanale radiowym wykorzystywany jest system komunikacji nazywany LoRa. W odróżnieniu od innych znanych technologii, typu Bluetooth, Wi-Fi oraz ZigBee, LoRa umożliwia przesyłanie danych na relatywnie duże odległości dzięki modulacji CSS (Chirp Spread Spectrum). Co ciekawe, jest to technika opracowana w latach 30-tych XX wieku na potrzeby konstruowanych w tym czasie radarów. Stosowana też była do łączności w astronautyce. CSS jest odporna na zakłócenia wynikające z odbić (interferencji sygnałów), jest odporna na zjawisko Dopplera, nie wymaga synchronizacji odbiornika i nadajnika, i co ważne, amplituda sygnału nie ma praktycznie wpływu na stopę błędów podczas transmisji (amplituda ma wpływ tylko na zasięg sygnału). Natomiast modulacja CSS, ze względu na swoje właściwości, nie pozwala na przesyłanie danych z dużymi prędkościami transmisji.

LoRaWAN jest protokołem dostępu do łącza MAC (Medium Access Protocol). Jak wiemy, przy jego opracowywaniu położono nacisk na pracę z łączami dalekiego zasięgu, ale o małej przepływności i jest z zasady przeznaczony dla urządzeń IoT pracujących ze zoptymalizowanym, małym zużyciem energii. Dwukierunkowość przesyłania danych pozwala na realizację niezawodnego przesyłania informacji dzięki możliwości zaimplementowania mechanizmu potwierdzeń oraz na przesyłanie komend sterowania. Bezpieczeństwo transmisji zapewnia silne szyfrowanie. Ważną cechą użytkową jest możliwość bezprzewodowej rejestracji nowych urządzeń w sieci, oraz przesyłanie danych w trybie multicast (jeden do wielu).

Na rysunku 1 pokazano strukturę sieci LoRaWAN. Węzły (urządzenia końcowe – czujniki) łączą się z koncentratorami za pomocą protokołu LoRaWAN RF. Koncentratory przesyłają dane do serwerów sieciowych standardowym połączeniem wykorzystującym protokoły LoRaWAN TCP/IP SSL (Wi-Fi, Ethernet), lub za pomocą usługi dostępowej w sieciach GSM (3G/LTE).

Rysunek 1. Struktura sieci LoRaWAN

Sieć jest zbudowana z czterech głównych komponentów:

• Urządzeń końcowych (węzłów)
• Koncentratorów (stacji bazowych, routerów, bramek)
• Serwera sieciowego
• Serwerów aplikacji

Urządzenia końcowe to sprzęt, który zawiera czujniki, układy sterowania , mikrokontroler i moduł transmisji radiowej. Obsługują transmisje dwukierunkową z koncentratorami – mogą same wysyłać dane, ale też otrzymywać dane z koncentratorów. W założeniu urządzenia IoT, które są czujnikami i pracują jako węzły sieci LoRaWAN, powinny mieć możliwość długotrwałej pracy z zasilania bateryjnego. Ze względu na rodzaj transmisji i zużycie energii wprowadzono podział urządzeń na klasy: A, B i C .

Klasa A – pobiera najmniej energii. Urządzenia tej klasy wysyłają krótkie informacje zdarzeniowo, to znaczy tylko wtedy, kiedy nastąpi zdarzenie typu przekroczenie jakiejś wartości mierzonego parametru. Mogą też wysyłać dane z określonym interwałem, na przykład raz na dobę, co godzina czy co 15 minut. Odbieranie informacji jest możliwe tylko po wcześniejszym wysłaniu własnych danych. Każda wymiana danych rozpoczyna się od wysłania przez urządzenie końcowe danych (uplink). Po ich wysłaniu węzeł odczekuje przez zdefiniowane dwa określone czasy (okna czasowe) na dane z serwera (wiadomość downlink). Po odebraniu wiadomości z serwera urządzenie końcowe (węzeł) przechodzi do stanu głębokiego uśpienia, żeby ograniczyć pobór energii przy pracy z baterii. Zaletą klasy A jest bardzo niski pobór energii, a wadą spore opóźnienia łącza, bo serwer sieciowy nie wie, kiedy transmisja zostanie zainicjowana.

Rysunek 2. Wymiana informacji z urządzeniem klasy A

Urządzenia klasy B mogą przesyłać i odbierać dłuższe informacje z mniejszym opóźnieniem reakcji serwera spowodowanej losowym wysyłaniem danych uplink jak w urządzeniu klasy A. W klasie B urządzenie okresowo otwiera okno czasowe do odbierania informacji z serwera dowlink. Okres otwarcia łącza (Beacon Period) pomiędzy urządzeniem i serwerem jest ustalany przez zsynchronizowane zegary. Synchronizacja jest realizowana przez sekwencyjne wysyłanie przez serwer komendy synchronizującej odbieranej przez urządzenie. Sama transmisja odbywa się tak jak w klasie A – rysunek 3. Zaletą klasy B jest szybszy dostęp do połączenia, bo serwer sieciowy wie w jakim czasie może się spodziewać transmisji z urządzenia.

Rysunek 3. Wymiana informacji z  urządzeniem klasy B

Urządzenie klasy C może ciągle odbierać dane z wyjątkiem, kiedy samo wysyła dane. Klasa ta nie jest przewidziana do zasilania bateryjnego i wymaga stałego zasilania z sieci energetycznej. W trakcie pracy jest ciągle otwierane okno czasowe. Redukuje to opóźnienia łącza umożliwiając przesłanie relatywnie dużej ilości danych, ale znacznie zwiększa pobór energii.

Rysunek 4. Wymiana informacji z urządzeniem klasy C

Koncentratory, nazywane inaczej bramkami, modemami, czy punktami dostępu odbierają dane z węzłów końcowych. Przesyłane dane są dzielone na pakiety i przesyłane protokołami IP do serwera sieciowego Bramki są z zasady przezroczyste (nie modyfikują zawartości przesyłanych danych). Koncentrator musi być połączony z Internetem.

Serwer sieciowy realizuje dość skomplikowany proces przetwarzania danych przesłanych z węzłów:

• Określa, która z bramek jest najlepsza do komunikacji z węzłem. Do tego celu są wykorzystane parametry łącza radiowego: RRSI (wskaźnik siły odbieranego sygnału ) i SNR (współczynnik sygnał/szum) z poprzednio otrzymanych pakietów,
• Przekierowuje dane do odpowiednich aplikacji,
• Usuwa zwielokrotnione (zduplikowane) wiadomości przekazane do węzła przez więcej niż jedną bramkę,
• Deszyfruje wiadomości przesyłane przez węzeł i szyfruje wiadomości przesyłane do węzłów,
• Zapewnia nadzór i diagnostykę szyfrowanego połączenia IP serwer/bramki.

Serwer aplikacji realizuje właściwą usługę związaną z aplikacją IoT zbierającą dane z węzłów. Takie serwery wykorzystują chmury, które łączą się z serwerami sieciowymi.

Węzły (urządzenia końcowe) sieci LoRaWAN jak wiemy muszą się charakteryzować bardzo małym poborem energii. W urządzeniach klasy A i B stosuje się głębokie uśpienie w czasie braku aktywności, pozwalające na mocne obniżenie poboru prądu. Ale niezbędny jest też pewien stopień wydajności wbudowanego mikrokontrolera, pozwalający na obsługę stosu, kodowanie transmisji danych i oczywiście obsługę czujnika pomiarowego. Dlatego wielu producentów stosuje 32-bitowe mikrokontrolery z wbudowanymi zaawansowanymi trybami obniżonego poboru energii. Jednym z gotowych modułów przeznaczonych do pracy jako węzeł sieci LoRaWAN jest ATSAMR34 XPRO Demo Board, produkowany i oferowany przez firmę Microchip, jednego z członków grupy LoRaAlliance (rysunek 5).

Rysunek 5. Moduł ATSAMR34 XPRO Demo Board

Moduł jest oparty o specjalizowany mikrokontroler ATSAMR34J18B z wbudowanym trasceiverem LoRa i 32 bitowym rdzeniem Cortex M0+. Jego podstawowe właściwości są zamieszczone poniżej:

• Wsparcie dla pasm 868MHz i 915MHz,
• Moc wyjściowa: maksymalnie +20dBm,
• Wbudowany oscylator TCXO,
• Gniazdo antenowe SMA RF z dołączoną w zestawie anteną (Whip Antenna),
• Układy do pomiaru poboru prądu współpracujące z XPRO Current Measurement System Data Visualizer,
• Wbudowany system zarządzenia energii z monitorowaniem poboru prądu,
• Wbudowany EDBG Debugger, współpracujący ze środowiskiem Atmel Studio 7 ICE,
• Dwa złącza rozszerzeń,
• 10 pinowe złącze dla programatora Cortex Programmer,
• Przyciski Reset i GPIO,
• Diody LED: statusowa i sygnalizująca włączone zasilanie,
• Holder na baterię podtrzymującą CR1220.

Najważniejszym elementem modułu jest oczywiście mikrokontroler. Seria SAMR34 ma 32-bitowy rdzeń ARM Cortex M0+ połączony z wbudowanym tranceiverem UHF wspierającym standard LoRa z modulacją FSK. Rdzeń może być taktowany maksymalną częstotliwością 48MHz. Na rysunku 6 pokazano schemat blokowy mikrokontrolera z zaznaczonym modułem transceivera

Rysunek 6. Schemat blokowy mikrokontrolera ATSAM34/35

ATSAMR34J18B jest wyposażony w wiele układów peryferyjnych. Najważniejsze z nich, oprócz transceivera UHF, to:

• Układ AES ze sprzętowym generatorem liczb losowych,
• 12 bitowy ADC z układem nadpróbkowania i programowanym układem wzmacniacza wejściowego,
• Interfejs USB 2.0 ,
• 2 analogowe komparatory,
• 5 interfejsów szeregowych SERCOM mogących pracować jako USART, I2C, SPI lub LIN,
• 12 kanałowy układ DMA i 12 kanałowy Event System,
• 3 szesnastobitowe bitowe liczniki TC,
• 3 szesnastobitowe liczniki TCC,
• Moduł zegara czasu rzeczywistego RTC

Żeby 32-bitowa jednostka mogła pracować z bardzo małym poborem mocy, trzeba ją wprowadzać w stan uśpienia w czasie, kiedy nie ma niczego do zrobienia. W mikrokontrolerze ATSAM34 trybami oszczędzania poborem energii zarządza moduł Power Manager. Power Manager ma do dyspozycji 4 tryby oszczędzania energii: Idle, Standby, Backup i Off. Wejście w tryb uśpienia zatrzymuje wykonywanie kodu, część modułów mikrokontrolera i ich taktowanie. Od trybu uśpienia zależy, które moduły są wyłączane. Wyjście ze stanu obniżonego poboru energii następuje po zgłoszeniu przerwania od aktywnego układu peryferyjnego – na przykład od licznika.

Moduł ATSAMR34 XPRO Demo Board może być zasilany z trzech źródeł: z debuggera EDBG USB, z portu USB (target USB), lub z zewnętrznego źródła zasilania +5 V. Na płytce umieszczono dwa stabilizatory LDO +3,3V. Jeden z nich zasila debugger EDBG i moduł XAM(Xplained Pro Analog Module), a drugi mikrokontroler ATSAM34 – rysunek 7.

Rysunek 7. Układ dystrybucji zasilania modułu ATSAMR34 XPRO Demo Board

Układ XAM jest funkcjonalnym rozszerzeniem EDBG i umożliwia pomiar prądu przez układy modułu. Schemat blokowy XAM został pokazany na rysunku 8.

Rysunek 8. Schemat modułu XAM

Układ pomiarowy jest zbudowany z:

• Układu kalibracji pomiaru
• Układu napięcia referencyjnego +2,7V
• Właściwego układu pomiarowego zbudowanego z szeregowego rezystora pomiarowego, przedwzmacniacza i dwóch aktywnych filtrów z funkcją wzmacniacza sygnału.
• Mikroprocesorowego sterownika z przetwornikiem analogowo-cyfrowym i procesorem przetwarzania sygnału
• Interfejsu komunikacyjnego z debuggerem EDBG

Do dokładnego pomiaru prądy są wykorzystywane 4 zakresy pomiarowe:

1. Zakres z dużą rezystancją rezystora pomiarowego i dużym wzmocnieniem układu pomiarowego. Rozdzielczość pomiaru wynosi ok 20nA. Użyteczny zakres pomiaru to 1uA – poniżej tej wartości spada dokładność pomiaru.
2. Zakres z dużą rezystancją rezystora pomiarowego i małym wzmocnieniem układu pomiarowego. Rozdzielczość pomiaru wynosi 150nA.
3. Zakres z małą rezystancją rezystora pomiarowego i dużym wzmocnieniem układu pomiarowego. Rozdzielczość pomiaru: 10uA.
4. Zakres z małą rezystancją rezystora pomiarowego i małym wzmocnieniem układu pomiarowego. Rozdzielczość pomiaru: 100uA.

Zakres pomiarowy jest automatycznie przełączany przez XAM w zależności od mierzonych wartości. Zmierzone wartości mogą być wyświetlane w dedykowanej aplikacji DataVisualizer.

Oprogramowanie stosu LoRaWAN oparto o model warstwowy składający się z warstw: aplikacji, MAC  i PHY – rysunek 9.

Rysunek 9. Model warstwowy LoRaWAN dla urządzenia końcowego (węzła)

Warstwa aplikacji zawiera funkcje i procedury użytkownika, które wykorzystują możliwości warstwy MAC do realizowania przesyłania danych (nadawania i odbierania) przez łącze radiowe LoRa. Warstwa MAC jest pomostem pomiędzy warstwą aplikacji wykonującą funkcje związane z pracą czujnika i warstwą fizyczną PHY. W niej jest organizowana transmisja danych właściwa dla danej klasy urządzeń (A, B, lub C). Warstwa fizyczna PHY to układ transceivera wysyłający i odbierający dane radiowe w kanale radiowym. Zawiera modulator, demodulator CSS, oraz tory nadajnika i odbiornika wraz z układami konfiguracyjnymi i układami sterowania.

Microchip dostarcza własny stos LoRaWAN MLS (Microchip LoRaWAN Stack), przeznaczony dla mikrokontrolerów ATSAM R34/R35, funkcjonalnie podzielony na kilka modułów z funkcjami interfejsu API:

• LoRaWAN MAC Layer (MAC) – warstwa MAC,
• LoRaWAN Radio Layer (TAL) – warstwa do obsługi sprzętu – wbudowanego Transceivera,
• Persisent Data Server (PDS),
• Power Manager Module (PMM) – funkcje zarzadzanie poborem mocy,
• Hardware Abstraction Layer (HAL) – warstwa abstrakcji sprzętu oddzielająca funkcje API od zastosowanych rozwiązań sprzętowych w warstwie PHY.

Na rysunku 10 pokazano architekturę stosu MLS.

Rysunek 10. Architektura stosu MLS

Warstwa MAC dostarcza niezbędnych usług zdefiniowanych w specyfikacji LoRAWAN. Warstwa TAL wykorzystuje driver modułu radiowego w celu dostępu dla transceivera. Driver radia komunikuje się z modułem radiowym przez interfejs SPI wspomagany przez dodatkowe linie GPIO i wejście przerwania IRQ. Stos MLS może konfigurować urządzenie końcowe, a w zasadzie jego tor radiowy do pracy w wielu pasmach radiowych dostępnych w różnych lokalizacjach (Europa, Azja, USA itp). Parametry konfiguracji toru radiowego są pobierane spoza MLS.

PDS zawiera parametry konfiguracyjne LoRaWAN zapisane w pamięci Flash. Są one pobierane i odtwarzane w czasie każdego cyklu wybudzenia z uśpienia. Moduł PMM zarządza układami ograniczania poboru energii przez usypianie mikrokontrolera, kiedy stos wchodzi w tryb IdleMode. ASFv3 jest zbiorem driverów i usług dla interfejsów szeregowych I2C, SPI i UART, a także dla GPIO.

Stos działa w systemie wielozadaniowym bez wywłaszczania (non-preemptive priority), zarządzającym pracą MAC, TAL, PMM, PDC.

Naturalną konsekwencją takiego podziału jest struktura katalogów firmowego przykładu dostępnego na stronach Microchipa i przeznaczonego dla modułu ATSAMR34 XPRO Demo Board  – rysunek 11.

Rysunek 11. Struktura katalogów projektu stosu LoRaWAN Microchipa

Dokładny opis wszystkich funkcji API można znaleźć w dokumencie SAM R34/R35 Microchip LoRaWAN Stack Software API Reference Manual DS70005382A.

Moduł ATSAMR34 XPRO Demo Board trzeba połączyć z portem USB komputera kablem dołączonym do złącza EBDG USB (wtyczka USB Micro). Jeżeli jest uruchomiony IDE Atmel Studio 7 to moduł zostanie przez niego wykryty i zidentyfikowany – rysunek 12.

Rysunek 12. Wykrycie modułu SAM R32 Xplained Pro

Microchip dostarcza na swojej stronie projekt z plikami źródłowymi APPS_ENDDEVICE_DEMO przeznaczony dla środowiska Atmel Studio 7. Po pobraniu projekt trzeba rozpakować i uruchomić z menu File->Open->Project/Solution. Przed użyciem w sieci LoRaWAN niezbędna jest konfiguracja wykonywana przez wpisanie odpowiednich ustawień w pliku conf_app.h w kilku krokach:

1. Metoda aktywacji urządzenia końcowego: ręcznie lub przez serwer (Over The Air)

/* Enable one of th activation methods */
#define DEMO_APP_ACTIVATION_TYPE        OVER_THE_AIR_ACTIVATION
//#define DEMO_APP_ACTIVATION_TYPE         ACTIVATION_BY_PERSONALIZATION

2. Rodzaj wysyłanej wiadomości przez urządzenie końcowe (potwierdzona/nie potwierdzona)

/*Select the Type of Transmission - Confirmed (CNF( / Unconfirmed (UNCNF) */
#define DEMO_APP_TRANSMISSION_TYPE      UNCONFIMED
//#define DEMO_APP_TRANSMISSION_TYPE    CONFIRMED

2. Port dla danych UPLINK

/* FPORT Value (1-255) */
#define DEMO_APP_FPORT          1

2. Definicja klasy urządzenia końcowego

/* Device Class - Class of the device (CLASS_A/CLASS_C) */
#define DEMO_APP_ENDDEVICE_CLASS                 CLASS_A
//#define DEMO_APP_ENDDEVICE_CLASS                 CLASS_C

5. Adres urządzenia końcowego

/* Device Class - Class of the device (CLASS_A/CLASS_C) */
#define DEMO_APP_ENDDEVICE_CLASS                 CLASS_A
//#define DEMO_APP_ENDDEVICE_CLASS                 CLASS_C

6. Klucze AES dla połączenia z serwerem

#define DEMO_APPLICATION_SESSION_KEY            {0x41, 0x63, 0x74, 0x69, 0x6C, 0x69, 0x74, 0x79, 0x00, 0x04, 0xA3, 0x0B, 0x00, 0x04, 0xA3, 0x0B}
#define DEMO_NETWORK_SESSION_KEY                {0x61, 0x63, 0x74, 0x69, 0x6C, 0x69, 0x74, 0x79, 0x00, 0x04, 0xA3, 0x0B, 0x00, 0x04, 0xA3, 0x0B}

Dokładniejsze dane dotyczące konfiguracji można znaleźć w dokumencie SAM-R34_MLS-Getting Started User Guide DS50002812A.

Jak już wspomniałem na początku zasięg sieci LoRaWAN w naszym kraju jest bardzo ograniczony. W trakcie pisanie tego tekstu nie byłem w stanie przetestować transmisji pomiędzy modułem, a serwerem. Jednak po doświadczeniach z produktami Microchipa należy się spodziewać, że po prawidłowym skonfigurowaniu modułu powinno wszystko działać.

Ponieważ moduł jest wyposażony w układ pomiaru prądu, a dla urządzeń końcowych pobór energii ma bardzo ważne znaczenie postanowiłem sprawdzić, czy ta funkcjonalność działa i jak jest przydatna. Wykonane pomiary nie będą miarodajne, bo nie można nawiązać połączenia z serwerem, ale dadzą pojęcie o skali poboru mocy. Poza tym, mając do dyspozycji możliwość szybkiego pomiaru prądu i łatwej wizualizacji jego zmian można szybko oszacować jaki wpływ na pobór mocy będą miały zmiany w programie, czy zmiany w konfiguracji stosu.

W środowisku Atmel Studio 7 można uruchomić z menu Tools program Data Visualizer – rysunek 13.

Rysunek 13. Uruchomienie Data Visualizer

Jest to aplikacja współpracująca między innymi z debuggerem EDBG połączonym z układem XAM. Pozwala w sposób graficzny przedstawić bieżące zużycie prądu przez moduł. W menu interfejsów obsługiwanych przez EDBG i Data Visualizer zaznaczamy okienko Power – rysunek 14.

Rysunek 14 Wybór pomiaru prądu przez Data Visualizer

Przed wykonaniem pomiarów trzeba się połączyć z wykrytym EDBG z modułu SAM32 Xplained Pro klikając na przycisk Connect i uruchomić rejestrację pomiarów klikając na przycisk Start – rysunek 15.

Rysunek 15. Łączenie z wykrytym EDBG i rozpoczęcie pomiarów

Na rysunku 16 został pokazany fragment okna z graficznym przedstawieniem poboru prądu testowanego modułu w trakcie pracy.

Rysunek 16. Pomiar prądu przez moduł

Podsumowanie

Konstrukcja mikrokontrolera ATSAM34/35 z rdzeniem Cortex M0+, zintegrowanego z modułem radiowego transceivera LoRa, wyraźnie pokazuje, że Microchip poważnie podchodzi do technologii LoRaWAN. Moduł z tym mikrokontrolerem i dołączone kompletne oprogramowanie stosu jest na pewno silnym wsparciem konstruktorów urządzeń IoT. Nie bez znaczenia są też dodatkowe funkcje pozwalające szybko zmierzyć, lub przynajmniej oszacować bardzo istotną dla urządzeń zasilanych bateryjnie wartość poboru prądu. Sama technologia radiowa LoRa jest również atrakcyjna z powodu możliwości przesyłania danych na relatywnie duże odległości przy bardzo energooszczędnych transceiver’ach.

Ale według mnie jest jeden podstawowy problem z LoRaWAN – brak infrastruktury koncentratorów. Żeby cokolwiek przesyłać, trzeba być w zasięgu koncentratora połączonego Internetem do serwera. A z tym jak na razie u nas i nie tylko u nas jest niezbyt dobrze. Jeżeli ktoś jest zdeterminowany, to może “postawić” sobie swój własny koncentrator. Nie jest to bardzo drogie ani mocno skomplikowane, pod warunkiem, że mamy do dyspozycji miejsce do zainstalowania anteny i w pobliżu łącze do Internetu. A to w wielu przypadkach może być wielkim problemem, lub może nie być w ogóle możliwe. Jak na razie tylko sieci telefonii komórkowej dysponują infrastrukturą zapewniającą bardzo duże pokrycie zasięgiem: maszty, anteny i łącza informatyczne o odpowiedniej przepustowości. Wydaje się, że największe prawdopodobieństwo powodzenia będą miały oparte o tani abonament komercyjne systemy wykorzystujące tą infrastrukturę. LoRaWAN może być bardzo dobrym uzupełnieniem tam, gdzie nie ma zasięgu, lub nie będzie usługi przeznaczonej dla IoT, na przykład w terenach mało zaludnionych. Być może będą również powstawać sieci koncentratorów montowane przez entuzjastów.