(WS19-01)Wetterballon Auswertung

Aus Verteilte Systeme - Wiki
Wechseln zu: Navigation, Suche

Sensordaten

Erfreulicherweise konnten sämtliche angeschlossenen Sensoren während des gesamten Fluges Daten aufzeichnen. Daher können an dieser Stelle einige ausgewählte Datensätze präsentiert werden.

Anmerkung: Etwa eine viertel Stunde nach dem Start kam es zu einem Neustart des Systems durch den Watchdog. Nach dem Neustart hat die eingebaute Real-Time-Clock die Systemzeit nicht korrekt gesetzt, weshalb sich die Zeitstempel der Daten teilweise überschnitten. Für die Auswertung wurden alle Zeitstempel nach dem Neustart manuell um einen festen Wert von 800 Sekunden nach vorne versetzt.

Höhe

Final Höhe.PNG

Zweifellos der interessanteste Wert ist, wie hoch der Ballon denn am Ende geflogen ist. Aus den Daten ist zu erkennen, dass der Ballon nach ~80 Minuten eine Höhe von 26 Kilometern erreicht hat und dort geplatzt ist. Damit liegen wir vier Kilometer unterhalb der geplanten Mindestflughöhe. Es ergibt sich eine durchschnittliche Aufstiegsgeschwindigkeit von 5,42 Metern pro Sekunde, womit wir die gesetzliche Mindestanforderung erfüllt haben.

Daraufhin ist der Payload über einen Zeitraum von ~70 Minuten wieder zur Erde gefallen, was einer durchschnittlichen Fallgeschwindigkeit von 6,19 Metern pro Sekunde entspricht. Die letzten fünf Kilometer wurden in ~25 Minuten zurückgelegt, also mit etwa 3,34 Metern pro Sekunde, wodurch wir auch hier die gesetzliche Anforderung erfüllt haben.

Die Beschleunigung wurde zwar auch separat aufgezeichnet, allerdings unterlag diese Messung erheblichen Schwankungen, wodurch das Ermitteln der Geschwindigkeit über das Höhendiagramm praktikabler ist.

Temperatur

Außentemperatur:

Final Temp.PNG

Auch hier sind einige Schwankungen zu sehen, dennoch kann man erkennen, dass wir während des Aufstiegs und des Falls Temperaturen von bis zu -40 °C aufgezeichnet haben. Am Wendepunkt sind wir dann wieder fast auf 0 °C gekommen. Diese Temperaturen sind erheblich höher als erwartet und auch die Temperatur beim Start ist etwa 5 °C über der tatsächlichen Temperatur, die am Startplatz geherrscht hat. Unsere Vermutung ist, dass Wärme aus dem Inneren des Payloads durch die Öffnung in der Styroporwand nach Außen gedrungen ist und so die Messwerte verfälscht hat. Bei zukünftigen Projekten müsste hier auf eine besonders starke Abdichtung geachtet werden.

Innentemperatur:

Final Temp Innen.PNG

Die Innentemperatur hat sich bis in den Abstieg hinein bei >= 0 °C gehalten und ist beim Abstieg auch nur bis auf -10 °C gefallen. Es befand sich nur ein Handwärmer im Payload.

Weitere Werte

Luftdruck

Final Druck.PNG

Wenn man den Luftdruck (Hektopascal, y-Achse) gegen die Höhe (Meter, x-Achse) aufträgt, kann man sehr gut den logarithmischen Verlauf beim Durchflug durch die Atmosphäre erkennen.

Luftfeuchtigkeit

Final Feucht.PNG

Wie zu erwarten war, sinkt die Luftfeuchtigkeit ab einer gewissen Höhe auf null.

Beschleunigung, Ausrichtung, Magnetfeld und UV-Strahlung

Daten zu diesen Messgrößen wurden zwar aufgezeichnet, allerdings sind diese nicht sehr aussagekräftig, weshalb sie hier ausgelassen werden. Gerade die Daten zur Ausrichtung im Raum sind in einem 2D-Diagramm nicht wirklich darstellbar. Die Zeitstempel würden eine Korrelierung zwecks Erstellung eines animierten 3D-Modells zwar erlauben, dies liegt aber außerhalb der Kapazitäten des Auswertungsprogramms und war in der gegebenen Zeit auch nicht realisierbar. Hier könnte u. U. das Auswertungsprogramm eines Folgeprojektes ansetzen.

GPS-Daten

Allem Anschein nach hat das eingebaute GPS-Modul nach dem Neustart des Systems keine Verbindung mehr aufbauen können, weshalb der Großteil der Route nicht aufgezeichnet werden konnte. Ein Neustart durch den Watchdog fand genau zum letzten GPS-Datensatz statt. Am Landeort selbst befand sich das GPS-Modul im Init-Zustand, der erst verlassen wird, sobald gültige GPS-Daten empfangen/generiert werden.

Warum auch das Versenden von SMS ausgeblieben ist, darüber kann ohne Bergung des Payloads keine definitive Aussage gemacht werden. Mögliche Ursachen könnten sein:

  • aufgebrauchtes SMS-Guthaben
  • LTE-Stick konnte in der Landephase und auch später in der Baumkrone keinen Empfang mehr bekommen
  • Ausfall wegen Umweltbedingungen

Die aufgezeichnete Route sieht wie folgt aus:

Flugroute.PNG

Kamera-Fotos

Aufgrund des Versagens der RTC, dem Auslösen des Watchdogs und ungünstigem Zeitverhalten, wurden Fotos aus der Startphase überschrieben. Versagt die RTC und kommt es zu einem Neustart, wird die letzte gespeicherte Systemzeit herangezogen, was zu einem Zeitversatz zur echten Zeit führt. Das hat zur Folge, dass das Foto, das zur echten Zeit um bspw. 13:41:00 geschossen wird, beim erreichen dieser Uhrzeit in der falschen Zeit zu genau diesem Zeitpunkt von einem neuen Foto überschrieben wird.

Wie hätte es verhindert werde können?

Bspw. mit einem persistent gespeicherten Zähler als zusätzliche Komponente im Namen.

Anforderungsabdeckung

Um den Erfolg des Projektes in Zahlen fassen zu können, wurde bewertet, ob die zu Beginn aufgestellten Anforderungen erfüllt werden konnten.

Anforderungsabdeckung.pdf

Es ergibt sich eine Anforderungsabdeckung von ~81 %, die nur geringfügig nach oben abweicht, wenn die Anforderungen nach ihrer Priorität gewichtet werden. Folgende Anforderungen konnten nicht erfüllt werden:

  • Flughöhe: Da uns nach dem ersten, missglückten Start nur noch ein stark begrenztes Budget zur Verfügung stand, mussten wir zu einem kleineren Ballon wechseln. Da das Gewicht des Payloads aber nicht signifikant verringert werden konnte, wurde die angepeilte Flughöhe von 30 bis 35 Kilometern nicht erreicht.
  • Helligkeitssensor: Aufgrund von Zeitproblemen konnte dieser Sensor nicht mehr implementiert werden.
  • UV-C Strahlung: Wir waren nicht in der Lage, einen Sensor zu finden, der für das Aufzeichnen von UV-C Strahlung geeignet ist. Da diese Strahlung aber auch erst ab 30 Kilometern messbar ist, wurde diesem Punkt keine hohe Priorität zugeordnet.
  • LoRaWAN: Zu Beginn sah es nicht danach aus, als würde die Implementierung von LoRaWAN uns vor große Probleme stellen. Jedoch konnte über einen Zeitraum von mehreren Wochen keine Verbindung aufgebaut werden, weshalb dieses Vorhaben zu Gunsten von wichtigeren Arbeiten nicht weiterverfolgt wurde.
  • GSM: Diese Methode zur Datenübertragung wurde vor Abflug implementiert und erfolgreich getestet. Da eine Bergung des Payloads zum gegenwärtigen Zeitpunkt noch nicht stattgefunden hat, ist es nicht möglich zu sagen, warum sie versagt hat.