Hallo zusammen,
ich brauche mal wieder eure(n) Ratschlag/Bestätigung/Kritik.
Das hat unter anderem was mit Programmierung zu tun aber es geht eher um den Hardwareaufbau, deswegen mal hier im Offtopic-Bereich.
Es geht darum, dass für einen Versuch über mehrere Tage/Wochen Messwerte eines Sensors aufgenommen werden sollen. Die Abtastrate liegt bei 200 Hz, aber ich würde zur Sicherheit und falls man mal kürzere Versuche macht, wollen dass auch 500Hz möglich sind.
Der Sensor wird über den I2C-Bus angesprochen. Gerade steht die Überlegung im Raum, die Werte mit einem Rasperry Pi aufzunehmen. Ich habe Angst dass das nicht sonderlich robust aus. Da dachte ich mir, man könnte doch einen ESP32 mit erweitertem RAM (falls notwendig) die Werte auslesen lassen und in sowas wie eine "deque" ablegen. Der Pi macht einen Access-Point auf und immer wenn die"deque" voll ist, schiebt der ESP die Daten rüber. Dann hat der Pi Zeit die Werte in eine Datei zu schreiben oder zu sammeln und weiter zu schicken. Der Teil ist noch nicht festgelegt.
Was denkt ihr darüber? Kann der Pi alles alleine machen? Also im Takt von 500Hz die Sensorwerte entgegennehmen und diese dann bspw. auf einen Stick oder Festplatte schreiben. Oder wäre es sicherer sich die Aufgaben aufzuteilen? Und, da wir ja im Python-Forum sind, war das mit der "deque" hier das richtige Stichwort?
Ich bin mir nicht sicher ob die Frequenz für den Pi eher viel oder wenig ist und ob dann Linux zwischen drin mal noch ein zwei andere Aufgaben priorisiert und mir Werte verloren gehen oder sonst was.
Vielen Dank für eure Meinung und Hilfe.
Dennis
Raspberry soll robust Messwerte im Takt von 200Hz entgegen nehmen
Was ist das denn für ein Sensor, und wieviele Daten müssen gespeichert werden? Wie sind die Anforderungen an die zeitliche Genauigkeit und braucht es auch noch einen Echtzeitbezug?
Der ESP32 kann ja auch selbst direkt auf eine SD-Karte speichern. Würde ich auch machen, alleine aus Gründen der Redundanz.
dqueue ist schon prinzipiell richtig. Persönlich würde ich einen Ringbuffer aus einem Array mit den tatsächlichen Werten nehmen, weil das den Speicher bedarf reduziert, und du so viel wie möglich an Daten cachen willst. Und da wartet man auch nicht, die zu verschicken. Sondern macht das so kontinuierlich und schnell wie möglich, damit der Ring buffer nicht überläuft.
Der ESP32 kann ja auch selbst direkt auf eine SD-Karte speichern. Würde ich auch machen, alleine aus Gründen der Redundanz.
dqueue ist schon prinzipiell richtig. Persönlich würde ich einen Ringbuffer aus einem Array mit den tatsächlichen Werten nehmen, weil das den Speicher bedarf reduziert, und du so viel wie möglich an Daten cachen willst. Und da wartet man auch nicht, die zu verschicken. Sondern macht das so kontinuierlich und schnell wie möglich, damit der Ring buffer nicht überläuft.
Hi und danke für deine Antwort.
Der Sensor ist gerade noch im Prototypen-Status, ich kann deswegen kein Datenblatt liefern. Aber wir haben nächstes Jahr die Möglichkeit den Sensor in einer unserer Anlage zu testen. Da heute jemand einen Raspberry zum loggen der Daten vorgeschlagen hat, hatte ich ein ungutes Gefühl. Ich wollte mich aber erst mal informieren, bevor ich da mit so Halbwissen in die Diskussion einsteige.
Es werden Drücke gemessen. Und wenn wir sagen die Anlage läuft zwei Wochen durch und es werden tatsächlich 500 Messungen pro Sekunde gemacht, dann wären das 604.800.000 Messungen die gespeichert werden müssen. In einer Speichergröße kann ich das nicht ausdrücken. Obwohl, es werden Werte zwischen 0 und 500,00bar sein. Ich weis nicht ob ich jetzt ins philosophieren komme, aber dann hätte der Maximalwert 6Bits, dann bräuchte ich maximal 3,6288*10⁹ Bits == 453.600.000 Bytes == 453,6MB. Oder?
Einen Echtzeitbezug sehe ich als nicht notwendig.
Die Frage nach der zeitlichen Genauigkeit kann ich dir so leider nicht beantworten. Sprechen wir hier von der Konstanz der verstrichenen Zeit zwischen den Messungen? Hast du da ein Erfahrungswert dazu?
Das mit der zusätzlichen SD-Karte ist eine gute Idee.
Den Begriff Ringbuffer habe ich schon gehört/gelesen, das schaue ich mir mal an. Es wird vermutlich (leider)nicht meine Aufgabe werden, das zu programmieren, aber je nach dem ob ich mit meinen Bedenken recht habe, will ich mir natürlich etwas Hintergrundwissen aneignen, bevor ich mit rede.
Grüße
Dennis
Der Sensor ist gerade noch im Prototypen-Status, ich kann deswegen kein Datenblatt liefern. Aber wir haben nächstes Jahr die Möglichkeit den Sensor in einer unserer Anlage zu testen. Da heute jemand einen Raspberry zum loggen der Daten vorgeschlagen hat, hatte ich ein ungutes Gefühl. Ich wollte mich aber erst mal informieren, bevor ich da mit so Halbwissen in die Diskussion einsteige.
Es werden Drücke gemessen. Und wenn wir sagen die Anlage läuft zwei Wochen durch und es werden tatsächlich 500 Messungen pro Sekunde gemacht, dann wären das 604.800.000 Messungen die gespeichert werden müssen. In einer Speichergröße kann ich das nicht ausdrücken. Obwohl, es werden Werte zwischen 0 und 500,00bar sein. Ich weis nicht ob ich jetzt ins philosophieren komme, aber dann hätte der Maximalwert 6Bits, dann bräuchte ich maximal 3,6288*10⁹ Bits == 453.600.000 Bytes == 453,6MB. Oder?
Einen Echtzeitbezug sehe ich als nicht notwendig.
Die Frage nach der zeitlichen Genauigkeit kann ich dir so leider nicht beantworten. Sprechen wir hier von der Konstanz der verstrichenen Zeit zwischen den Messungen? Hast du da ein Erfahrungswert dazu?
Das mit der zusätzlichen SD-Karte ist eine gute Idee.
Den Begriff Ringbuffer habe ich schon gehört/gelesen, das schaue ich mir mal an. Es wird vermutlich (leider)nicht meine Aufgabe werden, das zu programmieren, aber je nach dem ob ich mit meinen Bedenken recht habe, will ich mir natürlich etwas Hintergrundwissen aneignen, bevor ich mit rede.
Grüße
Dennis
"When I got the music, I got a place to go" [Rancid, 1993]
6 Bit Auflösung wären eher ungewöhnlich wenig. 8 oder eher 16 Bit, also 2 Byte, damit 1kb/Sekunde. Bei freiem Speicher im ESP in der Größenordnung von 100-200KB also entsprechend einige Minuten Aufzeichnungszeit, die man Zeit hat, das ganze irgendwie weg zu schreiben oder zu schicken.
1KB/s sind wiederum nur 8Kbit/s, selbst mit einem hohen Sicherheitsfaktor von 10 sollte das von der Schreibgeschwindigeit der SD-Karte auch beim ESP mit SPI-Anbindung ausreichen. Realistisch sind da so 5MBit/s, passt also.
Ich würde das aber mit C++ oder Rust angehen, nicht, weil Python per se zu langsam wäre, sondern weil die SD-Karte sich auch mal ein paar 100mS an Bedenkzeit gibt, und man dann mit echten Tasks arbeiten muss, damit das nix aus dem Tritt bringt.
Zeitliche Genauigkeit meint wie präzise es 500Hz sein müssen. Wenn das nur so Pi-mal-Daumen muss, reicht ein normaler Pi. Bei höherer Genauigkeit muss dann IMHO schon PREEMPT_RT ran, und auch wieder eher C++ oder Rust. Die 2 Wochen Dauer ist so eine Sache, kann der Pi, aber ich wäre auch eher im Camp microcontroller.
1KB/s sind wiederum nur 8Kbit/s, selbst mit einem hohen Sicherheitsfaktor von 10 sollte das von der Schreibgeschwindigeit der SD-Karte auch beim ESP mit SPI-Anbindung ausreichen. Realistisch sind da so 5MBit/s, passt also.
Ich würde das aber mit C++ oder Rust angehen, nicht, weil Python per se zu langsam wäre, sondern weil die SD-Karte sich auch mal ein paar 100mS an Bedenkzeit gibt, und man dann mit echten Tasks arbeiten muss, damit das nix aus dem Tritt bringt.
Zeitliche Genauigkeit meint wie präzise es 500Hz sein müssen. Wenn das nur so Pi-mal-Daumen muss, reicht ein normaler Pi. Bei höherer Genauigkeit muss dann IMHO schon PREEMPT_RT ran, und auch wieder eher C++ oder Rust. Die 2 Wochen Dauer ist so eine Sache, kann der Pi, aber ich wäre auch eher im Camp microcontroller.
Das hört sich sehr gut an, vielen Dank.
Ich weis nicht wieso, ich hatte mal ein C++ Tutorial angefangen, aber die Motivation lies sehr schnell nach. Als du vor einiger Zeit hier im Forum mal geschrieben hattest, dass du dich zur Zeit mit Rust beschäftigst, hatte ich mal danach gegooglt und war irgendwie sofort motiviert das zu lernen. Komisch irgendwie. Hat zeitlich aber noch nicht hingehauen.
Ob es eine Anforderung der Genauigkeit gibt, muss ich mal nachfragen, aber das glaube ich nicht. Würde es jetzt auf die Genauigkeit ankommen, dann könnte dass der ESP aber auch oder geht das dann nur mit einem Pi und PREEMPT_RT? Eigentlich stört den ESP ja kein Betriebssystem, das dazwischen funken kann, dann sollte der so oder so die Genauigkeit haben wie Linux mit PREEMPT_RT.(?)
Wäre halt echt nervig, wenn der Pi irgendwie rumzickt und man wieder anfangen muss. Theoretisch sind wir ja gerade an einem Punkt, an dem man den Aufbau ordentlich planen kann. Den Vorteil sollten wir meiner Meinung nach schon nutzen.
Falls es zur ESP-Lösung klommt, gibt es Bedenken über eine Dauerhafte stabile Wifi-Verbindung der zwei Geräte um die Daten auf den Pi zu schicken oder sollte man die eher zwei eher mit einem Kabel verbinden?
Grüße
Dennis
Ich weis nicht wieso, ich hatte mal ein C++ Tutorial angefangen, aber die Motivation lies sehr schnell nach. Als du vor einiger Zeit hier im Forum mal geschrieben hattest, dass du dich zur Zeit mit Rust beschäftigst, hatte ich mal danach gegooglt und war irgendwie sofort motiviert das zu lernen. Komisch irgendwie. Hat zeitlich aber noch nicht hingehauen.
Ob es eine Anforderung der Genauigkeit gibt, muss ich mal nachfragen, aber das glaube ich nicht. Würde es jetzt auf die Genauigkeit ankommen, dann könnte dass der ESP aber auch oder geht das dann nur mit einem Pi und PREEMPT_RT? Eigentlich stört den ESP ja kein Betriebssystem, das dazwischen funken kann, dann sollte der so oder so die Genauigkeit haben wie Linux mit PREEMPT_RT.(?)
Wäre halt echt nervig, wenn der Pi irgendwie rumzickt und man wieder anfangen muss. Theoretisch sind wir ja gerade an einem Punkt, an dem man den Aufbau ordentlich planen kann. Den Vorteil sollten wir meiner Meinung nach schon nutzen.
Falls es zur ESP-Lösung klommt, gibt es Bedenken über eine Dauerhafte stabile Wifi-Verbindung der zwei Geräte um die Daten auf den Pi zu schicken oder sollte man die eher zwei eher mit einem Kabel verbinden?
Grüße
Dennis
"When I got the music, I got a place to go" [Rancid, 1993]
Rust in embedded ist schon ne Herausforderung, aber wenn es dir mehr zusagt als C++, go for it.
Der ESP sollte genau genug sein. Der hat zwar auch ein OS (FreeRTOS), aber aus diversen Gründen ist das berechenbarer. Darum ja auch das RT in RTOS.
Bei Wifi gibt es immer Bedenken. Darum wäre mein Ansatz redundant, zb ESP mit SD-Karte plus Wifi und ein zweiter ESP oder ein Pi.
Der ESP sollte genau genug sein. Der hat zwar auch ein OS (FreeRTOS), aber aus diversen Gründen ist das berechenbarer. Darum ja auch das RT in RTOS.
Bei Wifi gibt es immer Bedenken. Darum wäre mein Ansatz redundant, zb ESP mit SD-Karte plus Wifi und ein zweiter ESP oder ein Pi.
Guten Morgen,
vielen Dank für deine Hilfe.
Dann kann ich das so mal ansprechen und bin auf die Reaktion gespannt.
Vielleicht finde ich demnächst mal Zeit um mich intensiver mit einer anderen Sprache auseinander zu setzen.
Grüße
Dennis
vielen Dank für deine Hilfe.
Dann kann ich das so mal ansprechen und bin auf die Reaktion gespannt.
Vielleicht finde ich demnächst mal Zeit um mich intensiver mit einer anderen Sprache auseinander zu setzen.
Grüße
Dennis
"When I got the music, I got a place to go" [Rancid, 1993]