Liebe Community,
bei der Weiterentwicklung unseres Loggerprojekts (Outdoor) bräuchte ich eure Unterstützung.
Das Problem: Stromverbrauch des Rasp Pi Pico mittels Watchdog drosseln, Integration eines externen BLE-Boards
Aktuelles Setting:
Rasp Pi Pico
SHT31D
DS3231
TPL5110
Xiao Seeed ESP32-C3
4x 2100 mAh NiMH Akkus
Die Idee ist die MCU mittels Watchdog (TPL5110) alle ~ 10 min aufzuwecken, die Zeit vom RTC (DS3231) zu bekommen, den SHT31D Sensor abzulesen (GPIO4 SDA, GPIO5 SCL) und die Messung zu speichern und dann wieder komplett im power-off Modus zu gehen
Zusätzlich soll die Batteriespannung über GPIO26 gemessen werden, die Schaltung erfolgt mit Bat+ --- 1M --- GPIO26 --- 820 K --- GND
Wichtiges weiteres Feature: Reed-Schaltung des Watchdog, mit der die MCU ohne das wasserdichte Gehäuse zu öffnen mit einem Magnet geweckt werden kann und dann mittels BLE die Daten abgerufen werden können.
Die firmware steht, ich brauche allerdings Hilfe bei der Schaltung. Die Wiederstands-Stärken und die Schaltung habe ich mir so zusammengegoogelt und KI gefragt, es wäre gut wenn jemand der sich auskennt da noch einmal drüber schaut.. ich habe noch keine gute Lösung wie ich das XIAO SEEED ESP32-C3 Board für die BLE Unterstützung mit Strom versorge (5V über Pin/Bat nötig, 3,3V des Pico ggf mit zu starken Peaks die das ESP32-C3 möglicherweise nicht verträgt (?)
Bis auf die BLE-Komponente funktioniert die Schaltung soweit ich sie testen kann - da ich am Breadboard das ESP32-C3 aktuell über USB mit Strom versorge kann ich nicht sagen ob der Prototyp auf BAT funktioniert.. der kritische Punkt ist mE ob der Watchdog zuverlässig die Intervalle hält und ob er sich triggern lässt über Reed-Schaltung und den Pico und BLE zuverlässig anstellt
Jede Hilfe dazu und Erfahrungsaustausch zu ähnlichen Projekten danke ich euch sehr
Auf der Seite 625 des RP2040-Datenblatts steht: ...
Da kann ich nur dem Post bei Artemis II angepaßt wiederholen:
Die Lesefähigkeit in der Bevölkerung nimmt laut Studien, wie IGLU, seit
Jahren ab. Mit dem Lese- und Hörverständnis geht es auch bergab.
Der Fokus liegt zunehmend auf digitalen Inhalten und kurzen Texten
(Happen), was zu Lasten der Konzentration für längere Texte geht. Und da
kommen diese auf Seite 625 in der PDF (erst) zu dem Thema! Wahnsinn! 😱 Unfassbar! 😉
GPio 29 ist also der gesuchte Kandidat und die Widerstände braucht es nicht, das ist schon mal eine gute Info.
Ich sollte vielleicht sagen, dass ich mich mit der MCU und der Programmierung und Schaltung dieser seit etwa 7 Tagen alleine befasse, also erhebe ich definitiv keinen Anspruch auf Richtigkeit meines Schaltplans oder das tiefgehende Verständnis/Wissen über die Zusammenhänge. Ich denke jeder fängt mal an und es bewährt sich immer wieder auch einfach der Satz:
Am schnellsten bekommst du eine richtige Antwort wenn du die falsche Lösung postest ;-)
Gibt es hier vielleicht auch Erfahrungswerte zu TPL5110-Nutzung und der Reed-Schaltung?
Beim Pico sind die integrierten Überspannungsdioden nach Vcc sehr leistungsschwach. D.h. um eine Begrenzung sicherzustellen, solltest Du die Batterie nicht direkt an einen der vier ADC-Eingänge anlegen.
Gibt es hier vielleicht auch Erfahrungswerte zu TPL5110-Nutzung und der
Reed-Schaltung?
Eher nicht, weil, wer einen RTC-Chip hat, benutzt den zum Aufwecken. Der kann jedenfalls genaue Intervalle. Den Reed-Kontakt kann man direkt parallel zum Open-Collector Ausgang der RTC anschließen. Es gibt auch RTC-Chips mit einem Eingang speziell für den Zweck, z.B. RV-3032-C7. Nebenbei braucht der auch weniger Strom und ist genauer und billiger.
Warum die Kombination RP2040 und ESP32? Mit dem Pico W gibt es ein Board mit integriertem Bluetooth-Modul, aber auch der ESP32 sollte deine Anforderungen alleine umsetzen können
Fehlt da nicht was auf deiner Schaltung, wo werden denn die Daten gespeichert?
Der SHT31D ist ein Luftfeuchtesensor, in einem typischen wasserdichten Gehäuse wirst du damit keine Freude haben
Gibt's einen Grund für die Akkuwahl?
Ist dir bekannt, dass viele RTC-ICs einen Alarm-Ausgang haben, der konfiguriert werden kann, um zu einer bestimmten Zeit geschaltet zu werden?
Eher nicht, weil, wer einen RTC-Chip hat, benutzt den zum Aufwecken. Der
kann jedenfalls genaue Intervalle. Den Reed-Kontakt kann man direkt
parallel zum Open-Collector Ausgang der RTC anschließen. Es gibt auch
RTC-Chips mit einem Eingang speziell für den Zweck, z.B. RV-3032-C7.
Nebenbei braucht der auch weniger Strom und ist genauer und billiger.
Gibt diesen Chip oder etwas vergleichbares bereits auf einem Breadout? Ich konnte leider nichts finden. Wir sind noch weit entfernt davon eine eigene Platine selbst zu entwerfen.
-Externer Timer da Pico im deep sleep noch zu viel Strom verbraucht
Der externe Timer verbraucht im besten Fall nur um die 35nA
Warum die Kombination RP2040 und ESP32? Mit dem Pico W gibt es ein
Board mit integriertem Bluetooth-Modul, aber auch der ESP32 sollte deine
Anforderungen alleine umsetzen können
Der Pico RP2040 ohne W liegt bereits in einer gewissen Stückzahl vor, den Pico W müssten wir erst noch kaufen (~7,50 Euro im Vergleich zu BLE-Board für unter 4,50 Euro) - und für die Picos ohne W hätte ich dann erst mal keine Verwendung mehr
Fehlt da nicht was auf deiner Schaltung, wo werden denn die Daten
gespeichert?
die 2 MB Flash Speicher auf dem Pico reichen dafür völlig aus
Der SHT31D ist ein Luftfeuchtesensor, in einem typischen wasserdichten
Gehäuse wirst du damit keine Freude haben
Der Sensor ist natürlich nicht im Gehäuse ;-) der wird rausgeführt und die Stelle wird abgedichtet (100 % dicht ist das nicht, aber ausreichend, in der Box gibts ein Silikagelsäckchen gegen die Kondensationsfeuchte, das hat bisher gut funktioniert)
Gibt's einen Grund für die Akkuwahl?
Akkus vorhanden bzw. mehrfache Verwendung in anderen Projekten möglich
Ist dir bekannt, dass viele RTC-ICs einen Alarm-Ausgang haben, der
konfiguriert werden kann, um zu einer bestimmten Zeit geschaltet zu
werden?
Ja, aber soweit ich erfahren habe kann dieser den Pico nicht aufwecken aus einem kompletten power-off Status - ist das korrekt?
Hast Du mal überschlagen oder gemessen, wie hoch die Stromaufnahme Deiner Schaltung ist bzw. sein könnte und welche Laufzeit erwartet wird?
Vielleicht hat Norbert da Erfahrungswerte, aber 'stromsparend' und RP2040-Fertigmodul in einem Satz zu fordern, ist meines Erachtens ein Widerspruch.
Den RP2040 für einen Datenlogger zu verwenden, hatte ich mal überschlagen aber schnell wieder verworfen.
Andere Controller lassen sich sehr stromsparend betreiben, haben eine interne RTC für genaues Timing und sind ebenfalls als fertiges Modul günstig zu beschaffen. Als Beispiel was für Deine Anwendung reichen würde: https://de.aliexpress.com/i/1005005748198584.html
Ein weiterer, überdenkenswerter Punkt an Deiner Planung wäre die Stromversorgung. NiMH kann man nehmen, LiIon-Zellen passen mit ihrem Spannungbereich und geringen Selbstentladung besser, wenn der zu messende Temperaturbereich dies zuläßt.
Ich verstehe ja, dass du gern den Weg des geringsten Widerstands gehen willst und möglichst viel von dem einsetzen, was du hast, aber jetzt mal Hand aufs Herz: Um wieviele Geräte geht's denn eigentlich? Und was ist das Ziel? Möglichst schnell mit dem vorhandenen Zeug zu arbeiten (z.B. als Prototyp für eine Machbarkeitsuntersuchung) oder eine Lösung zu finden, die dauerhaft funktioniert?
Wie oft soll ausgelesen werden? Wie erreichbar sind die Geräte?
Gegebenenfalls geht das alles nämlich mit vertretbarem Aufwand mit deutlich weniger Leistungsaufnahme, vielleicht sogar sogar per NFC.
ob er sich triggern lässt über Reed-Schaltung
und den Pico und BLE zuverlässig anstellt
Wenn du einen externen Trigger hast, dann kannst du die gesamte Stromversorgung abstellen, so dass der Energieverlust gegen Null geht.
Dazu schaltest du die Batterie mit einem Mosfet ab. Durch den Triggerimpuls wird der Mosfet eingeschaltet und der Pico startet. Über einen GPIO geht der Pico in Selbsthaltung. Ist das Programm durch, kann sich der Pico selbst abschalten indem er den GPIO wieder aus macht.
Hast Du mal überschlagen oder gemessen, wie hoch die Stromaufnahme
Deiner Schaltung ist bzw. sein könnte und welche Laufzeit erwartet wird?
Vielleicht hat Norbert da Erfahrungswerte, aber 'stromsparend' und
RP2040-Fertigmodul in einem Satz zu fordern, ist meines Erachtens ein
Widerspruch.
Den RP2040 für einen Datenlogger zu verwenden, hatte ich mal
überschlagen aber schnell wieder verworfen.
Andere Controller lassen sich sehr stromsparend betreiben, haben eine
interne RTC für genaues Timing und sind ebenfalls als fertiges Modul
günstig zu beschaffen. Als Beispiel was für Deine Anwendung reichen
würde: https://de.aliexpress.com/i/1005005748198584.html
Ein weiterer, überdenkenswerter Punkt an Deiner Planung wäre die
Stromversorgung. NiMH kann man nehmen, LiIon-Zellen passen mit ihrem
Spannungbereich und geringen Selbstentladung besser, wenn der zu
messende Temperaturbereich dies zuläßt.
Vielen Dank für diese Gedanken.
Ich wurde bei dem Rasp Pi Pico leider schlecht beraten und hatte mich auf die Info von einem Freund verlassen.
In erster Linie sollten die Kosten sehr günstig gehalten werden, daher erschien das Board als passend.
Erfahrungswerte haben wir testweise gesammelt: bie -18°C lief der Logger ohne Watchdog 14 Tage, bei Zimmertemperatur 42.
Für NiMH haben wir uns auch wegen des niedrigen Temperaturbereichs im Gelände im Winter entschieden unter denen er noch gut arbeitet, LiPo allerdings aufgrund der starken Energieverluste nicht mehr realisierbar gewesen wäre.
ob er sich triggern lässt über Reed-Schaltung
und den Pico und BLE zuverlässig anstellt
Wenn du einen externen Trigger hast, dann kannst du die gesamte
Stromversorgung abstellen, so dass der Energieverlust gegen Null geht.
Dazu schaltest du die Batterie mit einem Mosfet ab. Durch den
Triggerimpuls wird der Mosfet eingeschaltet und der Pico startet. Über
einen GPIO geht der Pico in Selbsthaltung. Ist das Programm durch, kann
sich der Pico selbst abschalten indem er den GPIO wieder aus macht.
Der Messimpuls alle 10 Minuten sollte allerdings erhalten bleiben, der externe Trigger durch z.B. Magnet wäre dann zusätzlich.
Die Frage ist ob man den Mosfet zwingend braucht oder ob der TPL5110 diese Funktion ebenfalls übernehmen kann.
Ich verstehe ja, dass du gern den Weg des geringsten Widerstands
gehen
willst und möglichst viel von dem einsetzen, was du hast, aber jetzt mal
Hand aufs Herz: Um wieviele Geräte geht's denn eigentlich? Und was ist
das Ziel? Möglichst schnell mit dem vorhandenen Zeug zu arbeiten (z.B.
als Prototyp für eine Machbarkeitsuntersuchung) oder eine Lösung zu
finden, die dauerhaft funktioniert?
Wie oft soll ausgelesen werden? Wie erreichbar sind die Geräte?
Gegebenenfalls geht das alles nämlich mit vertretbarem Aufwand mit
deutlich weniger Leistungsaufnahme, vielleicht sogar sogar per NFC.
Ausgelesen werden sollte 1x im Monat um die Datenverluste bei Fehlfunktion gering zu halten.
Die Idee mit NFC hatte ich auch sondiert, allerdings kann NFC nicht die Datenmenge senden die sich dann auf dem Logger befinden würde oder zumindest wird abgeraten NFC für größere Datenmengen zu verwenden
Hast du da ggf. andere Informationen? Hat jemand mit NFC in diesem oder ähnlichem Kontext ggf. schon einmal gearbeitet?
Beim Pico sind die integrierten Überspannungsdioden nach Vcc sehr
leistungsschwach. D.h. um eine Begrenzung sicherzustellen, solltest Du
die Batterie nicht direkt an einen der vier ADC-Eingänge anlegen.
Danke dir für diese Info. Würdest du dann also doch einen Widerstand einbauen? Wenn ja, welche Stärke müsste dieser haben? (gehen wir mal von 5V Batteriestrom aus)
Hast Du mal überschlagen oder gemessen, wie hoch die Stromaufnahme
Deiner Schaltung ist bzw. sein könnte und welche Laufzeit erwartet wird?
Vielleicht hat Norbert da Erfahrungswerte, aber 'stromsparend' und
RP2040-Fertigmodul in einem Satz zu fordern, ist meines Erachtens ein
Widerspruch.
Den RP2040 für einen Datenlogger zu verwenden, hatte ich mal
überschlagen aber schnell wieder verworfen.
Andere Controller lassen sich sehr stromsparend betreiben, haben eine
interne RTC für genaues Timing und sind ebenfalls als fertiges Modul
günstig zu beschaffen. Als Beispiel was für Deine Anwendung reichen
würde: https://de.aliexpress.com/i/1005005748198584.html
Ein weiterer, überdenkenswerter Punkt an Deiner Planung wäre die
Stromversorgung. NiMH kann man nehmen, LiIon-Zellen passen mit ihrem
Spannungbereich und geringen Selbstentladung besser, wenn der zu
messende Temperaturbereich dies zuläßt.
Beim STM32 Core Board Demo Board bräuchte man auf jedenfall eine zusätzliche Speicheroption
Es scheint mir auch weniger Beginner-freundlich zu sein wie Arduino, ESP oder eben Rasp Pi
Unter diesen Alternativen war Rasp Pi immer noch die günstigste Lösung
In ein paar Jahren oder mit Unterstützung könnte ich mir schon vorstellen dann komplett umzustellen bzw die Platinen selbst zu entwerfen
Wenn du einen externen Trigger hast, dann kannst du die gesamte
Stromversorgung abstellen, so dass der Energieverlust gegen Null geht.
Dazu schaltest du die Batterie mit einem Mosfet ab. Durch den
Triggerimpuls wird der Mosfet eingeschaltet und der Pico startet. Über
einen GPIO geht der Pico in Selbsthaltung. Ist das Programm durch, kann
sich der Pico selbst abschalten indem er den GPIO wieder aus macht.
Ja, den Ansatz halte ich auch für zielführend.
Vermutlich wird die Batterielaufzeit durch den Standby-Verbrauch dominiert. Den zu senken macht also Sinn.
Als Trigger zum einen den Reed-Switch verwenden, zum anderen eine RTC. Schau mal bei Micro Crystal, z.B. die RV-8803-C7 wird mit 240nA beworben. Bei 5V werden es ein bischen mehr werden, aber das ist dennoch Größenordnungen von einem ständig laufenden DC-DC-Wandler entfernt.
So eine RTC kann zu einem per I2C vorher eingestellten Zeitpunkt ein Interrupt-Signal senden. Das dann zum Aktivieren der Stromversorgung des Mikrocontrollers alle paar Minuten verwenden.
Den zusätzlichen Mikrocontroller mit Funkmodul normal gar nicht bestromen. Den nur aktivieren wenn er wirklich gebraucht wird (per Reed-Switch eingeschaltet).
Auf Verluste durch Pullups etc. achten, also z.B. I2C-Leitungen zu einem unbestromten Mikrocontroller. Das ist zu vermeiden, da z.B. nen Analogschalter dazwischenpacken.
Erfahrungswerte haben wir testweise gesammelt: bie -18°C lief der Logger
ohne Watchdog 14 Tage, bei Zimmertemperatur 42.
Zum Vergleich: Atmega328, NRF24+-Funkmodul, DS18B20(-Klon) und SHT21 laufen hier seit 1256 Tagen an zwei NiMH AA LSD-Zellen, und funkt jede Minute die Messwerte zur Basis (ESP+NRF24, schickt die Daten weiter zu MQTT).
Letzte Batteriespannung im MQTT: 2.60V. Wenn das Teil ausgeht, bestimmt wegen Selbstentladung der Zellen.
Keine große Magie dahinter, Arduino-Framework, Libs aneinandergepappt, etwas Sleep-Mode drübergesprinkelt.
'stromsparend' und
RP2040-Fertigmodul in einem Satz zu fordern, ist meines Erachtens ein
Widerspruch.
Den RP2040 für einen Datenlogger zu verwenden, hatte ich mal
überschlagen aber schnell wieder verworfen.
Hinzu kommt, der Widerstandsteiler im Megaohm Bereich war ja nur das Sahnehäubchen. Benutzte man den und würde 1ms lang die Werte messen, dann erhielte man eine 500er Punkteschar welche nur eine Mutter lieben kann. Ein Polynom zweiten Grades würde dann so etwas wie ein Kurvensegment von EinsMinusEhHochMinusTeeDurchTau zeigen.
Hinzu kommt, dass es laut Wachsmalstift - /Maling/ wohl PiPicos und andere Komponenten gibt, welche ohne Masse arbeiten.
Hinzu kommt, dass der TPx das Zeug wohl direkt aus dem DRV Pin, ohne Zuhilfenahme eines FET, versorgen soll. Das ist bei 1mA lt. Datenblatt, hmmm, ambitioniert.
Hast Du mal überschlagen oder gemessen, wie hoch die Stromaufnahme
Deiner Schaltung ist bzw. sein könnte und welche Laufzeit erwartet wird?
Das ist mal ein vernünftiger Vorschlag! Und das Pico Board soll im DORMANT Mode unterhalb 1mA liegen. Das würde geraume Zeit reichen.
Zumindest bis der ESP eingeschaltet wird und sich erst mal ein halbes Ampere aus den schon gut gelagerten Akkus genehmigt.
'stromsparend' und
RP2040-Fertigmodul in einem Satz zu fordern, ist meines Erachtens ein
Widerspruch.
Den RP2040 für einen Datenlogger zu verwenden, hatte ich mal
überschlagen aber schnell wieder verworfen.
Hinzu kommt, der Widerstandsteiler im Megaohm Bereich war ja nur das
Sahnehäubchen. Benutzte man den und würde 1ms lang die Werte messen,
dann erhielte man eine 500er Punkteschar welche nur eine Mutter lieben
kann. Ein Polynom zweiten Grades würde dann so etwas wie ein
Kurvensegment von EinsMinusEhHochMinusTeeDurchTau...
Ich bin ja froh dass nicht alle hier in der Community so wenig Information in so viel Text packen ;-)
Mi N. schrieb:
Hast Du mal überschlagen oder gemessen, wie hoch die Stromaufnahme
Deiner Schaltung ist bzw. sein könnte und welche Laufzeit erwartet wird?
Das ist mal ein vernünftiger Vorschlag! Und das Pico Board soll im
DORMANT Mode unterhalb 1mA liegen. Das würde geraume Zeit reichen.
Zumindest bis der ESP eingeschaltet wird und sich erst mal ein halbes
Ampere aus den schon gut gelagerten Akkus genehmigt.
Leichte Übertreibung intentionally
Wie bereits geschrieben reicht der dormant mode beim Pico nicht für unsere Zwecke, 1mA ist sehr viel, v.a. wenn zusätzlich die Temperaturen im Minusbereich liegen und entsprechende Leistungsverluste der Stromversorgung dazukommt
Erfahrungswerte haben wir testweise gesammelt: bie -18°C lief der Logger
ohne Watchdog 14 Tage, bei Zimmertemperatur 42.
Zum Vergleich: Atmega328, NRF24+-Funkmodul, DS18B20(-Klon) und SHT21
laufen hier seit 1256 Tagen an zwei NiMH AA LSD-Zellen, und funkt jede
Minute die Messwerte zur Basis (ESP+NRF24, schickt die Daten weiter zu
MQTT).
Letzte Batteriespannung im MQTT: 2.60V. Wenn das Teil ausgeht, bestimmt
wegen Selbstentladung der Zellen.
Keine große Magie dahinter, Arduino-Framework, Libs aneinandergepappt,
etwas Sleep-Mode drübergesprinkelt.
Der Atmega328 wäre der Goldstandard, aber so viel Budget haben wir nicht zur Verfügung
v.a. wenn zusätzlich die Temperaturen
im Minusbereich liegen und entsprechende Leistungsverluste der
Stromversorgung dazukommt
Und der ESP läuft damit dann aber problemlos? Verblüffend.
Aber einfacher:
rp2040 ADC: sowieso schon schlecht. Derart hochohmig: noch viel schlechter.
TPx DRV als Stromversorgungspin: schlecht. Vmtl. sogar nicht funktionell.
Masse an allen Komponenten: gut.
Du machst halt immer noch so ein Staatsgeheimnis daraus, was du nun eigentlich erreichen willst.
Mit Watchdog-Modul und FET uswusf. kommst du auch auf Kosten und Entwicklungsaufwand. Das kann okay sein, je nach Zielsetzung und Umfang, aber der Pi Pico ist auch ganz gut verkäuflich, gegebenenfalls lohnt sich einfach eine andere Systemkonzeption.
Ich würde mich zum Beispiel direkt fragen, ob die Daten nicht mehrmals täglich einfach per Funk übertragen werden können, dann hat man den Aufwand mit der Auswertung nicht, aber natürlich höhere Hardwarekosten. Der Pi Pico ist extrem leistungsfähig und sehr günstig, aber für das, was du machen willst (oder zumindest das, was du hier erzählt hast) reicht einer der neuen Attinys. Der macht auch den gesamten Spannungsbereich deiner NiMH-Batterien mit, dann hast du auch keine Verluste durch Spannungsregler. Aber: Dafür müssen wir eben wissen, was du willst. Aktuell scheint es so, dass das ein Testballon werden soll, wenn du noch keine Platine dafür machen willst?
Du machst halt immer noch so ein Staatsgeheimnis daraus, was du
nun
eigentlich erreichen willst.
Mit Watchdog-Modul und FET uswusf. kommst du auch auf Kosten und
Entwicklungsaufwand. Das kann okay sein, je nach Zielsetzung und Umfang,
aber der Pi Pico ist auch ganz gut verkäuflich, gegebenenfalls lohnt
sich einfach eine andere Systemkonzeption.
Ich würde mich zum Beispiel direkt fragen, ob die Daten nicht mehrmals
täglich einfach per Funk übertragen werden können, dann hat man den
Aufwand mit der Auswertung nicht, aber natürlich höhere Hardwarekosten.
Der Pi Pico ist extrem leistungsfähig und sehr günstig, aber für das,
was du machen willst (oder zumindest das, was du hier erzählt hast)
reicht einer der neuen Attinys. Der macht auch den gesamten
Spannungsbereich deiner NiMH-Batterien mit, dann hast du auch keine
Verluste durch Spannungsregler. Aber: Dafür müssen wir eben wissen, was
du willst. Aktuell scheint es so, dass das ein Testballon werden soll,
wenn du noch keine Platine dafür machen willst?
Ziel ist die effektiven Kosten möglichst gering zu halten, der Entwicklungsaufwand ist erst mal gedeckt
Gebrauchte Picos wird mir wsl keiner abkaufen für einen für mich guten Preis
Funkübertragung (z.B. LoRaWan + Gateway) hatte ich ebenfalls recherchiert, die Möglichkeiten in unserem Fall sind allerdings begrenzt, wir bräuchten zu viele Gateways und hätten ggf trotzdem Schwierigkeiten mit dem Internetempfang - Damit wäre das Projekt also deutlich zu teuer
Ich hatte 30 der Picos mit SHT-Sensor bereits im Einsatz, Probleme gab es wegen der Laufzeit und dem Handling beim Datenauslesen
Daher würde ich das System gerne erweitern und robuster machen und bin vorerst an Pico gebunden mit der Einschränkung dass wir nicht gleich den Pico W bestellt hatten (und dass möglicherweise andere Boards erst mal rausfallen)
Eine Platine kann ich definitiv mit meinem aktuellen Wissenstand nicht entwerfen und die Unterstützung die ich habe reicht dafür leider auch nicht aus.
Beim STM32 Core Board Demo Board bräuchte man auf jedenfall eine
zusätzliche Speicheroption
Es scheint mir auch weniger Beginner-freundlich zu sein wie Arduino, ESP
oder eben Rasp Pi
Mit dem WeAct-Board habe ich eine ältere Schaltung, die einen 16 MB Speicher auf der Platine verwendet. Routinen für Speicherung, RTC, Datenausgabe, Fernbedienung, ... sind vorhanden und könnten abgekupfert werden. Allein Deinen Sensor müßtest Du über IIC anschließen und programmieren, wobei es genug Beispiele gibt, dafür beliebige IO-Pins zu verwenden.
http://mino-elektronik.de/Gemischtes/2-Kanal%20Datenlogger.html#grund_1
Weiter unten findet sich eine Schaltung mit einem STM32G031 im TQFP32 Gehäuse, für die ich noch Leerplatinen habe (bei Bedarf 2,50 Euro inkl. Briefverand).
Die 'hohe' Stromaufnahme im aktiven Zustand liegt daran, daß das Programm immer mit 1 ms Interrupts läuft, nie richtig stoppt und UART/ADC permanent aktiv sind. Nimmt man nur 1 s Aufweckintervalle der RTC oder, wie bei Dir wohl ausreichend, Intervalle von 10 Minuten, kann die Stromaufnahme kleiner sein, als der Leckstrom des Akkus.
'Anfängerfreundlich' geht nicht mehr, wenn man eine stromsparende Lösung braucht. Die von Dir genannten Laufzeiten bei 10 Minuten Abtastintervallen mögen Dir reichen, für mich wäre solch eine Lösung nicht akzeptabel.
Aber gut, alles nur als Anregung für Dich!
Ziel ist die effektiven Kosten möglichst gering zu halten, der
Entwicklungsaufwand ist erst mal gedeckt
Das ist doch mal eine Aussage.
Kleiner Hinweis fürs nächste Mal: Es ist geschickt, Dinge zu testen, bevor man sich entscheidet, sowas dreißig Mal zu bauen.
Jetzt bin ich direkt, auch wenn es dir nicht gefallen wird:
Mit deinen Einschränkungen ist das System so völlig in Ordnung. Lass die Bluetooth-Übertragung mit dem teuren Modul sein, lass den teuren Watchdog sein und benutze RTC-Wakeup. Stattdessen baust du dir einfach nochmal 5 von deinen Systemen und fährst dann periodisch raus und tauschst die Geräte einfach aus. Zuhause werden sie geöffnet, ausgelesen, frische Akkus reingepackt und wieder verschlossen.
Anpassungen des Systems würde ich nicht vornehmen, denn du bist in einer Sackgasse und musst dich im Prinzip einzig und allein auf Module verlassen, die du so von der Stange kaufen kannst, bei gleichzeitig extrem eingeschränktem Budget.
Beim STM32 Core Board Demo Board bräuchte man auf jedenfall eine
zusätzliche Speicheroption
Es scheint mir auch weniger Beginner-freundlich zu sein wie Arduino, ESP
oder eben Rasp Pi
Mit dem WeAct-Board habe ich eine ältere Schaltung, die einen 16 MB
Speicher auf der Platine verwendet. Routinen für Speicherung, RTC,
Datenausgabe, Fernbedienung, ... sind vorhanden und könnten abgekupfert
werden. Allein Deinen Sensor müßtest Du über IIC anschließen und
programmieren, wobei es genug Beispiele gibt, dafür beliebige IO-Pins zu
verwenden.
http://mino-elektronik.de/Gemischtes/2-Kanal%20Datenlogger.html#grund_1
Weiter unten findet sich eine Schaltung mit einem STM32G031 im TQFP32
Gehäuse, für die ich noch Leerplatinen habe (bei Bedarf 2,50 Euro inkl.
Briefverand).
Die 'hohe' Stromaufnahme im aktiven Zustand liegt daran, daß das
Programm immer mit 1 ms Interrupts läuft, nie richtig stoppt und
UART/ADC permanent aktiv sind. Nimmt man nur 1 s Aufweckintervalle der
RTC oder, wie bei Dir wohl ausreichend, Intervalle von 10 Minuten, kann
die Stromaufnahme kleiner sein, als der Leckstrom des Akkus.
'Anfängerfreundlich' geht nicht mehr, wenn man eine stromsparende Lösung
braucht. Die von Dir genannten Laufzeiten bei 10 Minuten
Abtastintervallen mögen Dir reichen, für mich wäre solch eine Lösung
nicht akzeptabel.
Aber gut, alles nur als Anregung für Dich!
Danke für den Link. Ich hätte noch ein paar Fragen, würde dich aber dann per Mail nochmal kontaktieren, wenn das in Ordnung ist.
Ziel ist die effektiven Kosten möglichst gering zu halten, der
Entwicklungsaufwand ist erst mal gedeckt
Das ist doch mal eine Aussage.
Kleiner Hinweis fürs nächste Mal: Es ist geschickt, Dinge zu testen,
bevor man sich entscheidet, sowas dreißig Mal zu bauen.
Wie kommst du darauf dass wir das nicht getestet hatten?
Für die erste Runde war das System ok, trotz Einschränkungen, die mir natürlich bewusst waren. Allerdings kann man alles verbessern und dazu diente die Anfrage an euch.
Der Atmega328 wäre der Goldstandard, aber so viel Budget haben wir nicht
zur Verfügung
Der ist von ~2009, gibt inzwischen viel bessere, und kostet bei Reichelt (ATMEGA 328P-PU) im Steckbrett-freundlichen DIP28 2,75€.
Als TQFP32 bei TME.eu oder JLCPCB etwa die Hälfte.
Als Breakout-Board bei Ali/eBay gehts noch billiger, aber du kriegst du u.U. Klone, was aber nicht unbedingt schlecht sein muss. Nur die Stromfresser-Extrabauteile auf dem Board musst du halt runterlöten/knipsen.
Der Atmega328 wäre der Goldstandard, aber so viel Budget haben wir nicht
zur Verfügung
Der ist von ~2009, gibt inzwischen viel bessere, und kostet bei Reichelt
(ATMEGA 328P-PU) im Steckbrett-freundlichen DIP28 2,75€.
Als TQFP32 bei TME.eu oder JLCPCB etwa die Hälfte.
Als Breakout-Board bei Ali/eBay gehts noch billiger, aber du kriegst du
u.U. Klone, was aber nicht unbedingt schlecht sein muss. Nur die
Stromfresser-Extrabauteile auf dem Board musst du halt
runterlöten/knipsen.
Das sind hilfreiche Infos, ich hatte den Atmega328 auf dem Arduino-Board mir angesehen, was preislich deutlich über unserem Budget liegt
Da ich nicht im IT/Elektronikbereich ausgebildet bin würde ich mich an die Weiterentwicklung auf diesem Niveau erst mal nicht rantrauen. Wobei es aus meiner Sicht sehr gewinnbringend wäre, das als OpenSource Projekt zu verfolgen bzw. auf bestehenden Arbeiten wie der von MiNo aufzubauen.
Die Software wird auch als Open Source bei Codeberg hinterlegt.
Ziel ist die effektiven Kosten möglichst gering zu halten, der
Entwicklungsaufwand ist erst mal gedeckt
Das ist doch mal eine Aussage.
Kleiner Hinweis fürs nächste Mal: Es ist geschickt, Dinge zu testen,
bevor man sich entscheidet, sowas dreißig Mal zu bauen.
Wie kommst du darauf dass wir das nicht getestet hatten?
Für die erste Runde war das System ok, trotz Einschränkungen, die mir
natürlich bewusst waren. Allerdings kann man alles verbessern und dazu
diente die Anfrage an euch.
Du baust 30 Stück, sprichst aber von "erster Runde". Das sagt mir, dass die Anforderungen nicht klar genug waren.
Ich will dir auch keinen Vorwurf machen: Kann ja durchaus sein, dass ihr schnell was brauchtet, dann bastelt man eben irgendwas zusammen. Aber die "Verbesserung" des Systems besteht daraus, einen klaren Anforderungskatalog aufzustellen und es dann neu zu designen. Deine Energiespar- und Auslese-Anforderungen machen die Nachrüstung aufwendig und teuer, weil die gewählte Hardware dafür nur unzureichend geeignet ist. Das heißt nicht, dass du irgendwas falsch gemacht hast, sondern nur, dass du bestimmte Dinge nicht entsprechend bedacht hast. Das passiert, gerade dann, wenn man sowas zum ersten Mal macht. Jetzt wäre der Zeitpunkt, sich damit zu beschäftigen, wie man Platinen entwirft und das System mit den klareren Anforderungen, die sich aus dem bisherigen Betrieb ergeben haben, neu zu konzipieren.
Aber du hast kein Geld, was ich bei 30 Stationen durchaus verstehen kann. Allerdings: Dein Watchdog-Modul kostet meinetwegen 3 Euro, dein ESP32-Board nochmal 5. Wenn man gute Preise kriegt. Das sind 8 Euro extra, und wirklichen Low-Power-Betrieb erreicht man so auch nicht. Für 240 Euro plus den ganzen Aufwand lohnt sich das meines Erachtens nach absolut nicht, da das grundlegende Problem, nämlich ungünstige Komponentenauswahl, so nicht gelöst wird. Wenn du sowieso jeden Monat auslesen willst, dann musst du jeden Monat zu deinen Sensoren gehen. Es ist gegebenenfalls möglich, mit ein paar Tricks die Akku-Lebensdauer auf diesen Monat zu strecken, außer dann, wenn's wirklich dauerhaft extrem kalt ist. Das kannst du ja aber mal testen. Aber wenn du sowieso jeden Monat dort bist, dann kannst du die Geräte auch einfach rotieren, statt sie auszulesen. Ich halte es für unwahrscheinlich, da auf einmal jahrelangen Betrieb rausholen zu können. Das gefällt dir natürlich nicht, aber das ist genau die Lösung, die deinem Wunsch nach minimalem Budget und minimalem Hardware-Entwicklungsaufwand entspricht.
Genau so war es, wir brauchten schnell eine günstige Lösung und haben mit minimalem Aufwand dann etwas bekommen, das natürlich nicht ideal ist.
Das Problem ist, dass das Tauschen der Stationen auch wieder zusätzlichen Aufwand bedeutet, da die Logger in einer gewissen Höhe mit Hilfsmitteln angebracht werden und diese mitzubringen ist umständlich. Dann würde doch das Mitbringen eines Notebooks mit Ersatzbatterien als machbarer einstufen und das Gehäuse mit MCU im Gelände öffnen, wie bisher.
Ich kann das durchaus nachvollziehen, dass das aktuell die beste Lösung ist in Anbetracht des geringen Budgets und dass wir keine fachlichen Resourcen haben.
Der Watchdog und DS3231 allein würde uns allerdings dann auch schon weiterhelfen, da die Logger immerhin 2-3 Monate durchlaufen, sollte man nicht zum Auslesen kommen (Krankheit/zu viel Arbeit/andere Gründe) würde das immerhin nicht bedeuten dass keine Daten vorliegen.
Die Schaltung mit Watchdog hatte ich bereits getestet und die klappt. Ich teste gerade bei -18°C ob die Laufzeit länger ist als 14 Tage (die wir ihne Watchdog hatten) und wie stark die Knopfzelle leidet. Die Flexibilität die wir durch weitere ~120 Euro bekommen wäre es wert, zumindest darauf umzustellen.
Wenn aus eurer Sicht die Implementierung von einem bedarfsmäßig anstellbaren BLE Support + Erweiterungsboard keinen Sinn ergibt würde ich das weglassen und warten, bis wir das ganze nochmal neu aufsetzen können - dann vielleicht auch mit einer eigenen Platine.
Das Problem ist, dass das Tauschen der Stationen auch wieder
zusätzlichen Aufwand bedeutet, da die Logger in einer gewissen Höhe mit
Hilfsmitteln angebracht werden und diese mitzubringen ist umständlich.
Dann würde doch das Mitbringen eines Notebooks mit Ersatzbatterien als
machbarer einstufen und das Gehäuse mit MCU im Gelände öffnen, wie
bisher.
Dann sollte man sich eine Halterung ausdenken, die das vereinfacht.
Der Watchdog und DS3231 allein würde uns allerdings dann auch schon
weiterhelfen, da die Logger immerhin 2-3 Monate durchlaufen, sollte man
nicht zum Auslesen kommen (Krankheit/zu viel Arbeit/andere Gründe) würde
das immerhin nicht bedeuten dass keine Daten vorliegen.
Wo speichert Ihr die Daten lokal? SD-Karte? EEPROM? FRAM?
Die Schaltung mit Watchdog hatte ich bereits getestet und die klappt.
Ich teste gerade bei -18°C ob die Laufzeit länger ist als 14 Tage (die
wir ihne Watchdog hatten) und wie stark die Knopfzelle leidet. Die
Flexibilität die wir durch weitere ~120 Euro bekommen wäre es wert,
zumindest darauf umzustellen.
Wenn aus eurer Sicht die Implementierung von einem bedarfsmäßig
anstellbaren BLE Support + Erweiterungsboard keinen Sinn ergibt würde
ich das weglassen und warten, bis wir das ganze nochmal neu aufsetzen
können - dann vielleicht auch mit einer eigenen Platine.
Warum wollt Ihr einen Pico Pi UND einen ESP32-C3 verwenden, wenn der ESP32-C3 auch noch die RTC, den Watchdog (zusammen als regelmäßiger Wecker) und die BLE-Verbindung bietet?
Das ESP32-C3-Mini-Board (~5Euro) hat ein 2,54mm-Raster, das von Steckbrettern und Lochrasterplatinen unterstützt wird.
Ich teste gerade bei -18°C ob die Laufzeit länger ist als 14 Tage (die
wir ihne Watchdog hatten)
Hast Du vielleicht auch die Möglichkeit, parallel eine LiIon 18650 Zelle mit zu testen? Und sind die -18 °C Dauertempertur oder eher nächtliche Tiefstwerte?
Entladen bei tiefen Temperaturen wird dann zum Problem, wenn höhere Ströme benötigt werden. Im <= mA-Bereich sollte das keine Rolle spielen. Die Selbstentladung ist deutlich geringer als bei NiMH, was gerade bei längerer Laufzeit von Vorteil ist.
Was ich an LiIon mag ist die passende Nennspannung zu 3,3 V Systemen und einfache Ladeschaltung (Module mit TP4056). Geringes Gewicht, kleine Abmessungen und einfach beschaffbar: Notebook oder e-Zigarette ausschlachten ;-)
Noch etwas: Welcher Betrag ist denn bei Deiner Anwendung teuer bzw. zu teuer? In der Regel ist die Arbeitszeit das Teuerste bei kleinen Stückzahlen. Wenn man Deinen Datensammler braucht, sind ein paar Euro Differenz doch kein nennenswerter Betrag, verglichen mit einem Bier in der Kneipe oder einen Packung stinkender Glimmstengel.
Ich würde es auch so machen wie andere es schon geschrieben haben.
Den Raspi Pico komplett weglassen und alles auf dem ESP machen.
Dann noch den TPL weglassen und in 1-2 MOSFET/Transistoren investieren und den Interrupt Pin der RTC nutzen um die Spannung zyklisch zum Messen einzuschalten.
Wenn du später eine Platine selber machst die RTC gegen eine andere tauschen. Ich mag auch die RV-3028-C7 von Micro Crystal.
Oder dann halt komplett umstellen auf einen dedizierten Funk uC (vlt. Nordic).
Wenn du die Daten auf dem ESP speicherst hast du vermutlich sogar noch mehr Platz frei als auf dem Raspi Pico (2 vs 4MB).
Der Atmega328 wäre der Goldstandard, aber so viel Budget haben wir nicht
zur Verfügung
Der Mega328 war vor 20 Jahren vielleicht mal "Goldstandard". Heute wären das eher die DA/DB/DD-Teile. Billiger und gleichzeitig viel, viel besser.
Aber da ja sowieso noch ein ESP32 mitwerkeln soll, würde man sinnvollerweise dem die Messung noch mit aufdrücken, dann bliebe für den "Co-Prozessor" nur noch die stromsparende RTC-Funktion. Dafür würde dann auch einer der kleinsten aktuellen Tinies noch vollkommen ausreichen.
Das Problem ist, dass das Tauschen der Stationen auch wieder
zusätzlichen Aufwand bedeutet, da die Logger in einer gewissen Höhe mit
Hilfsmitteln angebracht werden und diese mitzubringen ist umständlich.
Dienen diese Hilfsmittel der (De-)Montage oder werden sie benötigt, um die Stationen in der gewissen Höhe zu erreichen?
An den Reed-Kontakt zum Aktivieren der BLE-Übertragung kommst du ohne diese Hilfsmittel ran?
Wichtiges weiteres Feature: Reed-Schaltung des Watchdog, mit der die MCU
ohne das wasserdichte Gehäuse zu öffnen mit einem Magnet geweckt werden
kann und dann mittels BLE die Daten abgerufen werden können.
Zur Messung von Gleichspannung darf man der Quellimpedanz des
Messsignales mit einem Kondensator unter die Arme greifen.
Wenn man dann nur ein oder zwei Messungen macht, dann ja. Aber dann darf man im wahrlich besten Fall auch nur mit 8-8½ nutzbaren Bits rechnen. Wenn man's besser braucht, dann muss man eine Menge sammeln. Da empfehle ich mal spaßeshalber eine hohe Quellimpedanz und einen kleinen Ko zu testen. Da wirst du präzise den von mir oben beschriebenen Effekt (Segment der Kondensator-Entladekurve) bekommen. Ich habe den pico ADC über die Jahre wirklich bis zum Abwinken getestet.
Als Breakout-Board bei Ali/eBay gehts noch billiger, aber du kriegst du
u.U. Klone, was aber nicht unbedingt schlecht sein muss.
Genau das, als Arduino-ProMini. Aktuelle Preise habe ich nicht, ich habe die um 1,30..1,75 €uro gekauft.
Nur die
Stromfresser-Extrabauteile auf dem Board musst du halt
runterlöten/knipsen.
Einen ProMini 8MHz habe ich hier mit einem externen 3V3-LDO an einer 18650 laufen, den AZ1117 und die LED runter. Der könnte auch direkt an der LiIon laufen, aber meine Peripherie nicht.
rp2040 ADC: sowieso schon schlecht. Derart hochohmig: noch viel
schlechter.
Zur Messung von Gleichspannung darf man der Quellimpedanz des
Messsignales mit einem Kondensator unter die Arme greifen.
Das hat deutliche Grenzen. In einer Akkuanwendung habe ich einen P-FET spendiert und schalte den Meßteiler nur alle 15 Minuten für 2..3 ms an den Akku. An anderer Stelle mit ADS1115 habe ich den Teiler 510k-470k dauerhaft am Akku, die 4µA kann ich dort ertragen.
Schade dass da nicht mehr geht, wo doch die Picos, besonders der Pico2, überragende Rechenleistung liefern. Das Update RP2350 schafft auch nur 0,5 Bit höhere Auflösung.
Mag sein, dass ein hochauflösender ADC und eine CPU auf einen Chip unvereinbar sind. Die neueren AVR sind auch nicht besser, getestet an einem Tiny1627.
Das Problem ist, dass das Tauschen der Stationen auch wieder
zusätzlichen Aufwand bedeutet, da die Logger in einer gewissen Höhe mit
Hilfsmitteln angebracht werden und diese mitzubringen ist umständlich.
Dann würde doch das Mitbringen eines Notebooks mit Ersatzbatterien als
machbarer einstufen und das Gehäuse mit MCU im Gelände öffnen, wie
bisher.
Dann sollte man sich eine Halterung ausdenken, die das vereinfacht.
Der Trade-off ist hier die einfache Anbringung gegen Diebstahlsicherung (bzw. Sicherung gegen niedrigschwelligen Vandalismus)
Wenn aus eurer Sicht die Implementierung von einem bedarfsmäßig
anstellbaren BLE Support + Erweiterungsboard keinen Sinn ergibt würde
ich das weglassen und warten, bis wir das ganze nochmal neu aufsetzen
können - dann vielleicht auch mit einer eigenen Platine.
Warum wollt Ihr einen Pico Pi UND einen ESP32-C3 verwenden, wenn der
ESP32-C3 auch noch die RTC, den Watchdog (zusammen als regelmäßiger
Wecker) und die BLE-Verbindung bietet?
Das ESP32-C3-Mini-Board (~5Euro) hat ein 2,54mm-Raster, das von
Steckbrettern und Lochrasterplatinen unterstützt wird.
Lieber würde ich das ESP32-Board mit einem anderen günstigen Kommunikationsmodul ersetzen, das BLE unterstützt als komplett auf ESP32 umzuschwenken, da ich die picos eigentlich gerne einsetzen würde
Weitere Aspekte: Beim ESP32-C3 komme ich bei der internen RTC-Zeitdrift wahrscheinlich in eine kritische Asynchronität bei Extremtemperaturen sodass es bei der Datenauswertung Probleme geben könnte - das wäre es aber mal wert zu testen
Auf das DS3231 würde ich also erst mal sowieso nicht verzichten weil kurzzeitiger Spannungsverlust z.B. durch Batteriewechsel prinzipiell vertragen werden soll vom System und die Zeitdrift beim ds höchstwahrscheinlich geringer ist
Den Watchdog könnte man möglicherweise ersetzen
TPL5110 hat im power-off Modus 0,035 µA Verbrauch, der ESP32-C3 5 µA im deep sleep
Wobei rechnerisch bei 1s Aktivität während der Messphase die Laufzeiten trotzdem ähnlich sind
Mal angenommen es sind 80mA Verbrauch während der Messung + ab und zu BLE-Unterstützung
ESP32-C3: 0.005 mA (Schlaf) + 90 mA* 1/600 = 0.155 mA
Laufzeit: 2400 mAh / 0.138 ≈ 645 Tage
TPL5110: 0.000035 mA (Schlaf) + 90 * 1/600 = 0.150 mA
Laufzeit: ≈ 667 Tage
Kriechströme und Selbstentladung nicht eingerechnet natürlich
Gibt es denn wirklich keine Möglichkeit eine BLE-Unterstützung günstig für den Pico zu bekommen?
Ich teste gerade bei -18°C ob die Laufzeit länger ist als 14 Tage (die
wir ihne Watchdog hatten)
Hast Du vielleicht auch die Möglichkeit, parallel eine LiIon 18650 Zelle
mit zu testen? Und sind die -18 °C Dauertempertur oder eher nächtliche
Tiefstwerte?
Nicht jetzt gleich aber im Verlauf der Entwicklung sicherlich
Danke für den Hinweis zu NiMH-LiIon und deine Meinung dazu
Noch etwas: Welcher Betrag ist denn bei Deiner Anwendung teuer bzw. zu
teuer? In der Regel ist die Arbeitszeit das Teuerste bei kleinen
Stückzahlen. Wenn man Deinen Datensammler braucht, sind ein paar Euro
Differenz doch kein nennenswerter Betrag, verglichen mit einem Bier in
der Kneipe oder einen Packung stinkender Glimmstengel.
Wir haben intern als Zielsetzung definiert für Board, Sensoren und Add-ons nicht mehr als 20 Euro zu brauchen pro Logger
Wobei jeder Euro Ersparnis gut gebraucht wird für andere Ausgaben -wir sind leider chronisch unterfinanziert
Aber es mangelt nicht an Einsatz für die Sache, daher ist das mit der Arbeitszeit relativ zu sehen
Ich würde es auch so machen wie andere es schon geschrieben haben.
Hört sich für mich nach einer sehr machbaren und sinnvollen Alternative an
Schade, dass es wohl keine günstige Möglichkeit gibt anders an BLE für den Pico ohne W zu kommen
Den Raspi Pico komplett weglassen und alles auf dem ESP machen.
Dann noch den TPL weglassen und in 1-2 MOSFET/Transistoren investieren
und den Interrupt Pin der RTC nutzen um die Spannung zyklisch zum Messen
einzuschalten.
Gibt es dazu ggf. eine Beispielschaltung, hätte da jemand eine Seite parat?
Wenn du später eine Platine selber machst die RTC gegen eine andere
tauschen. Ich mag auch die RV-3028-C7 von Micro Crystal.
Oder dann halt komplett umstellen auf einen dedizierten Funk uC (vlt.
Nordic).
Ok.. werde ich mir notieren. Dafür würde ich aber mehr Know-How brauchen und ob ich mich da so reinfuchsen kann dass das dann klappt.. alleine jedenfalls nicht.
Falls Interesse besteht das als OpenSource Projekt anzugehen, gerne melden..
Wenn du die Daten auf dem ESP speicherst hast du vermutlich sogar noch
mehr Platz frei als auf dem Raspi Pico (2 vs 4MB).
Die 2MB Flash sind ohnehin mehr als genug, die 4MB wären daher äußerst komfortabel.
Das Problem ist, dass das Tauschen der Stationen auch wieder
zusätzlichen Aufwand bedeutet, da die Logger in einer gewissen Höhe mit
Hilfsmitteln angebracht werden und diese mitzubringen ist umständlich.
Dienen diese Hilfsmittel der (De-)Montage oder werden sie benötigt, um
die Stationen in der gewissen Höhe zu erreichen?
An den Reed-Kontakt zum Aktivieren der BLE-Übertragung kommst du ohne
diese Hilfsmittel ran?
Die Hilfsmittel sind für Aufbau und Anbringung relevant und ein Magnet ließe sich leicht an einem Stab oder ähnlichem anbringen daher ist der Magnet die aus meiner Sicht einfachste Möglichkeit einen Trigger zu setzen
Als Breakout-Board bei Ali/eBay gehts noch billiger, aber du kriegst du
u.U. Klone, was aber nicht unbedingt schlecht sein muss.
Genau das, als Arduino-ProMini. Aktuelle Preise habe ich nicht, ich habe
die um 1,30..1,75 €uro gekauft.
Nur die
Stromfresser-Extrabauteile auf dem Board musst du halt
runterlöten/knipsen.
Einen ProMini 8MHz habe ich hier mit einem externen 3V3-LDO an einer
18650 laufen, den AZ1117 und die LED runter. Der könnte auch direkt an
der LiIon laufen, aber meine Peripherie nicht.
Schade, dass Rasp Pi den anderen Boards so unterlegen ist
Rainer W. schrieb:
rp2040 ADC: sowieso schon schlecht. Derart hochohmig: noch viel
schlechter.
Zur Messung von Gleichspannung darf man der Quellimpedanz des
Messsignales mit einem Kondensator unter die Arme greifen.
Das hat deutliche Grenzen. In einer Akkuanwendung habe ich einen P-FET
spendiert und schalte den Meßteiler nur alle 15 Minuten für 2..3 ms an
den Akku. An anderer Stelle mit ADS1115 habe ich den Teiler 510k-470k
dauerhaft am Akku, die 4µA kann ich dort ertragen.
Das würde mich sehr interessieren wie das im Detail aussieht
Schade dass da nicht mehr geht, wo doch die Picos, besonders der Pico2,
Da geht sogar deutlich mehr. Aber nicht ultimativ schnell. Ganz im Gegenteil sogar.
Es sind sogar 12-13 stabile und linearisierte Bits möglich.
Dazu muss man allerdings ein wenig Hardware Aufwand treiben, den unteren 5% Bereich und den oberen 95% Bereich verabschieden und für den Rest ein wenig der
Da verweise ich mal auf meine Tests vor ein paar Jahren hier im Forum. Der 32F407 rauscht auch wie ein Blätterwald wenn die Isobaren eng beieinander liegen.
Da verweise ich mal auf meine Tests vor ein paar Jahren hier im Forum
OK, deine Tests kenne ich nicht. Aber mehr als 8,x ENOB ist bei STM (oder TI) seither immer drin gewesen.
Dann wandeln die STMs je nach Typ zwischen 2-15MSPS. Man kann also im Vergleich zwischen 4-30-fach filtern. Je nach Typ macht der das in Hardware. Was dem Rauschen auch nochmal gut tut.
Dann wandeln die STMs je nach Typ zwischen 2-15MSPS. Man kann also im
Vergleich zwischen 4-30-fach filtern.
Der 32F407 konnte 3ADC (à 2.4Msps) zeitlich versetzt auf einem Kanal nutzen und brachte es bis auf 7.2 Msps. Soweit ich mich erinnere, musste man dann aber mit der einstellbaren Sampletime hinunter auf den kleinsten Wert gehen, was ihm bzgl. Rauschen nicht dienlich war.
Da geht sogar deutlich mehr. Aber nicht ultimativ schnell. Ganz im
Gegenteil sogar.
Bei einer Anwendung mit dem RP2040 hatte ich per hochohmigen Widerstand einen umschaltbaren Eingangsoffset vorgesehen, sodaß ein 'unpassendes' Ergebnis aus dem fehlerhaften Bereich verschoben werden konnte. Das Ergebnis mußte dann noch umgerechnet werden. Das ging recht schnell.
Auf der anderen Seite braucht der TO doch garkeinen hochgenauen ADC. Es geht allein darum, die Versorgungsspannung zu überwachen.
Wir haben intern als Zielsetzung definiert für Board, Sensoren und
Add-ons nicht mehr als 20 Euro zu brauchen pro Logger
Wobei jeder Euro Ersparnis gut gebraucht wird für andere Ausgaben -wir
sind leider chronisch unterfinanziert
Auf der einen Seite spiele ich mit dem Gedanken, meine Schaltung mal für einen SHT31 anzpassen - allein aus Neugierde. Auf der anderen Seite und damit Du irgendwie zu einer Lösung kommst, wäre eine gezielte Abschaltung der Versorgungsspannung vielleicht der einfachste Weg, Deine jetzigen Bauteile weiter zu verwenden. Dazu mußt Du auch entscheiden, wie das in der Praxis gehandhabt werden kann.
Ein wenig blöd ist, daß Du selber keine Platine machen kannst(willst) und damit immer abhängig davon bleibst, was sich an brauchbaren Fertigmodulen finden lässt.
Da geht sogar deutlich mehr. Aber nicht ultimativ schnell. Ganz im
Gegenteil sogar.
Bei einer Anwendung mit dem RP2040 hatte ich per hochohmigen Widerstand
einen umschaltbaren Eingangsoffset vorgesehen, sodaß ein 'unpassendes'
Ergebnis aus dem fehlerhaften Bereich verschoben werden konnte. Das
Ergebnis mußte dann noch umgerechnet werden. Das ging recht schnell.
Auf der anderen Seite braucht der TO doch garkeinen hochgenauen ADC. Es
geht allein darum, die Versorgungsspannung zu überwachen.
Es würde in meinem Fall reichen, wenn die erste Nachkommastelle bei der V-Angabe passt
Christie schrieb:
Wir haben intern als Zielsetzung definiert für Board, Sensoren und
Add-ons nicht mehr als 20 Euro zu brauchen pro Logger
Wobei jeder Euro Ersparnis gut gebraucht wird für andere Ausgaben -wir
sind leider chronisch unterfinanziert
Auf der einen Seite spiele ich mit dem Gedanken, meine Schaltung mal für
einen SHT31 anzpassen - allein aus Neugierde. Auf der anderen Seite und
damit Du irgendwie zu einer Lösung kommst, wäre eine gezielte
Abschaltung der Versorgungsspannung vielleicht der einfachste Weg, Deine
jetzigen Bauteile weiter zu verwenden. Dazu mußt Du auch entscheiden,
wie das in der Praxis gehandhabt werden kann.
Ein wenig blöd ist, daß Du selber keine Platine machen kannst(willst)
und damit immer abhängig davon bleibst, was sich an brauchbaren
Fertigmodulen finden lässt.
Genau dafür wäre der TPL5110 doch gut geeignet (wenn auch relativ teuer, aber einfach einzusetzen)?
Für eine Platine bräuchte ich Unterstützung.
Bei einer Anwendung mit dem RP2040 hatte ich per hochohmigen Widerstand
einen umschaltbaren Eingangsoffset vorgesehen, sodaß ein 'unpassendes'
Ergebnis aus dem fehlerhaften Bereich verschoben werden konnte.
Das ist ja genau das, was ich weiter oben mit den (1,3,5,7) × 2⁹ erwähnt hatte. Wenn man mit einem schmalen Band zwischen den vier /schlimmsten/ Punkten klar kommt, ist das der richtige Ansatz. Wird's breiter gebraucht, dann hat man etwas Arbeit vor sich.
Weitere Aspekte: Beim ESP32-C3 komme ich bei der internen RTC-Zeitdrift
wahrscheinlich in eine kritische Asynchronität bei Extremtemperaturen
sodass es bei der Datenauswertung Probleme geben könnte - das wäre es
aber mal wert zu testen
Das brauchst du nicht zu testen. Eine RTC mit integriertem Quarz und TCXO ist um Welten besser als jedes fertige µC-Modul. Hier geht's ja um etwas mehr (bzw. weniger) als konstante Zimmertemperatur.
Auf das DS3231 würde ich also erst mal sowieso nicht verzichten weil
kurzzeitiger Spannungsverlust z.B. durch Batteriewechsel prinzipiell
vertragen werden soll vom System und die Zeitdrift beim ds
höchstwahrscheinlich geringer ist
Nicht nur wahrscheinlich, siehe oben. Mit der Einschränkung "keine eigene Platine" ist ein DS3231-Modul sicher die beste Wahl.
Die Beiträge zum ADC sind ja ganz interessant, aber laut erstem (Schalt-)Bild wird doch nur die Akkuspannung gemessen? Dafür reicht der ADC vom 2040 doch locker? Die Widerstände sind zwar unbedingt nötig, aber man kann den Spannungsteiler z.B. zusammen mit dem Funk-Modul abschalten. Dann spielt sein Stromverbrauch keine Rolle und man misst unter Last. Die Leerlaufspannung ist doch eher irreführend.
Mein Ferrari braucht für die Fahrt zum Einkaufen auch zu viel Sprit, was kann ich am Ferrari ändern damit das besser wird, einen Rasenmähermotor einbauen ???
Ein RasPiPico Board braucht auf Grund der LED viel Strom. Entfernt man die, braucht es immer noch 1-2mA in dormant. Zum Strom sparen würde man sich 1/1000 davon wünschen. Der PR2040 alleine schafft das. Die RasPiPico Platine nicht.
RP2040 Datasheet, Section 4.9.4. sagt dir z.B. dass ein Spannungsteiler aus 1Meg/820k einfach zu hochohmig ist um noch irgendwas messen zu können, du brauchst einen Buffer-OpAmp.
Mit vernünftiger Wahl des uC (der z.B. direkt am Akku läuft und seine Betriebsspannung messen kann) wären die 57.5k der grösste Stromverbrauch, man wurde die Reedkontakt Schaltung anders bauen.
Meinst du die LED, welche im Normalzustand nach RESET ausgeschaltet ist?
Genau die, aber da warst Du schneller ;-)
Wenn die Versorgungsspannung hoch genug ist, kann man den Schaltregler durch einen LDO-Regler ersetzen. Kostet ein paar Cent. Andere Pico-Boards arbeiten von Hause aus mit einem LDO.
Eine RTC mit integriertem Quarz und
TCXO ist um Welten besser als jedes fertige µC-Modul. Hier geht's ja um
etwas mehr (bzw. weniger) als konstante Zimmertemperatur.
Es gibt auch 32,768 kHz TCXO, mit denen ein µC seine interne RTC laufen lassen kann. Aber gut, man braucht eine eigene Platine und viel heiße Luft: https://www.mouser.de/ProductDetail/SiTime/SiT1552AC-JE-DCC-32.768D?qs=dMZC7um9hO%2FIvYvvHhpVFQ%3D%3D
Wenn alle Logger ähnlicher Temperatur ausgesetzt sind, dürfte die Drift selbst bei einfachen, billigen Quarzen zwischen ihnen klein sein und bezogen auf die genannten 10 Minuten Intervalle dennoch synchron messen.
Da die Temperatur mit gemessen wird, könnte man die Drift ggf. 'herausrechnen'. Aber gut, das ist etwas für Sparfüchse ;-)
Das hat deutliche Grenzen. In einer Akkuanwendung habe ich einen P-FET
spendiert und schalte den Meßteiler nur alle 15 Minuten für 2..3 ms an
den Akku.
Die Zeitkonstante, die sich durch den Kondensator ergibt, musst du schon berücksichtigen. Wenn man alle 15 min einen Messwert bekommen möchte, liegen zwischen "2..3 ms" und "dauerhaft" immerhin 5½ Zehnerpotenzen, d.h. trotz Abschaltung und Zeitkonstante gibt es da erheblichen Spielraum.
spendiert und schalte den Meßteiler nur alle 15 Minuten für 2..3 ms an
den Akku. An anderer Stelle mit ADS1115 habe ich den Teiler 510k-470k
dauerhaft am Akku, die 4µA kann ich dort ertragen.
Das würde mich sehr interessieren wie das im Detail aussieht
Ich nehme an, dass Du den geschalteten Teiler meinst - habe ich vorhin für Dich gezeichnet. Der Teiler 26k1-9k09 passt bei Nutzung der internen 1,1V-Referenz, muß ggfs. angepasst werden.
Die Beiträge zum ADC sind ja ganz interessant, aber laut erstem
(Schalt-)Bild wird doch nur die Akkuspannung gemessen? Dafür reicht der
ADC vom 2040 doch locker? Die Widerstände sind zwar unbedingt nötig,
aber man kann den Spannungsteiler z.B. zusammen mit dem Funk-Modul
abschalten. Dann spielt sein Stromverbrauch keine Rolle und man misst
unter Last. Die Leerlaufspannung ist doch eher irreführend.
Das ist richtig, die Spannung unter Last wäre aussagekräftiger. Allerdings ginge es nur darum eine Info zu haben, ob die Akkus noch gut sind, ausgewechselt werden müssen oder auch ob sie zu schnell Spannung verlieren. Da ich zum Auslesen aber sowieso das Gehäuse öffnen muss ist die Frage, ob ich überhaupt die Akkuspannung messen muss. Es wäre gut gewesen, wenn wir mit BLE die Logger auslesen einen Überblick über den Akkustand zu haben und dann die Akkus rechtzeitig zu wechseln. So würde ich sie einfach wechseln wenn man sowieso aufmacht, unabhängig vom Ladezustand. Testen könnte man die Akkus dann ja auch zuhause.
Mein Ferrari braucht für die Fahrt zum Einkaufen auch zu viel Sprit, was
kann ich am Ferrari ändern damit das besser wird, einen Rasenmähermotor
einbauen ???
Gut, dass ich keinen Ferrari fahre, bei den Spritpreisen wäre ja jedes Mal ein Fertiglogger drin für einmal einkaufen fahren - Was ich sowieso lieber mit dem Rad erledige
Die LED ist natürlich deaktiviert für die meiste Zeit und läuft nur kurz beim Datenloggen zur Kontrolle.
Wenn alle Logger ähnlicher Temperatur ausgesetzt sind, dürfte die Drift
selbst bei einfachen, billigen Quarzen zwischen ihnen klein sein und
bezogen auf die genannten 10 Minuten Intervalle dennoch synchron messen.
Da die Temperatur mit gemessen wird, könnte man die Drift ggf.
'herausrechnen'. Aber gut, das ist etwas für Sparfüchse ;-)
Wahrscheinlich ja, aber die Funktion des Reboots bei Stromverlust wäre es mir weiterhin wert auf ein DS3231 zu setzen.
Ich nehme an, dass Du den geschalteten Teiler meinst - habe ich vorhin
für Dich gezeichnet. Der Teiler 26k1-9k09 passt bei Nutzung der internen
1,1V-Referenz, muß ggfs. angepasst werden.
Ok. Schade dass meine einfache 1Ohm-820k nicht läuft. Das Ohmsche Gesetz U=RxI greift also nicht bei GP26?
Wenn ich maximal 5,5 V Eingangsspannung habe geht immerhin nichts kaputt.
Sollte ich tatsächlich auf den ESP32-C3 umsteigen würde ich mir das mit dem geschalteten Teiler nochmal überlegen.. Danke für den Hinweis auf deine Schaltung.
Ok. Schade dass meine einfache 1Ohm-820k nicht läuft. Das Ohmsche Gesetz
U=RxI greift also nicht bei GP26?
Wenn ich maximal 5,5 V Eingangsspannung habe geht immerhin nichts
kaputt.
Wenn du den normalen Standard Pi Pico nimmst, dann benutze den Teiler welcher dort bereits auf das Board aufgelötet wurde.
Die genannte 1MΩ/820kΩ Version ist zu hochohmig um gescheit zu messen. Der ADC belastet das Ding nämlich und verfälscht das Ergebnis nicht unerheblich.
Wenn du den normalen Standard Pi Pico nimmst, dann benutze den Teiler
welcher dort bereits auf das Board aufgelötet wurde.
Die genannte 1MΩ/820kΩ Version ist zu hochohmig um gescheit zu messen.
Der ADC belastet das Ding nämlich und verfälscht das Ergebnis nicht
unerheblich.
Heißt das es ist kein weiteres Bauteil nötig? Ich kann mittels Firmware direkt ablesen?
So eine Implementierung würde ausreichen?
1
#include <hardware/adc.h>
2
static void vsys_adc_init(void) {
3
adc_init();
4
adc_gpio_init(29); // GPIO29
5
}
6
static uint16_t vsys_read_raw(void) {
7
adc_select_input(3); // ADC3
8
sleep_us(10);
9
return adc_read();
10
}
11
static int32_t vsys_read_mv(void) {
12
uint16_t raw = vsys_read_raw();
13
float adc_v = ((float)raw * 3.3f) / 4095.0f;
14
float vsys_v = adc_v * 3.0f; // Pico-intern ist VSYS auf 1/3 geteilt
Wenn du den normalen Standard Pi Pico nimmst, dann benutze den Teiler
welcher dort bereits auf das Board aufgelötet wurde.
Die genannte 1MΩ/820kΩ Version ist zu hochohmig um gescheit zu messen.
Der ADC belastet das Ding nämlich und verfälscht das Ergebnis nicht
unerheblich.
Heißt das es ist kein weiteres Bauteil nötig? Ich kann mittels Firmware
direkt ablesen?
So eine Implementierung würde ausreichen?#include <hardware/adc.h>
static void vsys_adc_init(void) {
adc_init();
adc_gpio_init(29); // GPIO29
}
static uint16_t vsys_read_raw(void) {
adc_select_input(3); // ADC3
sleep_us(10);
return adc_read();
}
static int32_t vsys_read_mv(void) {
uint16_t raw = vsys_read_raw();
float adc_v = ((float)raw * 3.3f) / 4095.0f;
float vsys_v = adc_v * 3.0f; // Pico-intern ist VSYS auf 1/3
geteilt
return (int32_t)(vsys_v * 1000.0f + 0.5f);
}
vsys_adc_init();
int32_t vsys_mv = vsys_read_mv();
printf("VSYS: %ld mV\n", (long)vsys_mv);
Ja, kannst du. Aber WICHTIG, erst nach frühestens 1ms nach dem Einschalten. Selbst so ein Winzling von 1nF muss erst aufgeladen werden.
Und zu schnelles, oft wiederholtes Lesen wird den gemessenen Wert etwas sinken lassen. Sechzehn mal aufsummieren und >> 4 sollte noch gut funktionieren. Da du aber wie oben angegeben keine Genauigkeit brauchst, sind das eher Betrachtungen für später mal wenn's nötig wird.
Ach ja, teilen durch 4096 wäre korrekt, macht aber den Braten auch nicht mehr fett.
Und zu schnelles, oft wiederholtes Lesen wird den gemessenen Wert etwas
sinken lassen. Sechzehn mal aufsummieren und >> 4 sollte noch gut
funktionieren. Da du aber wie oben angegeben keine Genauigkeit brauchst,
sind das eher Betrachtungen für später mal wenn's nötig wird.
Ach ja, teilen durch 4096 wäre korrekt, macht aber den Braten auch nicht
mehr fett.
Die genannte 1MΩ/820kΩ Version ist zu hochohmig um gescheit zu messen.
Der ADC belastet das Ding nämlich und verfälscht das Ergebnis nicht
unerheblich.
Wie meinst du das?
Einen belasteten Spannungsteiler zu rechnen, ist doch kein Hexenwerk. Gegenüber was wird das Ergebnis verfälscht?
Die genannte 1MΩ/820kΩ Version ist zu hochohmig um gescheit zu messen.
Der ADC belastet das Ding nämlich und verfälscht das Ergebnis nicht
unerheblich.
Wie meinst du das?
Einen belasteten Spannungsteiler zu rechnen, ist doch kein Hexenwerk.
Gegenüber was wird das Ergebnis verfälscht?
Die Eingangsdaten des µC-AD sind nicht stabil bekannt und dürften auch deutlich streuen. Ob das ohmsch-linear ist, weiß zumindest ich nicht.
Ich sehe nicht, dass man da einfach einen belasteten Spannungsteiler rechnen könnte, sondern nur, den Eingang niederohmig genug anzufahren.
Wie meinst du das?
Einen belasteten Spannungsteiler zu rechnen, ist doch kein Hexenwerk.
Gegenüber was wird das Ergebnis verfälscht?
Der Spannungsteiler samt 1nF Kondensator wird gepulst mit einem weiteren Kondensator kapazitiv belastet, präzise Parameter sind jedoch nicht vorhanden. Man darf davon ausgehen, das jeder sample-Vorgang eine Verfälschung in Form eines Teilabschnittes einer Kondensator Lade/Entladekurve darstellt. Je nach Geschwindigkeit der Abfragehäufigkeit sieht diese Belastung etwas anders aus.
Anders ausgedrückt, je hochohmiger der Eingang, desto lahmarschiger muss die Abfrage erfolgen.
Die Meinungen hier waren sehr klar, dass der Raspi nicht wirklich als Low-Power MCU geeignet ist, ich habe nicht aufgegeben und würde gerne eine vorgelagerte An/Aus-Schaltung versuchen, wenn das auch nicht klappt würde ich auf ein anderes Board umsteigen.
Mir hat jemand eine kleine Platine mit einer Flip-Flop/Latch Schaltung zur Verfügung gestellt testweise.
Leider klappt es nicht zuverlässig, dass der Pico den nächsten Alarm am DS3231 setzt, da er - so vermute ich - nicht genug Strom bekommt um vollständig zu booten und der Selbsthalt wird nicht zuverlässig gesetzt.
Das erste Wecken klappt mit dem INT-Signal nachdem er über USB angeschlossen war und den Alarm gesetzt hat, er wacht also 1x ordnungsgemäß auf, die Messung schließt er allerdings nicht richtig ab und danach geht er leider nicht mehr an.
Hat jemand evtl eine Idee, was das Problem ist und ob es an der Flip-Flop-Schaltung liegt? Es wurde hier ja eine bistabile Kippstufe empfohlen, warum muss es diese sein und keine einfache Flip-Flop/Latch?
Mir hat jemand eine kleine Platine mit einer Flip-Flop/Latch Schaltung
zur Verfügung gestellt testweise.
Was Du im Schaltplan zeigst ist keine Latch-Schaltung an sich. Die Latch-Funktionalität entsteht entsteht erst durch die Firmware auf dem Pico.
Wenn es nicht klappt dann beobachte doch erst mal mit dem Oszi Vsys und den Selbsthaltungs-Ausgang und schau was da für Spannungen in den verschiedenen Zuständen anliegen. Wenn die Zustände und deren Wechsel nicht offensichtlich sind, dann gib die über einen zusätzlichen Pin des Microcontrollers aus. Hier wird jetzt ein 4-Kanal-Oszi oder ein MSO hilfreich.
Die laut Schaltplan vorgesehenen MOSFETs sind nicht sonderlich geeignet für Selbsthaltung bei 3.3V-Systemen. Die Platine scheint dem Schaltplan nicht ganz zu folgen.
Die Platine könnte mit anderen Picos/bei anderen Temperaturen/mit anderen Stromquellen nicht tun, was von ihr erwartet wird.
Die laut Schaltplan vorgesehenen MOSFETs sind nicht sonderlich
geeignet für Selbsthaltung bei 3.3V-Systemen. Die Platine scheint dem
Schaltplan nicht ganz zu folgen.
Die Platine könnte mit anderen Picos/bei anderen Temperaturen/mit
anderen Stromquellen nicht tun, was von ihr erwartet wird.
Das hilft nur nicht viel, wenn Langzeitmessungen mit hohem Speicherbedarf notwendig sind.
Bei den auf RP2040 Boards typisch bestückten W25Qxyz hat man viel Platz.
Beim totalen Abschalten der Versorgungsspannung muß man jedoch etwas Programmieraufwand treiben, ihn voll zu nutzen. Schreibvorgänge verwenden immer 256 Byte 'pages' und bei Stromausfall kann das interne RAM nicht als Puffer verwendet werden.
Aber vielleicht hat Arduino hierfür schon fertige Lösungen.
Bei den auf RP2040 Boards typisch bestückten W25Qxyz hat man viel Platz.
Beim totalen Abschalten der Versorgungsspannung muß man jedoch etwas
Programmieraufwand treiben, ihn voll zu nutzen. Schreibvorgänge
verwenden immer 256 Byte 'pages'
Ganze Pages zu schreiben ist beim W25Q möglich, aber nicht Pflicht.
Aus dem Datenblatt:
9.2.13 Page Program (02h)
The Page Program instruction allows from one byte to 256 bytes (a page) of data to be programmed at previously erased (FFh) memory locations.
Du kannst also einzelne Bytes oder kleinere Datenblöcke schreiben. Wenn Du kleinere Datenblöcke schreibst, darf der Datenblock aber eine Page-Grenze nicht überschreiten. Der gesamte Schreibvorgang muss sich also innerhalb einer Page des Flash-Chips abspielen.
Ganze Pages zu schreiben ist beim W25Q möglich, aber nicht Pflicht.
Das ist nicht der Punkt. Blöd ist, daß eine 'page' für ein neues Beschreiben zuvor gelöscht werden muß.
to be programmed at previously erased (FFh) memory locations.
Eine einzelene Seite läßt sich nicht löschen, sondern es muß minimal ein 4 KB Sektor gelöscht werden. Soweit, so gut.
Angenommen ein Datenpaket besteht aus 8 Bytes, sodaß 512 Pakete in einen Sektor passen, der dann für komplettes, lineares Beschreiben ca. 500 mal gelöscht werden muß.
Das nagt an der Lebensdauer des Speichers und wird bei häufiger Nutzung relevant. Hier könnte es wegen der geringen Datenrate vielleicht egal sein, da nominell >= 100000 Löschzyklen genannt werden.
Bei einem µC, der im Schlafmodus nur noch einige µA benötigt, können die Daten im internen RAM gehalten werden, bis eine Seite geschrieben werden muß.
Angenommen ein Datenpaket besteht aus 8 Bytes, sodaß 512 Pakete in einen
Sektor passen, der dann für komplettes, lineares Beschreiben ca. 500 mal
gelöscht werden muß.
Das ist aber unnötig.
Man schreibt 8 Bytes ab [0], beim nächsten Mal dann 8 Bytes ab [8], …
Nach 256 Bytes, also 32 Einträgen wechselt man (transparent) zur nächsten Page.
Wohin man jeweils schreiben muss, kann mit einer simplen linearen Suche in Achterschritten geklärt werden. Das braucht nur Mikrosekunden.
Mit dem letzten Eintrag in die letzte beschreibbare Page, löscht man sofort den (ringförmig gesehen) folgenden Sector und hat wieder Platz für 8Pages×32 Einträge.
Wenn man sich 1MiB Platz für das Log lässt, dann kann man 131072 8Byte Pakete schreiben. Das ganze 100000 mal wiederholen (Lebensdauer lt. Datenblatt)
Wenn man jede Sekunde ein 8Byte Paket schreibt, sollte das, wenn ich mich nicht verrechnet habe, ca. 415 Jahre halten.
Man schreibt 8 Bytes ab [0], beim nächsten Mal dann 8 Bytes ab [8], …
Nach 256 Bytes, also 32 Einträgen wechselt man (transparent) zur
nächsten Page.
Wohin man jeweils schreiben muss, kann mit einer simplen linearen Suche
in Achterschritten geklärt werden. Das braucht nur Mikrosekunden.
Ja, genau.
Evtl. macht es Sinn zu den eigentlichen Datenbytes noch einen Zähler oder eine Prüfsumme hinzuzufügen. Denn sonst kann man einen Datensatz, der aus lauter Bytes mit 0xFF besteht, nicht von unbeschriebenen Bytes unterscheiden.
Wenn man also z.B. 8 Nutzdatenbytes mit Temperatur und Zeitstempel speichern möchte, legt man 12 Bytes ab. Wovon dann 4 Bytes eine CRC32 enthalten. Wenn die stimmt kann man sich recht sicher sein dass die Daten vollständig geschrieben wurden und gültig sind.
Die laut Schaltplan vorgesehenen MOSFETs sind nicht sonderlich
geeignet für Selbsthaltung bei 3.3V-Systemen.
Sage besser ungeeignet.
Könntest du da etwas konkreter werden?
Der BSS84 mit
1,2..10 Ohm bei U(GS) 5 Volt bei 100 mA Last
taugt in der Versorgungsleitung garnichts.
Es wäre zu schwierig, mal den Eingang am N-FET manuell auf Plus zu ziehen und zu messen, was bei aktivem µC-Board am Source des BSS84 ankommt? Mit aktiv meine ich den Betriebszustand mit maximaler Stromaufnahme!
Das Prinzip der Schaltung funktioniert, aber der µC muß natürlich zügig dafür sorgen, dess seine Betriebsspannung nicht gleich wieder wegstirbt.
So deutlich wollte ich es nicht sagen. Es besteht die Gefahr, dass mit den vorhandenen MOSFETs die Selbsthaltung im (unbeaufsichtigten) Einsatz nicht funktioniert.
Der Spannungsteiler samt 1nF Kondensator wird gepulst mit einem weiteren
Kondensator kapazitiv belastet, präzise Parameter sind jedoch nicht
vorhanden.
Wozu auch? Die Größe des Kondensator beträgt wenige pF. Auf präzise Werte kommt es da wahrlich nicht an, wenn es um die Abschätzung des Effektes geht.
Anders ausgedrückt, je hochohmiger der Eingang, desto lahmarschiger muss
die Abfrage erfolgen.
Wer sagt, dass es ein 1nF Kondensator sein muss und dass Batteriespannung, Temperatur oder Luftfeuchte mit irgendwelchen kSa/s abgefragt werden müssen?
Hest du dir einmal die Zeitkonstanten der Sensoren bzw. der Signale angesehen. Die Messrate darf gerne daran angepasst sein.
Angenommen ein Datenpaket besteht aus 8 Bytes, sodaß 512 Pakete in einen
Sektor passen, der dann für komplettes, lineares Beschreiben ca. 500 mal
gelöscht werden muß.
Ich denke, das ein einmaliges Löschen genügt. Danach kann man den Sektor (es dachte es heißt Page) nach und nach befüllen.
Bei einem µC, der im Schlafmodus nur noch einige µA benötigt, können
die Daten im internen RAM gehalten werden, bis eine Seite geschrieben
werden muß.
Diese Methode passt auch gut zum internen Flash Speicher. Ich weiß nicht wie viele Daten er erfassen will. Eventuell reicht die Lebensdauer des internen Flash schon aus.
Eventuell reicht die Lebensdauer des
internen Flash schon aus.
Hatten wir schon.
Sekündlich 8 Bytes in einen 1MiB Bereich schreiben und überschreiben reicht gerade einmal für 415 Jahre. Ist ein bisschen eng, aber mehr wird nicht garantiert.
So deutlich wollte ich es nicht sagen. Es besteht die Gefahr, dass mit
den vorhandenen MOSFETs die Selbsthaltung im (unbeaufsichtigten) Einsatz
nicht funktioniert.
Der untere N ist einigermaßen unkritisch, da dort nur 33µA fließen müssen. Das Problem befürchte ich im Plus-Pfad, dass der P-FET nicht niederohmig genug wird und der µC wegen Unterspannung wegstirbt.
Der ist immerhin ab 2,7V Gatespannung spezifiziert, aber gibt es denn nichts niederohmigeres? Für solche Basteleien setze ich NDP6020P ein, der aber schon lange nicht mehr hergestellt wird und im TO-220 nicht jedem gefällt - der ist Faktor 10 niederomiger als ein IRLML6302.
Der untere N ist einigermaßen unkritisch, da dort nur 33µA fließen
müssen. Das Problem befürchte ich im Plus-Pfad, dass der P-FET nicht
niederohmig genug wird und der µC wegen Unterspannung wegstirbt.
Seh ich auch so. BSS123 oder BSS138 tun es da wunderbar.
Der ist immerhin ab 2,7V Gatespannung spezifiziert, aber gibt es denn
nichts niederohmigeres? Für solche Basteleien setze ich NDP6020P ein,
der aber schon lange nicht mehr hergestellt wird und im TO-220 nicht
jedem gefällt - der ist Faktor 10 niederomiger als ein IRLML6302.
Mein Vorschlag wäre AO3401A. Aber bitte die echten und keine Fälschungen. Also nicht von ebay, Amazon, Aliexpress.
Der untere N ist einigermaßen unkritisch, da dort nur 33µA fließen
müssen. Das Problem befürchte ich im Plus-Pfad, dass der P-FET nicht
niederohmig genug wird und der µC wegen Unterspannung wegstirbt.
Seh ich auch so. BSS123 oder BSS138 tun es da wunderbar.
Es schadet niemandem, sich dort mit einem IRLML2502PbF auf die sichere Seite zu begeben. Kommt halt drauf an, ob man Bestand verbauen will oder bestellen muß.
Der ist immerhin ab 2,7V Gatespannung spezifiziert, aber gibt es denn
nichts niederohmigeres? Für solche Basteleien setze ich NDP6020P ein,
der aber schon lange nicht mehr hergestellt wird und im TO-220 nicht
jedem gefällt - der ist Faktor 10 niederomiger als ein IRLML6302.
Mein Vorschlag wäre AO3401A.
Gefällt mir, der ist deutlich nierohmiger als ein IRLML6302.
Aber bitte die echten und keine
Fälschungen. Also nicht von ebay, Amazon, Aliexpress.
Ja, das muß leider ständig wiederholt werden, der Markt ist von Betrügern dominiert.
Hatten wir schon.
Sekündlich 8 Bytes in einen 1MiB Bereich schreiben und überschreiben
reicht gerade einmal für 415 Jahre. Ist ein bisschen eng, aber mehr wird
nicht garantiert.
Genau, der 2MB Flash-Speicher ist üppig für solche Datenmengen und reicht für meinen Anwendung locker aus.
Das Prinzip der Schaltung funktioniert, aber der µC muß natürlich zügig
dafür sorgen, dess seine Betriebsspannung nicht gleich wieder wegstirbt.
Das scheint zu klappen, er misst sauber seine Intervalle, ich habe leider kein dafür geeignetes Strommessgerät, mein Multimeter taugt gerade Mal für V und mAh
Aber ich schätze dass er nicht über 100 mA zieht in der Spitze und das scheint es liefern zu können. Im Power Off sind wir unter 1 nA.
Wie das mit mehr Last wäre weiß ich nicht.
Ein bisschen umständlich ist für mich eher dass es erhebliche Probleme gibt UART Kommunikation mit Flash Speicher Zyklen zu kombinieren (man kann also während der USB seriellen Kommunikation nicht auf den Flash schreiben) und die Erkennung ob der Pico über USB oder über Batterie gespeist wird scheint hardwareseitig nicht trivial zu sein, jedenfalls ist er in einer vorversion immer wieder in den USB Mode gesprungen weil er fälschlich über GPio24 USB an gelesen hatte.. der vout läuft über VSYS nicht VBUS.. man muss anscheinend den GPio24 mehrmals ansteuern, damit das Signal stabil wird und den korrekten Zustand widergibt.
Ich habe es jetzt so gelöst dass ich USB Session mit einem weiten tinyUSB Befehl initiiere und während USB nicht auf den Flash geschrieben wird sondern die Daten nur gepuffert werden. Hauptziel ist sowieso die autonome Messung ohne USB Anschluss daher passt das für mich.
Ein bisschen umständlich ist für mich eher dass es erhebliche Probleme
gibt UART Kommunikation mit Flash Speicher Zyklen zu kombinieren (man
kann also während der USB seriellen Kommunikation nicht auf den Flash
schreiben)
Schreibst du Tolkiens Drei-Bänder plus Silmarillion bei jedem Messzyklus?
Selbst ein RP2040 arbeitet bei 125MHz mit 62.5MHz (DIV:2) Clock für den FLASH Chip. Das QSPI ist 4 Bit breit angebunden, braucht also zwei Übertragungen pro Byte (31.25 Mhz). Ergibt 32ns pro Byte.
Alles in allem 8.32µs pro 4 Byte CMD/ADR + 256 Byte für eine volle page. Acht Mikrosekunden sollte man schon erübrigen können.
Schreibst du Tolkiens Drei-Bänder plus Silmarillion bei jedem
Messzyklus?
Nicht die Datenmenge ist das Problem, sondern die zeitkritische
USB-CDC-Bedienung während Flash-Operationen auf einem XIP-System wie dem
RP2040.
Da ist mal gar nichts zeitkritisch.
Im schlimmsten Fall USB-Interrupt abschalten, FLASH schreiben, USB-Interrupt einschalten.
Die für USB erforderlichen Antwortzeiten liegen gleich um viele Größenordnungen über der Zeit für's FLASH schreiben.
Zumal bei USB-FS die IRQs auch nur einmal pro Millisekunde im Idle und acht Mal pro Millisekunde im aktiven Betrieb liegen.
Dazwischen kann man die Mondlandung berechnen und vorbereiten.
Das kommt mir für einen Mikrocontroller mit RTC immer noch arg wenig vor. Ich habe allerdings den Faden verloren, um welches Board es hier konkret geht. Kannst du das bitte aufklären?
Das kommt mir für einen Mikrocontroller mit RTC immer noch arg wenig
vor.
Ich vermute das ist im abgeschalteten Zustand. Sprich, die RTC läuft aus der Batterie. Der uC ist komplett abgeschaltet. Also wären es nur die MOSFETs/Biasing Widerstände/kriechströme über die PCB...
