Ich lege A/D Eingänge immer für 0-15V aus.
Die Auflösung reicht ja meist aus um da noch Details zu sehen, mit 12 Bit hat man ja da 15V/4096 = 3mV / Digit.
Das verhindert unabsichtliche Zerstörung durch Anwenderfehler.

Zünder hängen an einem Altimeter ja meist mit einer Seite an +, die andere an den Schalt-FET, der den Pin auf Masse zieht wenn gezündet werden soll. An der Stelle kann man messen ob ein Zünder da ist.
Beispielhaft hier der Ausgang eines Telemetrum. Ich habe da mal einen Zünder eingemalt.

An der Stelle wo "A/D Eingang" steht kann man messen, high=Zünder da, LOW=Zünder nicht mehr da.
Im Falle einer Zündung wir der Anschluss auf Masse gezogen.
Mit dem Spannungsteiler wird einmal der Prüfstrom festgelegt, zum Anderen die Spannung die am A/D ankommen soll.
Damit kann man dann die Zündspannung (0-15V) auf erträgliche Werte reduzieren.

Wenn man das auf Logic-Level reduziert kann man sogar einen digitalen Eingang nehmen um den Zünder zu erkennen!

Geändert von Lschreyer am 07. September 2020 um 10:50

Hab mich mal mit der Sprachausgabe versucht. Hier kommt es als zip-Datei. Ist aus sechs einzelnen Elementen zusammengesetzt.

Anhang: 1823.zip

Gruß Achim

Servus,

Ich will eure Unterhaltung hier nicht unterbrechen , nur mal meine Erfahrungen mit GPS tracking über LoRa einschieben ...

Nachdem ich letztes Jahr auf der Roten Jahne eine Oberstufe verloren habe, habe ich nach einer Tracking Lösung gesucht. Bin bei Adafruit und deren Feather System fündig geworden. Nicht ganz billig, aber Hardware scheint gute Qualität zu sein und es gibt sehr gute Software Bibliotheken und Dokumentation.

Der Transmitter in der Rakete besteht aus einem “Sandwich” mit einem Adafruit Feather M0 RFM96 LoRa Radio - 433MHz (Part No 3179) und einem Adafruit Ultimate GPS FeatherWing (Part No 3133) draufgesetzt. Damit das Ganze nicht zu hoch wird, benutze ich das Short Headers Kit for Feather (Parts No 2940 und No 3002). Der Transmitter ist klein genug, dass er in eine 40 mm Spitze (für Rohre von Noris Raketen) reinpasst.



Die Antenne ist ein einfacher 16,5 cm langer Draht.



Der Empfänger nutzt das gleiche LoRa Board wie der Transmitter. Zur Anzeige verwende ich den Assembled Adafruit FeatherWing OLED (Part No 3045). Noch ist der Empfänger “fliegend” aufgebaut, wie im Bild zu sehen. Stromversorgung ist eine einfache Power Bank (Varta vom Hornbach, die schaltet sich nicht ab).



Zusätzlich habe ich einen Adafruit Wireless Bluefruit LE UART Friend - Bluetooth Low Energy (BLE) (Part No 2479) angeschlossen, der die Daten unverändert über eine BLE Verbindung an mein iPhone weiterleitet.



Fürs iPhone habe ich eine App geschrieben (recht rudimentär). Diese managed die Bluetooth Verbindung und kann bei erfolgreichem Empfang eine Spur der Rakete auf einer Karte darstellen. Gerade die Spur war sehr hilfreich, da ich trotz Empfangsproblemen die Richtung hatte. Alternativen sind z.B. einfache Geocaching Apps ein die man die Koordinaten vom OLED Display eingibt.

Mein Ziel ist noch die Darstellung der Flugdaten, wie z.B Höhe AGL nach abgeschlossenem Flug. Zu diesem Zweck habe ich in der Transmitter Einheit die Header auf einer Seite gekürzt, um Zugang zum I2C des µC zu bekommen. Das ist aber alles noch in Planung.



Ich hatte in Manching zwei Tracker im Einsatz. Beide wurden von einer LiPo Zelle mit 150 mAh mit Strom versorgt. Diese Art der Stromversorgung ist definitiv unterdimensioniert. Bei meinem zwei Stufen Model (hier in den Bildern) hatte ich keine Daten mehr bei ca 350 m AGL, Gipfelhöhe war um die 600m AGL. Zum Glück hatte ich die Spur auf der iPhone App, der ich einfach weiter folgen konnte und so habe ich die zweite Stufe wiedergefunden. Ich kann nicht genau sagen wann, aber kurz bevor ich die Rakete wieder in der Hand hielt, hatte ich auch wieder Kontakt.

Beim zweiten Modell hat der Kontakt schon vor dem Start abgerissen. Es braucht einfach seine Zeit vom preppen der Rakete, bis es an den Start geht. Und am Wochenende hat es dann auch noch etwas gedauert bis gestartet wurde, ganz klar. Ich denke auch die Zelle schon einen Schaden hatte, weil ich danach auch mit dem Laden der Zelle Probleme hatte.

Ausserdem muss ich nachschauen, ob in meinem silbernen Lack nicht zu viel Metall drin ist

Zitat:

---

Fürs iPhone habe ich eine App geschrieben

---

Hast du die über den AppStore eingebracht, die Testumgebung oder gar einen Jailbreak gemacht?

Auf den Seiten der Bundesnetzagentur ist für 433 MHz eine Sendeleistung von max. 10 mW angegeben. Da in USA die Bestimmungen anders sind, ist mal wieder die Frage, ob die Sendeleistung bei uns zulässig wäre. Hast du Informationen dazu?

Aber dein Projekt klingt sehr interessant, und stören tust du damit hier niemand. Informationen über Projekte sind immer willkommen.

Gruß Achim

Servus,

Für eigene Apps brauche ich keinen Jailbreak. Nervig sind aber Limitierungen wie max 5 Apps pro Gerät und vor allem, dass diese nach 7 Tagen nicht mehr starten. Habe mich inzwischen beim Developer Program angemeldet. Könnte also über Test Flight eine App bis zu 100 Leuten zukommen lassen (zum Testen ;-) oder in den App Store.

Die Sendeleistung lässt sich über die Software kontrollieren. Habe mich zwar bisschen schlau gemacht zu LoRa, aber das 10 mW Limit hab ich wohl übersehen. Ich befürchte, ich bin momentan bei 200 mW (23 dBm). Denke, dann müsste ich empfängerseitig eine Yagi Antenne dranhängen um die fehlenden 13 dB halbwegs zu kompensieren.

Grüße, Holger

Zitat:

---

Ich denke auch die Zelle schon einen Schaden hatte, weil ich danach auch mit dem Laden der Zelle Probleme hatte.

---

Manche Ladegeräte weigern sich, wenn die Akkuspannung zu niedrig ist, zu laden. Das Problem könnte auch damit zusammenhängen.

Gruß Achim

@Louis:

Danke für den Schaltplan! Ich denke, so sollte es gemacht werden. Analoge Eingänge scheinen ausreichend zu sein. Ich habe das auch mal erfolgreich mit dem Simply getestet.

Dabei ist mir in der Beschreibung des Simply folgendes aufgefallen:

Unter 'Elektrischer Anschluss AltiMAX G2 Simply' sind die Anschlüsse in der Tabelle richtig wiedergegeben. Im Bild darunter (Überschrift 'AltiMAX G2 Mini'; denke, das sollte 'Altimax G2 Simply' heißen) weichen Pyro1- und Pyro1+ davon ab. Am gelben Kabel liegt bei mir tatsächlich Pyro1+ und am grünen Kabel Pyro1-, wie in der Tabelle darüber angegeben.

Das Gleiche gilt für die Beschreibung des AltiMAX.

Gruß Achim

Geändert von AchimO am 09. September 2020 um 12:54

Nach einigem Stochern in Dokumentationen und Foren bin ich zu dem Schluss gekommen, dass es nicht möglich ist, die Anforderungen
- Überwachung diverser Spannungen und
- Erkennung diverser Events
mit den Bordmitteln des LoRa32-Boards zu erfüllen.

Meine Idee ist daher, für diese "niederen Aufgaben" einen weiteren Prozessor einzusetzen. Da bietet sich der ATtiny84 an. Er hat 10 nutzbare Ports, von denen sehr viele auch analogen Input erlauben. Die Kommunikation soll über eine serielle Schnittstelle geschehen. Der ATtiny84 muss dann mit 3,3 Volt betrieben werden, damit er an anderen Bauteilen keinen Schaden anrichtet.

Das LoRa-Board hat 3 serielle (Hardware-)Schnittstellen. Eine ist für Programmladen und Monitor-Ausgabe vergeben, die zweite für die Kommunikation mit dem GPS-Empfänger. Nutzt man dann noch die dritte, gibt es einen Konflikt mit der Display-Ausgabe; das heißt, das Onboard-Display kann dann nicht genutzt werden. Damit kann man leben, denn es geht ja noch die Monitor-Ausgabe beim Anschluss am PC.

Der GPS-Empfänger kann mit dem LoRa-Board aus dem gleichen Akku betrieben werden. Vorteil: Ein weiterer Spannungsregler entfällt. Die 75 mA, die der GPS-Empfänger zieht, machen sich aber schon bemerkbar: Zum Laden des Programms muss die Versorgung des GPS-Empfängers abgezogen werden.

Die Verteilung der Ports des ATtiny84 würde dann so aussehen:
- serielle Schnittstelle(SoftSerial) (2)
- BMP180 (2) zur Höhenmessung
- Spannungsüberwachung und Events (6)

Die Überwachung der Spannung des LoRa-Bords kann dessen Prozessor übernehmen.

Gruß Achim

Geändert von AchimO am 13. September 2020 um 21:14

Nachdem ich jetzt mit verschiedenen Prozessor-Boards getestet habe und einige Design-Entscheidungen gefallen sind, wird es Zeit für einen Zwischenbericht.

Ich habe mich für Sender und Empfänger jeweils für ein CubeCell-AB02-Board von Heltec entschieden, bei ebay für 16,17€ plus 1,16€ Versand. Es hat, was mich interessierte:
- natürlich den LoRa Transceiver
- eine freie serielle Hardware-Schnittstelle (benötigt für den GPS-Empfänger)
- 3 analoge Schnittstellen, von denen eine für die eigene Batteriespannung vorgesehen ist
- jede Menge digitale Schnittstellen
- einen Batterieanschluss
- einen Lader für einen 1S Lipo Akku bei Anschluss an USB
- die Möglichkeit, weitere Komponenten mit 3,3V zu versorgen
- und ein Display

Man hat dann also eine Lademöglichkeit bei Anschluss über USB (Laptop, Powerpack usw.)
Natürlich ist für den Sender kein Display erforderlich, obschon hilfreich: Es gibt auch das CubeCell-AB01, das kein Display hat; aber das hat nur die eine analoge Schnittstelle für die Messung der Batteriespannung und keinen freien seriellen Port.

Nun war ja das Ziel, neben der Batteriespannung noch zwei weitere Spannungen messen zu können, außerdem noch festzustellen, ob die Anschlüsse von Drogue und Main Spannung haben.

Wenn zwei Spannungen vom CubeCell-AB02 gemessen werden können, fehlt nur noch der Anschluss von Drogue und Main. Geht man davon aus, dass hier Spannungen von bis zu 15V anliegen können und außerdem davon, dass die Betriebsspannung 3,3V beträgt, ist die Eingangsspannung am Spannungsteiler als Logikpegel zu niedrig. Daher habe ich mich dafür entschieden, die Messung der Spannungen von Drogue und Main analog mit einem ATtiny85 als Coprozessor durchzuführen. Der signalisiert dann die Zustände Drogue bzw. Main ON oder OFF über eine digitale Schnittstelle: simpel und platzsparend; der ATtiny85 hat ja nur 8 Beinchen.

Es kommen also dann noch Widerstände für vier Spannungsteiler dazu und natürlich der GPS-Empfänger.

Die Batterie direkt an das Prozessor-Board anzuschließen, ist sicher keine gute Idee. Besser über das Board führen, damit man sie abschalten kann.

Die Software für Sender und Empfänger läuft schon ganz gut, sodass ich demnächst ans Layout gehen werde. Am aufwändigsten ist natürlich die Senderseite. Ist schon kein ganz kleines Programm mehr. Hier bewährt sich wieder der Einsatz eines Automaten (Finite State Machine), Es zeigt sich dabei eine Analogie zur Logik eines Höhenmessers. Ich habe die Zustände
- INITIAL,
- ONPAD
- STARTED
- APOGEEREACHED
- LANDING
- LANDED
benannt. Wer mag, kann sich das Zustandsdiagramm des Automaten anschauen.

Anhang: fsm_sender.zip

Auf dem Empfänger-Display kann man dann folgendes sehen (Lesebrille vorausgesetzt):
- geographische Koordinaten Länge, Breite
- vier Spannungen: Lokale und Remote Batteriespannung, zwei Spannungen X und Y
- aktuelle Höhe
- Höhe des Apogee
- Höhe der Auslösung des Drugue
- Hähe der Auslösung des Main
- außerdem noch den RSSI-Wert (Stärke des Empfagssignals)
- und den SNR-Wert (Signal-Rauschverhältnis)



Nun zu den zeitlichen Abständen der gesendeten Pakete: Für Europa ist im 868MHz-Band eine Sendeleistung von 25mW entsprechend 14 dbm mit einem Duty Cycle von 1 Prozent zulässig. Ich gehe von folgenden Parametern für LoRa-Pakete aus:
- Bandbreite 125kHz
- variable Paketlänge, d. h. explicit Header Mode
- mit CRC
- Spreading Faktor 7
- Coding Rate 1, d. h. 4/5

Das entspricht etwa auch den Standardwerten von LoRaWAN.

Meine Nutzdatenlängen (Payload Length) sind
- 15 (nur für Initial-Daten)
- 11 (Position)
- 3 (Events wie Spannungsänderung, Drogue, Main, Apogee, Höhe, usw.)
Bytes.
Das sind wie gesagt nur die Nutzdaten. Die Pakete enthalten natürlich noch mehr wie Preamble, Header, CRC. Unter loratools.nl findet man ein Berechnungstool für die sogenante Airtime, also die zum Aussenden benötigte Zeit.

Daraus ergiben sich die Duty Cycles zu
- 15 Byte: ca. 4,6s (unwichtig, da nur in der Anfangsphase)
- 11 Byte: ca. 4,1s
- 3 Byte: ca. 3,1 s
Ein wenig Zeit kommt dabei noch hinzu, da der GPS-Empfänger in einem bestimmten Zeitraster (bei meinem Ublox MV6 alle Sekunde) Daten sendet, an dem dann alles Weitere hängt, denn die GPS-Daten müssen ausgeräumt werden, sonst gibt es Salat.

Man könnte die Bandbreite auch auf 250kHz setzen. Dann halbieren sich die Sendezeiten und die Duty Cycles, aber das geht dann zu Lasten der Reichweite.

Von der Idee, Daten auf einer SD-Karte aufzuzeichnen, habe ich Abstand genommen. Die zeiltichen Abstände, die man einhalten muss, sind einfach zu groß, um ausreichend Daten für eine Kurve zu erhalten
.
Dann habe ich mir noch überlegt: Es kann ja sein, dass mehr als nur eine Rakete zur gleichen Zeit auf dem Pad oder sonstwo unterwegs ist. Dann gibt es Salat, weil die Empfänger das nicht auseinanderhalten können. Eine elegante Lösung wäre, das über unterschiedliche Kanäle abzuhandeln. Alternativ könnte man noch ein individuelles Scrambling der Pakete ins Auge fassen. Da wäre es sinnvoll, noch ein paar Jumper für eine individuelle Einstellung vorzusehen; genügend Ports sind vorhanden.

So weit der aktuelle Stand. Wenn Fragen sind: Nur zu!

Gruß Achim

Aus dem Dokument der Bundesnetzagentur ergeben sich die folgenden Frequenzbereiche, bei denen mit einer Strahlungsleistung von 25 mW und einem Arbeitszyklus von 1% gesendet werden darf:

865,0 - 868,0 MHz
868,0 - 868,6 MHz
869,7 - 870,0 MHz

LoraWAN belegt die folgenden 8 Kanäle (Uplink und Downlink)
siehe https://github.com/TheThingsNetwork/lorawan-frequency-plans/blob/master/EU_863_870.yml

Band-Id: EU_863_870
- 868100000
- 868300000
- 868500000
- 867100000
- 867300000
- 867500000
- 867700000
- 867900000

LoraWAN belegt also den Bereich 867 .. 869 MHz. Die Kanäle haben eine Bandbreite von 125 kHz; der Kanalabstand ist 75 kHz. Der an sich auch noch zulässige Bereich 865 .. 867 MHz wird nicht genutzt. In diesem Frequenzbereich liegen Datennetze, bei denen mit 500 mW und längerem Arbeitszyklus gesendet werden darf, was vermutlich der Grund ist.
Man liegt mit diesen Frequenzen sicher auf der richtigen Seite, wenn es in andere europäische Länder geht, denn das LoRaWAN-Komitee hat Pionierarbeit geleistet und eine starke Position.

Ich habe daher auf Sender- und Empfänger-Board 3 Jumper zur Einstellung der Kanäle vorgesehen. Die Boards werden demnächst eintreffen; ich bin mal gespannt.

Die Bestimmung der Höhe mit GPS ist ja sehr ungenau und es ergeben sich Sprünge beim Wechsel von einer Satellitenkonstellation auf eine andere. Daher ermittle ich die Höhe mit dem sehr verbreiteten BMP180-Sensor.

Nun zum Kalmàn-Filter:

Ich hatte zunächst vor, den Filter von Thomas Müller einzusetzen: ist im Archiv zu finden unter "Der billigste Altimeter ...". Ich nahm daher Flugdaten des Fluges einer meiner Wasserraketen für eine Simulation im Programm des Senders und multiplizierte die Höhen mit 10, um realistischere Werte zu haben. Beim Test zeigte sich leider, dass der Filter von Thomas Müller eine starke Schwingneigung hat. Ich verwende daher jetzt wieder den Kalmàn-Filter von Boris du Reau, den ich schon in meinen Altimetern eingesetzt habe mit guten Erfahrungen. Die Simulation soll dann auch beim Test von Sender und Empfänger gute Dienste leisten, und ich bin unabhängig davon, dass momentan so gut wie keine Flüge sttattfinden können.

Gruß Achim