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.
Untersuchung und Verbesserung des Timings bei der Ansteuerung der DS18B20 Sensoren unter MicroPython
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.
-
https://swarm.hiveeyes.org/api/hiveeyes/testdrive/area-38/fipy-workbench-01/data.txt?from=20190827T000000&to=now ↩︎
-
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 ↩︎
-
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/terkin-datalogger: Datalogger for MicroPython and CPython.?
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/terkin-datalogger: Datalogger for MicroPython and CPython. 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 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
page 6
*The power-on reset value of the temperature register is +85°C.
2 Likes
Just found another piece worth to be referenced here.
Moin.
Hier nochmal ein Auszug von meinem System.
Die Ursache für die Glitches finde ich aktuell noch nicht valide. könnte doch auch Reflexionen an den Pfostensteckern sein? Interessanterweise tauchen die Glitches nur bei den internen Sensoren auf
Es kann nicht an der Hardware liegen. Ich kann die selben ( nicht gleichen ) Sensoren an einem RaspberryPi und einem Python-Programm ohne viele Messwert-Ausreisser betreiben. Wenn ich sie an den FiPy mit MicroPython stecke, tauchen sie auf. Aus meiner Sicht gibt es noch Timing-Probleme im Onewire-Treiber.
Früher wurde schon viel diskutiert, wie man die Messfehler erkennt und dann mit ihnen macht.
Mein Ansatz war, Temperatursprünge ( z.B. 10°C innerhalb von 10 sec ) zu erkennen und dann einfach den Wert durch den letzten zu ersetzen, da die Temperatur nie so schnell wechseln kann.