LoRaWAN od zera: czujniki na kilometr i własna bramka

Co to jest LoRa i LoRaWAN – praktyczne spojrzenie

LoRa – warstwa radiowa o zasięgu „na kilometr”

LoRa to przede wszystkim modulacja radiowa, czyli sposób „opakowania” danych do transmisji drogą radiową. Została zaprojektowana specjalnie pod kątem:

• bardzo dużego zasięgu (kilka kilometrów w terenie otwartym, zwykle kilkaset metrów do 2–3 km w mieście),
• niskiego zużycia energii (czujniki bateryjne działające latami),
• odporności na zakłócenia (różne „SF” – spreading factor – pozwalają przebić się przez szumy).

Moduł LoRa można podłączyć do mikrokontrolera (np. STM32, ESP32, Arduino), skonfigurować częstotliwość, moc nadawania oraz parametry modulacji i wymieniać proste ramki radiowe. Sama LoRa nie wymusza jednak żadnego standardu sieciowego ani sposobu adresowania urządzeń.

W praktyce oznacza to, że LoRa ≠ LoRaWAN. Można używać LoRa w zupełnie własnym, prostym protokole punkt–punkt (np. pilot zdalnego sterowania, łącze telemetryczne między dwoma urządzeniami w polu). Taki system będzie jednak:

• niekompatybilny z cudzymi bramkami,
• pozbawiony standardowych mechanizmów bezpieczeństwa LoRaWAN,
• wymagał samodzielnego projektowania adresacji, retransmisji, zarządzania urządzeniami.

Do budowy miejskiej lub domowej sieci IoT, która ma współpracować z serwerami i aplikacjami w chmurze, znacznie praktyczniejsze jest oparcie się na LoRaWAN.

LoRaWAN – sieć, serwer, reguły gry

LoRaWAN to protokół sieciowy i cała architektura warstwy wyższej, która korzysta z LoRa jako „kabelka radiowego”. Standaryzuje:

• jak urządzenia (end-devices, czujniki) rozmawiają z bramkami,
• jak bramki przekazują dane do serwera sieciowego (Network Server),
• jak działa bezpieczeństwo (klucze AES, autoryzacja, szyfrowanie),
• jak zarządza się kanałami, parametrami transmisji i klasami urządzeń.

Typowy łańcuch wygląda następująco:

• czujnik LoRaWAN – np. licznik wody, termometr, czujnik otwarcia furtki; wysyła maleńkie paczki danych (uplink),
• bramka LoRaWAN (gateway) – tylko „przekazuje” ramki radiowe do sieci IP (Ethernet, Wi-Fi, LTE) i odwrotnie; nie interpretuje sensu danych,
• serwer sieciowy (Network Server) – np. The Things Network (TTN), ChirpStack; sprawdza poprawność ramek, zarządza kluczami, deduplikuje pakiety,
• serwer aplikacyjny / aplikacja – tam dane są dekodowane i zamieniane na coś użytecznego: wykres, powiadomienie, sterowanie.

Cała „magia” dzieje się między bramką a serwerem sieciowym oraz w samym serwerze. Bramka nie „rozumie” sensu danych – to tylko most między radiem a IP. Dzięki temu czujnik może być odbierany przez wiele bramek, a sieć zadba o to, by ramka dotarła do właściwej aplikacji.

Typowe zastosowania i czego LoRaWAN nie zastąpi

LoRaWAN sprawdza się najlepiej tam, gdzie:

• dane są niewielkie (kilka–kilkadziesiąt bajtów na jedną ramkę),
• wysyłki są rzadkie (co kilka minut, godzinę, a nawet raz dziennie),
• zasilanie jest bateryjne lub z panelu słonecznego,
• zasięg Wi-Fi jest za mały, a LTE zbyt kosztowne energetycznie i abonamentowo.

Przykłady:

• rolnictwo – czujniki wilgotności gleby, temperatury, otwarcia zaworów na polu oddalonym o kilometr od gospodarstwa,
• miasto – parkowanie, czujniki zanieczyszczeń, poziomu w śmietnikach, oświetlenie uliczne,
• dom i ogród – czujnik otwarcia bramy wjazdowej 500 m od domu, monitorowanie szklarni za działką,
• media – zdalne odczyty liczników wody, gazu, energii w piwnicach i szybach instalacyjnych.

LoRaWAN nie nadaje się natomiast do:

• strumieni wideo (kamery IP, monitoring – to domena Wi-Fi, LTE),
• szybkich sterowań w czasie rzeczywistym (ms-sekundy – tutaj lepsze są przewody, Wi‑Fi, ZigBee, czasem LTE‑M),
• dużych ilości danych (logi, pliki, obrazki, audio).

LoRaWAN vs Wi‑Fi, LTE-M, NB-IoT – porównanie na chłodno

Porównanie podstawowych technologii sieciowych warto zestawić w prostej tabeli.

LoRaWAN wygrywa z Wi‑Fi zasięgiem i zużyciem energii, przegrywa przepustowością. W porównaniu do LTE-M/NB-IoT jest:

• tańsze (brak karty SIM, abonamentu),
• wymaga jednak własnej bramki lub dostępu do publicznej sieci LoRaWAN operatora / TTN.

Co sprawdzić na tym etapie

Przed wejściem w szczegóły warto przejść krótką checklistę:

• Czy dane z czujników to kilka–kilkadziesiąt bajtów, a nie megabajty?
• Czy wystarczy aktualizacja co kilka minut lub rzadziej, a nie co sekundę?
• Czy zasilanie bateryjne/panel słoneczny jest istotne (brak możliwości ciągłego zasilania)?
• Czy czujniki są rozproszone na dużym obszarze, gdzie Wi‑Fi nie sięga?

Jeżeli na większość pytań odpowiedź brzmi „tak”, LoRaWAN pasuje do projektu i warto iść dalej.

Podstawy techniczne LoRaWAN – częstotliwości, klasy i limity

Pasma ISM w Europie: EU868 w praktyce

W Europie LoRaWAN korzysta głównie z pasm ISM 868 MHz, czyli tzw. EU868. To pasma nielicencjonowane, ale objęte ograniczeniami, które mają zapewnić współistnienie wielu systemów.

Najważniejsze pojęcie to duty cycle – maksymalny procent czasu, jaki urządzenie może spędzić na nadawaniu na danej częstotliwości. Dla typowych kanałów EU868 jest to zwykle 1%. Przekłada się to na:

• maks. 36 sekund nadawania na każdą godzinę pracy,
• konieczność planowania krótkich ramek i rzadkich transmisji.

Oprócz duty cycle dochodzą inne ograniczenia, np. maksymalna moc nadawania (w EU868 zazwyczaj do 14 dBm dla urządzeń końcowych) oraz wymagania co do szerokości pasma (BW – Bandwidth) i kanałów. Standard LoRaWAN dla EU868 definiuje domyślne kanały, które muszą obsługiwać urządzenia zgodne ze specyfikacją.

Z praktycznego punktu widzenia oznacza to:

• nie można po prostu nadawać „non stop” – sieć jest wspólna dla innych użytkowników,
• czujnik wysyłający dane co kilka sekund szybko przekroczy limity i przestanie być zgodny z przepisami,
• dla typowych czujników z interwałem 5–15 minut ograniczenia są spełnione z dużą rezerwą.

Parametry radiowe: SF, BW, moc nadawania

LoRa ma kilka podstawowych parametrów, które wpływają na zasięg, czas transmisji i zużycie energii:

• SF (Spreading Factor) – zwykle od 7 do 12 (w EU868). Im wyższy SF, tym:
  • większy zasięg,
  • dłuższy czas transmisji pojedynczej ramki,
  • większe zużycie energii przy każdym wysłaniu.
• BW (Bandwidth) – szerokość pasma (np. 125 kHz). Węższe pasmo oznacza większą czułość i zasięg kosztem przepustowości.
• Moc nadawania – zwykle 2–14 dBm; wyższa moc to lepszy zasięg, ale też większe zużycie energii.

LoRaWAN wspiera mechanizm ADR (Adaptive Data Rate), który pozwala serwerowi sieciowemu podpowiedzieć urządzeniu, by używało:

• niższego SF i mniejszej mocy nadawania, gdy jest blisko bramki,
• wyższego SF, gdy jakość łącza spada.

Na start, przy prostym systemie domowo-ogrodowym, zwykle można pozwolić sieci zarządzać ADR automatycznie. Przy własnej implementacji LoRa (bez LoRaWAN) te parametry trzeba dobierać ręcznie.

Klasy urządzeń A, B, C – która do czujników?

LoRaWAN definiuje trzy klasy urządzeń:

• Klasa A – najprostsza i najbardziej energooszczędna. Urządzenie:
  • nadaje uplink (np. co 10 minut),
  • po każdym uplinku otwiera krótkie „okienka” nasłuchu (downlink),
  • poza tym czasem śpi i nie nasłuchuje.
• Klasa B – dodaje wyznaczone w czasie okna nasłuchu zsynchronizowane z bramkami; używana rzadziej, gdy trzeba częściej wysyłać komendy w dół przy nadal oszczędnym zasilaniu.
• Klasa C – urządzenie ciągle nasłuchuje (poza krótkim czasem nadawania); idealna do sterowników z zasilaniem sieciowym, nie do czujników bateryjnych.

W praktyce:

• większość czujników bateryjnych powinna działać w klasie A,
• klasa C przydaje się do sterowania (np. otwieranie zaworu, sterownik kotła), gdzie liczy się szybka reakcja na polecenie, a zasilanie nie jest problemem,
• klasa B jest rzadko spotykana w gotowych czujnikach, wymaga bardziej złożonej synchronizacji.

Limity sieci: duty cycle i ograniczenia publicznych sieci

Oprócz przepisów radiowych (duty cycle, moc nadawania) dochodzą jeszcze:

• ograniczenia operatorów (np. komercyjnych sieci LoRaWAN),
• zasady fair use w publicznych sieciach takich jak The Things Network.

TTN (The Things Network) ma własne zalecenia co do:

• częstotliwości wysyłania danych (typowo nie częściej niż co kilka minut),
• maksymalnej liczby ramek downlink (bo obciążają bramki i pasmo),
• sumarycznego czasu nadawania na urządzenie.

Przekroczenie tych limitów może skutkować:

• utraconymi ramkami,
• blokadą lub ograniczeniem urządzeń przez operatora,
• niezgodnością z przepisami radiowymi, co w skrajnych przypadkach może mieć konsekwencje prawne.

Co sprawdzić przy planowaniu limitów

Kilka kluczowych pytań kontrolnych:

• Jaki jest rozmiar ramki wysyłanej przez czujnik (ile bajtów payloadu + nagłówki)?
• Jak często czujnik nadaje uplink (co 1, 5, 15, 60 minut)?
• Czy używana sieć (TTN, własny serwer, operator) ma opisane limity fair use?

Bilans energetyczny czujnika – jak nie „zajechać” baterii

Zanim przejdziesz do konkretnego projektu, trzeba policzyć, czy bateria to wytrzyma. Bez tego łatwo skończyć z czujnikiem, który zamiast 3 lat działa 3 miesiące.

Krok 1: oszacuj, ile energii zużywa czujnik w trzech stanach:

• sen (sleep) – mikroampery; to powinno być >99% czasu,
• pobór pomiaru – gdy czujnik/ADC się budzi (miliampery, zwykle ułamki sekund),
• radio LoRa – podczas nadawania i ewentualnego nasłuchu (dziesiątki miliamperów).

Krok 2: określ częstotliwość pomiarów i wysyłek:

• czy mierzysz co minutę, ale wysyłasz uśredniony wynik co 15 minut,
• czy każdy pomiar to osobna ramka.

Krok 3: przelicz to na czas działania baterii. Proste, „na serwetce” liczenie:

• sprawdź czas trwania jednego uplinku (w zależności od SF i rozmiaru ramki),
• policz łączny czas nadawania na dobę (czas_uplink × liczba_wysłań),
• dodaj margines na nasłuch po uplinku (okienka RX1/RX2),
• resztę czasu traktuj jako sen.

Częsty błąd: patrzenie tylko na prąd w śnie i ignorowanie radia. Przy SF12 długi uplink potrafi „zjeść” tyle energii, co kilkanaście godzin w śnie.

Co sprawdzić:

• czy producent modułu podaje realne wartości prądu w śnie (a nie tylko „najlepszy możliwy scenariusz”),
• czy interwał wysyłania nie jest zbyt agresywny jak na baterię,
• czy nie trzymasz niepotrzebnie długo otwartych okien nasłuchu po uplinku (konfiguracja stosu LoRaWAN).

Jak zaplanować prosty projekt LoRaWAN – od pomysłu do wymagań

Krok 1: zdefiniuj, co naprawdę chcesz mierzyć

Na początku warto odpowiedzieć sobie na kilka bardzo przyziemnych pytań:

• jaki parametr fizyczny mierzysz (temperatura, wilgotność, poziom wody, stan styku),
• jaką dokładność i stabilność pomiaru potrzebujesz,
• czy potrzebny jest tylko pomiar okresowy, czy także alarmy (np. zalanie, otwarcie drzwi).

Przykład: w monitoringu studni często nie jest ważne, czy poziom wody jest o 2 cm wyższy czy niższy, ale czy spada poniżej progu. Można wtedy wysyłać co 30 minut „zwykłe” pomiary i od razu alarm, gdy poziom spadnie poniżej granicy.

Co sprawdzić:

• czy wymagania dokładności nie wymuszają drogiego czujnika (i czy jest to faktycznie potrzebne),
• czy zamiast ciągłego logowania nie wystarczy alarm + sporadyczne pomiary.

Krok 2: określ częstotliwość danych i opóźnienie

Teraz trzeba ustalić, jak często dane mają trafiać do systemu i jakie opóźnienie jest akceptowalne:

• odczyt temperatury pomieszczenia co 10 minut jest zazwyczaj w zupełności wystarczający,
• stan kontaktu drzwi (otwarte/zamknięte) powinien być wysłany od razu po zmianie,
• wilgotność gleby w grządce może być mierzona raz na godzinę, a wysyłana co kilka godzin.

Krok 2.1: rozdziel:

• częstotliwość pomiaru lokalnego (na mikrokontrolerze),
• częstotliwość wysyłki przez LoRaWAN.

Mikrokontroler może mierzyć częściej, ale po stronie sieci idzie już tylko uśredniony/spreparowany wynik. To prosta droga do oszczędności baterii i zmieszczenia się w limitach duty cycle.

Co sprawdzić:

• czy Twoja częstotliwość uplinków jest zgodna z ograniczeniami (EU868, TTN itd.),
• czy nie wysyłasz nadmiarowych danych, które i tak odrzucisz w aplikacji.

Krok 3: narysuj topologię – zasięg, przeszkody, wysokości

Kolejny etap to prosta mapa: gdzie będą czujniki, a gdzie bramka. Wystarczy szkic na kartce:

• zaznacz budynki, drzewa, pagórki,
• zaznacz wysokość montażu czujników i bramki (piwnica, parter, dach),
• dodaj potencjalne źródła zakłóceń (linie wysokiego napięcia, maszty GSM, hale metalowe).

LoRa najlepiej działa „na widoczność” – antena bramki na dachu domu na wsi potrafi „zobaczyć” czujniki na kilku kilometrach. Ten sam czujnik w piwnicy wieżowca potrafi nie dogadać się z bramką piętro wyżej za stropem żelbetowym.

Co sprawdzić:

• czy możesz zamontować bramkę jak najwyżej (strych, maszt, komin),
• czy krytyczne czujniki nie siedzą w „klatkach Faradaya” (metalowe szafy, kasety liczników).

Krok 4: zasilanie – bateria, zasilacz, panel słoneczny

O zasilaniu opłaca się myśleć jak najwcześniej, bo narzuca ono resztę projektu:

• czujniki w polu – zwykle bateria + ewentualnie panel słoneczny,
• czujniki w budynku – często można podciągnąć zasilanie 230 V / 12 V,
• bramka – praktycznie zawsze zasilanie stałe (router, PoE, zasilacz ścienny).

Jeśli planujesz panel słoneczny:

• upewnij się, że kontroler ładowania ma bardzo niski pobór w spoczynku,
• przelicz najgorszy scenariusz – zimowe, krótkie dni, śnieg na panelu.

Co sprawdzić:

• czy miejsce montażu panelu nie jest w cieniu przez większość dnia,
• czy da się wymienić baterię bez demontażu całego czujnika.

Krok 5: architektura danych – od ramek po backend

LoRaWAN przenosi tylko małe paczki bajtów. Reszta dzieje się po stronie serwera aplikacyjnego:

• czujnik wysyła surowe dane (np. 2 bajty temperatury, 2 bajty wilgotności),
• serwer sieciowy (TTN, ChirpStack) przekazuje je do Twojej aplikacji (HTTP, MQTT, WebSocket),
• aplikacja dekoduje payload i zapisuje do bazy / wysyła powiadomienia.

Na tym etapie zadaj sobie kilka pytań:

• gdzie będą przechowywane dane – lokalnie (Raspberry Pi, NAS) czy w chmurze,
• czy potrzebujesz wizualizacji (dashboard), czy tylko logów,
• czy wymagane są powiadomienia (SMS, e-mail, komunikator).

Co sprawdzić:

• czy wybrany serwer sieciowy ma gotowe integracje (np. TTN → MQTT/HTTP),
• czy masz zaplanowany schemat dekodowania ramek (format payloadu, wersjonowanie).

Wybór sprzętu: czujniki, moduły i płytki deweloperskie

Gotowe czujniki LoRaWAN – kiedy nie warto wyważać otwartych drzwi

Jeżeli zależy Ci na czasie lub nie chcesz projektować elektroniki, najprostszą drogą są gotowe, certyfikowane czujniki LoRaWAN:

• czujniki temperatury/wilgotności do wnętrz (biura, magazyny),
• czujniki zalania, otwarcia drzwi/okna (kontaktrony),
• czujniki poziomu (pływaki, ultradźwiękowe),
• liczniki impulsów (do wodomierzy, gazomierzy z wyjściem impulsowym).

Atuty gotowców:

• gotowa obudowa IP, często z uchwytami montażowymi,
• zwykle dobra optymalizacja energetyczna i przewidziana żywotność baterii,
• prosta integracja z TTN / operatorami (profil urządzenia, gotowe dekodery).

Trzeba jednak zaakceptować:

• mniejszą elastyczność (ustalone interwały, ograniczona liczba parametrów),
• wyższą cenę jednostkową niż własnoręcznie zrobiony czujnik.

Co sprawdzić:

• wspierany region (EU868, nie US915 itd.),
• klasę urządzenia (A/C) i czy jest możliwość konfiguracji interwału wysyłki.

Moduły LoRa / LoRaWAN – serce własnego czujnika

Jeśli chcesz mieć pełną kontrolę nad funkcjami czujnika, lepszym wyborem są moduły radiowe i mikrokontroler:

• klasyczne moduły z układem SX1276/78 – radio LoRa, bez stosu LoRaWAN (stapel po Twojej stronie lub w zewnętrznej bibliotece),
• moduły z wbudowanym stosem LoRaWAN (np. RN2483 w wersji EU), gdzie komunikujesz się prostymi komendami UART,
• nowocześniejsze układy dwumodowe (LoRa + FSK) z gotowym firmware LoRaWAN.

Krok 1: wybierz, czy chcesz:

• pisać stos LoRaWAN samodzielnie (więcej kontroli, większa złożoność),
• korzystać z gotowego stosu w module (mniej kodu, ale musisz żyć z ograniczeniami producenta).

Co sprawdzić:

• dokumentację modułu (komendy AT, przykład integracji z LoRaWAN),
• dostępność biblioteki do Twojego środowiska (Arduino, STM32 HAL, Zephyr, ESP-IDF).

Płytki deweloperskie – szybkie prototypowanie

Do pierwszych testów wygodnie jest użyć płytek deweloperskich z wbudowanym radiem LoRa:

• Arduino + shield LoRa – prosty start, dużo przykładów, większy pobór energii,
• płytki z STM32 + SX1276 – bardziej „produkcyjny” kierunek, lepsza kontrola nad energią,
• ESP32 + LoRa – jeśli potrzebujesz Wi‑Fi + LoRa w jednym urządzeniu, np. czujnik pełniący też rolę lokalnego koncentratora.

Przy wyborze płytki zwróć uwagę na:

• łatwość podłączenia Twoich czujników (I2C, SPI, 1-Wire, wejścia analogowe),
• możliwość programowania z środowiska, które dobrze znasz (Arduino IDE, PlatformIO, CubeIDE).

Co sprawdzić:

• dostępność przykładów LoRaWAN dla wybranej płytki (nie tylko „gołe LoRa”),
• czy płytka pozwala wyłączyć zbędne układy (diody, debuger) dla oszczędzania energii.

Obudowa i antena – drobiazgi, które psują zasięg

Sam wybór modułu to dopiero połowa sukcesu. Dwa elementy potrafią całkowicie popsuć lub poprawić zasięg:

• obudowa – metalowa puszka to ekran; plastikowa obudowa jest zwykle bezpieczniejsza dla anteny,
• antena – zbyt krótka, źle dopasowana, schowana przy metalowych elementach szybko zabije zasięg.

Krok 1: zdecyduj, czy użyjesz:

• prostej anteny typu „ćwierć fali” (kawałek przewodu ok. 8,6 cm dla 868 MHz),
• anteny PCB (wbudowanej na płytce),
• anteny zewnętrznej na złączu SMA (najlepszy wybór dla bramek).

Krok 2: sprawdź, czy antena:

• ma deklarowane pasmo 868 MHz (nie tylko „ISM 433/868/915” bez konkretnych parametrów),
• nie jest zasłonięta metalem, ścianą zbrojoną, blachą dachową.

Co sprawdzić:

• czy długość przewodu antenowego jest rozsądna (za długie tanie kable tłumią sygnał),
• czy obudowa ma przepust lub mocowanie pod antenę zewnętrzną, jeśli planujesz takie rozwiązanie.

Wybór i rodzaje bramek LoRaWAN – od dongla USB po pełny gateway

Architektura bramki LoRaWAN – co tak naprawdę robi gateway

Jak działa gateway – prosty „tłumacz” między radiem a IP

Gateway LoRaWAN nie „rozumie” Twoich czujników ani aplikacji. Jego zadaniem jest:

• odebrać sygnał radiowy LoRa z wielu kanałów jednocześnie,
• zapakować go w ramki UDP (najczęściej protokół Semtech UDP),
• wysłać do serwera sieciowego (TTN, ChirpStack, operator),
• odebrać downlink z serwera i nadać go w eter.

Gateway nie dekoduje payloadu czujnika – nie zna kluczy szyfrujących ani formatu danych. Całą logikę (autoryzację, dekodowanie, integracje) obsługuje serwer sieciowy. To ważne, bo:

• łatwo zmienić backend (np. z TTN na własny ChirpStack) bez ruszania bramek,
• fizyczna bramka może „obsługiwać” wiele niezależnych aplikacji jednocześnie.

Co sprawdzić:

• czy wybrany gateway obsługuje standardowy protokół (UDP/Basic Station),
• czy masz możliwość zmiany adresu serwera sieciowego w konfiguracji.

Jednokanałowe „bramki” – kiedy wolno, a kiedy to ślepa uliczka

Na start kuszące są tzw. single-channel gateways – dongle USB, Raspberry Pi z prostym modułem LoRa, które:

• nasłuchują tylko na jednym kanale i jednym SF,
• mają minimalny koszt i prostą konfigurację,
• pozwalają „pobawić się” LoRaWAN bez większych inwestycji.

Problem w tym, że sieć LoRaWAN w EU868 zakłada wiele kanałów. Jednokanałowy gateway:

• gubi większość ramek czujników (bo słucha tylko fragmentu pasma),
• zaburza mechanizmy ADR (serwer nie dostaje pełnego obrazu sygnałów),
• nie nadaje się do obsługi większej liczby urządzeń ani do zastosowań produkcyjnych.

Krok 1: użyj jednokanałowego rozwiązania tylko jako:

• lokalnego sniffera do nauki protokołu,
• narzędzia do pierwszych testów zasięgu wokół domu.

Krok 2: jeśli planujesz prawdziwą sieć (nawet kilka–kilkanaście czujników na wsi), przeskocz od razu na pełny, wielokanałowy gateway. Inaczej stracisz czas na debugowanie problemów, które znikną same po zmianie sprzętu.

Co sprawdzić:

• czy sprzedawca wyraźnie oznacza urządzenie jako single-channel (1–2 kanały),
• czy dokumentacja nie obiecuje jednoczesnego nasłuchu 8 kanałów – jeśli nie, to nie jest pełny gateway.

Pełne bramki wielokanałowe – fundament stabilnej sieci

„Prawdziwy” gateway LoRaWAN ma co najmniej:

• 8 kanałów uplink (często 8–16),
• dedykowany koncentrator radiowy (np. SX1301, SX1302, SX1303),
• możliwość pracy 24/7 z zasilaniem stałym.

Przekłada się to na:

• obsługę wielu ramek równocześnie (różne kanały, różne SF),
• poprawne działanie mechanizmów LoRaWAN (ADR, potwierdzenia, klasy B/C),
• większą odporność na kolizje i „zatkanie” pasma w okolicy.

W praktyce różnica jest wyraźna. Jedna bramka wielokanałowa na dachu budynku w małym miasteczku potrafi obsłużyć setki czujników rozrzuconych w promieniu kilku kilometrów, a Ty widzisz stabilną jakość linku i powtarzalne wyniki.

Co sprawdzić:

• liczbę kanałów i zgodność z planem częstotliwości EU868,
• jaki chip koncentratora wykorzystuje sprzęt (SX1302/1303 są nowsze i bardziej energooszczędne).

Klasyfikacja bramek – indoor, outdoor, DIY, operatorskie

Przy wyborze sprzętu dobrze jest od razu dopasować go do środowiska pracy. Najczęstsze kategorie:

• bramki indoor – do wnętrz, z zasilaczem 230 V, plastikowa obudowa,
• bramki outdoor – szczelne, zwykle IP65+, z możliwością montażu na maszcie,
• zestawy DIY – Raspberry Pi + koncentrator LoRa na złączu (HAT/mPCIe),
• bramki operatorskie – z redundantnym zasilaniem, LTE, często dla ISP / operatorów.

Krok 1: określ miejsce montażu:

• mieszkanie, biuro – bramka indoor + ewentualnie zewnętrzna antena przy oknie lub na balkonie,
• dach budynku, maszt – bramka outdoor z PoE i anteną na krótkim kablu,
• samodzielny słup w polu – outdoor z zasilaniem solarnym/database PoE zasilanym z rozdzielni.

Krok 2: zdecyduj, ile chcesz mieć kontroli:

• gotowa bramka operatorska – minimum konfiguracji, szybki start, wyższa cena,
• DIY z Raspberry Pi – maksymalna elastyczność, ale aktualizacje i bezpieczeństwo są na Twojej głowie.

Co sprawdzić:

• stopień ochrony obudowy (IP) względem warunków otoczenia,
• obsługiwane metody zasilania (230 V, PoE, DC 12–48 V).

Łącze do internetu – Ethernet, Wi‑Fi, LTE

Gateway musi mieć stabilne połączenie IP z serwerem sieciowym. Opcje są trzy:

• Ethernet – najbardziej przewidywalny, zero problemów z zasięgiem, idealny w budynkach,
• Wi‑Fi – szybkie do uruchomienia, ale podatne na zakłócenia i zmiany hasła/routera,
• LTE/4G – niezależne od infrastruktury na miejscu, dobre w terenie.

Krok 1: dla stałego montażu na budynku celuj w:

• Ethernet z PoE – jeden kabel do zasilania i danych, wygodny przy montażu na dachu lub poddaszu,
• lub LTE, jeśli nie masz dostępu do sieci przewodowej (np. farma, pole, hala magazynowa poza miastem).

Krok 2: jeśli używasz LTE:

• sprawdź dostępność sygnału w miejscu montażu (nie tylko w biurze),
• zaplanuj pakiet danych – LoRaWAN jest lekki, ale logi, aktualizacje systemu i inne usługi mogą zwiększyć zużycie.

Co sprawdzić:

• czy gateway pozwala ustawić statyczne DNS/NTP (często przydaje się przy problemach z siecią),
• czy dostawca LTE nie blokuje ruchu UDP do portów wykorzystywanych przez LoRaWAN.

Konfiguracja bramki dla TTN – krok po kroku

Najprostsza ścieżka dla własnej bramki to podłączenie jej do The Things Network. Procedura wygląda podobnie dla większości modeli.

Krok 1: rejestracja bramki w TTN

• załóż konto na TTN i przejdź do konsoli,
• wybierz region (najczęściej „Europe 1” dla EU868),
• dodaj nową bramkę – wpisz jej EUI (zwykle na naklejce lub w panelu konfiguracyjnym).

Krok 2: ustawienia sieciowe gatewaya

• podłącz bramkę do routera (Ethernet/Wi‑Fi),
• wejdź do panelu konfiguracyjnego (adres IP z DHCP lub wg instrukcji),
• skonfiguruj adres serwera: właściwy dla regionu TTN (np. eu1.cloud.thethings.network dla Europe 1),
• ustaw protokół (Semtech UDP lub Basic Station – zależnie od modelu).

Krok 3: częstotliwości i kanały

• wybierz plan częstotliwości EU868,
• upewnij się, że lista kanałów odpowiada temu, co sugeruje TTN dla danego regionu,
• nie twórz niestandardowych kanałów, jeśli nie wiesz dokładnie, co robisz – utrudnia to roaming i kompatybilność.

Krok 4: test połączenia

• sprawdź w konsoli TTN, czy bramka wyświetla status „connected”,
• uruchom czujnik i obserwuj, czy TTN rejestruje przychodzące uplinki (RSSI, SNR, liczba ramek).

Co sprawdzić:

• czy czas systemowy gatewaya jest poprawny (NTP) – błędny czas bywa źródłem dziwnych problemów,
• czy router/firewall nie blokuje ruchu wychodzącego UDP/TCP na porty używane przez TTN.

Własny serwer sieciowy – ChirpStack i alternatywy

Jeśli nie chcesz zależeć od publicznej infrastruktury lub planujesz sieć w odizolowanym środowisku (np. zakład przemysłowy), możesz postawić własny serwer LoRaWAN. Popularny wybór to ChirpStack:

• open source,
• instalacja na Linux/VM/Docker,
• panel webowy do zarządzania bramkami, urządzeniami i aplikacjami.

Krok 1: zaplanuj miejsce instalacji:

• mały projekt – Raspberry Pi lub mały serwer/VM w sieci lokalnej,
• większy – VM w chmurze (np. VPS), z dostępem przez VPN z bramek.

Krok 2: skonfiguruj ChirpStack:

• zainstaluj bazę danych (PostgreSQL + Redis wg dokumentacji),
• skonfiguruj serwer LoRaWAN dla regionu EU868 (kanały, limity),
• dodaj pierwszą bramkę i aplikację,
• zdefiniuj profil urządzenia (klasa, wersja specyfikacji LoRaWAN, plan częstotliwości).

Krok 3: integracja z aplikacją:

• skorzystaj z MQTT lub HTTP do odbierania ramek z ChirpStacka,
• zaimplementuj dekodery payloadu po swojej stronie.

Co sprawdzić:

• czy masz kopię zapasową bazy danych (klucze do urządzeń są krytyczne),
• czy dostęp do panelu ChirpStacka jest zabezpieczony (hasła, TLS, firewall/VPN).

Planowanie lokalizacji bramki – wysokość, antena, okolica

Dobrze postawiona bramka bywa ważniejsza niż sam typ sprzętu. Prosty przykład: gateway indoor na parapecie pierwszego piętra może „widzieć” czujniki gorzej niż outdoor na dachu, nawet z tą samą anteną.

Krok 1: maksymalna wysokość, rozsądna odległość

• szukaj miejsc jak najwyżej – dach, maszt, komin,
• unikaj bezpośredniej bliskości dużych metalowych konstrukcji (maszty GSM, kratownice),
• utrzymaj rozsądną długość kabla antenowego – im krótszy, tym mniej strat.

Krok 2: antena gatewaya

• wybierz antenę dostosowaną do 868 MHz, o zysku 3–6 dBi na start,
• zbyt duży zysk (np. 9–12 dBi) może zawęzić „kierunek patrzenia” anteny,
• zadbaj o solidne uziemienie masztu – chroni to zarówno sprzęt, jak i budynek.

Krok 3: testy w terenie

• zanim przykręcisz wszystko „na stałe”, przejdź/pojedź z czujnikiem w różne miejsca i sprawdź RSSI/SNR,
• zapisz sobie kilka punktów odniesienia (np. odczyt przy bramie wjazdowej, przy końcu działki) – pomoże to w przyszłych zmianach ustawienia anteny.

Co sprawdzić:

• czy antena nie jest dokładnie na wysokości i w linii z przeszkodą (np. metalową barierką),
• czy miejsce montażu nie uniemożliwi łatwego serwisu (wymiana bramki, reset, aktualizacja).

Zasilanie bramki – stabilność ważniejsza niż oszczędność

Gateway najczęściej pracuje 24/7, więc tu nie liczy się ultraoszczędność, tylko nieprzerwane działanie. Krótkie przerwy w zasilaniu potrafią komplikować debugowanie (brak ramek w losowych momentach).

Krok 1: wybór źródła zasilania

• zasilacz sieciowy 230 V – najprostsze rozwiązanie w budynkach,

Najczęściej zadawane pytania (FAQ)

Czym się różni LoRa od LoRaWAN w praktyce?

LoRa to wyłącznie warstwa radiowa – sposób modulacji sygnału. Moduł LoRa możesz podłączyć do mikrokontrolera i wymieniać proste ramki punkt–punkt, ale całą logikę sieci (adresy, potwierdzenia, bezpieczeństwo) musisz zaprojektować samodzielnie.

LoRaWAN to kompletny protokół sieciowy oparty na LoRa. Określa, jak czujniki rozmawiają z bramkami, jak dane lecą do serwera sieciowego, jak działa szyfrowanie i zarządzanie urządzeniami. Dzięki temu czujnik LoRaWAN „dogada się” z typowymi bramkami i serwerami (TTN, ChirpStack).

Co sprawdzić:

• krok 1: jeśli potrzebujesz tylko prostego linku punkt–punkt – wystarczy LoRa,
• krok 2: jeśli planujesz wiele czujników i integrację z chmurą – wybierz LoRaWAN.

Do czego najlepiej użyć LoRaWAN, a do czego się nie nadaje?

LoRaWAN jest idealny do czujników wysyłających małe porcje danych co kilka minut lub rzadziej, zwłaszcza tam, gdzie nie ma Wi‑Fi, a LTE jest zbyt drogie lub prądożerne. Typowe scenariusze to rolnictwo (wilgotność gleby na polach), smart city (liczniki, śmietniki, parkingi) czy dom/ogród (czujniki bramy, szklarni, piwnicy).

Nie używaj LoRaWAN do wideo, audio, dużych logów ani szybkich sterowań w czasie rzeczywistym. Przesłanie zdjęcia lub strumienia z kamery jest praktycznie niewykonalne z powodu limitów przepustowości i przepisów (duty cycle).

Co sprawdzić:

• krok 1: oszacuj rozmiar pojedynczej wiadomości (bajty, nie megabajty),
• krok 2: określ wymaganą częstotliwość wysyłek (minuty/godziny, nie sekundy),
• krok 3: jeśli potrzebujesz „ciągłego” połączenia – szukaj Wi‑Fi lub LTE.

Jaki zasięg można realnie uzyskać z LoRaWAN w mieście i w terenie otwartym?

W terenie otwartym z dobrze ustawioną bramką (antena wyżej niż zabudowania) realny zasięg to zwykle kilka kilometrów. W mieście, między budynkami, typowe są setki metrów do 2–3 km – im wyżej antena bramki i im mniej przeszkód, tym lepiej.

Na zasięg mocno wpływają parametry SF i BW oraz moc nadawania. Wyższy SF daje większy zasięg kosztem dłuższego czasu nadawania i większego poboru energii. Mechanizm ADR może dobrać parametry automatycznie, ale na starcie i tak warto sprawdzić sytuację w terenie testowymi pakietami.

Co sprawdzić:

• krok 1: zrób test z jedną bramką i jednym czujnikiem w kilku lokalizacjach,
• krok 2: notuj SF i jakość sygnału (RSSI, SNR),
• krok 3: zmień lokalizację anteny bramki, jeśli zasięg jest zbyt mały.

Czy mogę zbudować własną bramkę LoRaWAN i czy potrzebuję internetu?

Tak, możesz zbudować własną bramkę, np. na Raspberry Pi z modułem LoRa lub na gotowym, przemysłowym urządzeniu. Taka bramka wysyła odebrane ramki do serwera sieciowego (TTN, ChirpStack w chmurze lub lokalnie). Sama bramka nie analizuje danych – jest tylko „mostem” radio ↔ IP.

Brama LoRaWAN w typowym scenariuszu wymaga dostępu do sieci IP: Ethernet, Wi‑Fi lub LTE. Bez tego nie przekaże pakietów do serwera. Da się zbudować w pełni lokalną instalację (serwer LoRaWAN w tej samej sieci LAN), ale nadal potrzebne jest połączenie IP między bramką a serwerem.

Co sprawdzić:

• krok 1: wybierz, czy korzystasz z publicznej sieci (np. TTN), czy własnego serwera,
• krok 2: upewnij się, że miejsce montażu bramki ma stabilne łącze IP,
• krok 3: sprawdź, czy Twoja bramka obsługuje pasmo EU868 i LoRaWAN.

Jak często mogę wysyłać dane w LoRaWAN w paśmie EU868?

W EU868 obowiązuje limit duty cycle, zwykle 1% na kanał. Oznacza to maksymalnie 36 sekund nadawania na godzinę na danej częstotliwości. Czas jednej ramki zależy od SF, BW i wielkości payloadu; im wyższy SF i większa ramka, tym dłuższa transmisja.

Dla typowych czujników, wysyłających kilka–kilkadziesiąt bajtów co 5–15 minut, limity są spełnione z dużym zapasem. Problem pojawia się, gdy próbujesz wysyłać dane co kilka sekund – wtedy łatwo przekroczyć ograniczenia i złamać przepisy.

Co sprawdzić:

• krok 1: oblicz szacowany czas trwania pojedynczej ramki (na podstawie SF/BW),
• krok 2: pomnóż to przez planowaną liczbę wysyłek na godzinę,
• krok 3: upewnij się, że łączny czas nadawania nie przekracza 1% na kanał.

LoRaWAN, Wi‑Fi czy LTE-M/NB-IoT – co wybrać do mojego projektu IoT?

LoRaWAN wygrywa z Wi‑Fi zasięgiem i niskim zużyciem energii, ale przegrywa przepustowością. W porównaniu z LTE-M/NB-IoT jest zwykle tańsze (brak karty SIM i abonamentu), wymaga jednak własnej bramki lub dostępu do publicznej sieci LoRaWAN.

Dobry schemat wyboru jest prosty:

• krok 1: jeśli potrzebujesz wysokiej przepustowości i masz zasięg routera – wybierz Wi‑Fi,
• krok 2: jeśli czujniki są rozproszone na dużym obszarze i nie chcesz stawiać bramek – LTE-M/NB-IoT,
• krok 3: jeśli dane są małe, urządzenia są na baterii, a możesz postawić 1–2 bramki – LoRaWAN.

Co sprawdzić:

• czy masz możliwość montażu własnej bramki w dobrej lokalizacji,
• czy w miejscu instalacji działa sieć operatora LTE-M/NB-IoT,
• czy koszt abonamentu na kartę SIM nie „zje” budżetu projektu.

Jakie parametry LoRa (SF, BW, moc) ustawić na start?

Na początek najprościej jest włączyć mechanizm ADR w LoRaWAN i pozwolić sieci dobrać parametry. Jeśli ustawiasz wszystko ręcznie, typowy punkt wyjścia w EU868 to BW 125 kHz, moc nadajnika 14 dBm i środkowe SF (np. 9 lub 10), a następnie korekta w zależności od zasięgu i jakości sygnału.

Kluczowe Wnioski

• LoRa to tylko warstwa radiowa (modulacja o dużym zasięgu i niskim poborze energii), a LoRaWAN to kompletny protokół sieciowy z adresacją, bezpieczeństwem i integracją z serwerami – nie wolno ich wrzucać do jednego worka.
• Krok 1: decydując między „gołą” LoRa a LoRaWAN, trzeba określić cel – proste połączenie punkt–punkt (np. pilot, link telemetryczny między dwoma urządzeniami) można zbudować na samej LoRa, ale sieć miejską/domową IoT z czujnikami i chmurą sensownie oprzeć już na LoRaWAN.
• LoRaWAN układa całą drogę danych: czujnik → bramka → serwer sieciowy → aplikacja; bramka pełni tylko rolę „mostu” radio–IP i nie interpretuje pakietów, więc ten sam czujnik może być odbierany przez wiele bramek jednocześnie.
• Technologia LoRaWAN jest stworzona do rzadkich, małych komunikatów (kilka–kilkadziesiąt bajtów co parę minut lub rzadziej) z urządzeń bateryjnych rozproszonych na dużym obszarze – idealna np. dla liczników, czujników na polu oddalonym o kilometr czy bramy wjazdowej 500 m od domu, ale kompletnie nie pasuje do wideo, audio i szybkich sterowań w czasie rzeczywistym.
• Krok 2: porównując LoRaWAN z Wi‑Fi i LTE‑M/NB‑IoT, trzeba rozumieć kompromisy – LoRaWAN wygrywa zasięgiem i energooszczędnością, jest tańsza (brak karty SIM), ale oferuje bardzo niską przepustowość i wymaga własnej bramki lub publicznej sieci (np. TTN).