Untersuchung und Verbesserung des Timings bei der Ansteuerung der DS18B20 Sensoren unter MicroPython

This.

Vielen Dank für den Support, so sehe ich das an dieser Stelle derzeit auch und das ist nun auch der aktuelle Softwarestand.

Für mich bedeutet das absolut das höchste der Gefühle innerhalb des aktuellen Schlamassels, da die Firmware nun nach diesem aktuellen Stand absolut keine Glitches mehr in den Messungen zu produzieren und daher ausschließlich korrekte Werte zu liefern scheint – zumindest bezogen auf die Probleme beim Auslesen innerhalb der digitalen Sensordomäne, die uns lange Zeit plagten.

Jegliche Workarounds würde ich weiterhin sehr ungerne an dieser Stelle einbauen.

discodoc und Terkin 0.6.0 rufen laut nach Buschfeuerlöschung, daher muss ich kurzfristig weiterreiten und würde gerne erst bei der nächsten Gelegenheit wieder auf Optimierungen in diesem Bereich zurückkommen.

@roh und andere haben Interesse signalisiert, gemeinsam auf etwaige Streifzüge in Richtung Pycom Firmware selber bauen zu gehen, um zu schauen ob wir uns die esponewire.c und die zugehörige modonewire.c aus dem Genuine MicroPython Projekt zu eigen machen können.

Sehe es genauso wie @wtf – bloß nicht beschönigen!
Das kann man später sonst nicht mehr nachvollziehen, wenn es einmal darauf ankommen sollte.
Grafana oder Beep kommen sehr gut damit zurecht.

Wenn man größere Messabstände in Betracht zieht, um Strom zu sparen, muß man auf alle Fälle – wie @clemens vorgeschlagen hat – die Messung des Sensors wiederholen. Eine Fehlermeldung dass ein Wert nicht gelesen wurde, gibt die Firmware bereits aus. Da sollte es kein Problem sein, sie dort nochmal zu versuchen auszulesen.

2 Likes

Retry reading of failed DS18B20 sensors

Das ist auf jeden Fall wichtig und darf nicht unter den Teppich gekehrt werden. Ich bin da ganz bei Euch, dass wir als Kompensation und als maximal erträglichen Workaround ein Retry-Verfahren einführen können, das die konkret jeweils fehlerhaft gelesenen Sensoren (also dort wo vermutlich der CRC-Check negativ zuschlägt) weitere Male versucht, auszulesen.

Drüben bei [Backlog] Terkin-Datenlogger für BOB steht es nun auf der Agenda:

also was mich jetzt irritiert, nachdem alles scheinbar “stabil” läuft … dass die Sensoren extreme Temperatur ausreißer haben …

Sind das die besagten Timingprobleme beim 10sec Messintervall ?

Das scheinen noch Probleme im MicroPython-Treiber zu sein, denn die gleichen Sensoren haben bei mir auf dem Fipy mit der Arduino-IDE nicht zu solchen Messwert-Aussetzern geführt.
Die Frage ist jetzt, wie man damit umgeht, solange der Fehler im Treiber nicht behoben ist.
Ich hatte angeregt, die Aussetzer zu erkennen und dann den letzten gültigen Wert zu übertragen.
Andere möchten nur erkennen und dann nichts übertragen.

Hi Ingo und Didi,

das eine Gerät, das seit dem 27. August durchgehend Daten übermittelt, die bei [1] und [2] einzusehen sind, ist mit zwei DS18B20 Sensoren ausgestattet. Ich hatte bisher jedoch leider noch keine Gelegenheit, die entsprechenden Daten [3] durchzusehen [4].

Bei diesen Pycom-Gerätschaften kann ja wirklich alles mögliche im Busch sein und wir mussten leider unerwartet hart darum kämpfen, um den aktuellen, nun scheinbar einigermaßen robusten Stand zu erreichen.

Eigentlich hatten wir gehofft, uns langsam ernsthaft dem Thema HTTP- und webbasierte Konfiguration des Terkin-Datenloggers zur Implementierung eines Captive Portal widmen zu können und dass die Probleme hinsichtlich Laufzeitstabilität endlich der Vergangenheit angehören würden.

Um weiteren Ursachen für fehlerhafte Sensorlesungen auf den Grund zu gehen, brauchen wir Eure engagierte Mithilfe. Kannst Du uns für den konkreten Fall weitere Details über Dein genaues Setup zukommen lassen, @IngoP? Merci vielmals schon im Voraus!

Viele Grüße,
Andreas.


  1. Labor / [amo] FiPy Workbench ↩︎

  2. https://swarm.hiveeyes.org/api/hiveeyes/testdrive/area-38/fipy-workbench-01/data.txt?from=20190827T000000&to=now ↩︎

  3. https://swarm.hiveeyes.org/api/hiveeyes/testdrive/area-38/fipy-workbench-01/data.txt?from=20190827T000000&to=now&include=temperature.28ff641d8fc3944f.onewire:0,temperature.28ff641d8fdf18c1.onewire:0 ↩︎

  4. Vielleicht könnte jemand aus der Leserschaft hier mithelfen? ↩︎

Blockquote Kannst Du uns für den konkreten Fall weitere Details über Dein genaues Setup zukommen lassen, @IngoP

Was genau meinst Du mit SETUP ?

Wenn ich richtig mitgekommen bin, laufen deine FiPy’s mit der aktuellen Hiverize/FiPy master Firmware. Soweit ich weiß sind dort die Timingprobleme noch nicht behoben.
Und daher tauchen ab und zu die falschen Messwerte auf.

In der Hiveeyes Micropython Firmware ist dieser Fehler behoben, allerdings werden dort bei Fehlerwerten, diese nicht übertragen.

Ja genau.

Das SETUP ist der Original Sketch des KÖLN Workshops, der hier verteilt wurde. Die Systeme laufen in der Firmware mit dem LittleFS.

Habe mit der hiveeyes-Software und dem release 0.6.0 ein paar einzelne glitches in Form von deutlichen Ausreißern (die wir eigentlich schon als gefixed durch den CRC-check gesehen haben). Es sind einzelne Ausreißer wie hier mit exakt 85,00 °C:

Die 85,00 °C, sind ein Fehlercode des Sensors,

There is a footnote on page 4 which says “The power-on reset value of the temperature register is +85°C.”
so if you read 85 degrees it means it hasn’t done a conversion since the last power on.
You hadn’t wired it up properly so the sensor was being powered off and on periodically, which resets the register to 85 and that is why you got a valid CRC from it.

zwar unlogisch, warum der CRC dann nicht false ist, aber ok. Den sollten wir also noch filtern und nicht als valides sensor reading weiterreichen.

2 Likes

Setze doch die Lesezyklen mal auf 15 sec. und versuche doch mal die Auflösung des TempSensors auf 10 bit runterzudrehen … geht das via config ?

Ich glaube nicht, dass der Lesezyklus eine Rolle spielt. In der hiverize/FiPy-Software dauert das Lesen von BME280, HX711 und 5 mal DS18B20 gut 5 sec. Dann wird bis Sekunde 10 gewartet und dann von vorne. Ob man noch weitere sec wartet ist für den DS18B20 egal. Ich wüsste auch nicht, wo man die Auflösung einstellen kann.
Meine Sensoren haben gut mit dem Python von Raspbian funktioniert, mit dem MicroPython von PyCom gibt es Aussetzer. Allerdings ist der onewire-Treiber im Raspbian enthalten. Der legt eine Datei an, die man mit dem Python-Programm ausliesst. Das ist bei MicroPython ganz anders

While I’m inclined to believe this is true, I would be happy to have it confirmed better. Is there something about this detail within the datasheet?

Thanks for telling us. Is there any chance to switch over to GitHub - hiveeyes/hiveeyes-micropython-firmware: Hiveeyes MicroPython Datalogger - data logging for humans?

This is definitively a good thing!

Also 85Grad habe ich nicht als Ausreißer sondern 74 oder 63 … also auch in der Reihe und sehr skurril

Das kann nicht sein. Die Auflösung des DS ist auf 12 bit.
Das Datenblatt sagt da eine Latenz bis zum Ergebnis der Messung von rund 750msec.

Und in diesem Kontext kann ein Blick auf die Register LS und MS zur Datenbeschaffung helfen.

Die Werte der Ausreisser sind irrelevant. Da werden 1 oder mehrere Bit “verschluckt” und es entstehen komische Messwerte. Bei mir kam alles vor von 0°C, 29,4 oder 85 oder 258 oder 519 oder 2513 °C. Das falsche Bit ist zufällig, da kann man nichts aus ableiten, ausser es liegt ein falscher Messwert vor.

1 Like

Ich bin kein OO Programmierer, von daher ist das für mich schwierig… Bascom assembler und co kann ich unterstützen ;-)

Bei meinem PI klappt es hervorragend.

Vielleicht, nur so eine Idee, können wir mal bei espeasy in die libraries schauen…
Die funktionieren …

Ja, das trat auf, solange das Timing noch nicht in Ordnung war. Hier im Beitrag hatten wir uns das mühsam erarbeitet und das Problem bereits vor einiger Zeit bei GitHub - hiveeyes/hiveeyes-micropython-firmware: Hiveeyes MicroPython Datalogger - data logging for humans behoben [1] [2].

Ich habe das Gefühl, dass wir aneinander vorbeireden, da dieses Problem eben nur innerhalb der GitHub - Hiverize/FiPy noch nicht behoben wurde.

Es ist wirklich blöd, dass wir hier immer noch mit ganz unterschiedlichen Softwarevarianten zum gleichen Thema hantieren. Habt Ihr Ideen, wie wir diese Angelegenheit verbessern können?


  1. Untersuchung und Verbesserung des Timings bei der Ansteuerung der DS18B20 Sensoren unter MicroPython ↩︎

  2. onewire.py: Use library optimized for timing and with enabled CRC checks · hiveeyes/hiveeyes-micropython-firmware@226d40e · GitHub ↩︎

1 Like

… außer, wenn als erster Wert nach dem Bestromen der DS18B20 aus dem 2 byte -Tempraturregister 0550h (“85°C”) kommt, denn das ist klar ein Indiz, daß diese Register ausgelesen wurden, ohne, daß vorher eine temperature conversion dort gestartet wurde.

3 Likes

Ja genau @weef wir müssen aufpassen das, die Info welche @clemens gefunden hat, nicht gleich wieder im Caos um die Firmware-Versionen untergeht.
Hatte auch schon einen 85°C Wert, seit dem die Gliches in der hiveeyes-micropython-firmware behoben sein sollten.

Genau!

2 Likes