Ich glaube das ist schon cool so "Wie findest du dein Modell, das macht bei mir LOTAR"

Zitat:

---

Original geschrieben von AchimO

Jetzt soll das Ding einen Namen bekommen:

Was haltet ihr von LOTAR: LoRa Tracker with Altitude Estimation for Rocketry ?

Gruß Achim

---

Trifft meinen Humor, dafür!

Aber Höhenmessung? Habe ich noch eine ältere Variante oder wie funktioniert das? Ich bekomme nur Koordinaten angezeigt.

Klasse Idee.

War wohl nicht so gut. Besser:

LOTAR: LoRa Tracker with Apogee Indication for Rocketry ?

Höhe kann er natürlich nicht. Nur Apogee. Mit allen Ungenauigkeiten, die GPS mit sich bringt. Ist aber momentan noch experimentell. Bei Ralfs Flug zeigte er etwas über 1000, ich glaube 1057- an. Kann - da von GPS ermittelt - immer nur ein Anhaltspunkt sein.

Gruß Achim

Vielleicht belassen wir es auch bei LoRa-Tracker bzw. LoRa-Tracking und nennen nur das Protokoll so. Irgendwann werde ich auch noch das Protokoll ins Netz stellen, wenn es sich so weit stabilisiert hat.

Heute morgen kam mir noch eine gute Idee für das Einstellen der ID, wenn wir über die mit Jumpern maximal mögliche 15 hinauskommen. Das Stichwort heißt "Prägung". Der Tracking-Empfänger wird dabei zum Sender und prägt dem Tracking-Sender, der dann Empfänger ist, seine ID auf. Ich nenne das Prägung, weil danach die Sender (die kleinen Gänse) dem Empfänger (der Gänsemutter) folgen.

Also so ähnlich wie man bei DECT ein neues Telefon einbindet. Etwaige Patente werden da wohl ausgelaufen sein.

Mit der Prägung vereinfacht sich die Einstellung erheblich und man kann sich dabei nicht vertun.

Die ID 0 reserviere ich. Durch Einstellung von ID=0 auf dem Empfänger ergäbe sich eine einfache Möglichkeit, das Belauschen des gesamten Datenverkehrs zu ermöglichen. Eine entsprechende Software auf dem Empfänger natürlich vorausgesetzt.

Gruß Achim

Geändert von AchimO am 05. Juni 2025 um 11:01

Zitat:

---

Original geschrieben von AchimO

.....................

Höhe kann er natürlich nicht. Nur Apogee. Mit allen Ungenauigkeiten, die GPS mit sich bringt. Ist aber momentan noch experimentell. Bei Ralfs Flug zeigte er etwas über 1000, ich glaube 1057- an. Kann - da von GPS ermittelt - immer nur ein Anhaltspunkt sein.

Gruß Achim

---

Hallo Achim,
den Flug den Du meintest ging lt. Altimax auf 989m, Lora hat 1057m angezeigt, also ausreichend präzise .
Die Lora Einheit war die, die das GPS nach oben ausgerichtet hat.
Die andere Lora-Einheit mit dem GPS quer zur Flugrichtung hat bei zwei Flügen keine Höhe angezeigt.
Soll aber nicht heißen, dass das nicht nur Zufall war.
Ich bin rund um zufrieden mit dem System.

Gruß Ralf

Hallo Achim

Ich habe mich letzte Nacht endlich mal durch deine vielen Seiten LoRa Thematik gelesen. Sehr beeindruckt, da hast du wirklich viel Energie und Gehirnschmalz reingesteckt und anscheinend funktioniert es auch in der Praxis richtig gut.

Durch dein Projekt have ich jetzt echt viel über LoRa gelernt. Was mir noch etwas schleierhaft ist, wie die Pakete genau aufgebaut sind. Ich hatte mir mal deinen "RATTLE Standard" angeguckt, aber da stand auch nicht alles drin, insbesondere wie die Präambel und Header aussehen, und mittlerweile machst du es ja wohl auch komplett anders.

Anfangs war dein Plan doch, dass jeder Tracker eine eigene Funkfrequenz bekommt, oder nicht? Nun hast du die IDs, das ist also eine Software-Selektion? Dazu brauchst du ein Schema, mit dem zuerst LoRa Tracker Pakete von anderen LoRa Diensten getrennt werden, und dann wiederum nur Pakete weiterverarbeitet werden die die richtige ID haben.

Im Prinzip kann ja jedes andere LoRa Modul das einfach in der Gegend ist und von einem völlig Unbeteiligtem stammt jederzeit dazwischenfunken. Das dürfen die, und dagegen kann man sich nicht wehren. Das soll man ja auch gar nicht. Das Konzept des time-domain Multiplex mit sehr geringem Duty Cycle und wenigen Kanälen drückt ja gerade aus, dass die Kanäle dann von vielen Sendern gleichzeitig bzw. zeitversetzt genutzt werden sollen. Also muss man damit klarkommen. Dazu musst du dir ja selber irgendwie einen Payload-Header basteln und den nach Empfang auch wieder anlysieren.

Ich hab in der Vergangenheit einiges mit anderen Funkmodulen on Hope RF gemacht, gerade mit dem RFM69 und RFM73, auf 433MHz und 2.4GHz. Die arbeiten intern schon mit Addressierung und bidirektionaler Kommunikation, falls erwünscht. Viele Module können auf der selben Frequenz arbeiten, jedes hat eine eindeutige Adresse, eine Nachricht geht immer von einer Quell- zu einer Zieladresse (außer Broadcast), wenn die Empfangsadresse im Header eines Paketes nicht passt hört der Empfänger gar nicht weiter zu, und es ist sogar vorgesehen, dass der Empfänger den korrekten Eingang bestätigt und der Sender es ansonsten nochmal versucht.

Für die niedrige Bandbreite und die Tracking-Anwendung macht die Empfangsbestätigung natürlich keinen Sinn. Nach meinem bisherigen Verständnis läuft LoRa aber immer im Broadcast, es wird also jedes beliebige Paket immer von allen Empfängern empfangen. Für deinen Tracker bedeutet das, dass du im Prinzip eine ganze Menge Müll empfangen könntest, der gar nicht für deinen Empfänger bestimmt ist. Das musst du irgendwie aussortieren. Wie machst du das?

Und hat LoRa eigentlich ein "Listen-before-Talk" eingebaut? Bei dem RFM-73 ist das der Fall, es wird erst gehorcht ob der Kanal frei ist, bevor ein Paket losgeballert wird. Das ist natürlich der erste Schritt um Paketkollisionen zu vermeiden.

Ist auf jeden Fall ein cooles Projekt und durch die ganzen Informationen hier habe ich jetzt eigentlich genug gelesen um mal meine eigenen Module auszupacken. Falls du aber doch nochmal eine Dokumentation schreibst wäre das natürlich auch noch super hilfreich.

Alles Gute
Schmidti

Hallo Schmidti,

danke, dass du dich so intensiv mit dem Thema beschäftigt und ausführlich kommentiert hast.

Ja, von dem "RATTLE Standard" habe ich mich insoweit entfernt, als ich festgestellt habe, dass das Interesse und der Bedarf eher beim Tracking - insbesondere dem Wiederfinden der Rakete -, als bei der Telemetrie liegt.

"RATTLE" wird dabei nicht ausgeschlossen, sondern eher noch erweitert.

Der Ausgangspunkt ist der durch die Behörden festgelegte Duty Cycle für das ISM-Band von 868 MHz von 1 Prozent. Auf 433 MHz gibt es den nicht, aber da ist sicher mehr los und die Sendeleistung ist stärker begrenzt als bei 868 MHz. Auf 868 MHz tummelt sich vor allem auch die Autoindustrie mit Türschlüsseln usw. Holger, ein Raketenfreund, der auch auf dem RJD war, verwendet z. B. 433 MHz. Wir kommen uns da nicht in die Quere, was beim fehlenden Duty Cycle problematisch werden könnte. Mir ist also der Duty Cyle auf 868 MHz gar nicht so unlieb.

LoRa versus LoRaWAN: LoRaWAN hat ein eigenes Sync-Wort; ich verwende das default LoRa Sync-Wort. Damit bekommen wir von LoRaWAN schon mal gar nichts mit. LoRaWAN hat auch einen noch restriktiveren Duty Cycle als der von der Bundesnetzagentur vorgegebene. LoRaWAN ist vor allem in den Städten verbreitet, nicht so sehr auf dem flachen Land, wie man auf deren Karte sehen kann. Nach meiner Einschätzung wird sicher mehr LoRaWAN verwendet als LoRa. Auf Flugtagen haben sich da jednfalls noch keine Konflikte ergeben.

Präambel und Header: Sind default, nichts spezielles.

Mein Tracking-System verwendet nur den Kanal 7 (im Sinne von LoRaWAN). Die Verbindung ist connection-less, arbeitet also sozusagen nur mit Datagrammen. Dass der Empfänger Daten vom Sender empfängt, erkennt man daran, dass beim Empfänger eine grüne LED aufblitzt und sich etwas auf dem Display tut. Eine Connection ist also gar nicht nötig, ich wage sogar die Behauptung: Gar nicht sinnvoll. Liegt die Rakete einmal im Raps- oder Maisfeld, bzw. wie beim RJD 2025 häufig im Erbsenfeld, werden auf die Entfernung Wiederholungen auch nicht viel bringen. Eher kann man darauf bauen, wieder etwas empfangen zu können, wenn man sich der Rakete weiter genähert hat.

Zum Thema "Listen-before-Talk": Das LoRa-Chip kann es wohl, ich weiß aber nicht, ob es die Library kann. Bei LoRaWAN gibt es so etwas wohl. LoRaWAN hat ja auch so etwas wie eine Connection. Die Autoschlüssel werden das vermutlich nicht machen. So befinde ich mich in guter Gesellschaft, wenn ich darauf verzichte. Für unsere Anwendung spielt es keine Rolle: das nächste Paket kommt bestimmt.

Paketkollisionen: Was ich mache, ist folgendes: Sind mehrere Sender aktiv, könnte es passieren, dass sie sozusagen synchron laufen, also immer wieder zu gleicher Zeit senden und danach die gleiche Zeit wegen des Duty Cycle abwarten. Daraus kämen sie dann nicht heraus. Daher verzögere ich das Senden immer um eine kleine Zeiteinheit zufallsbedingt (die Zufälligkeit leite ich aus der geographischen Position ab).

Der Verzicht auf "Listen-before-Talk" mag vielleicht etwas "rustikal" sein. Ist aber für unsere Zwecke völlig ausreichend.

Aufbau der Pakete Es gibt nur 4:

ID, "R", Voltage
ID, "O", HDOP
ID, "A", Apogee
ID, "P", Latitude, Longitude

ID: 1 Byte Identifier
Voltage: Spannung des Senders, mit 10 multipliziert und in unsigned int gewandelt (Empfänger wandelt es zurück)
HDOP: liefert der GPS-Empfänger, mit 1000 multipliziert und in unsigned int gewandelt (Empfänger wandelt es ebenfalls)
Apogee: Apogee als unsigned int in Meter
Latitude, Longitude: jeweils float (Genauigkeit float reicht für unsere Anwendung)

Es wird folgendes geprüft:
- hat ein Paket ein falsches CRC, wird es verworfen
- hat ein Paket die falsche ID (also nicht die auf dem Empfänger eingestellte), wird es verworfen
- hat ein Paket nicht den Typ "R", "O", "A", "P", wird es verworfen

Ich habe eine Weile überlegt, ob man zur zusätzlichen Prüfung noch ein 2-byte-CRC anhängen sollte, habe es aber fallen gelassen. Unabhängig davon: Das LoRa-Paket hat ja auch ein CRC, was ich (s. o.) prüfe.

Ich hoffe, damit ist es etwas klarer geworden. Gerne bleibe ich in der Diskussion.

Viele Grüße
Achim

Hallo Achim,

herzlichen Dank für deine ausführliche Antwort!

Zitat:

---

Original geschrieben von AchimO
Präambel und Header: Sind default, nichts spezielles.

---

Tja, vielleicht liegt hier ja der Hase im Pfeffer. Auf welchen Standard beziehst du dich hier? Hast du eine entsprechende Dokumentation? Ich habe nämlich keine richtige gefunden.

Wenn man z.B. in das Datenblatt des RFM95W schaue (Kapitel 4), ist dort die Paketstruktur von LoRa beschrieben, allerdings nur auf der PHY-Ebene. Die Präambel hat eine einstellbare Länge von 10,25 bis 65539,25 Symbolen. Der Header, falls er denn genutzt wird, hat 20 Bit, enthält aber nur die Länge des Paketes, die Coding-Rate und ob ein CRC vorhandne ist. Das wars.

Ein richtiges "Sync-Wort" finde ich in der Beschreibung des LoRa-Paketes nicht. Die Sequenz in der Präambel ist immer gleich, nur unterschiedlich lang um dem Empfänger mehr oder weniger Zeit zu geben sich zu sznchonisieren. Also entweder habe ich ein Brett vor dem Kopf, oder du nutzt über dem reinen LoRa-PHY-Standard eine MAC- oder Application-Ebene die z.B. ein Sync-Word enthält. Aber auch aus dieser Beschreibung des LoRaWAN-Protokollstacks werde ich nicht schlau, was davon du genau nutzt.

So wie du es jetzt beschreibst, und angenommen du bleibst bei der reinen LoRa-PHY-Ebene, hast du die ID und den Payload-Identifier zur Identifikation gewollter Pakete. Es ist nicht unmöglich, dass andere Pakete zufällig genau so beginnen, aber unwahrscheinlich, das ist wahrsheinlich schon ok. Wenn du das so macht, ist mir das halbwegs klar.


Ganz unabhängig davon finde ich deine Paketstruktur, was die Übertragung angeht, etwas ineffizient. Du hast ja selber den Air Time Calculator angegeben, die Formel steht aber auch im Datenblatt. Ist ein bisschen kompliziert und die genaue Bedeutung aller Terme habe ich auch noch nicht ganz duchschaut, ich bin auch sicher, dass da eine kleine Ungenauigkeit oder Inkonsistenz din sein muss, aber sie scheint ja weitgehend zu stimmen. Jedenfalls sieht man daran, dass man ziemlich viel Overheads hat. Mit ein bisschen rumspielen kommt man darauf, dass die Overheads etwas über 17 Bytes Payload entsprechen.
Ein "Service-" oder "Byte-Identifier" sowie eine Sender-ID, was praktisch einen sehr kurzen Payload-Header darstellt, gehören ja eigentlich auch zu den Overheads. Damit wird das Nutzdatenverhältnis nochmal schlechter. Wenn man also nur einen Spannungswert überträgt, hat man im Prinzip über 91% Overheads. Für die Koordinaten sind es auch immernoch 70%.

Mein Ansatz wäre, um Overheads zu minimieren, alle Daten simultan zu senden. Solang die Overheads dominieren, ist es praktisch kostenlos mehr Payload anzuhängen. Ein Status Byte, Anzahl Stalliten und HDOP, Position, Höhe, und Spannung kann man in 14 Bytes unterbringen. Dazu drei Bytes als Service-Identifier und ID. Wenn man mindestens 10Bit für die ID nimmt, kann man jedem Sender bei der Produktion eine feste und eindeutige Sender-ID ins EEPROM brennen. Jedenfalls hätte man so etwa gleich viel Payload wie Overhead und in jedem Datagramm immer alle Informationen. Da alle Pakete gleich aussehen, kann man sich dann sogar den Header sparen, wäre in unter 45ms mit der Übertragung fertig und könnte alle 5 Sekunden einen vollständigen Status übermitteln. Nur so als Idee...

Alles Gute und noch ganz viel Erfolg beim Tracken!

Schmidti

Hallo Schmidti,

da hast du im Prinzip natürlich Recht: Datensparsamkeit ist sinnvoll und auch das Verhältnis von Overhead zu Nutzdaten gilt es zu beachten.

Wenn aber
- die Spannung nur interessiert, wenn sie sich vom vorherigen (dargestellten) Wert unterscheidet,
- HDOP nur bis zum Start der Rakete interessiert,
- nicht die laufende Höhe, sondern nur das Apogee übertragen wird (kann allerdings mehr als einmal passieren wegen Änderung in der Satellitenkonstellation),

sieht die Sache schon wieder ganz anders aus.

Was die Spannung betrifft, habe ich die Erfahrung gemacht, dass eigentlich nur eine Nachkommastelle interessant ist. Macht man den Vergleich auf zwei Stellen hinter dem Komma, führt das wegen der dadurch häufigeren Schwankungen in beide Richtungen zu unnötig vielen Übertragungen.

Was das Sync-Wort angeht, so scheint es sicher, dass LoRaWAN 0x34 verwendet. Für nicht-LoRaWAN ist manchmal von 0x12 die Rede, manchmal auch für SX127x von 0x1424. Das verstehe ich aber auch nicht ganz, denn eine Abhängigkeit vom Chip würde ja dazu führen, das verschiedene Chips sich gegenseitig nicht verstehen. Kann aber auch sein, dass hier die Modulationsarten vermischt wurden.

Siehe diese Diskussion.

Man müsste wohl mal einen Test machen mit expliziter Vorgabe des Sync-Wortes.

Viele Grüße
Achim

Geändert von AchimO am 06. Juni 2025 um 21:31