Zwischenpufferung von Daten und Log-Informationen auf SD-Karte

Bei der Verheiratung der beiden Micropython-Stränge BOB/Hiverize und BOB/Hiveeyes gibt es noch das feature SD-logging, das momentan nur die BOB/Hiverize-Software hat.

Bei einem Telefonat mit @caro und @Diren haben wir dieses feature gerade höher priorisiert, da in der Anfangsphase gerade das loggen von errors und warnings für die Fehlersuche hilfreich sein kann.

Auch ein backup der Daten auf SD kann hilfreich sein, wenn wir in einem unreliablen WLAN Daten sammeln wollen.

Vorschlag

Konfiguration des loggings in mindestens 2 flavors

  • Daten
  • errors / warnings

Mein Vorschlag wäre auf der SD-Karte ein Verzeichnis mit der MAC-Adresse des nodes zu erstellen, dann hätte man beim ggf. späteren rumkopieren einen eindeutigen Identifier.

Darin zwei Verzeichnisse

  • /data/
  • /log/

und dort Dateien mit Daten / logs pro Tag mit dem Datum als Dateiname:

  • 2019-07-11_data.csv bzw.
  • 2019-07-11_log.txt

Damit wäre das recht übersichtlich, zu große Dateien gibt es nicht …

Höher als die Hochzeit? Oder nur mit auf Prio1. Wie gesagt nettes Feature aber ohne die Hardware zu tauschen die gerade im und auf dem Weg ins “Feld” ist, nicht möglich.
Ich würde zumindest die Grundfunkionalität im Webinterface implementieren (einfachstes Setting für BOB Teilnehmer) fehlende aber im Settings.py mögliche Konfigurationsmöglichkeiten könnte man dann erstmal den Spezis und Entwicklern überlassen.
Und und dann auf die Speicher Lösung stürzen.
Ich habe aber auch schon etwas mitgedacht und hab da schon was zu Hause liegen.
An welche Pin’s soll die SD gebunden werden oder eher gefragt welche sind noch zur freien Verwendung? Sie braucht eine SPI Schnittstelle = mosi, miso, cs, sck

Nein:

A post was merged into an existing topic: Remote-Debugging für den Terkin-Datenlogger

Gut ist richtig. GND und 3V3 sind klar Definiert daher hatte ich sie in der Überlegung weg gelassen.
Der 1 bit-SDIO Mode ist Recht kompliziert und relativ Fehleranfällig daher hatte ich ihn jetzt nicht explizit hervorgehoben. Wenn es dazu aber vernünftige Libarys gibt, nur zu gerne.

Gut ich melde mich Mal artig. Aber habe nur am Rande mitgewirkt und mich trotzdem intensiv mit dem Thema beschäftigt.
Die gefährlichste Hürde die ich hier sehe ist der Akkubetrieb. Die meisten SD-Karten machen sofort unter 3,3V einfach dicht oder Müll. Auch ist das Timing auf der Schnittstelle entscheidend. Der Stromverbrauch ist nicht so Kritisch im Standby nur wenige uA. Beim Schreiben oder lesen nur wenige mA.

Unter anderem wegen der Spannung verwende ich bei mir auch nur 12V AGM Akkus über step down. Da dort egal wie voll der Akku ist immer eine gleichwertige Spannung zur Verfügung steht.

Ich schlage vor, den festen Teil des Namens am Anfang zu haben:

  • data_2019-07-11.csv
  • log_2019-07-11.txt

und Unterverzeichnisse für Jahr und Monat einzuführen. Bei mir hat sich das seit 1999 auch mit alten DOS 8.3 Namen bewährt.
2019
1901
data_2019-01-01.csv

data_2019-01-31.csv
1902
data_2019-02-01.csv

Beispiel:

Das ist Wunschdenken - sieh Dir die Datenblätter von einschlägigen Herstellern an und studiere funktionierende Schaltungen mit SDIO im SD mode, - Du bist da um Größenordnungen zu optimistisch.

Apacer-, Panasonic-, Kingston-, Sandisk, Viking- und Swissbit -Datenblätter für SD(HC), die ich finden konnte, weisen einen standby current von 200µA bis zu 5 mA aus. Im read haben sie mehr als im write, peaks (RMS) für 10µs gehen auch mal auf 300 mA hoch (HS und DS mode). Die meisten haben sustained im read bzw write 60 / 50 mA und 120 mA peaks, auch bei ‘langsamen’ Übertragungsgeschwindigkeiten.

Der von mir genannte cap am supply der SD-Karte mit 1µ (keramisch) ist Minimum gegen diese peaks (parallel 100n keram. ist immer gut), häufiger sieht man 10µ sowie 22µ keram. - die Karten sind ja meist am Rand des PCBA verbaut, da sind supply rails weit weg von den Speisepunkten und daher höher impedant, es braucht dann halt wieder größere Kondensatoren direkt am Verbraucher.


ein paar Datenblätter, teilweise industrial grade SD(HC)

Die Wikipedia dazu:

2 Likes

2 posts were split to a new topic: Wo Daten auf dem node zwischenspeichern

wo evtl. nicht jedes Board WLAN haben mag, hat nicht jedes Board ne serialnumber?

Konkret beim ESP32 läufts eh aufs gleiche raus ;].

Ich habe das Logging auf SD-Karte bei hiverize/FiPy überarbeitet:
in logging.csv werden alle wichtigen Aktionen geloggt in z.B.

werden die Messdaten von heute ohne key mit “,” getrennt gespeichert.

Zusätzlich gibt es ein Steuerfile für gnuplot V5
image

Mit filezilla übertrage ich sie auf den PC,

PlotBOB.plt ist ein Steuerfile für gnuplot, das über Variable von 2020-02-09-plt gesteuert wird.


Man erkennt die CRC-Fehler der DS18B20, die ich willkürlich auf 15 °C gesetzt habe.
Auf dem BEEP - Bienenmonitor werden sie weggerechnet.

Ich möchte so die Fehlerhäufigkeit der Onewire-Treiber untersuchen: es war mir zu mühselig, die Fehler nur zu zählen. Ein Bild sagt mehr als 1000 Worte.
Ausserdem ist es praktisch, die Daten zu haben, wenn WLAN oder Internet Probleme machen.

1 Like