Inhalt
Noch mehr Sensoren und Daten
(Zum ersten Artikel der Serie)
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)
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.“
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