Starttermin: nächster Termin: 16.-20.03.2020 https://mcudude.github.io/MightyCore/package_MCUdude_MightyCore_index.json Was hat der MCU-dude denn da gebaut und was soll mir das sagen? In dieser Datei beschreibt die Arduino IDE, ihrere Packte. Hier stehen z.b. auch Daten drin, woher die neuste Version bezogen werden kann und sowas. - Pluto Außerdem steht auch hier drin, für welche Microkontroller das ganze ist. und für weche Plattform Wer möchte beim Start dabei sein? - Michael Springwald(Pluto) vom Space - Alexey LiveTracking * http://huesemann.de/strato/ * Jetzt mit ublox GPS im Airborne <2g Mode und Quectel GPS im Balloon Mode * Timestamp ist jetzt local time * Anzahl Gateways, die das Paket empfangen haben, wird angezeigt Aktueller Status up and running! -> "Jugend forscht" in Diepholz ist nun der nächste Termin (20-+21- Februar) ---------------------- Archiv ---------------------------------------- Probleme mit der Zeitauflösung des GPS-Signals - weiter unten habe ich diverse Quellen zusammengestellt, die die Überleungen stützen bzw. verdeutlichen. - Das GPS-Modul sendet ständig über einen serial-Bus - Empfang der Daten vom GPS über serial. Buffergröße: 1 byte(waren das nicht 1 kb?, ein 1 byte komm mit etwas wenig vor....ich meine sogar es waren ca 64 Byte) - 1 Byte in AVR + 64 in Arduino (Software Ringbuffer) - alle Module erzeugen beim auslesen lag, so dass Teile der sentences vom GPS nicht ausgewertet werden bzw. das was wir empfangen ist ein abgeschnittener Satz und einen, den wir nicht. - Mir kommt es so vor, als wenn auch nicht alle gesendeten senteces werden. *wie viele verschiedene sentences sendet unser modul und wie lange dauert das überhaupt?* - auf jeden fall mehrere, zwei davon werden von der bibliothek ausgewertet: die beginnen jeweils mit GP - für uns interessant ist der GPGGA - sentence, da stehen alle infos drin, die wir haben wollen. - update-Rate unsere Moduls: 5Hz (siehe unten) - ich hab mal in die Bibliotheken reingeschaut. da werden zwei sentences geparsed. - die tiny-gps-bib sieht dabei unsauberer aus als die nmea-bibliothek - die nmea-bibliothek hae ich in "interessante Quelle" verlinkt Lösungsvorschläge: (Alexey) Die Lösung ist bekannt, wird immer an solchen Stellen verwendet. Man muss nicht lange darüber diskutieren, einfach implementieren. Jede "einfachere" Lösung ist nicht richtig und wird noch weitere Probleme verursachen. Lösung: für GPS Serial ein Interrupt-Handler programmieren, der die Daten in einen Ringspeicher hinzufügt. In der Hauptschleife die aten aus diesen Speicher lesen. Gibt es denn pausen zwischen den GPS-Sensor und den anderen Sensoren? So das in den Pausen quasi die Daten geschrieben werden können? Der Ringspeicher hat ja auch "nur" eine gewisse größe.- NEIN. GPS-Sensor sendet Daten, wann er will. (Alexey) Ich habe den Quellcode von Arduino geprüft. Arduino hat schon einen eigenen Ringspeicher. Und `serialEvent` ist KEIN Interrupt. Der Ringspeicher ist echt klein, nur 64 Bytes. Die Änderung der Größe ist nicht vorgesehen aber mit einem Hack möglich (direkte Änderung in einer interner Datei von Arduino). Die Größe von mehr als 256 Bytes funktioniert nicht richtig (Bug in Arduino). https://github.com/arduino/ArduinoCore-avr/blob/master/cores/arduino/HardwareSerial.h https://github.com/arduino/ArduinoCore-avr/issues/177 Lösung: 1) Geswindigkeit von Debug-Serial auf 115200 erhöhen. Die Debug-Schnittstelle muss schneller sein, als die GPS-Schnittstelle. Ist die Die Debug-Schnittstelle das schreiben auf der SD Karte? Oder ist das ein weitere Uart?- UART. Wir müssen schreiben schneller, als wir lesen. 2) Timer-Interrupt verwenden (das ist ein Hack, aber besser ist es mit Arduino nicht möglich). D.H. alle X ms bzw. µs? wird der Aufgerufen? und dort schauen wir ob es was neues gibt?- Ja. Arduino hat 64 Bytes Ringbuffer. Die Geschwindigkeit ist 9600, d.h. Ringbuffer reicht nur für 1/150 Sekunden. Ich übertrage die Daten ca. 500 Mal pro Sekunde in einen größeren Ringbuffer. Der ist 4096 Bytes groß, das ist mehr als 2 Sekunden = reicht. Fertige Lösung: https://github.com/Bella2712/strato/pull/2 * Alexey möchte alle Daten von GPS immer verfügbar machen (Rinspeicher, byteweises lesen/schreiben) (genauer kann ich das grad nicht beschreiben) * Was ist ein Rinspeicher? Speichert man dabei alles als eine Variable und speichert diese am Ende in die Datei? * Fast: Du hast ein Array mit einer bestimmten Größe. Dann hast du ein "Index", überschreitet der Index die Maximal größe, wird er auf 0 gesetzt. - Nein, das ist kein Ringspeicher. Im Ringspeicher gibt es ein "Lese-Index" und ein "Schreibe-Index". Oh, fürs schreiben und fürs lesen? Ok...- https://en.wikipedia.org/wiki/Circular_buffer#/media/File:Circular_Buffer_Animation.gif * Das Ziel ist es Zeit zu sparen, die beim schreiben auf der SD Karte verloren geht. Schreiben wir eine Zeile, braucht das "recht " lange, so das die nächste Zeile verloren geht bzw. zum teil verloren geht(pluto) Dies erscheint mir auf jeden Fall als die saubere Methode. Dürfte auch die einfachste sein, als alles neu zu schreiben, alternative wäre, alle Sensoren selbst ohne LIbray's auszulesen und zwar in der Roh Form, keinelei aufarbeitung der Daten auf dem MC. * Ich hab folgende Idee: wir bauen den duty-cycle um, so dass dann während einer loop folgendes passiert: 1. Lesen der sensoren (bme280, Beschleunigungssensor, usw, KEIN GPS) - geht nicht. Egal, ob wir GPS lesen oder nicht, DIE DATEN KOMMEN. Gerade das ist das Problem: wir MÜSSEN GPS STÄNDIG lesen, keine Pausen sind erlaubt. 2. Schreiben der Daten incl GPS aus dem vorherigen Durchlauf auf SD-CARD - Genau jetzt würden wir daten verlieren. 3. Beginn des GPS-lesens: mehrere lesevorgänge, davon werden die ersten n weggeworfen, durchlauf n+1 wird gespeichert - Das Problem ist, wir dürfen die GPS Daten nicht bufferen. Den Buffer weg zu schreiben, kostetn zu viel Zeit. Wir wissen nicht welche Daten wann kommen. - Um die nicht zu buffern, brauchen wir eine Zeitmaschine. Wir dürfen die nicht rausgeben, wenn sie noch keine vollständige Zeile sind. Das bedeutet buffern. - Arduino buffert die Daten schon selbst. Das kann man nicht abschalten. - meine Idee ist: Reicht es nicht einfach eine weile den stream zu lesen und nicht direkt den ersten datensatz zu nehmen, den wir kriegen? - Das macht nichts besser. in dieser Phase darf der Controller dann nichts anderes machen - kein SerialPrint, kein sd-card-schreiben, kein auslesen der sensoren, usw. 4. wenn ein valider Datensatz gelesen wurde, dann sprung zu 1. - -da stellt sich mir dir Frage, ob wir sowas wie einen einfachen check machen können, einen hashwert berechnen und vergleichen o.ä. - wenn wir nach ca. 3s (oder einer ähnlichen zeit keinen validen Datensatz haben, dann sollten wir auch zu 1. springen. Diesen Zustand haben wir auf jeden Fall zu Beginn direkt nach dem Start. - Meiner Meinung nach verlieren wir wichtige Daten vom GPS Empfänger, auf diese Art und weise. Aus meiner Sicht nur 1-2 Datensätze. Wenn wir valide - Wir dürfen NICHTS verlieren. Das Problem ist folgendest, soweit ich es verstanden habe(pluto): - Wir lesen die Sensoren der Reihe nach ein und speicheren sie auf der SD Karte. - Wir lesen die GPS Daten ein und speicheren sie auf der SD Karte. Ja, genau. So sehe ich es auch. Der stream reisst immer ab, wenn wir irgendwas anderes machen (Lesen der sensoren, schreiben auf sd-card, usw.). Meine Idee ist es nach all diesen vorgängen erstmal eine weile nur gps-daten zu verarbeiten. Wie ich es sehe verarbeiten wir momentan direkt nach dem schreiben der Daten die GPS-Daten. Die Idee ist, nach den zeitintensiven Dingen, die ersten x vom GPS gelieferten Daten wegzuwerfen um nicht direkt den ersten empfangenen Datensatz auszuwerten, da der vermutlich einen buffer-overflow enthält. Keine Ahnung ob ich hier in die falsche Richtung denke. Arduino liest die Daten in einen internen Ringspeicher. Dieser Speicher hat 64 Bytes. Falls mehr als 64 Bytes kommen, ohne von uns gelesen zu sein, fängt Arduino an, die Daten zufälligerweise zu verlieren. Das was man hier tun würde ist, den Ringspeicher einfach größer zu machen. Aber das ist in Arduino nicht vorgesehen. Die Größe ist in "HardwareSerial.h" hartkodiert.Wäre es nicht Sinnvoll, den Ringspeicher zwischendurch zu "leeren"? Jedes mal, wenn auf der SD Karte geschrieben wird, verlieren wir Zeit. So entstehen Kaputte Datensätze.... Ja, aber wir kriegen wie es scheint mit einer update-Rate von 5Hz Daten vom GPS - also 5 Daten-Sätze pro Sekunde bzw. einen alle 0.2s. Wenn wir davon z.B. 1 wegwerfen, und den nächsten auswerten dann dauert dies 0.4s - bleiben 0.6s zum Speichern der Daten, wenn wir jede Sekunde einen Messwert haben wollen. - meine Idee: Es ist anzunehmen, dass der erste Datensatz vom GPS kaputt ist, darum soll dieser verworfen werden. - Lieber nicht kaputt machen. Im eigentlichen Durchlauf einer loop: 1. messen (alles ohne GPS) und schreiben aller Daten incl. der GPS-Daten(vom vorherigen durchlauf) 2. GPS-Daten generieren: z.B. 2Sätze lesen und den ersten Satz verwerfen bzw. ca. 0.4s "zuhören" - den Daten, die wir direkt nach Schritt 1 empfangen können wir nicht vertrauen, nach 0.4s müssten wir zwei Datensätze empfangen haben. 3. den letzten GPS-DATENSatz für die nächste loop in globalen variablen übergeben. - vermutlich sollte man zuerst 1. 2 Datensätze lesen 2. sensoren auslesen und alles speichern. Wir wollen einiges ausprobieren, aber die Grund Idee ist folgende: Wir schreiben jedes Byte einzeln. Vielleicht reicht das.- nein, das würde nur gehen, wenn wir KEINE weitere Sensoren lesen. Ohne Interrupt-Handler gibt es KEINE funktionierende Lösungen. Vielleicht können wir sogar ein Start und End Punkt ausmachen, aber wir wissen halt nicht, wann was gesendet wird.... z.b. wenn ein $ kommt erst dann einlesen und wenn ein \n kommt dann abbrechen. - Bitte nicht solche "Lösungen" erfinden. Die alle sind keine Lösungen, die maskieren nur das Problem, uns es wird immer wieder an verschieneden Stellen auftreten. Die einzige Lösung wäre, keine Daten zu verlieren. Mit einem Zugang zur Interrupt wäre das machbar. Es gibt doch ein Hack mit Timer-Interrupt. Da die Datenstäze öfter gesendet werden, fangen wir immerhin NICHT in der mitte an. Wir bekommen zwar nicht alle mit, aber das brauchen wir ja auch eventuell gar nicht.... // Interessante Quelle: https://www.instructables.com/id/The-Easiest-Arduino-High-Altitude-Balloon-Data-Log/ https://github.com/SlashDevin/NeoGPS Hier bastelt jemand mit einem Arduino einen HAB-Datenlogger und verwendet eine andere Bib. Die sieht in meinen Augen aufgeräumter aus. auf der insctructables-Seite unter Punkt 4 ist der verwendete Quellcode verlinkt. Der sah interesaant aus und könnte eine Lösung unseres Problems enthalten. // Zitat aus: https://www.u-blox.com/sites/default/files/products/documents/NEO-6_DataSheet_%28GPS.G6-HW-09005%29.pdf S.8: update-Rate Raw data output is supported at an update rate of 5 Hz on the NEO-6T and NEO-6P. The UBX-RXM-RAW message includes carrier phase with half-cycle ambiguity resolved, code phase and Doppler measurements, which can be used in external applications that offer precision positioning, real-time kinematics (RTK) and attitude sensing. S.11: Standart-Config 1.15.1 Boot-time configuration CFG_COM1 CFG_COM0 Protocol Messages UARTBaud rate USB power 1 1 NMEA GSV, RMC, GSA, GGA, GLL, VTG, TXT 9600 BUS Powered // Zitat Ende // Zitat aus Data24.csv: (7Zeilen aus der Mitte) 6.35;1022.29;77.81;5.75;1021.48;83.35;-1.12;0.28;-9.38;-0.19;-0.20;0.07;-13.40;7.68;24.54;780286;2020/02/07;22:31:21.00;53.14354;8.22171;1000000.00;11.91;255 $GPGGA,223120.00,5308.61347$GPRMC,223121.00,A,5308.61265,N,00813.30254,E,6.432,124.77,070220,,,D*6B $GPVTG,124.77,T,,M,6.432,N,11.912,K,D*06 6.63;1022.37;78.50;6.25;1021.51;84.45;-0.70;-0.45;-10.75;-0.36;0.92;-1.84;-13.04;5.90;24.20;781289;2020/02/07;22:31:22.00;53.14351;8.22180;1000000.00;31.15;255 $GPGGA,223121.00,530$GPRMC,223122.00,A,5308.61047,N,00813.30816,E,16.820,119.67,070220,,,D*57 $GPVTG,119.67,T,,M,16.820,N,31.150,K,D*3B 6.86;1022.28;79.25;6.94;1021.49;85.88;1.63;0.05;-9.33;0.79;-0.10;-1.93;-16.43;30.73;27.11;782282;2020/02/07;22:31:23.00;53.14347;8.22197;1000000.00;47.74;255 // Zitat Ende Im Datenfile erkennt man, das sein GPS-sentence abgeschnitten wiedergegeben wird: Zeile 1,4,7 sind unsere Sensordaten, die anderen Zeilen sind die GPS-sentences. siehe: https://www.gpsinformation.org/dale/nmea.htm Beobachtung Zeile 2 und 5: hier scheint ein zweiter abgeschnittener GPS-sentence zu stelen - beginnend mit $GPMRC, der erste sentence ist abgeschnitten und ist gelegentlich auch mal länger. //Zitat: Bedeutung der Sentences:: Auszug aus https://www.gpsinformation.org/dale/nmea.htm GGA - Fix information GLL - Lat/Lon data GSA - Overall Satellite data GSV - Detailed Satellite data RMC - recommended minimum data for gps ZDA - Date and Time //Zitat Ende // Zitat Beispiel-sentences für ublox Auszug aus https://www.gpsinformation.org/dale/nmea.htm : UBlox $GPRMC,162254.00,A,3723.02837,N,12159.39853,W,0.820,188.36,110706,,,A*74 $GPVTG,188.36,T,,M,0.820,N,1.519,K,A*3F $GPGGA,162254.00,3723.02837,N,12159.39853,W,1,03,2.36,525.6,M,-25.6,M,,*65 $GPGSA,A,2,25,01,22,,,,,,,,,,2.56,2.36,1.00*02 $GPGSV,4,1,14,25,15,175,30,14,80,041,,19,38,259,14,01,52,223,18*76 $GPGSV,4,2,14,18,16,079,,11,19,312,,14,80,041,,21,04,135,25*7D $GPGSV,4,3,14,15,27,134,18,03,25,222,,22,51,057,16,09,07,036,*79 $GPGSV,4,4,14,07,01,181,,15,25,135,*76 $GPGLL,3723.02837,N,12159.39853,W,162254.00,A,A*7C $GPZDA,162254.00,11,07,2006,00,00*63 Some observations * This is a 16 channel unit and shows up to 4 GSV sentences. * The sentences were captured at 9600 b/s, some are missing at 4800. * WAAS satellites can be used for ranging even if WAAS is turned off. // Zitat Ende Starttermin Das Wetter ist nicht auf unserer Seite, daher müssen wir erneut verschieben. Zur Zeit würden wir in Greifswald landen, Wetter liefert Regen und Wind Neuer Termin 25-31.01.2020 Starterlaubnis Wir haben heute die Starterlaubnis für den 1.11 - 7.11. jeweils zwischen 10 und 12 Uhr von Brake aus bekommen. Ziel ist, ihn an 1.11. steigen zu lassen. An Mittwoch 23.10 wollen wir die Sonde in der Schule fertig zusammenbauen. Ein kurzer Zwischenbericht Nach langem hin und her werden wir voraussichtlich zwischen dem 1.11 und 7.11. Einen Start versuchen. Die Genehmigung steht zwar noch aus, ist aber wohl nur Formsache. Platine angekommen! Nächstes Treffen: Donnerstag, 15.08.2019 gegen 19:00 Uhr(?) Wer kommt? Ziele: Es geht darum die Platine, die am 14.08.2019 sogut wie Fertig ist in China zu bestellen. Nächstes Treffen: Freitag 9. August nach dem CoderDojo, ca 20 Uhr!? Wer kommt? 1. Simone (nur bis 22 Uhr) Nächstes Treffen: Donnerstag 1.8.19 um 19 Uhr Wer kommt? 1. Pluto 2. Simone 3. Hannes Mögliche Ziele für das treffen(vom voherigen treffen übernommen): 1. Als Ziel sehe ich unseren Sensor zu testen und weitere Fehler zu beheben. 2. Test von Kamera etc. Evtl Langezeittest vorbereiten 25.07.2019: Programm schreibt immernoch nur Mist. Wenn man den Flugmodus auskommentiert funktioniert es allerdings richtig. Dateiformat auf .csv geändert. Nächster Termin Donnerstag, 25.Juli.2019 gegen 18:00 Uhr Wer kommt? 1. Pluto(Wegen der hitze, werde ich heute nicht beim treffen dabei sein) 2. Alexey 3. Simone (erst ab 19:00 Uhr, eher etwas später) 4. DU? 5. Abwesend: Arne (Grüße aus dem Urlaub) 6. Hannes Mögliche Ziele für das treffen: 1. Als Ziel sehe ich unseren Sensor zu testen und weitere Fehler zu beheben. 2. Test von Kamera etc. Evtl Langezeittest vorbereiten Nächster Termin Donnerstag, 11.Juli.2019 18:00 Uhr Protokoll Treffen 03.07.19 18 Uhr Mitgebrachte Sensoren: * GYUE/BMP280, temp + pressure, https://cdn-shop.adafruit.com/datasheets/BST-BMP280-DS001-11.pdf ersetzt bmp180, afaik nicht dabei!! * bme280, hygro + temp + pressure, https://cdn-shop.adafruit.com/datasheets/BST-BME280_DS001-10.pdf * BMP 180, temp + pressure, https://cdn-shop.adafruit.com/datasheets/BST-BMP180-DS000-09.pdf * CSS811 CO, indoor air quality, https://cdn-learn.adafruit.com/assets/assets/000/044/636/original/CCS811_DS000459_2-00-1098798.pdf?1501602769 , Anmerkung: halte ich für ungeeignet * BH1750, Licht intensität, ambient light quality,lux, https://www.mouser.com/ds/2/348/bh1750fvi-e-186247.pdf ,S.3: reference data * TEMT 6000 Licht, ambient light sensor, https://www.sparkfun.com/datasheets/Sensors/Imaging/TEMT6000.pdf S.2: reference data * GYML 8511, UVA +UVB, UV-sensor, https://cdn.sparkfun.com/datasheets/Sensors/LightImaging/ML8511_3-8-13.pdf , S.4: reference data * VEML 6075, UVA/UVB, UV-Sensor, https://www.vishay.com/docs/84304/veml6075.pdf , S.5: reference data * GUVA S125D, https://cdn-shop.adafruit.com/datasheets/1918guva.pdf, S.2 reference Data * GY30 BH1750FVI, Digital Light intensity Sensor, https://www.mouser.com/ds/2/348/bh1750fvi-e-186247.pdf , S.3: reference Data ------------------------ Archiv ende -------------------------- ---------------------------------- NEO 6M u-blox -------------------- https://www.u-blox.com/sites/default/files/products/documents/NEO-6_DataSheet_%28GPS.G6-HW-09005%29.pdf https://www.u-blox.com/sites/default/files/products/documents/u-blox6_ReceiverDescrProtSpec_%28GPS.G6-SW-10018%29_Public.pdf?utm_source=en%2Fimages%2Fdownloads%2FProduct_Docs%2Fu-blox6_ReceiverDescriptionProtocolSpec_%28GPS.G6-SW-10018%29.pdf Das scheint das richtige Datenblatt mit über 200 Seiten zu sein. Der Begriff "Dynamic Platform Model" kommt an meheren stellen vor, wie z.b. Seite 13. Airborne <1g Used for applications with a higher dynamic range and vertical acceleration than a passenger car. No 2D position fixes supported. MAX Altitude [m]: 50000, MAX Velocity [m/s]: 100, MAX Vertical Velocity [m/s]: 100, Sanity check type: Altitude, Max Position Deviation: Large https://www.u-blox.com/sites/default/files/products/documents/u-blox6_ReceiverDescrProtSpec_%28GPS.G6-SW-10018%29_Public.pdf Mögliche Arduino Libs: 1. https://github.com/mikalhart/TinyGPS/blob/master/TinyGPS.h 2. https://github.com/adafruit/Adafruit_GPS 3. https://github.com/sparkfun/SparkFun_Ublox_Arduino_Library Hier kann man scheinbar die "Dynamic Platform Model" einstellen.... NavMode, der 1. Parameter sollte geändert werden. Problem ist nur: Wie testen wir das.... 4. https://playground.arduino.cc/UBlox/GPS/ ukhas: UK High Altitude Society https://ukhas.org.uk/guides:ublox6 ---------------------------------- GM-Zählrohr ------------------------ Pocket-Geiger-Type5-Strahlenmessgerat-Geigerzahler-Halbleitersensor https://www.ebay.de/itm/Pocket-Geiger-Type5-Strahlenmessgerat-Geigerzahler-Halbleitersensor-f-Arduino/303096969700?hash=item4691fcb9e4:g:FcoAAOSw3utY6LvD ---------------------------------- GM-Zählrohr ENDE ------------------------ -------------------- Planung 2019 - Massen und Termine ----------------- aktuelle Planung (28.06.2019) ca. 300g bis 350g Nutzlast über Massen: Styroporbox mit alten Sensoren: 311g 4 Kameras: a 57 gesamt: 228g 2 Powerbanks: 103g gesamt 206g GPS Tracker (evtl. 2x): 63g Datenlogger (Stratofight): 50g 9v Block für Datanlogger: 43g Fallschirm: 71g 2 Flügel breit: 81g 2 Flügel schmal: 16g Stangen 10g Außenexperiment ca. 70g + Tape etc. x g Insgesamt ca 1200g Aussenexperimente vor der Kamera geplant und auch eine zusätzliche Kamera insgesamte Nutzlast: 1,6kg - davon 1,3kg vom Gymnasium genutzt in der Nutzlast sind 2 Powerbanks a ca. 200g und 4 Kameras (vorne/hinten/oben/unten) drin. Mitgewogen wurde der Messsensor vom Space, der sich noch in der Schule befindet geplanter Starttermin: September 2019 (Anfang bis Mitte) 10.-20. 09. ist für Michael schlecht Wir haben ein Schliessfach: Nr. 12 - Schlüssel beim Keyholder nächstes Treffen: Mittwoch 03.07.19 18:00 -------------------- Planung 2019 - Massen und Termine ENDE----------------- ------------Flugmodus ---------------------------- Flightmodus für GPS: Der Sensor ublox Neo 6M hat kein eeprom und "merkt" sich Einstellungen nicht. https://ava.upuaut.net/?p=738 HAB: Anleitung für ublox https://ukhas.org.uk/guides:falcom_fsa03 ublox-messages encoded Code-Schnipsel: auf: https://ava.upuaut.net/?p=750 U-Blox-Software: https://www.u-blox.com/de/product/u-center Doku Dynamic Models: https://wiki.paparazziuav.org/wiki/Module/GPS_UBlox_UCenter -------- Ende Flugmodus ----------------------------------- -------------------- Beginn alte Ideen ------------ Planung für den Stratosphärenflug mit Wetterballon (Nachbereitung Flug 2018) Extrawünsche fürs nächste Mal: * Besseres Live-Erlebnis * Stream * Liveübertragung der Flugroute * Standortvergleich Sonde-vs-Messteam * Fähnchen unten Überlegungen für Sensoren: 1. Position über GPS (Konfiguration!) 2. Lage über 9-DOF Sensor mit Fusion, z.B. über BNO055 3. empfindlicher Drucksensor (bis ca. 5hPa) 4. UV-Sensor 5. LUX-Sensor 6. Temperatur (möglichst großer Temperaturbereich) bspw. Pt100/pt1000 7. Luftsensoren (Qualität / CO2 / NOx)? 8. Windsensoren (Durchflutungsrohr?) 9. Strahlung (UV-A/B/C) 10. Verschiedene Reinstoffe 11. Erdanziehungskraft/Gravitation? 12. Auswirkungen auf die Elektronik messen (Wheatstone-Messbrücken mit einmal Spannung, einmal Strom) zu7) CO2: diverse Sensoren gefunden: - MG812 bzw MG811 (-20 bis 50 Grad C) benötigen wohl nach längerer Lagerung eine 'Einbrennzeit von bis zu einer Woche' Strombedarf: max 150mA bei 5V -> 0,75W Datenblatt: https://www.winsen-sensor.com/d/files/PDF/Solid%20Electrolyte%20CO2%20Sensor/MG812%20CO2%20Manual%20V1.1.pdf breakout-board: https://sandboxelectronics.com/?product=mg-811-co2-gas-sensor-module für 52.95 Dollar mit http://www.myduino.com/index.php?route=product/product&product_id=812 schaltplan: http://sandboxelectronics.com/?p=147 ali (nur sensor) (ca. 8 euro pro Stück (2erPacks)): https://de.aliexpress.com/wholesale?SearchText=mg812 forum: https://community.particle.io/t/ppm-calculation-from-mg812-co2-sensor/25656 - CCS811 indoor (0-50 Grad C)https://cdn.sparkfun.com/assets/learn_tutorials/1/4/3/CCS811_Datasheet-DS000459.pdf https://de.aliexpress.com/item/CCS811-Sensor-Modul-GY-811-Air-Qualit-t-Numerische-Gas-Sensoren-TVOC-CO2-GY-CCS811-Elektronische/32850761608.html?spm=a2g0s.13010208.99999999.260.2c973c007TVeqH - MH-z19: https://de.aliexpress.com/wholesale?catId=0&initiative_id=SB_20190214140048&SearchText=mh-z19 - viele und teure bei digispark: https://www.digikey.de/products/de/sensors-transducers/gas-sensors/530?FV=ffe00212&quantity=0&ColumnSort=1000011&page=1&k=co2&pageSize=500: Kameras - 360°? Verbesserungen am System: * Anderer microcontroller (Teensy? https://www.pjrc.com/teensy/) -> 3.6 Wäre der Beste. Bestellungen am besten nicht über Reichelt, ist am günstigsten im Vgl. https://www.exp-tech.de/plattformen/teensy/ * Zusätzlich Raspberry Pi Zero? Robusteres Speichern der Werte (vom Microcontroller über USB) und einfacheres verteilen (Lora, GSM, Wifi?). Einfache Diagnose am Starttag per WLAN? * Mehr Platinen, weniger Kabel * Syncronisation aller Systeme (Knopfdruck-On/Off) * LoRa-WAN Ausgabe verbessern (Traffic-Limit?) * Solarpanel zur Verbesserung der Batteriekapazität * Eine zentrale Stromversorgung (USB-Powerbank) (Redundanz?) 9DOF https://github.com/kriswiner/MPU6050/wiki/affordable-9-dof-sensor-fusion https://github.com/adafruit/Adafruit_AHRS/ -------------------- Ende alte Ideen ------------