Hallo Achim,

das sieht gut aus was Du da entwickelst.
Hoffentlich hast Du bald Gelegenheit einen Test zu machen.

Gruß Ralf

Man kann es nicht vermeiden: Irgendwie kommt selbst im hohen Alter noch der Ingenieur durch. Habe ja mal vor über 50 Jahren Elektrotechnik studiert. Und die Technik von damals ist heute Bastler-gerecht.

Wahrscheinlich muss ich mich für einen richtigen Test bis Manching gedulden.

Gruß Achim

Weiter geht es mit dem Telemetriesender:

Ich habe mir gesagt: Wenn ich schon einen Druckluftsensor auf dem Board habe und sowieso schon das Apogee feststelle, kann ich doch relativ leicht einfache Höhenmesserfunktionen integrieren. Bisher scheiterte das entweder daran, dass der verwendete Prozessor zu wenig Pins hatte oder der Speicher bis zum Anschlag belegt war.

Da kam mir der Arduino Nano 33 IOT gerade recht. Er hat
- genau so viele Pins wie der Arduino Nano
- WiFi-Funktion und Bluetooth BLE 5.0
- 256K Flash-Speicher und 32K SRAM
- außerdem ein CE-Zeichen

Ist die Höhenmesserfunktion integriert, hat es den weiteren Vorteil, dass die Verhinderung von Einstreuungen auf die Zünderkabel durch den Sender einfacher ist als wenn man - wie im anderen Fall - zusätzliche Kabel von den Zündleitungen zum Sender verlegen müsste.

Hat man die WiFi-Funktion zur Verfügung, ist die folgende Überlegung nicht weit:
Macht man die Bedienung komplett über WiFi, benötigt man
- keine Jumper mehr und
- keinen Summer

Die Bedienung lässt sich also sozusagen von den nicht sehr komfortablen traditionellen Bedienelementen Jumper / Summer auf WiFi mit dem allgegenwärtigen Smartphone umstellen. Hier mal ein Teil des Menüs zur Einstellung von LoRa-Kanal und Auslösung des Main:



Dadurch ist das folgende Board entstanden:



Als Sender fungiert jetzt ein LoRa 1276-C1-868 von Nice-RF. Der hat ebenfalls CE.
Mittlerweile stoße ich jetzt allerdings an Grenzen. Unter dem Prozessor, dem BMP180-Modul und dem Sender-Modul befinden sich noch diverse Widerstände und zwei MOSFETs. Das lässt sich mit einem doppelseitigen Layout nicht mehr ganz ohne Brücken verdrahten.

Ich habe auch schon mal testweise ein Layout mit SMD-Widerständen versucht. Das brachte aber keine Verbesserung. Vielleicht würde eine SMD-Platine mit 4-fach-Layout helfen; das geht aber mit Fritzing nicht.

Der Test mit Treppensteigen vom Keller in die 2. Etage verlief erfolgreich. Ich bin jetzt auf den RJD gespannt.

So weit der aktuelle Stand.

Gruß Achim

Eine (hoffentlich letzte) wesentliche Änderung:

Das Übertragen der GPS-Daten mit 9600 Baud dauert ca. 600 ms, der zeitliche Abstand von einem zum nächsten GPS-Fix eine Sekunde. Das sind zumindest übliche Werte bei vielen GPS-Modulen. Natürlich weiß ich, dass bei einigen auch andere Baudraten möglich sind, wenn man denn weiß, wie man das einstellt und die nötigen Tools hat.

Geht man also von den ca. 600 ms aus und weiß man weiter, dass man die GPS-Daten rasch ausräumen muss, weil es sonst Überläufe und somit Datensalat gibt, folgt daraus, dass der Prozessor je Sekunde zu 60% mit dem Auslesen der GPS-Daten beschäftigt ist. Das ist für eine halbwegs genaue Höhenmessung natürlich nicht recht zu gebrauchen und das Kalmàn-Filter verlangt eigentlich auch gleiche Zeitabstände zwischen jeweils zwei Messungen.

Leider hat der Prozessor nur einen Kern und Multitasking ist daher nicht möglich. Daher habe ich mich zu folgendem entschlossen:
- die GPS-Daten liest ein anderer Prozessor
- und liefert Breite und Länge über eine I2C-Schnittstelle an den Hauptprozessor, der damit wesentlich entlastet wird

Gern hätte ich dafür einen ATtiny genommen - weil der so schön klein und preiswert ist -, aber weder der ATTiny85 noch der ATtiny84 kommen damit zurecht. GPS-Empfang allein geht, auch I2C-Übertagung, aber beides zusammen führt zu Konflikten.

Um dennoch nicht zu viel Platz zu verbrauchen, fiel mir der TinyLiliy Mini ein. Schon teurer und nur aus USA zu beziehen, aber geeignet.



Der hat ca. 14 mm im Durchmesser und die Anschlüsse sind etwas exotisch, weil er für Wearables gedacht ist, aber das bekommt man hin. Der Prozessor ist ein ATMega328P. Den habe ich schon mal in einem WaRa-Altimeter eingesetzt.

Gruß Achim

Geändert von AchimO am 25. August 2021 um 18:02

Hallo Achim,
da ich ja derzeit auch an einer LoRa Lösung für das Tracking bzw. die Ortung arbeite kann ich nur sagen:

Ich arbeite mit einem T-Beam. (Derzeit ca. 25-30€)

Dieser hat den normalen ESP32 mit Bluetooth und Wlan auch einen µBlox 6 GPS Empfänger sowie das LoRa und einen 18650er Halter nebst Ladecontroller On-Board.
Den µBlox habe ich mit einer Weiterleitung der Seriellen Schnittstelle vom ESP32 auf die serielle Schnittstelle vom GPS auf 25Hz eingestellt. Die Software hierfür ist u-center. Bei der Software muss man aber wirklich wissen was man macht, sonst kann es sein das er sich nicht (nie wieder) ansprechen lässt. Die Schnittstelle vom GPS wurde geändert auf 115200Baud, genau so wie die Kommunikation über USB auch stattfindet.

Meine ersten Tests habe ich mit LoRaWAN gemacht und auch ein MicroTik LoRa Outdoor Gateway installiert.
Ich bin sehr zufrieden mit der Reichweite von ca. 12km über LoRaWAN.
Derzeit arbeite ich an der direkten Kommunikation und der Sprachausgabe über eine SD-Karte mit dem bekannten DF-Player. (Diesen nutze ich auch schon in der Awtrix 2.0 ).
Natürlich musste die Antenne am T-Beam gegen "etwas Vernünftiges" getauscht werden.

Soweit ich es verstanden habe bezieht sich die Sendedauer auf 24h.
Das könnte u.A. ein Tagespunkt bei der SOFEX sein :-) (LoRa und Gesetzliche Bestimmungen)

Ich hoffe das wir es von Solaris schaffen das nächste SOFEX u.A. über LoRa und unsere Entwiklungen miteinander zu diskutieren und eventuellen "Neulingen" einen kleinen Workshop anbieten. (Hardware ist dann selbst mitzubringen)

Vielleicht sollten wir uns sogar auf einen Standard-Protokoll für die Trackingdaten einigen (LoRaRok = LongRangeRocketTracking).

viele Grüße
Pierre aka. CharlyMai

Hallo Pierre,

schön, dass noch jemand Interesse an meinem Thread zeigt. Ich hatte ja schon fast das Gefühl, dass sich niemand angesprochen fühlt.

Den T-Beam kannte ich bisher noch nicht. Muss ich mir mal ansehen.

Dass es einige GPS-Empfänger gibt, die eine höhere Übertragungsrate zulassen und einstellbar sind, ist mir bekannt. Mit dem u-center habe ich auch schon etwas herumgespielt. Ich hatte aber das Ziel, die relativ preiswerten fest auf 9600 Baud eingestellten GPS-Module einsetzen zu können; auch deshalb, weil ich das GPS-Modul nicht fest auf dem Board habe. So kann ich in einer kleinen Rakete die kleinen Module von Beitian einsetzen und in einer größeren z. B. ein preiswertes U-Blox-Modul. Einmal ganz abgesehen davon, dass ich hier schon einige nicht einstellbare Module herumliegen habe.
Daraus folgt natürlich die im Thread beschriebene relativ "lange Beschäftigung" mit dem Auslesen der Daten. Das habe ich aber mittlerweile im Griff und zwar dadurch, dass ich einen ATtiny85 nutze, der die Daten vom GPS-Empfänger liest, daraus die GPS-Koordinaten ermittelt und diese an den Hauptprozessor liefert.
Interessanterweise geht das mit einer einzigen "SoftwareSerial"-Schnittstelle des ATtiny, denn mehr kann er ja nicht. Rx des ATtiny ist also zum GPS-Modul verdrahtet und Tx zum Hauptprozessor. Beide müssen natürlich auf 9600 Baud eingestellt sein.

Zum Duty Cycle: Ich sehe es so, dass er sich auf eine Stunde bezieht; ich meine, ich hätte das an verschiedenen Stellen gesehen, z. B. hier:

https://www.bundesnetzagentur.de/SharedDocs/Downloads/DE/Sachgebiete/Telekommunikation/Unternehmen_Institutionen/Frequenzen/Allgemeinzuteilungen/AlarmUeberwachungOrtung/2016_Vfg_45_Alarmfunkanlagen_868-870_MHz.pdf?__blob=publicationFile&v=1

Bei meiner Anwendung spielt es nicht solch eine große Rolle, da ich ja die Ereignisse akustisch ausgebe, was eh nicht so schnell geht. Die einzige Situation, wo man vielleicht häufiger übertragen möchte, wäre der Zeitpunkt der Landung. Da könnte ich auch noch etwas ändern und mehr Priorität geben, da die Landephase bezogen auf den Duty Cycle von einer Stunde sehr kurz ist.
Meine Sicht war daher, dass es sinnvoller ist, in einem EEPROM die Ereignisse und aktuellen Höhen aufzuzeichnen und nach dem Flug auslesbar zu machen als diese in Realzeit zu übertragen, denn während des Fluges kann man mit diesem Datenwust sowieso nicht viel anfangen. Setzt natürlich voraus, dass die Elektronik nicht durch Absturz zerstört wurde.

Ich finde es interessant, dass LoRa ein Thema auf dem SOFEX sein könnte und hoffe, dass wir "Nerds" die anderen nicht zu sehr langweilen. Aber dazu im SOFEX-Thread mehr.

Auch deinen Vorschlag, ein Projekt zu einen "Industriestandard" für Raketen-Telemetrie aufzusetzen, finde ich interessant. Dabei sehe ich vor allem dies:

Eine Vereinheitlichung der Kanäle
- kann gegenseitige Störungen vermeiden

Eine Vereinheitlichung des Protokolls
- könnte ggf. sogar Interoperabilität erlauben

So weit meine Sicht. Demnächst spätestens auf dem Jahresendfliegen weiter und danach das SOFEX!

Gruß Achim

Hallo Achim,

glaub bloß nicht, dass sich dafür keiner interessiert.
Die Frage ist wie lange kann am Euch Experten noch folgen?
Ich habe viel Lehrgeld für nichts bezahlt und habe eine ganze Kiste Elektroschrot produziert.
Auf dem Schreibtisch funktionierte der Kram, auf dem Acker nicht.
Wenn sich sonst niemand einmischt, legt doch Ihr beide die Standards fest.
Euer Projekt = Eure Bestimmertag
Wichtig wäre nur aus meiner Sicht, dass die bisherigen kommerziellen Geräte nicht gestört werden bzw wir ein Prozedere bei den Flugtagen einführen, dass verhindert, dass jemand in seinem Tracking behindert wird. Mit den Altusmetrum hatte es da schon mal Probleme gegeben, da alle auf der Default Frequenz rum funkten.
Ansonsten, macht weiter, ich lese auf jeden Fall mit.

Gruß Ralf

Nochmal zum Duty Cycle: Die zuletzt 2020 herausgegebene Fassung der Allgemeinverfügung der Bundesnetzagentur zu Funkanlagen mit geringer Reichweite

https://www.bundesnetzagentur.de/SharedDocs/Downloads/DE/Sachgebiete/Telekommunikation/Unternehmen_Institutionen/Frequenzen/Allgemeinzuteilungen/FunkanlagenGeringerReichweite/2018_05_SRD_pdf.pdf;jsessionid=22B96F382D8874BD313DF1AB88F33192?__blob=publicationFile&v=7

enthält folgenden Absatz dazu:

Zitat:

---

„Arbeitszyklus“ ist das in Prozent ausgedrückte Verhältnis von Summe(Ton)/(Tobs), wobei ‚Ton‘ die ‚Ein-Zeit‘ eines einzelnen Sendegeräts und ‚Tobs‘ der Beobachtungszeitraum ist. Ton wird in einem Beobachtungsfrequenzband (Fobs) gemessen. Sofern in dieser Allgemeinzuteilung nicht anders bestimmt, ist Tobs ein fortlaufender Zeitraum von einer Stunde und Fobs das zutreffende Frequenzband in dieser Allgemeinzuteilung (Tabelle).

---

Das ist zwar etwas merkwürdig formuliert, sagt aber eindeutig, dass sich der Duty Cycle auf eine Stunde bezieht (da nichts anderes vermerkt).

Anders sieht es im Frequenzbereich um 433 MHz aus. Da kann offenbar jeder so viel senden wie er will, allerdings nur mit 10 mW Sendeleistung und nicht mit 25 mW wie im betreffenden Bereich um 868 MHz. Dafür ist dieser Bereich aber stärker genutzt, was aber auf dem Flugfeld vielleicht nicht so stark ins Gewicht fällt. 8 Kanäle könnte man nach dem entsprechenden Schema auch unterbringen.

Gruß Achim

Geändert von AchimO am 07. Oktober 2021 um 17:41

Hallo,

ich habe gerade den Bauvorschlag zu einem Transroc gefunden.
Nicht ganz das Thema hier, ich hoffe trotz dem von Interesse.

Gruß Ralf

Geändert von RalfB am 25. Oktober 2021 um 08:42

Ist ja sehr nostalgisch. Aber beim RJD dürfte man damit nicht antreten, sonst würden sich die Modellflieger beschweren …

Gruß Achim