LoRa-APRS – Funkkollision

Alles Problemlos, oder doch nicht?

Der Vorteil von LoRa ist so vielfältig, dass eine Aufzählung sehr umfangreich ist.

  • Zuerst der Preis für ein Tracker oder iGate
  • Konfiguration der Baugruppen, alles auf den Boards vorhanden
  • Leichte Installation der Software (Webflasher)
  • iGate oder Tracker entscheidet die Software
  • Kompakte Bauform
  • Akkubetrieb mit integrierter Ladeautomatik
  • Geringes Gewicht
  • Sendeleistung liegt im Milliwattbereich (Jedermannsfunk)
  • Sendefrequenz für jeden nutzbar
  • und die enorme Funkreichweite
  • und noch viel mehr…

Alle diese Leistungsmerkmale ermöglichen eine unkomplizierte Inbetriebnahme.
Also los, soviel iGate wie möglich. Aber genau da beginnt das Problem.

Unsere bisherige Erfahrung im Relaisbetrieb lautet:

„je höher der Standort, je größer der Antennengewinn und höher die Sendeleistung desto besser…“

Dies gilt leider nicht für LoRa. Euch ist bestimmt schon aufgefallen das Mobilfunkmasten ca. alle 7 Kilometer aufgebaut werden und die Antenne nur auf der Masthälfte hängen. Die LoRa iGate Betreiber haben das gleiche Problem. Und das Problem heißt „Funkkollision“[4]. Wenn viele auf der gleichen Frequenz (433.7750 MHz) senden, stören sie sich gegenseitig. Also müssen einige Regeln gelten damit das Problem minimiert wird.

Ich orientiere mich am Bericht von DC1NF[2].

Eine LoRa Aussendung dauert ca. 3,6 Sekunden[3] bei einem Spreading Faktor von 12. Er nimmt an, dass eine Station je Minute ein Signal sendet. Dann könnten theoretisch 60/3,6 = 17 Teilnehmer konfliktfrei funken. LoRa hat aber kein koordiniertes Zugriffsverfahren. Das heißt, jeder sendet wann er will. Theoretisch liegt hier eine 30 prozentige Kanal Belegung vor. Beim Betrachten der CRC Error Statistik eines iGates ist deutlich die Problematik zu sehen. Beim iGate DBØBRB liegt die Rate für „Erfolgreiches Decodieren“ bei 85.48%. Das heißt aber auch 14 Prozent fehlerhafte Meldungen.

Je mehr Teilnehmer hinzukommen, kommt es zu verstärkter Funkkollision und die CRC Fehlerqoute steigt.

Und bei einem exponierten Standort sind deutlich mehr LoRa Teilnehmer gleichzeitig auf der Frequenz zu hören, weil der Empfangsbereich auch viel größer ist.

Eine Lösung zur Minimierung ist das deaktivieren der Funktion Digipeat am iGate. Wozu muss ein fester iGate sein Standort und empfangene Signale mehrmals melden?


Die Funktion „Digipeat“ würde die Funkkollision noch zusätzlich verstärken. In der Software (Webflash) kann man das „Digipeaten über RF“ aktiveren, sollte man aber nicht. Aktivieren sollte man hingegen die Funktion „Send beacon via APRS-IS“. Dann wird der Standort des iGates übers Internet, und nicht über Funk gesendet. Der eingestellte Beacon-Intervall von 15 Minuten reicht hierbei völlig, weil die APRS Karten auch mit diesem Intervall arbeiten.

Eine weitere Lösung ist der Einsatz von kleinen Empfangsgebieten bzw. „niedrigen“ Antennen abhängig von weiteren iGates-Standorten. Warum muss ein bereits versorgter Empfangsbereich auch noch abgedeckt werden?

Quelle: aprs-map.info

Ein kleines Empfangsgebiet empfängt nur wenige „durchfahrende“ iTracker und die Funkkollision ist geringer.

Damit entsteht aber wieder ein Problem. Denn so viele iGates können wir gar nicht aufbauen um unser ländliches Gebiet abzudecken. Darum müssen wir auch weiterhin exponierte Antennenstandorte, wie zum Beispiel DB0BEL, haben.

Nur nicht im Städtischen Bereich, wo auch mehr OM’s wohnen und auch mehr iTracker im Einsatz sind.

Also ein gutes Verhältnis ist erfolgreicher. Bei der Beratung von LoRa-iGate Betreiber sollte dieses Thema angesprochen werden. Trotzdem sollte sich jeder mit LoRa beschäftigen, der Interesse an dieser modernen Datenübertragung hat und auch ein iGate aufsetzen.

Die Webseite lora-aprs.live erfasst viele Informationen, so auch die Fehlerquote.

Links zur Statistik:

https://lora-aprs.live/stats.html

https://lora-aprs.live/stats/web.html

CRC Error 102 Counts
100 Fehlerhafte Signale in 3 Tagen empfangen

Wechselnde Übertragung des LoRa-Signal

Warum übertragen andere iGates meine LoRa-Daten zum APRS-Server obwohl ich doch näher am iGates bin. Das zu beschreiben ist gar nicht so einfach. Aber ich versuche es mal mit einem Gleichnis[1].

Stellt euch vor ihr steht im Zentrum eines Stadions und sendet ein LoRa-Standort-Signal. Alle Zuschauer empfangen dein Signal und senden mit ihren Internetgeräten (sagen wir mal, das Gerät heißt iGate) dein Signal weiter zum APRS Server. Aber nicht jeder ist gleich schnell mit dem senden. Hier geht es um Millisekunden und die Qualität des Signals.

Und nun kommt der APRS Server zum Einsatz. Wenn er bereits ein komplettes Signal (ohne Fehler) mit Rufzeichen und Standortkoordinaten erhalten hat, ignoriert er alle weiteren Signale die der Server erhält. Und so entsteht das Phänomen, dass man zwar dichter am iGates ist, aber ein anderer, weiter weg liegender iGate, mein Signal überträgt. Empfangen haben mehrere „Zuschauer“ (iGates), aber nur einer ist der schnellste beim Senden. In der nächsten Millisekunde kann es genau anders sein. Also liegt kein Problem mit euren iGates vor und ihr müsst nichts verbessern.


Natürlich gibt es noch weitere Faktoren die ein Signal stören (Reflektionen, Temperatursensoren, Fernbedienungen usw.). Schließlich senden wir auf Frequenzen die für jeden freigegeben sind.

[1] Gleichnisse hinken immer

[4] DC1NF

[2] Dieter, DC1NF

[3] Airtime bei 100 Byte Paketgröße

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert