du meinst wie beim ESP8266? die gibt es beim ESP32 nicht mehr, das geht, habe ich schon probiert (mit Arduino-code)!
Jo, wir müssten dann für jeden FiPy einen eigenen User anlegen? Andreas hat mir auch schon gesagt, dass er das mit den User-Daten nicht so kritisch sieht. Eigene User anzulegen wäre aber evtl. schon ne gute Versicherung? Aber auch ziemlich aufwendig.
nach dem Bulk-Senden, ja, genau.
Sehr gute Frage!
Klingt für mich auch nach der robustesten Lösung.
Einziger Hack, der mir noch einfällt wäre in jedem Messzyklus die aktuelle Uhrzeit als Start-Uhrzeit in die Config zu schreiben. Das hätte den Vorteil, dass die Uhrzeit, falls der WDT nen Neustart veranlasst, bis auf wenige Sekunden Abweichung stimmt.
Wäre natürlich optimal. Wie ist das nochmal? Die Solarladeregler, die wir bestellt haben sind nur für kleine Module. Wenn wir einen externen Solarladeregler für größere Module verwenden, wie Didi testet, dann kommt der FiPy nicht an die Batteriespannung?
Ich favorisiere aber generell schon den externen Laderegler für große Module.
Ich nehme folgende ToDos für mich mit:
- Zeit synchronisieren beim Holen der Daten
- Fehler abfangen beim Schreiben auf SD
- Kennzeichnen der schon gesendeten Daten/ löschen von gesendeten Daten
- wahrscheinlich am besten externes RTC-Modul implementieren
Vielleicht nicht für jeden FiPy, aber einen user für alle FiPys, die so Daten schicken, werden ja nicht zu viele sein. Als worst case wenn das doch ausgenutzt wird.
Können wir Zugangsdaten nicht auch encrypten, damit sie nicht ganz so offensichtlich als Klartext im Dateisystem liegen?
würde folgendes noch hinzufürgen:
- WLan aktivieren und verbinden wenn der Senden Button gedrückt wurde.
- Rückmeldungen über RGB LED an den Benutzer über RGB
-sollte im unbeaufsichtigten Betrieb nur nur kurzzeitig leicht/schwach Blinken z.B nur beim schreiben auf SD um ordnungsgemäßen Betrieb zu signalisieren.
-Rückmelden ob Daten erfolgreich Gesendet wurden Langes helles Blinken.
-Uhrzeit syncronisiert? oder vor Jahr 2000? Binken betrieb z.B rot und Grün
Ich will mir die Tage ein paar Teile bestellen.
Würde mir dann auch gleich eine Externe RTC holen.
Die Frage ist welches?
- DS1307 wie die Linker Kit RTC - Joy-IT 3 die @didilamken erwähnt hat
- DS3231 ohne EEprom
- DS3231 inkl EEprom
- Oder andere Typ ___?
@all Wär schön wenn wir uns vorweg schon auf einen Typen festlegen könnten, auch wenn sie später nicht verbaut werden. Am besten gleich für beide Firmware Varianten.
Ich wäre aktuell für die DS3231, da ich von den DS1307 gelesen habe, das sie Probleme haben sollen.
@Andreas macht es für Dich bzw. Terkin Datalogger Sinn gleich mit EEprom zu nehmen und wie schätzt du die bestehenden lib’s für Micropython ein.
Würde mir sonnst die ohne EEprom bestellen.
Die DS1307 vom LinkerKit haben bei mir seit Jahren funktioniert, allerdings nur am RPi mit Raspbian, nicht mit eigenen Python-Programmen.
Auch wenn der Raspi monatelang aus war, hat die Uhrzeit gestimmt, aber ich habe nicht genau hingeschaut, da meistens mit NTP synchronisiert wird.
Ich habe in github eine MicroPython-Library gefunden, aber noch nicht ausprobiert.
Die DS3231 habe ich zwar liegen, aber noch nie getestet.
Die DS1307 sollen Zeit verschiebungs Probleme beim häufigeren lesen haben und auch sonnst veraltet und etwas ungenauer sein.
Auch sollen sie eher nur für 5V was taugen.
Die DS3231 sollen weniger Problematisch sein.
Auch verbrauchen sie etwas weniger Energie zumindest wenn kein zusätzliches EEprom verbaut ist.
Wie gesagt ist nur aus div. Foren zusammengetragen.
Ich verstehe, wenn Du sagst, es sollen die 1307 sein, da Du sie kennst und weißt das sie zumindest in Python gut funktionieren.
Hallo Michael,
Diesen Chip haben @weef, @roh und @wtf beim Versuchsaufbau "Autonome Zelle" #1 & #2: Solar-Feinstaub-Wetter-Vergleichsding ebenfalls verwendet.
Für unsere Arbeiten an Zwischenpufferung von Daten und Log-Informationen im RTC slow memory des ESP32 sowie Externer nichtvolatiler Speicher zur Zwischenspeicherung von Daten wäre weiterer Zwischenspeicher auf jeden Fall nett.
Eine MicroPython-Modulsammlung gibt es bei Treiber- und Modulsammlung für MicroPython sowie Support more sensors · Issue #64 · hiveeyes/terkin-datalogger · GitHub. Nach einem ensprechenden Treiber habe ich bisher zwar nicht geschaut, wenn wir an der Stelle Lücken haben, schaue ich aber gern, was ich tun kann.
Viele Grüße,
Andreas.
… das aber nun nachgeholt. Es scheint was da zu sein, auf dem wir bestimmt aufbauen könnten.
1 Like
@MKO, Du hast recht. Auf dem RPI musste ich 5 V nehmen und die Pullup auslöten, da die GPIO nur 3.3V vertragen.
Also lieber DS3231.
DS3231 oder DS3231M. Genauer als zwei oder drei Minuten off pro Jahr (!) klappt nur mit einem GPS(GNSS) - also alternativlos.
Je nach Typ kosten die Originale von Maxim zwischen 5 und 10 €, es ist klar, daß es sich bei den blauen Platinen für 2 € Gesamtpreis um Bauteile zweifelhafter Herkunft handelt. Selbst diese sind aber immer noch wesentlich genauer als DS1307, DS1337, PCF8563…
Zum EEPROM auf den Billigplatinen: das ist oft ein 24C32, und anders, als der DS3231 (welcher 400 kHz kann), machen diese EEPROMs oft nur 100 kHz am I²C - nicht schlimm, aber muß man wissen. Der EEPROM ist natürlich nicht nötig für die Funktion des 3231 und komplett von diesem getrennt, sie hängen lediglich am gleichen I²C-Bus.
2 Likes
Stimmt, würde jetzt auch nicht mehr die Version mit EEprom nehmen hab sie mir mal genauer angeschaut diese platinen müsste man vor Betrieb auch noch umbauen. die LED müsste raus und oft sind nur normale CR2032 nicht wieder aufladbare LIR2032 Knopfzellen drin um den Preis zu senken.
Der Ladewiederstand anscheinend trotzdem drin. Da hat mal wieder einer sehr schlau Kopiert.
Auch hat ein EEprom nur 100.000 Schreibzyklen wenn wir dort alle 30 sec Daten für gebündeltes Senden zwischenspeichern wollen sollten die nicht lange durchhalten.
dann doch lieber ein seperates FRAM mit I²C .
jedes Byte kann da 10.000.000.000.000.000.000.000 mal gelesen/geschrieben werden.
Eine RTC mit im Chip integriertem 8kb FRam gibt es auch, der DS32B35 , wofür ich aber leider kein Breakout finden konnte.
1 Like
Super, genau den hab ich mir bei Eckstein auch gerade bestellt. 
@poesel ist da auch schon dran Treiberunterstützung für die DS3231 RTC
Ich hatte mir am Wochenende schon den DS1307 Chip bestellt, damit der schnell da ist und ich testen kann. Habe aber eigentlich keine Vorliebe. Dann bestelle ich mir auch noch den DS3231.
1 Like
@MKO Ich habe jetzt alle deine Pull-Requests bearbeitet. Ich hatte allerdings echt Schwierigkeiten die Buttons zu nutzen, wenn Sleep implementiert ist. Vielleicht fällt uns da noch was gutes ein. Ein Hack wäre z.B. nach einem Restart nicht in den Sleep zu gehen, dann können die entsprechenden Knöpfe gedrückt werden, aber ganz schön ist das auch nicht.
Ich habe deswegen vorerst zwei Branches daraus gemacht: kamerun und kamerun-sleep
Das sollte jetzt laufen:
- WLan aktivieren und verbinden wenn der Senden Button gedrückt wurde.
- Zeit synchronisieren beim Holen der Daten (Die Zeit wird auch als initial-time in der config gespeichert)
- Kennzeichnen der schon gesendeten Daten/ löschen von gesendeten Daten (Aktuell werden sie einfach gelöscht.)
Das noch nicht, vielleicht schaffe ich gleich noch was:
- Rückmeldungen über RGB LED an den Benutzer über RGB
-sollte im unbeaufsichtigten Betrieb nur nur kurzzeitig leicht/schwach Blinken z.B nur beim schreiben auf SD um ordnungsgemäßen Betrieb zu signalisieren.
-Rückmelden ob Daten erfolgreich Gesendet wurden Langes helles Blinken.
-Uhrzeit syncronisiert? oder vor Jahr 2000? Binken betrieb z.B rot und Grün - Fehler abfangen beim Schreiben auf SD
- wahrscheinlich am besten externes RTC-Modul implementieren
Aus dem deep sleep kann man per Interrupt aufwecken, ich denke dann sollte das auch im light sleep gehen.
Wie gesagt mindestens eine Messe-Pause Zeit gedrückt halten, dann klappt es bei mir immer.
Bin da aber dran. Wie schon beschrieben gibt es eine Möglichkeit ihn vor dem Schlafen zu legen einen einen aufwach Interrupt auf die gipos zu legen.
Wenn ich drüber nachdenke hilft es Evtl einfach nur das Ereignis zu ändern. Jetzt ist glaube ich
IRQ_RISING aktiviert Pin.IRQ_HIGH_LEVEL wäre dazu evtl. die alternative.
ansonnsten ist es echt mies dokumentiert.
In den meißten Foren wird für deep sleep ein Resetbutton Hack bevorzugt und angepriesen.
Thema Light sleep wird zu unrecht kaum behandelt. Gerade bei kurzen bis mittleren Messzeiten ist light sleep klar im Vorteil.
Wenn ich jetzt richtig gerechnet habe macht deep sleep wegen der Bootphasen bei BOB erst ab ca. 3 Min Messintervall überhaupt sinn.