Pi in the Sky V: Telemetrie-Daten und Sensoren II

Inhalt

Noch mehr Sensoren und Daten

Das Pi-in-the-Sky Ballontrackersystem (PITS) ist flexibel genug, auch andere Sensoren und Daten verarbeiten zu können. Mit etwas C/C++ Kenntnissen und gesundem Menschenverstand bringt man das hin. In diesem Blog Beitrag möchte ich einige Tips und Hilfen geben, wenn man einen neuen, dem PITS nicht bekannten Sensor anbinden will (siehe auch den 1. Artikel zum Thema hier).

Eine ganz andere Frage ist natürlich, die Messwerte korrekt zu erfassen.

BME 280: Temperatur, Luftdruck/Höhe, Feuchtigkeit

Meinen PITS habe ich für den Sensor BME 280 von Bosch eingerichtet (der Sensor ist dem PITS im wesentlichen bekannt, siehe Teil Telemetrie Daten I). Auf der PITS Platine gibt es praktischerwiese untendran einen Stecker für den I2C Bus (für ein 4-poliges Flachbandkabel):

Tracker Beispiel mit diversen I2C Sensoren

In diesem schön handlich beschriebenen Tracker-Beispiel Project Edge werden eine ganze Reihe von I2C Sensoren angeschlosssen:

LSM303DLHC Accelerometer/Compass/Magnetometer/Thermometer
Light Sensor TSL2561
Altimeter/Barometer/Thermometer MPL3115A2

Es fehlt noch der Code, der die Daten aus CSV Dateien liest und sendet. Ich würde das anders machen: nämlich im PITS tracker Code einen zusätzlichen „Handler“ für diese Sensoren einschlaufen, der die Daten wenn gewünscht in die Telemetrie einbaut und parallel in jedem Fall als CSV speichert. Bei jedem Sensor könnt man auch zentral im Code festlegen, ob seine Daten auch per Telemetrie übertragen werden sollen.

Schnelle/Langsame Sensoren, Events zählen

Wie binden wir Sensoren ein, die schnell (nicht nur alle x Sekunden) oder nur langsam ausgelesen werden müssen? Beispielsweise event-zählende Sensoren wie Geigerzähler? Grundsätzlich sollte man aus statistischen Gründen die Impulse von Geiger-Zählrohren längerer Zeit aufzeichnen und nur die gemittelten Werte vergleichen. Diese Diskussion würde hier zu weit führen. Es kann aber sein, dass die Messdaten weniger häufig aktualisiert werden als sie übertragen werden. Und umgekehrt: bei der Bildübertragung berücksichtigt der PITS Code ja bereits, dass die Bildübertragung länger dauert, als neue Bilder gemacht werden. Ausserdem wechslen sich Daten und Bilder bei der Übertragung ab.

Man hat also ein zeitliches (Sende-) Gerüst vor sich, das man nicht beliebig auf die Sensoren abstimmen kann und sich auch laufend ändern kann.

Meine Überlegungen dazu:

Der PITS Code ist bereits einigermassen komplex, da er schon viele Arbeiten erledigen muss: Bestimmung der Position, Abfragen der Messwerte, Speicherung in Dateien (telemetry.txt), Übermittlung per Funk (RTTY, APRS, LoRA parallel) mit zeitkritischen Abhängigkeiten
Die Hauptschleife im PITS Code (tracker.c) und die einzelnen Threads der Sensoren sind mit blockierenden sleep Anweisungen programmiert. Das kann nicht einfach beliebig beschleunigt werden
Ausserhalb der Haupt-Schleife könnte mit einem Timer und Interrupt-gesteuert die Sensoren gelesen werden. Dabei ist auf Konflikte (Sender-Timing!) zu achten, evtl. sind die Timer schon besetzt
Ein Raspberry kann nicht wirklich rein mit Interrupts umgehen (die wiringPI/GPIO Library beitet diese Möglichkeit aber)

Aus diesen Überlegungen könnte es eben sinnvoll sein, die Zählung einem Mikrocontroller zu überlassen und von ihm nur die fertigen Messwerte abzuholen. Überlegen muss man sich auch, ob man die Messwerte unabhängig von der Telemetrie-Schleife abholen und speichern will, oder ob man es in diese komplizierte Schleife einflechten will. Dies macht für mich nur Sinn, wenn die Werte auch gefunkt werden sollen.

Die Program-Struktur könnte dabei so aussehen:

Seite Raspberry:

– man definiert GPIO Pins als Ausgang/Eingang mit Interruptsteuerung (Anleitung bei der WiringPi/GPIO Library)

– in der Tracker-Hauptschleife klinkt man einen neuen „Handler“ ein, der die momentan aktuellsten Messwerte zurückgibt. Dies sind in Variablen mit Nummer und Zeitstempel bereits vorliegend. Damit wird – wenn angefordert – sofort ohne Warten die Telemetrie-Zeile gebaut und gesendet

– der neue Handler beschafft sich auch regelmässig, z.B. jede Minute, neue Messwerte(*). Dazu setzt er den GPIO Pin, wodurch per Interrrupt auf dem MC eine neue Messung gestart wird. Er wartet das Ende der Messung aber nicht ab, sondern kehrt sofort ins Hauptprogramm zurück

– der MC signalisiert das Ende der Messung per GPIO Pin, wodurch auf dem Pi eine weitere Interrrupt-Routine aktiviert wird. Diese holt nun vom MC den neusten Messwert ab und speichert ihn mit der nächsten Nummer und Zeitstempel ab. Der MC kann auch ein Flag führen, dass der Wert abgeholt worden ist – so gibt es sicher keine Dubletten

(*) so wird auch die Pi Kamera angesteuert, z.B. ein Bild jede 60s, unabhängig von der Senderei

Seite MC:

– wartet auf eine GPIO-Signal vom Raspberry

– beim Eintreffen wird die eigentliche Messung als Interruptroutine aktiviert und nach Ablauf der Messzeit wieder deaktiviert. Danach wird Zeit und Messwert in Variablen weggespeichert und dem Pi mittels GPIO-Pin signalisiert, dass der neue Messwert abgeholt werden kann

– die eigentliche Mess-Interruptroutine besteht nur daraus, einen Zähler bei Eintreffen der Impulse vom Geiger-Zählrohr zu erhöhen

Evtl. macht etwas analog-elektronisches Sinn. Geiger Zähler brauchen eine gewisse Ansteuerelektonik, dort könnte man auch die Events korrekt erfassen (Schmitt-Trigger) und mit einem Mikrontroller zählen. Da gibt es auch fertige Module (Sparkfun Strahlungssensor):
„The Type 5 Pocket Geiger Radiation Sensor from Radiation Watch is a highly sensitive radiation sensor designed for the embedded systems market. Capable of detecting Gamma and Beta radiation, this sensor has a simple pulsed output that can be used with any microcontroller“

Siehe auch die deutsche Bausatzbeschreibung zum Mighty Ohm Bausatz:
„Der Bausatz kann sowohl über den „Puls“-Ausgang (J6) als auch über die serielle Schnittstelle „Serial“ (J7) an den GPIO-Anschluss eines Raspberry Pi angeschlossen werden. Wesentlich leichter und praktischer ist die Verbindung des Geigerzählers über die serielle Schnittstelle, weil hier die Messdaten bereits in normierte Strahlungswerte umgerechnet ausgegeben werden.“

Der Code dazu ist Opensource und wartet nur auf die Plünderung 🙂

Referenz: Elektor

Sensoren für Arduino und Co. (3), Elektor 2017/1 pp. 74-79 für DS18B20, DHT11, IR
Sensoren für Arduino und Co. (2), Elektor 2016/12 pp. 33-39 Sensoren mit Komparator
Sensoren für Arduino und Co. (1), Elektor 2016/11 pp. 46-54 Kit 35 Sensoren

Andere Referenzen

Update 20170904/20170901/20171003

Merkbar.

IT, Elektronik und Mathematik