Hallo,

was macht der Raketeur in der Zeit, wo er keine Raketen starten kann? Richtig, entweder er baut neue oder er beschäftigt sich mit seinen Tools. Wobei man manchmal fast den Eindruck hat, dass für den einen oder anderen die Tools noch wichtiger sind als das Bauen.

Ich habe mich schon eine Weile gefragt, ob LoRa bzw. LoRaWAN für unsere Zwecke geeignet sein könnte. Wenn jemand zu LoRa (steht für Long Range) mehr wissen will, empfehle ich, im Netz nach "Andreas Spiess" und LoRa" zu suchen, ein Blogger, der sich damit schon eine Weile beschäftigt. Er kann das besser erklären als ich das je könnte.

Es handelt sich also um eine Übertragungstechnik, die durch eine sehr kleine Bandbreite hohe Reichweiten (bei geringen Datenmengen!) erreicht. In Europa steht dafür als ISM-Band der Frequenzbereich von 868 MHz zur Verfügung.

Dabei ist zu unterscheiden zwischen
- einem hierarchischen Netzwerk, in das Sensoren Daten liefern können, wie z. B. The Things Network
- und einer Punkt-zu-Punkt-Verbindung, also z. B. Rakete - Empfänger

Uns kommt ja entgegen, dass wir unsere Raketen
- meist im Flachland
- bei (hoffentlich) wenig Hindernissen wie Bäumen u. a.
starten, also bis auf den Moment der Landung im Sinne der Funktechnik "Sichtverbindung" zur Rakete haben, was günstig für die Reichweite ist.

Nun genug der Vorrede.

Ich habe mir also zwei LoRa32-Boards von Heltec über die üblichen Kanäle in Asien bestellt. Diese basieren auf einem ESP32-Prozessor, haben ein kleines Display, WLAN, BlueTooth, einen Transceiver mit LoRa-Chip, meiner für 868 MHz. Außerdem noch einen UBlox MV6 Empfänger für GPS; der kam immerhin aus Deutschland, daher schneller.

Diese Komponenten arbeiten alle mit 3.3 V und die Eingänge verabschieden sich bei höheren Spannungen, 5 V geht also nicht. Daher kam bei mir noch ein bereits vorhandener DC-DC-Wandler für 3.3 V zum Einsatz.

Der Vorteil vieler LoRa-Boards ist, dass sie über die Arduino IDE programmiert werden können. Leider liegt es mit der Dokumentation aber oft im Argen, so dass man ziemlich lange im Netz herumstochert, bis man alle Informationen zusammen hat. Aber es ist immer wieder bemerkenswert, was man alles beim Stochern so findet. Weiß man dann irgendwann, wie es gehen kann, ist es erstaunlich, wie einfach es ist.

So, nun konkret:



Auf dem bzw. am Steckbrett angeschlossen sieht man
- links den DC-DC-Wandler, der die Spannung von einem LiPo bekommt
- rechts das LoRa32-Board (Sender) mit Antenne
- darunter den GPS-Empfänger
Das Power-Pack dient zur Versorgung des LoRa-Boards

Unten das zweite LoRa-Board(Empfänger), versorgt vom PC. Dieser empfängt die Daten und zeigt folgendes an:
- den RSSI-Wert (Stärke des Empfangssignals)
- die aktuelle Höhe (nicht sehr genau, da vom GPS-Empfänger)
- geographische Breite
- geographische Länge

Hier nochmal als Nahaufnahme:



Mir ist natürlich klar, dass ein einfacher GPS-Tracker auch eine Ortung erlaubt, wenn man den entsprechenden Mobilfunkempfang hat. Aber was war doch oben gleich meine Anmerkung zu den Tools? Außerdem hat man hier noch weitere Möglichkeiten über eine Ortung hinaus.



Jetzt muss natürlich noch ein kleines Board erstellt werden, um die Komponenten im Sender besser anschließen zu können. Der Empfänger kann direkt von einem 1S-LiPo gespeist werden. Der braucht ein Gehäuse.

Fertig!

Was ist eure Meinung dazu?

Gruß Achim

Geändert von AchimO am 30. August 2020 um 17:16

Ziemlich cool, jetzt müsste man noch ein paar a/d kanäle haben dann könnte man Bordspannungen messen, und am Empfänger einen Sd-cardslot zum Speichern das Daten die ankommen.
Dann könnte man nach einem Flug schauen was los war, falls etwas schief ging.

Aber immer unter der Maßgabe, dass man nicht allzu viele Daten übertragen kann, wegen LoRa. Es gibt auch ein Lora Modem Calculator Tool; mit dem konnte ich mich aber bisher noch nicht recht anfreunden.

Die Restriktionen für Deutschland bzw. Europa sind, so weit ich das sehe:
- 25 mW maximale Sendeleistung
- Spreading Faktor maximal 6 (oder 7?)
- Duty Cycle 1%; das wird auf eine Stunde bezogen

AD-Kanäle sind noch reichlich da. Wenn man die LiPo-Spannung (also 1S) vorschreibt, um den Spannungsteiler entsprechend auszulegen, geht das: Eingang max. 3.3V!

Man könnte auch z. B. Events definieren und die jeweils mit einem Signal an einem Port des Senders verknüpfen, z. B.
- Drogue aktiviert
- Main aktiviert

Man muss nur aufpassen, dass man dann keinen Eingang zerschießt. Ich könnte mir auch vorstellen, dass man dann was beim Empfänger mit WiFi am Ende des Fluges macht, wäre für iOS und Android passend. Der Prozessor hat reichlich Speicher. Man kann sogar mit Dateisystem (SPIFFS) arbeiten. Geht dann vom Programmspeicher ab.

Beim "Thunda Down Under" war ja vielfach Ansage von Flugdaten per Sprachausgabe über Lautsprecher in Mode. Das Problem ist aber, dass wir die Systeme nicht verwenden können, weil sie meist mit 915 MHz arbeiten. Sprachausgabe könnte ich mir auch nett vorstellen. Aber besser in Englisch; die deutsche Syntax für Zahlen ist doch etwas krude.

Ich hatte auch mal bei Eggfinder angefragt, ob der Eggfinder als Export-Produkt bei 868 MHz auch mit 100 mW wie in den USA arbeitet (weil das hier nicht zulässig wäre), aber darauf keine Antwort bekommen. Da hat sich wohl das "America first!" zu sehr eingebrannt.

Gruß Achim

Geändert von AchimO am 31. August 2020 um 10:15

Louis,
da fällt mir ein: du sagst doch immer beim RJD an, dass Funk nur mit 2.4 GHz erlaubt ist: Woher kommt die Restriktion? Ist das wegen der Frequenzen der Modellbauer, des Startgeräts oder sind die ISM-Bänder 433 und 868 MHz erlaubt?

Gruß Achim

Wegen der Modellflieger, da fliegen noch welche mit den alten Anlagen, die sprechen sich ab. Wenn bei uns einer einen alten Sender mit der selben Frequenz aktiviert stürzt da etwas ab. Das hatten wir vor Jahren schon einmal.
Bei 2,4Ghz gibt es die Gefahr nicht.

Mit den "alten Anlagen" meinst Du aber die 35-MHz-Fernsteuerungen? Die ISM-Bänder sollten ja dann kein Problem sein.

Oliver

Die Idee mit dem Mikro-SD-Kartenleser gefällt mir immer besser. Da könnte ich relativ einfach den OpenLog verwenden, den ich auch in meinem WaRa-Altimeter habe. Um Events zu loggen, benötigt man die Uhrzeit. Da macht es sich gut, dass man sie vom GPS-Empfänger abfragen kann. Der hat eine Realtime-Clock (UTC) und korrigiert sie vermutlich mit der von den Satelliten erhaltenen Zeit.

Aber auch die Sprachausgabe reizt mich. Habe mir schon einen Satz Mini MP3-Player bestellt mit Mikro-SD-Kartenschnittstelle. Damit werde ich mal ein wenig herumexperimentieren. Zwei serielle Schnittstellen habe ich im Empfänger für die beiden Kartenleser noch.

Im Sender habe ich das jetzt so gemacht, dass Daten nur dann gesendet werden, wenn sich ihr Wert gegenüber dem früher mal gesendeten verändert hat. Das reduziert die Datenmenge erheblich, wenn auch wohl nicht während des Fluges.

Um jetzt mal die Ideen über das bisher vorhandene hinaus zusammenhängend aufzulisten:

Sender
- Events: Drogue, Main, ggf. weitere (AUX)
- Überwachung: Lipo-Spannung

Empfänger
- Logging von Events und Veränderungen (Uhrzeit)
- Sprachausgabe

Gruß Achim

Hallo Achim,

da hast Du ein cooles Projekt aufgelegt.
Die Geschichte mit LoRa hat ja wirklich Zukunftspotential. Einige käufliche Systeme sind ja schon darauf ausgelegt.


Gruß Ralf

Ich habe jetzt gesehen, dass mein 3.3V-Spannungsregler nicht besonders stabil arbeitet. Ich denke, ich werde auf einen echten DC-DC-Wandler für 3.3V gehen, der braucht dann einen 2S-Lipo.

Da das Projekt offenbar auf Interesse stößt, habe ich mal die Funktionen zusammengestellt, so wie ich es sehe.


Sender

- Messung von Spannungen: Messbereiche 1-mal 4.2V, 2-mal 8.4V (einer davon ist der eigene), 1-mal 12.6V (wer immer noch nicht von seinem 9V-Block lassen kann, soll ein Kabel an den 12.6V-Eingang anschließen)
- wird dann an einem Eingang eine zu hohe Spannung angelegt, führt das zum Defekt!
- liegt an einem Eingang keine Spannung an, wird dieser ignoriert
- Eingänge für Drogue, Main, AUX bzw. Pyro1, Pyro2, Pyro3; werden auf eine maximale Spannung von 15V ausgelegt
- Höhenmessung: GPS oder BMP180 (Vent Holes!), Auswahl über Jumper
- GPS-Daten: geogr. Koordinaten, vor dem Start zur Initialisierung, während des Fluges unterdrückt, ab einer bestimmten Höhe wieder kontinuierlich (nur die Veränderung); Initialisierung dauert im Freien etwa 30 Sekunden; erfolgreiche Initialisierung ist am Empfänger-Display erkennbar
- Events: Apogee, Drogue, Main, AUX, Spannungsänderung
- alle Datenpakete mit Uhrzeit
- Datenpakete können bei LoRa max. 51 Bytes (Nutzlast) lang sein
- nur die Höhenmessungen sind kritisch bzgl. des Datenvolumens (Duty Cycle 1%)


Empfänger

- Anzeige des RSSI-Werts (Empfangssignalstärke)
- Anzeige (kurzzeitig) von Events während des Fluges
- Anzeige der geographischen Koordinaten mindestens ab einer bestimmten Höhe vor der Landung, danach noch weiter (falls jemand die Rakete klaut )
- Logging von Events auf Mikro-SD
- ggf. Sprachausgabe der Höhe und bestimmter Events: Apogee, Drogue, Main

Zur Aufzeichnung auf der Mikro-SD-Karte:
- Uhrzeit, Höhe (das lässt sich z. B. mit Excel gut im Diagramm darstellen)
- eingestreut darin Event-Einträge mit Uhrzeit, Event und ggf. zugehörigem Wert; müssten vor der Übergabe an Excel entfernt werden

Sender und Empfänger sind als eine Einheit anzusehen, die aufeinander abgestimmt sind. Es gibt keinen offenen Standard für ein Telemetrie-Protokoll!


Gruß Achim

Geändert von AchimO am 09. September 2020 um 13:10

Um Events wie Drogue- und Main-Auslösung feststellen zu können, hat man ja die Aufgabe, einerseits sich an den Zünderanschluss anzuklemmen, andererseits den Zündertest aber dadurch nicht zu beeinträchtigen. Da der Zündertest üblicherweise mit sehr geringen Strömen erfolgt bzw. auch erfolgen muss, besteht das Problem darin, nicht einen Zünder vorzutäuschen, wo gar keiner ist.

Es zeigte sich, dass schon ein sehr geringer Strom im Bereich von einigen µA den Zündertest postiv ausfallen ließ, auch wenn kein Zünder angeschlossen war.

Um nach Einschalten der Elektronik bis zum erfolgten Zündertest eine Entkopplung des Zünderanschlusses zu erreichen, ist mir bisher nichts anderes eingefallen als ein (bistabiles?) Relais. Telemetrie-Elektronik erst einschalten, wenn der Zündertest erfolgt ist, ginge natürlich auch; das gefällt mir aber nicht.

Hat jemand eine bessere Idee?

Gruß Achim