Im Thread „Telemetrie mit LoRa“ habe ich beschrieben, wie LoRa im Raketenbereich zum Einsatz kommen kann, wohlgemerkt LoRa, nicht LoRaWAN.

Das wird dem einen oder anderen zu komplex und zu teuer vorgekommen sein. Auch erfordert die Sprachausgabe einen Lautsprecher, der im freien Feld schon eine gewisse Leistung haben muss.

Daher die Frage: Geht es nicht auch einfacher?

So habe ich überlegt, wie es wäre, wenn man auf die Telemetrie verzichtet und nur die Lokalisierung der Rakete nach der Landung durchführt. Hier das Ergebnis:

Man benötigt einen Prozessor mit LoRa-Modul, der auch eine Anzeige hat. Das wäre wie beim Telemetriesystem der CubeCell AB02 von Heltec. Der soll in einem einfachen Gehäuse untergebracht sein. Die Bedienelemente sind dann dessen Anzeige, ein Ein-/Ausschalter und ein Taster, um die Anforderung der GPS-Koordinaten der Rakete auslösen zu können. Des weiteren wäre noch eine Art von Adressierung sinnvoll, um ggf. mehrere Raketen, die aktuell gesucht werden, unterscheiden zu können. Dazu soll ein Jumperfeld dienen. Eine Antenne ist auch noch anzubringen und ein LiPo-Akku versteht sich ja von selbst.

Siehe da, der Prozessor wird in einer kleinen Schachtel aus PE geliefert, die wir als Gehäuse nutzen können, denn viel Platz braucht man nicht.



Zwar ist die Schachtel durchsichtig, aber auf der Oberseite ist ein Etikett aufgeklebt, was kaum zu entfernen ist. Also umdrehen und Ober- und Unterseite vertauschen.

Wie muss nun die Elektronik in der Rakete aussehen?

Klar, ein Prozessor muss sein, ein LoRa-Transceiver und – separat angeschlossen – ein GPS-Modul. Außerdem noch ein Spannungswandler und die üblichen Bauelemente wie Widerstände, Kondensatoren usw., dazu wie oben ein Jumperfeld für die Adressierung und natürlich ist auch ein LiPo nötig.

Zur Unterscheidung habe ich die Elektronik in der Rakete “LoRa-Tracker“ und die Schachtel mit ihrem Inhalt “LoRa-Locator“ genannt. Wenn jemand bessere Namen hat, bin ich gerne dafür offen.

Hier ist gezeigt, was auf der Anzeige zu sehen ist, im wesentlichen ein Subset des Telemetriesystems:



Wir sehen in der oberen Zeile bei “L:“ die lokale Spannung, hier 4,1 Volt, mit “R:“ die remote Spannung, hier also 3,8 Volt. Nach dem Einschalten kann man also erkennen,
- ob eine Verbindung besteht und
- ob der Akku in der Rakete ausreichend geladen ist (hier nicht der Fall!).

Danach wird die Anzeige der Spannung des Tracker-Akkus nicht mehr aktualisiert – das wäre ja wieder Telemetrie.

In der Zeile darunter sehen wir die auf dem Locator eingestellte ID (also die Adressierung, von der ich oben gesprochen habe), danach wie beim Telemetriesystem RSSI (ein Maß für die Empfangsfeldstärke) und SNR (Signal-/Rauschverhältnis).

Darunter wie gehabt die geographische Breite mit “B:“ und die geographische Länge mit “L:“ gekennzeichnet. Jetzt sind diese beiden Werte aktualisiert und wir haben einen Fix bekommen:



Außerdem ist die Spannung des Reketenakkus verschwunden. Stattdessen wird ein Wert “HDOP“ angezeigt. Was hat es damit auf sich? HDOP ist die Abkürzung für “Horizontal Dilution Of Position“, ein Maß für die erreichbare Genauigkeit der Positionsbestimmung. Vereinfacht gesagt, hat es etwas damit zu tun, ob je zwei Satelliten mit dem Punkt, an dem sich die Rakete befindet, etwa ein rechtwinkliges Dreieck bilden (gut!) – dann schneiden sich Kreisbögen um die Satelliten etwa im rechten Winkel – oder ob Kreisbögen um die Satelliten am Ort der Rakete schleifende Schnitte haben (schlecht!). Es bleibt dem Leser überlassen, bei Interesse hierzu genauere Informationen einzuholen, etwa bei Wikipedia. Ein niedriger Wert von HDOP ist gut. Ein sehr guter Wert ist 1, Werte von 2 werden als gut angesehen. Es können auch noch bessere Werte unter 1 auftreten.

Nach meiner Erfahrung, die ich mit verschiedenen GPS-Modulen und dem Testprogramm u-center von U-Blox gemacht habe, dauert es eine Weile, bis der GPS-Empfänger genügend Satelliten “sieht“ (bei mir im Haus – also erschwerte Bedingungen – einige Minuten) und sich ein guter Wert für HDOP einstellt. Daher kann die Beobachtung des HDOP-Wertes dazu dienen, den frühest sinnvollen Zeitpunkt für einen Raketenstart zu bestimmen. - Natürlich kann der Wert auch wieder steigen, meist aber nicht sehr stark. Da die Tracker-Elektronik keinen barometrischen Höhenmesser hat, weiß sie nicht, wann die Rakete tatsächlich gestartet wurde. Sie sendet daher munter weitere Werte von HDOP.

Links neben der Anzeige des Locators ist eine lichtstarke LED. Sie zeigt durch einen kurzen Blink-Impuls (Farbe: grün) an, wenn etwas empfangen wurde. Drückt man nun am Locator die Taste, so wird an den Tracker die Anforderung einer Position gesendet, erkennbar auch dadurch, dass die LED kurz rot leuchtet. Diese LED ist sehr hilfreich, denn wegen der Anforderung an den einzuhaltenden “duty cycle“ erfolgt ein Senden nicht immer sofort, sondern ggf. verzögert. Nach dem Senden eines Pakets gibt es bei unseren Paketlängen eine einzuhaltende Wartezeit in der Größenordnung von etwa 3 bis 4 Sekunden.

Wie kann man also in der Praxis vorgehen? Man hat nach dem Flug (hoffentlich) die Rakete landen sehen und weiß daher die Richtung, in die man gehen muss. Entweder man hat noch Kontakt zur Rakete – erkennbar daran, dass von dort weitere HDOP-Werte gesendet werden (LED grün blinkend in regelmäßigem Abstand): Dann kann man durch Druck auf den Taster eine Position anfordern. Das kommt bei bestehender Verbindung durch, da die Antwort darauf mit höherer Priorität behandelt wird als das Senden der HDOP-Werte. Oder man hat keinen Kontakt mehr zur Rakete, also kein regelmäßiges grünes Blinken: Dann kann man bei weiterer Annäherung erneut eine Position anfordern, diese dann ins Smartphone eingeben und navigieren.

Was sind die Vorteile?

Im Prinzip läuft das ja ähnlich ab wie bei einem GPS-Tracker mit Mobilfunkverbindung.
Nur sind wir hier nicht auf den Mobilfunk angewiesen:
- keine SIM-Karte in der Rakete nötig
- und kein Abo
- natürlich auch kein Mobilfunkempfang nötig – daher machen wir LoRa und nicht LoRaWAN!

Was die Bedienung angeht:

Beim LoRa-Locator/-Tracker:
Taster drücken reicht. Position vom Display in die Navigations-App auf dem Smartphone eintragen

Beim GPS-Tracker:
- (ggf. vorgefertigte) SMS an den Tracker in der Rakete schicken und als SMS empfangene Position in die Navigations-App kopieren
- oder laufend Positionen in der Karte angezeigt bekommen (Kosten?)

Kleiner Wermutstropfen: Die Anzeige des Locators ist im hellen Sonnenlicht schwer ablesbar, wie sich gezeigt hat. Man muss das Display abschatten, um eine Position auslesen zu können.

Wie ist der aktuelle Stand? Bisher konnte ich die Software gut testen mit einem Breadboard-Aufbau (Locator) bzw. vorhandener Hardware aus dem Telemetriesystem. Jetzt warte ich auf Platinen.

Ach so: Interessant ist ja die Frage, wie sich das mit dem Telemetriesystem (RATTLE) verträgt oder ob es da Konflikte geben kann. Davon später mehr.

Gruß Achim

Geändert von AchimO am 04. Dezember 2023 um 16:53

Ich habe mir noch eine Vereinfachung überlegt:
Der Tracker sendet jetzt im Wechsel immer HDOP-Wert und Position. Daher braucht der Locator nicht mehr zu senden. Das spart Platz und vereinfacht den mechanischen Aufbau des Kästchens, das jetzt nur noch
- die Elektronik
- den Ein-/Ausschalter
- den Akku
- und die Antenne
enthält.

Der Locator ist jetzt also nur noch ein Empfänger. Vereinfacht zusätzlich auch die Software, obzwar das bereits lief. Aber man weiß ja nie, wofür man den Speicherplatz, der reichlich vorhanden ist, noch brauchen kann.

Gruß Achim

Kannst du die tracking controller nach dem rattle standard programmieren?
Dann könnte man auch mit dem tracking Empfänger zumindest die tracking Daten der telemetrie Bauteile empfangen

Hallo Stefan,

bevor ich auf deine Frage eingehe, möchte ich erst einmal genauer beschreiben, wie der aktuelle Stand ist:

Im RATTLE-Standard sind ja 8 Kanäle für die Telemetrie definiert. Wenn man sich abspricht über die verwendeten Kanäle, gibt es da keinen Konflikt, auch weil ja zu einem bestimmten Zeitpunkt nicht viel mehr Raketen als die im Fokus stehende unterwegs sein können. Der Telemetriesender stellt ja kurze Zeit nach der Landung das Senden ein.

Wie ist es aber beim Tracking? Da können doch wesentlich mehr – und auch länger – Raketensuchende unterwegs sein. Und der Tracking-Sender sendet dauernd und zwar so lange, bis er ausgeschaltet wird.

Daher funktioniert dann die Absprache über die Kanäle nicht mehr so richtig. Deswegen habe ich mir für eine Erweiterung des RATTLE-Standards folgendes überlegt:

Die verschiedenen Datensätze werden bei RATTLE ja immer eindeutig über einen Großbuchstaben gekennzeichnet . I, A, B, L, P, usw. Datensätze, die im ersten Byte keines dieser festgelegten Zeichen enthalten, werden ignoriert. Man könnte daher die Tracking-Datensätze dadurch unterscheiden, dass man als erstes Byte eine binäre Adresse überträgt, deren Binärwert kleiner ist als die der in RATTLE bisher festgelegten Zeichen.
Auf dem Sender und dem Empfänger habe ich 4 Jumper vorgesehen, mit denen eine Adresse von 0 bis 15 festgelegt werden kann.

Ein Tracking-Datensatz hätte dann folgende Struktur:

Byte 0: Adresse / ID-Byte
Byte 1: Datensatz-Kennung (’P’ für Position, also Breite/Länge, ’O’ für HDOP)
Byte 2ff Daten

Ich habe Kanal 7 dafür genommen. Auf diese Weise können RATTLE-Telemetrie und Tracking koexistieren, ohne dass sie sich in die Quere kommen.

Das könnte natürlich auch als Erweiterung in RATTLE aufnehmen.

Nun zu deiner Frage:

Technisch wäre es kein Problem, mit dem Tracking-Empfänger auch die Telemetrie-Daten zu empfangen. Das wäre dann aber ein anderer Modus, in den man den Empfänger schalten müsste. Eine Umschaltung zwischen Telemetrie und Tracking z. B. über Schalter oder Jumper wäre das.
Macht es Sinn? Ich gebe zu bedenken, dass das Display – insbesondere die kleinen Zeichen – im hellen Sonnenlicht nur schwer ablesbar ist; daher hat mein Empfänger aktuell ja noch das e-paper-Display. Während des Fluges schaut man ja sowieso auf die Rakete und nicht aufs Display; daher ja auch die Sprachausgabe für die verschiedenen Ereignisse.

Gerne kannst du dir das auf einem der nächsten Flugtage anschauen. Der Platz für einen Jumper ist auf jeden Fall da, ohne dass eine Layout-Änderung erforderlich wäre, denn ich habe ja den Taster eliminiert.

Gruß Achim

Ich habe jetzt die Sache noch etwas vereinfacht:

Der Tracking-Sender (früher habe ich ihn LoRa-Tracker genannt) sendet jetzt immer im Wechsel
- seine Battereispannung
- den HDOP-Wert
- die Position

Der Tracking-Empfänger (früher hieß der Locator) sendet nichts mehr, sondern zeigt nur die empfangenen Werte für
- Remote Batteriespannung, also die des Senders
- den HDOP-Wert
- die Position des Empfängers
an, außerdem die lokale, also seine eigene Spannung.

Das hat den Vorteil, dass man den Empfänger zu beliebiger Zeit einschalten und auch aus- und wieder einschalten kann.

Der Empfänger:



Die Abmessungen sind 63 mm x 63 mm x 20 mm, also noch handlich für die Jackentasche.

Der Sender (hier mit GPS-Empfänger Beitian BN-180T:



Der Sender verbraucht ca. 60 mA mit dem Beitian-180T im Ruhezustand, beim Senden - was aber nur etwa 32 bis 42 ms im Abstand von 3,2 bis 4,2 s dauert (duty cycle 1%) - natürlich einiges mehr (schwer zu messen). Die Abmessungen der Platine sind 16,5 mm x 67 mm.

Ich habe noch eine Maßnahme zur Kollisionsvermeidung eingebaut. Sollten zwei Sender tatsächlich einmal im gleichen Takt senden, so kämen sie aus diesem Rhythmus nicht wieder heraus wegen des gleichen duty cycle. Ich verlängere daher beim Senden der Position die Wartezeit geringfügig um einen Zufallswert, den ich aus der Position (Länge und Breite) ableite.

Gruß Achim

Gruß Achim

Geändert von AchimO am 14. November 2023 um 21:21

Beim gestrigen Jahresendfliegen konnte ich die Trackinglösung auf der Roten Jahne testen. Als GPS-Modul diente dabei ein Beitian BN-220 GPS. Es war ein voller Erfolg! Nach Eingabe der Koordinaten führte mich die App Alf auf dem iPhone metergenau zur Rakete.

Dabei bekam ich zunächst einen Schreck, denn die letzten 4 Nachkommastellen der geographischen Breite waren alle 0! Aber das war reiner Zufall: Chance 1:10000

Auch stellte ich fest, dass der HDOP-Wert auch unter 1.0 liegen kann. Daher korrigiere ich die weiter oben gemachten Angaben.

Gruß Achim