LoRa - Die Funktechnik für das Internet der Dinge
Mit dem Thema LoRa will ich mich schon seit Jahren beschäftigen. Kilometerlange Funkreichweite bei minimalem Energieverbrauch, das klingt fast zu schön, um wahr zu sein. Bei meiner Wetterstation verwende ich bisher ESP-NOW für die Sensoren, ein proprietäres Funkprotokoll von Espressif Systems, das auf der WiFi-Funktechnologie aufsetzt, jedoch kein WLAN im klassischen Sinne ist. Die Reichweite ist aber relativ begrenzt und diese Technik ist auch nur mit ESP32 oder ESP8266 Mikrocontrollern einsetzbar.
In den letzten Wochen habe ich mich ein wenig mit der LoRa Funktechnik beschäftigt, und da es eine Weile gedauert hat, bis ich das Konzept verstanden habe, möchte ich hier eine kleine Einführung in das Thema geben. Von den Grundlagen der Chirp-Spread-Spectrum-Modulation über die verschiedenen Parameter wie Spreading Factor, Bandbreite und Coding Rate bis hin zu einem kurzen Überblick über LoRaWAN, Meshtastic und The Things Network.
Was ist LoRa?
Während klassische Funktechnologien wie WiFi, Bluetooth oder Zigbee primär auf hohe Datenraten und Bandbreite (bei entsprechend begrenzter Reichweite und höherem Energieverbrauch) ausgelegt sind, schlägt LoRa einen völlig anderen Weg ein. Mit Datenraten von wenigen Bit pro Sekunde bis zu einigen Kilobit pro Sekunde erreicht die Technologie Reichweiten von über 15 Kilometer in ländlichen Gebieten und durchdringt selbst dichte urbane Bebauung über mehrere Kilometer hinweg.
Diese Eigenschaften machen LoRa zur idealen Funktechnik für das Internet der Dinge (IoT). Überall dort, wo Daten von Sensoren über große Distanzen bei minimalem Energieverbrauch übertragen werden müssen, spielt LoRa seine Stärken aus. Im Gegensatz zu zellularen LPWAN-Technologien wie NB-IoT oder LTE-M benötigt LoRa keine lizenzierten Frequenzbänder und keine Mobilfunkverträge, sondern nutzt frei verfügbare ISM-Bänder (Industrial, Scientific and Medical). Damit ist diese Technologie auch für private Projekte einsetzbar.
Die Geschichte von LoRa beginnt 2009 in Frankreich, als Nicolas Sornin und Olivier Seller die Idee entwickelten, eine besonders energiearme Funkübertragung über große Distanzen zu ermöglichen. 2010 kam François Sforza dazu, und gemeinsam gründeten sie Cycleo. Für die Umsetzung verwendeten sie die Chirp-Spread-Spectrum-(CSS)-Modulationstechnologie. Semtech erkannte das Potenzial und übernahm Cycleo 2012, entwickelte mit den Gründern die ersten LoRa-Chips (SX1272/SX1276) und spezifizierte mit LoRaMAC ein eigenes Netzwerkprotokoll. 2015 wurde die LoRa Alliance gegründet und das Protokoll erhielt den Namen LoRaWAN, um globale Interoperabilität und eine standardisierte Weiterentwicklung sicherzustellen.
Wie funktioniert Chirp-Spread-Spectrum-(CSS)-Modulation?
Um zu verstehen, warum diese Technik so robust ist und eine solche Reichweite ermöglicht, muss man sich die Modulation ansehen, also die Art, wie digitale Daten in ein Funksignal umgewandelt werden. Viele klassische Verfahren kodieren Daten auf eine dieser drei Arten:
- Amplitudenmodulation (AM): Die Information steckt in der Stärke (Amplitude) des Signals. Die digitale Form ist Amplitude Shift Keying (ASK) oder simples On-Off Keying (OOK), wo "Sender an" eine "1" und "Sender aus" eine "0" bedeutet. Das ist simpel, aber sehr störanfällig.
- Frequenzmodulation (FM): Die Information steckt in der Tonhöhe (Frequenz) des Signals. Die digitale Form ist Frequency Shift Keying (FSK), die abrupt zwischen zwei festen Frequenzen für "0" und "1" hin- und herspringt.
- Phasenmodulation (PM): Die Information steckt im Winkel (Phase) der Welle. Die digitale Form ist Phase Shift Keying (PSK), die abrupt zwischen verschiedenen Phasenwinkeln springt (z.B. 0° für "0" und 180° für "1").
LoRa dagegen verwendet einen völlig anderen Ansatz. Es nutzt keine feststehenden Frequenzen oder Zustände. Stattdessen nutzt LoRa Bewegung: Es erzeugt ein Signal, dessen Frequenz wie eine Rampe kontinuierlich ansteigt (oder abfällt), ein sogenannter Chirp. Die kontinuierliche Verschiebung dieses Chirps ist die eigentliche Modulation. Genau diese Methode, das Chirp Spread Spectrum (CSS), macht das Signal sehr widerstandsfähig gegen Störungen und ist das Herzstück seiner Reichweite.
Das Kernprinzip: Der Chirp
Das Wort "Chirp" (englisch für "Zwitschern") ist ein Signal, dessen Frequenz sich über eine definierte Zeit linear ändert.
- Ein Up-Chirp startet bei einer niedrigen Frequenz () und steigt linear zu einer hohen Frequenz ().
- Ein Down-Chirp macht das Gegenteil und sinkt von hoch nach tief.
Dieses an- oder absteigende Signal ist das fundamentale Symbol - der "Daten-Baustein" von LoRa. Das folgende Diagramm veranschaulicht den zeitlichen Verlauf eines Chirps. Auf der linken Seite sieht man den Verlauf des Signals und rechts das entsprechende Frequenz/Zeit Diagramm mit dem linearen Anstieg der Frequenz.
Die eigentliche Information wird nicht durch die Frequenzänderung selbst kodiert, sondern durch die zyklische Verschiebung des Startpunkts des Chirps. Ein Chirp, der am Anfang der Bandbreite startet, bedeutet etwas anderes als ein Chirp, der in der Mitte beginnt. Der Empfänger muss nur den Basis-Chirp kennen und vergleichen, wo der empfangene Chirp im Vergleich dazu gestartet ist. Diese Frequenzverschiebung ist die Information. Das folgende Diagramm veranschaulicht den Frequenzverlauf eines verschobenen Chirps.
Die Dauer des Chirps sowie und haben sind nicht verändert, lediglich die Startfrequenz ist bei diesem Chirp anders.
Die Schlüsselparameter: Spreading Factor, Bandbreite und Coding Rate
Das Chirp Spread Spectrum (CSS) ist also das Grundprinzip von LoRa. Die Anzahl der möglichen Verschiebungen, also die Symbole, und die Dauer eines Chirps sind aber nicht willkürlich, sondern werden von den Parametern Spreading Factor (SF) und Bandbreite (BW) bestimmt.
Spreading Factor
Der Spreading Factor (SF) definiert, wie viele Verschiebungen und damit Symbole ein Chirp annehmen kann. Diese Anzahl ist definiert als die Zweierpotenz 2SF. Daraus folgt, dass ein einzelnes Symbol genau
an Information tragen kann. Bei einem Spreading Factor 3 gibt es also 23 = 8 verschiedene Symbole. Das folgende Diagramm zeigt diese 8 möglichen "Startrampen" für den Chirp.
Der Empfänger muss nur herausfinden, welche der 8 Rampen gesendet wurde, um die 3 Bits zu dekodieren. Bei LoRa wird ein Spreading Factor zwischen SF7 und SF12 verwendet, modernere Semtech Chips können auch SF5 und SF6 verwenden.
Bandbreite
Die Bandbreite (BW) ist der zweite entscheidende Parameter von LoRa. Sie legt fest, über welchen Frequenzbereich sich ein Chirp erstreckt, also von der minimalen Frequenz bis zur maximalen Frequenz :
Ein LoRa-Chirp ist in Wirklichkeit nicht so glatt wie in den Diagrammen dargestellt, sondern besteht aus vielen kleinen diskreten Frequenzschritten (den sogenannten Chips). Die Anzahl dieser Schritte entspricht genau der Anzahl der möglichen Verschiebungen einen Chirps, die zur Kodierung verwendet werden. Ein Symbol besteht daher aus:
Die Chiprate (RChip), also die Geschwindigkeit, mit der diese 2SF Chips gesendet werden, ist definitionsgemäß identisch mit der Bandbreite:
Jeder Chip dauert also:
Damit ergibt sich für die Gesamtdauer eines Symbols (der sogenannten Symbol-Dauer):
Daraus folgt die Brutto-Bitrate (Rb) des Signals:
Eine größere Bandbreite macht die Chips kürzer und damit den gesamten Chirp schneller. Das erhöht die Datenrate, reduziert aber gleichzeitig die Empfindlichkeit und Reichweite, da die empfangene Energie pro Zeiteinheit stärker vom Rauschen überdeckt wird. Eine kleinere Bandbreite bedeutet das Gegenteil. Langsamere Symbole, geringere Datenrate, aber deutlich höhere Reichweite und Störsicherheit. Übliche Werte bei LoRa sind 125 kHz, 250 kHz und 500 kHz.
Zwei Beispiele mit den Kombinationen SF7/500 kHz und SF12/125 kHz zeigen die maximalen und den minimalen Datenraten, die mit LoRa möglich ist, und veranschaulichen den Kompromiss zwischen Geschwindigkeit und Reichweite:
- SF7 (BW 500 kHz):
- SF12 (BW 125 kHz):
Obwohl SF12 nur 75-mal langsamer ist, gewinnt das Signal durch den hohen Spreading Factor so viel an Robustheit, dass es deutlich über den Faktor 100 weiter senden kann, als der reine Zeitunterschied vermuten lässt.
Empfindlichkeit, dBm und Verarbeitungsgewinn (Processing Gain)
Um die außergewöhnliche Reichweite von LoRa zu verstehen, muss man die Empfindlichkeit des Empfängers betrachten, also das schwächste Signal, das er noch detektieren kann. Die Leistung wird in der Funktechnik oft in dBm (Dezibel relativ zu einem Milliwatt) angegeben:
- 0 dBm entspricht 1 mW (Milliwatt) Sendeleistung.
- +30 dBm entspricht 1 W (Watt).
- -100 dBm ist eine extrem geringe Leistung von 0,0000000001mW.
Während traditionelle Funktechnologien typischerweise eine Empfindlichkeit von -100 dBm bis -110 dBm benötigen, können LoRa-Empfänger Signale von -125dBm bis zu -140dBm dekodieren. Diese Fähigkeit, extrem schwache Signale zu empfangen, ist der Schlüssel zur Reichweite.
Die Fähigkeit von LoRa, diese Signale zu empfangen, die weit unterhalb des Rauschpegels liegen, wird durch den sogenannten Verarbeitungsgewinn (Processing Gain, PG) ermöglicht. Der Verarbeitungsgewinn quantifiziert, um wie viele Dezibel (dB) das Signal durch die Spreading-Methode verstärkt wird. Bei LoRa ist der Verarbeitungsgewinn direkt an den Spreading Factor (SF) gekoppelt:
Der Verarbeitungsgewinn bewirkt, dass ein schwaches Nutzsignal, das beim Empfänger im Rauschen untergeht, durch die Dekodierung des langsamen Chirp-Musters wieder hervorgehoben wird. Beispielsweise bietet SF12 einen Verarbeitungsgewinn von ≈ 36 dB, wodurch ein Signal selbst dann dekodierbar ist, wenn es 20 bis 30 dB schwächer als das Umgebungsrauschen ist. Ein hoher SF opfert sozusagen Datenrate für einen massiven Zugewinn an Störfestigkeit und Reichweite.
Coding Rate
Die Coding Rate (CR) definiert die Redundanz für Vorwärts-Fehlerkorrektur (FEC), das heißt, wie viele zusätzliche Bits werden gesendet, um Übertragungsfehler zu korrigieren. Der Empfänger nutzt diese redundanten Bits, um zu erkennen, ob ein Fehler aufgetreten ist, und um die fehlerhaften Bits zu korrigieren. Die verfügbaren Werte sind 4/5, 4/6, 4/7 und 4/8:
- CR 4/5: 20% Redundanz – kann 1 von 5 Bits korrigieren
- CR 4/6: 33% Redundanz – kann 2 von 6 Bits korrigieren
- CR 4/7: 43% Redundanz – kann 3 von 7 Bits korrigieren
- CR 4/8: 50% Redundanz – kann 4 von 8 Bits korrigieren
Die reale Bitrate sinkt dadurch auf
Mit steigender Redundanz sinkt daher die effektive Datenrate, während die Störfestigkeit des Signals zunimmt.
Regulatorische Rahmenbedingungen: Frequenzbänder und Betriebsgrenzen
LoRa operiert auf den lizenzfreien ISM-Bändern (Industrial, Scientific, Medical). Die Nutzung dieser Bänder ist zwar kostenfrei, unterliegt jedoch strengen regionalen Regulierungen, um Interferenzen zu minimieren und eine faire Nutzung (Fair Access Policy) zu gewährleisten.
Regionale Frequenzpläne
Die Frequenzzuweisung ist global nicht einheitlich. Die LoRa Alliance definiert daher regionale Parameterpläne, die den lokalen Vorschriften entsprechen:
-
Europa (EU868 & EU433): Nutzt primär das Band von 863 bis 870 MHz (EU868). Es existiert auch ein Plan für das Band von 433,05 bis 434,79 MHz (EU433). Die Regulierung erfolgt durch das ETSI (European Telecommunications Standards Institute).
-
Nordamerika (US915): Nutzt das Band von 902 bis 928 MHz. Hier dominiert eine Frequency Hopping Spread Spectrum (FHSS)-Regelung, die statt strenger Duty Cycles eine maximale Verweildauer (Dwell Time) pro Kanal vorschreibt.
-
Asien (AS923): Nutzt Frequenzen um 923 MHz, ebenfalls mit spezifischen nationalen Anpassungen.
Regulatorische Limits in Europa (ETSI)
In Europa sind die zentralen regulatorischen Beschränkungen die Einschaltdauer (Duty Cycle) und die maximale Sendeleistung.
| Frequenzband (Sub-Band) | Max. Sendeleistung (ERP) | Max. Duty Cycle | Typische Nutzung |
| 433,05 – 434,79 MHz | 10 mW (+10 dBm) | 10 % (variiert) | EU433, störanfälliger |
| 863,0 – 868,0 MHz (g1) | 25 mW (+14 dBm) | 1 % | Standard-Uplink-Kanäle für LoRaWAN |
| 868,7 – 869,2 MHz (g2) | 25 mW (+14 dBm) | 0,1 % | Sehr restriktiv, oft vermieden |
| 869,4 – 869,65 MHz (g3) | 500 mW (+27 dBm) | 10 % | LoRaWAN RX2 (Downlink), Meshtastic |
| 869,7 – 870,0 MHz (g4) | 25 mW (+14 dBm) | 1 % | (oder 10% mit LBT/AFA) |
Wie die Tabelle zeigt, ist das 868-MHz-Band komplexer aufgeteilt. Es bietet das Standard-Band (g1) für Sensor-Uplinks mit 1 % Duty Cycle und das leistungsstarke "Power-Band" (g3) mit 500 mW Sendeleistung und 10 % Duty Cycle. Dieses g3-Band wird typischerweise von LoRaWAN-Gateways für Downlink-Nachrichten (Quittungen, Befehle) im RX2-Fenster genutzt. Auch Meshtastic verwendet dieses Band in Europa, um von der höheren Sendeleistung und der toleranteren Einschaltdauer für das Routing im Mesh zu profitieren.
Konsequenzen für die Sendezeit (Time on Air)
Der Duty Cycle hat direkte Auswirkungen auf die Architektur einer LoRa-Anwendungs, da die Time on Air (ToA), also die Dauer einer einzelnen Übertragung, die Wartezeit bis zur nächsten Sendung bestimmt:
-
SF7 (BW 500 kHz): Eine typische 20-Byte-Nutzlast hat eine ToA von ca. 9,4 Millisekunden (ms).
Mit einen 1 % Duty Cycle muss das Gerät nach der Sendung 99 * 9,4 ms ≈ 0,93 Sekunden warten. -
SF12 (BW 125 kHz): Dieselbe Nutzlast hat eine ToA von ca. 1,32 Sekunden (s).
Mit einen 1 % Duty Cycle muss das Gerät nach der Sendung 99 * 1,32 s ≈ 130,2 Sekunden (über 2 Minuten) warten.
Diese vereinfachte Rechnung verdeutlicht, dass ein hoher Spreading Factor, der für maximale Reichweite nötig ist, die maximale Sendefrequenz drastisch reduzieren. Bei SF12 ist auf einem 1%-Kanal nur eine Sendung alle paar Minuten möglich, was LoRa für Anwendungen mit hohem Datenaufkommen oder geringer Latenz ungeeignet macht.
LoRaWAN, Meshtastic und The Things Network
LoRa definiert lediglich die physikalische Übertragungsschicht. Erst die darauf aufbauenden Protokolle und Netzwerk-Architekturen verwandeln das reine Funksignal in ein nutzbares, skalierbares System. Sie definieren die notwendigen Regeln für die Kommunikation, kümmern sich um Adressierung, Datensicherheit und Interoperabilität der Endgeräte.
LoRaWAN: Das Netzwerkprotokoll für LoRa
LoRaWAN spezifiziert das komplette Netzwerkprotokoll für Low Power Wide Area Networks. Die LoRa Alliance, ein Konsortium von über 500 Unternehmen, entwickelt und pflegt die offene LoRaWAN-Spezifikation, die Netzwerkarchitektur, Sicherheitsmechanismen und Geräteprofile standardisiert.
Netzwerkarchitektur: Star-of-Stars-Topologie
LoRaWAN nutzt eine stern-förmige Netzwerktopologie, die sich fundamental von Mesh-Netzwerken unterscheidet:
End Devices (Sensoren/Aktoren)
↓ ↓ ↓
Gateways (Konzentratoren)
↓ ↓ ↓
Network Server (Zentrale Intelligenz)
↓
Application Server (Anwendungslogik)
End Devices sind die eigentlichen IoT-Geräte mit LoRa-Transceivern. Sie kommunizieren direkt mit einem oder mehreren Gateways, ohne Multi-Hop-Routing. Gateways fungieren als transparente Bridges zwischen End Devices und Backend und empfangen auf 8 Kanälen gleichzeitig. Der Network Server dedupliziert Pakete von mehreren Gateways, verwaltet Authentifizierung und optimiert Parameter via ADR. Der Application Server entschlüsselt die Payload und führt die Anwendungslogik aus.
Geräteklassen: Class A, B und C
LoRaWAN definiert drei Geräteklassen mit unterschiedlichen Energieprofilen:
Class A ist der Standard für batteriebetriebene Sensoren: Das Gerät initiiert alle Kommunikationen und öffnet nach jedem Uplink zwei kurze Empfangsfenster (RX1 nach 1s, RX2 nach 2s). Der Server kann nur direkt nach einem Uplink antworten.
Class B ergänzt Class A um periodische Empfangsfenster, die durch Gateway-Beacons (alle 128 Sekunden) synchronisiert werden. Dies ermöglicht vorhersagbare Downlink-Latenzen bei moderatem Mehrverbrauch.
Class C hält den Empfänger permanent aktiv (außer während TX), was minimale Latenz bei hohem Stromverbrauch bedeutet – ideal für netzbetriebene Geräte.
Sicherheit: Zwei-Layer-Verschlüsselung
LoRaWAN implementiert Ende-zu-Ende-Sicherheit mit AES-128 auf zwei Ebenen:
Network Session Key (NwkSKey): Sichert die MAC-Layer-Kommunikation, berechnet den Message Integrity Code (MIC) und verschlüsselt MAC Commands. Der Network Server kennt diesen Schlüssel.
Application Session Key (AppSKey): Verschlüsselt die Application Payload im AES-128-CTR-Modus. Nur End Device und Application Server kennen diesen Schlüssel – der Network Server kann die Nutzdaten nicht entschlüsseln.
Die Aktivierung erfolgt entweder per OTAA (Over-The-Air Activation) mit dynamischer Key-Generierung bei jedem Join-Prozess (sicher, empfohlen) oder per ABP (Activation By Personalization) mit vorprogrammierten Keys (einfacher, aber weniger sicher).
Jedes Paket enthält einen Frame Counter (FCnt), der Replay-Attacks verhindert. Der 4-Byte-MIC authentifiziert das gesamte Paket und schützt vor Manipulation.
Frequenzbänder und Data Rates
LoRaWAN nutzt regional unterschiedliche ISM-Bänder:
Europa (EU868): 8 Uplink-Kanäle (863-870 MHz), verschiedene Duty-Cycle-Limits (1% oder 10% je nach Sub-Band), RX2-Window auf 869,525 MHz @ SF12
USA (US915): 64 Kanäle @ 125 kHz + 8 Kanäle @ 500 kHz mit Channel-Hopping über alle Frequenzen
Asien: Verschiedene Varianten (AS923, CN470, etc.) mit lokalen Anpassungen
Data Rates reichen von DR0 (SF12BW125, 250 bps) bis DR6 (SF7BW250, 11 kbps) in Europa. Der Adaptive Data Rate (ADR) Algorithmus optimiert automatisch SF, TX-Power und Kanalnutzung basierend auf gemessener Signalqualität.
Meshtastic: LoRa ohne Infrastruktur
Während LoRaWAN auf zentrale Gateway-Infrastruktur setzt, ermöglicht Meshtastic ein vollständig dezentrales Mesh-Netzwerk auf LoRa-Basis. Das Open-Source-Projekt zielt auf Off-Grid-Kommunikation ohne Internet und Infrastruktur.
Grundprinzip: Mesh-Topologie
Node A ←→ Node B ←→ Node C
↑ ↑
↓ ↓
Node D ←→ Node E ←→ Node F
Jeder Node ist gleichzeitig Sender, Empfänger und Router. Nachrichten werden per Flooding mit Hop-Limit durch das Netz geleitet: Jeder Node, der eine Nachricht empfängt, sendet sie weiter (mit reduziertem Hop-Counter), bis das Hop-Limit erreicht ist. Ein Packet-ID-Cache verhindert, dass dieselbe Nachricht mehrfach weitergeleitet wird.
Modem-Konfiguration und Presets
Meshtastic nutzt vordefinierte Modem-Presets, die für verschiedene Anwendungsfälle optimiert sind:
LongFast (Standard): SF11 @ 250 kHz – Reichweite ~5-8 km, Airtime ~2s
LongSlow: SF12 @ 125 kHz – Reichweite ~10-15 km, Airtime ~8s
MediumFast: SF10 @ 250 kHz – Reichweite ~3-5 km, Airtime ~1s
ShortFast: SF7 @ 250 kHz – Reichweite ~1-2 km, Airtime ~200ms
Die Wahl des Presets bestimmt den Trade-off zwischen Reichweite pro Hop und Netzwerk-Durchsatz.
Sicherheit
Meshtastic verwendet AES-128-CTR-Verschlüsselung mit Channel-basierten Pre-Shared Keys. Der Encryption Key wird aus Channel-Name und PSK abgeleitet. Im Vergleich zu LoRaWAN fehlen jedoch Frame Counter (keine Replay-Protection) und Message Integrity Code (keine Authentifizierung gegen Manipulation). Für sensitive Anwendungen sollte zusätzliche Application-Layer-Encryption implementiert werden.
The Things Network: Community-LoRaWAN als Mittelweg
Zwischen professionellem LoRaWAN und infrastrukturfreiem Meshtastic existiert mit The Things Network (TTN) eine interessante Alternative: Ein kostenloses, community-betriebenes LoRaWAN-Netzwerk.
The Things Network ist ein globales, offenes, crowdsourced LoRaWAN-Netzwerk, das von einer Community aus über 190.000 Mitgliedern in mehr als 100 Ländern aufgebaut wird. 2015 in Amsterdam gestartet, wurde die gesamte Stadt innerhalb von 6 Wochen mit LoRaWAN-Coverage versorgt.
TTN nutzt die Standard-LoRaWAN-Technologie, aber die Gateways werden von Community-Mitgliedern betrieben und der Network Server ist kostenlos nutzbar. The Things Stack ist der LoRaWAN Network Server im Zentrum der Lösung und kümmert sich um Routing, Sicherheit, Message-Deduplizierung und ADR-Optimierung.
Coverage und Verfügbarkeit
Viele große Städte weltweit haben bereits vollständige TTN-Coverage. Ob die eigene Region Coverage hat, kann man auf der TTN-Karte prüfen. Anders als bei Meshtastic, wo man selbst Teil des Netzes ist, braucht man bei TTN ein Gateway in Reichweite. Sollte kein Gateway in der Nähe sein, besteht die Möglichkeit, ein eigenes Gateway aufzustellen (~300-600€ Investition).
Fair Use Policy
TTN ist zwar kostenlos, hat aber gewisse Limits:
- 30 Sekunden Airtime pro Device pro Tag (EU868)
- 10 Downlink-Messages pro Device pro Tag
- Maximal 500 Bytes Payload
Für typische Sensor-Anwendungen (alle 5-10 Minuten ein Paket) ist das großzügig. Für Streaming-Daten oder häufige Updates allerdings ungeeignet.
Fazit und Ausblick
Ich hoffe, es ist mir gelungen, die Grundlagen von LoRa, insbesondere die CSS-Modulation, einigermaßen verständlich darzulegen. Im nächsten Artikel zeige ich, wie man mit dem ESP32 und einem Semtech SX1262 Transceiver einen einfachen Sender und Empfänger implementiert.


