Der Test hat folgendes ergeben:

Setze ich das Sync-Wort auf 0x12, bekommt der Empfänger wie gewohnt die Pakete, bei 0x34 nicht. Daraus schließe ich:

Die Library
- setzt entweder das Sync-Wort auf 0x12 explizit, was durch Angabe eines anderen überschrieben werden kann
- oder 0x12 ist das default Sync-Wort des SX127x, was durch Angabe eines anderen überschrieben werden kann

Gruß Achim

Hallo Achim,

tja, das mit dem Sync-Wort lässt sich wohl nicht klären. Ich hab jetzt den Überblick verloren, welches LoRa-Modul du letztendlich nutzt, aber in den Datasheets der gängigen SX1261/2, SX127X, RFM95W, etc. kommt der Begriff gar nicht vor.

Es gibt nur eine Päambel deren Länge man wählen kann, aber wenn man sich das Signal im Wasserfall Diagramm anguckt, sieht man, dass das mit gutem Grund eine recht stupide Symbolfolge ist.

Naja, egal, Hauptsache es funktioniert gut.

Beste Grüße

Schmidti

Hallo Schmidti,

ich möchte dich einladen, mit mir zusammen einen Standard für das Raketen-Tracking zu definieren. Wenn mehrere Leute mit LoRa unterwegs sind, was Raketen betrifft, wäre es nicht gut, wenn wir uns gegenseitig stören würden. Es sollte aus meiner Sicht daher das Ziel sein
- mindestens zu koexistieren
- oder gar zu kooperieren, z. B. den gleichen Empfänger verwenden zu können.

Wenn AGM und Solaris sich da zusammentun, hat das ja Gewicht.
Ich habe natürlich den „Klotz am Bein“, dass einige mein Teil bereits einsetzen. Ich muss daher auf Rückwärtskompatibilität, Migration usw. achten.

Was hältst du davon?

Gruß Achim

P.S.: Kann natürlich auch noch jemand dazustoßen.

Hallo Achim

ich weiß nicht, ob ich da der beste oder sinnvollste Partner bin. Ich habe mich bisher ja nur theoretisch mit der Thematik auseinandergesetzt. Meine Module sind noch eingeschweißt, und ob die jemals auf einer Rakete stecken werden ist sehr fraglich. Also mach ruhig was Du oder Andere denken! Aber hier trotzdem mal meine Gedanken.

Ich sehe eigentlich drei potentielle Probleme:

- Überlastung des Frequenzbandes und Paketkollisionen
- Störung durch freme LoRa Nachrichten
- Störung durch Nachrichten von LoRa Trackern, jedoch von anderen Sendern als dem eigenen

Dies würde ich folgendermaßen angehen:

- Der 1% Duty Cycle reduziert schonmal die Wahrscheinlichkeit für Frequenzüberlastungen. Ich könnte das jetzt ausrechnen, abhängig von der Anzahl der Sender die simultan den selben Kanal nutzen, aber bis etwa ein Dudzend Sender dürfte das unkritisch sein.
Vorraussetzung ist, dass zu zufälligen Zeiten gesendet wird. Aber darum hast du dich ja auch schon gekümmert! Es gibt auch für Mikrocontroller Code der Zufallszahlen erzeugt. Das muss man nicht vom GPS-Empfänger abhängig machen, der könnte ja mal ausfallen oder keinen Empfang haben.

- Um die LoRa-Tracker von fremden Paketen zu unterscheiden, würde ich jedes Paket mit einer spezifischen Bitfolge beginnen lassen. Diese "Service-ID" stellt also dar, dass es sich um ein Paket deines LoRa Tracking Systems handelt. Natürlich kann man nicht 100% ausschließen, dass fremde Pakete zufällig mit der selben Bitfolge anfangen. Je länger die Bitfolge ist, umso unwahrscheinlicher und man sollte die Service-ID so wählen, dass sie sich von allen anderen bekannten Payloadanfängen, insbesondere von LoRaWAN unterscheidet. Ich würde mich hier für eine 12 bis 16 Bit lange Folge entscheiden. Das sollte ausreichen um fremde Kontamination sehr selten zu machen.

- Um verschiedene Nutzer des LoRa Tracking Systems zu unterscheiden würde ich jedem produzierten Sender eine eindeutige UID einbrennen. Solange nur du die fertigst, ist das einfach. Ich würde auch hier zwischen 12 und 16 Bit nehmen und am Empfänger per DIP schalter einstellen. Jedes Paket hätte also einen 3 oder 4 Byte langen "Payload-Header", bestehend aus Service-ID und Sender-UID. Das sollte reichen um Störungen auf ein sehr geringes Maß zu reduzieren.

Prinzipiell könnte man auch sowas wie Message Authentication Code oder Message Integrity Check einbauen. In diesem Protokollstack ist sowas mit drin. Dazu muss man aber einen geheimen Schlüssel austauschen und es erzeugt noch mehr Overheads und Komplexität. Ich würde es sein lassen. Ist Overkill. Ich gehe nicht davon aus, dass jemand bösartig versucht den Tracker zu stören und einzelne zufällige Fehlerpakete kann man auch akzeptieren, weil sie einfach offensichtlich unplausibel sind.

Wie die Daten-Payload dann genau aussieht, was man wie überträgt, ist wieder eine ganz andere Frage. Aber solange sich verschiedene Implementationen nicht stören (z.B. mit unterschiedlicher Service-ID), ist das ja auch egal.

Soviel nur mal zu meinen Ideen. Aber ich sehe mich da eigentlich als Unbeteiligter und nicht als Autorität. Mach was du für richtig hälst!

Alles Gute
Schmidti