So funktioniert Nova Aeris

Technische Dokumentation – LoRa Physical Layer, Meshtastic-Protokoll, Formeln, Tabellen und praktische Hinweise.

🛜 1. Basics

Das LoRa-Netzwerk von Nova-Aeris ist ein vollständig off-grid Funknetz auf Basis der LoRa-Technologie, das speziell für Umgebungen ohne Strom, Mobilfunk oder Internet entwickelt wurde. Im Gegensatz zu klassischen Netzen wie LoRaWAN oder Mobilfunk funktioniert es komplett dezentral: Jedes Endgerät (z. B. der Nova Ranger als Handheld) sendet Nachrichten oder Telemetriedaten per LoRa-Funk, die automatisch von anderen Geräten oder Relais weitergeleitet werden. So entsteht ein selbstorganisierendes Mesh-Netz, das in Katastrophen, Bergen, beim Offroad-Einsatz oder mit Drohnen zuverlässig arbeitet – einfach einschalten und kommunizieren, ohne zentrale Infrastruktur.

Technisch setzt Nova-Aeris auf eine echte Mesh-Topologie statt der sternförmigen LoRaWAN-Architektur. Jedes kompatible Gerät (Nova Ranger, Solar Relay, Sky Gateway oder Drone Pod) kann gleichzeitig Sender, Empfänger und Relay sein und Nachrichten über mehrere Hops weiterleiten. Das System basiert auf dem offenen Meshtastic-Protokoll, das verschlüsselte Text- und Sensordaten überträgt. Besonders stark wird die Reichweite durch luftgestützte Relais: Der Nova Drone Pod auf einer Drohne oder der 8-Kanal Sky Gateway in der Höhe umgeht Hindernisse und erreicht problemlos über 50 km pro Hop. Solarbetriebene Relais sorgen für autarke Dauerbetriebe, sodass das Netz komplett unabhängig von Stromnetz oder Internet bleibt.

Auf der physikalischen Schicht nutzt das Netzwerk die Chirp Spread Spectrum (CSS)-Modulation im ISM-Band (in Europa 868 MHz). Durch dynamische Anpassung des Spreading Factors (SF7 bis SF12) wird der Trade-off zwischen Datenrate und Reichweite gesteuert – bei SF12 sind Empfindlichkeiten unter -140 dBm und extrem niedrige Datenraten möglich, dafür aber maximale Distanz. Das Mesh-Routing erfolgt über Flooding mit Hop-Limit und Collision Avoidance, um Kollisionen zu minimieren. Die 8-Kanal-Gateways erhöhen die Parallelkapazität enorm, während das System keinerlei externe Server oder Internet-Backhaul benötigt – alles bleibt lokal, resilient und hochverfügbar, auch wenn die komplette zivile Infrastruktur ausfällt.

📡 2. LoRa – Die Physikalische Schicht

LoRa nutzt Chirp Spread Spectrum (CSS). Ein kontinuierlicher Frequenz-Chirp erzeugt einen Processing Gain von bis zu 20 dB, sodass das Signal weit unter dem Rauschpegel liegt und trotzdem zuverlässig demoduliert werden kann. Im Gegensatz zu herkömmlichen Modulationsverfahren wie FSK oder PSK, bei denen das Signal schmalbandig und anfällig für Störungen ist, breitet CSS die Energie eines Symbols über die gesamte Bandbreite (typisch 125 kHz) aus, indem die Trägerfrequenz linear von unten nach oben (Up-Chirp) oder umgekehrt (Down-Chirp) variiert. Dadurch entsteht eine orthogonale Symbolstruktur, die extrem robust gegen Mehrwegeausbreitung, Doppler-Effekte und schmale Störer ist – ideal für lange Reichweiten bei minimaler Sendeleistung.

Auf der physikalischen Schicht wird die Robustheit durch den Spreading Factor (SF7 bis SF12) gesteuert: jeder Schritt verdoppelt die Symbolzeit (Ts = 2^SF / BW) und erhöht den Processing Gain um etwa 3 dB, bei SF12 erreicht man Empfindlichkeiten unter -140 dBm und Reichweiten von über 20 km im Freien. Die Datenrate ergibt sich aus SF × (4/5) × (BW / 2^SF) bei Coding Rate 4/5, während Forward Error Correction (FEC) mit variablen Raten (4/5 bis 4/8) zusätzliche Redundanz hinzufügt. Das Ganze bleibt bei nur wenigen Milliwatt Sendeleistung energieeffizient, da die Luftzeit (Airtime) bewusst lang gehalten wird und keine permanente Verbindung besteht – perfekt für batteriebetriebene Sensoren und Mesh-Anwendungen wie bei Nova-Aeris.

f_low f_high Chirp Spread Spectrum

Spreading Factor Vergleich

SF Datenrate Reichweite (Luft) Airtime (51 Byte) Sensitivität
SF75,47 kbit/s2–8 km~0,07 s-123 dBm
SF91,76 kbit/s10–25 km~0,37 s-132 dBm
SF100,98 kbit/s20–50 km~0,74 s-135 dBm
SF120,29 kbit/s50–150 km~2,5 s-137 dBm

Airtime-Berechnung

Airtime = (Payload + Header) × (2SF / BW) × CR
BW = Bandwidth (125 kHz), CR = Coding Rate (4/5)

Beispiel: 51 Byte Payload, SF10, 125 kHz → ca. 0,74 Sekunden Airtime

🔄 3. Meshtastic – Das Routing-Protokoll

Das Routing-Protokoll von Meshtastic basiert auf einem Managed-Flood-Routing-Ansatz, der bewusst einfach und robust für dynamische, mobile LoRa-Meshe gehalten ist. Jede Nachricht wird mit einem HopLimit (maximal 7, in 3 Bit des Headers codiert) versehen und von jedem empfangenden Knoten dekrementiert und weitergeleitet, solange das Limit nicht null ist. Zur Vermeidung von Redundanzen wartet jeder Knoten vor dem Rebroadcast eine kurze, SNR-abhängige Zeit im Contention-Window: Knoten mit schlechterem Signal (weiter entfernt) senden zuerst, während näher liegende Geräte zuhören und ihre eigene Übertragung unterdrücken, wenn sie bereits eine Weiterleitung hören. Duplikat-Erkennung erfolgt über eine eindeutige Packet-ID (Sender + Sequenznummer) und eine lokale Seen-Liste; implizite ACKs entstehen, sobald irgendein Knoten die Nachricht rebroadcastet. Die Kernimplementierung liegt in FloodingRouter.cpp und erfordert keine Routing-Tabellen oder zentrale Koordination.

Seit Firmware-Version 2.6 ergänzt ein Next-Hop-Routing speziell für Direct Messages (punktuelle Nachrichten) das Flooding, bleibt aber vollständig rückwärtskompatibel. Zunächst wird die Nachricht per Managed Flooding versendet; anhand von Rückmeldungen wie ACKs, NodeInfo oder Traceroutes lernt der Sender den besten Relay-Knoten und trägt dessen ID in den unverschlüsselten Header (Next-Hop-Byte) ein. Nachfolgende Pakete werden dann nur noch von genau diesem Knoten weitergeleitet, was Airtime und Kollisionen massiv reduziert. Bei Topologieänderungen, asymmetrischen Verbindungen oder älterer Firmware fällt das System automatisch auf reines Flooding zurück – auch beim letzten Retransmissions-Versuch. Broadcasts bleiben unverändert beim klassischen Managed Flooding, sodass das gesamte Protokoll ressourcenschonend und ohne zusätzlichen Overhead für Low-Power-Geräte funktioniert.

Meshtastic verwendet ein hybrides Flooding + Adaptive Routing. Jedes Paket enthält eine Hop-Limit (max. 7), eine Packet-ID und eine Timestamp.

Routing-Protokoll in Aktion

⚖️ 4. LoRaWAN vs. Nova Aeris Mesh

LoRaWAN ist ein standardisiertes LPWAN-Protokoll mit sternförmiger Topologie, bei dem Endgeräte ausschließlich mit zentralen Gateways kommunizieren, die über Internet mit einem Network-Server verbunden sind. Es ist stark auf stationäre IoT-Anwendungen mit extrem niedrigem Datenaufkommen ausgelegt und nutzt Mechanismen wie Adaptive Data Rate (ADR), bestätigte Übertragungen und verschiedene Geräteklassen (A, B, C), um Batterielaufzeiten von mehreren Jahren zu erreichen. Meshtastic dagegen basiert auf einer dezentralen Mesh-Architektur, bei der jedes Gerät gleichzeitig als Sender, Empfänger und Relay fungiert. Es arbeitet komplett off-grid ohne Server oder Internet-Backhaul und verwendet das offene Meshtastic-Protokoll für Textnachrichten, GPS-Tracking und Telemetrie.

Im direkten Vergleich bietet LoRaWAN eine deutlich höhere Skalierbarkeit und Netzwerkkapazität, da ein einzelnes Gateway Tausende von Geräten bedienen kann, während Meshtastic durch sein Managed-Flooding-Routing mehr Airtime verbraucht und bei sehr vielen aktiven Nutzern schneller an Grenzen stößt. Dafür ist Meshtastic wesentlich resilienter und flexibler in dynamischen oder infrastrukturlosen Umgebungen wie Bergen, Katastrophengebieten oder mobilen Einsätzen, da Nachrichten automatisch über mehrere Hops weitergeleitet werden. LoRaWAN eignet sich ideal für klassische Sensornetzwerke (Landwirtschaft, Industrie, Smart City), Meshtastic hingegen für direkte Mensch-zu-Mensch-Kommunikation und Off-Grid-Anwendungen wie bei Nova-Aeris.

LoRaWAN – Star-Topologie

Gateway

Nova Aeris Mesh – Voll-Mesh (live)

Kriterium LoRaWAN Nova Aeris Mesh (Meshtastic)
TopologieStarVoll-Mesh
InternetPflichtKomplett offline
Reichweite pro Hop5–15 km50–150 km
Multi-HopNeinJa – beliebig viele
Blackout / KatastropheFunktioniert nichtFunktioniert perfekt
Fazit: LoRaWAN ist für große zentrale Sensornetze geeignet. Für Drohnen, Berge, Rettung und Katastrophen ist nur ein dezentrales Mesh sinnvoll – genau das, was Nova Aeris bietet.

Häufige Fragen & Troubleshooting

1. Warum verbindet sich mein Node nicht?

Prüfe: gleicher Frequency (868 MHz), gleicher Region (EU_868), gleicher Spreading Factor und gleicher Channel-Name.

2. Wie lange dauert ein Paket?

Siehe Airtime-Tabelle oben. Bei SF12 und 51 Byte ca. 2,5 Sekunden – deshalb immer kleine Payloads verwenden.

3. Warum bricht die Verbindung in den Bergen ab?

Frequenzabhängige Dämpfung. Versuche SF11 oder SF12 und eine bessere Antenne (z. B. 5–8 dBi).

4. Darf ich beliebig oft senden?

Nein – in Europa gilt 1 % Duty Cycle (36 Sekunden pro Stunde). Nova Aeris warnt automatisch bei Überschreitung.

5. Wie lange hält die Batterie wirklich?

Bei normalem Betrieb (alle 5 Minuten ein Paket) halten die Handhelds 48–72 Stunden. Mit Deep-Sleep-Optimierung und SF12 sind 5–7 Tage realistisch.

6. Beeinflusst die Flughöhe bei Drohnen die Reichweite stark?

Ja, extrem. Ab 100–200 Metern Höhe steigt die Reichweite oft auf 60–120 km, da Line-of-Sight-Verbindungen möglich werden und Bodenreflexionen wegfallen.

7. Kann ich mehrere unabhängige Mesh-Netze gleichzeitig betreiben?

Ja. Über unterschiedliche Channel-Namen oder separate Pre-Shared-Keys können mehrere komplett getrennte Meshes auf derselben Hardware laufen.

8. Wie sicher ist die AES-256 Verschlüsselung in der Praxis?

Sehr sicher. Die Verschlüsselung erfolgt End-to-End auf Payload-Ebene. Ohne den korrekten Key sind die Daten auch für Zwischen-Nodes unlesbar.

9. Welche Antenne bringt die beste Reichweite?

Für maximale Reichweite empfehlen wir 5,8 dBi oder 8 dBi Antennen mit gutem Groundplane. Bei Drohnen sind flexible 3–4 dBi Antennen oft die bessere Wahl.

10. Wie führe ich ein Firmware-Update durch?

Über die Nova Aeris App per Bluetooth oder mit dem offiziellen USB-Flasher-Tool. Wichtig: Alle Nodes sollten immer dieselbe Firmware-Version haben, um Kompatibilitätsprobleme zu vermeiden.