4 posts were merged into an existing topic: HX711 Zittergeist
Untersuchung und Verbesserung des Timings bei der Ansteuerung der DS18B20 Sensoren unter MicroPython
Dank @robert-hh konnten wir hier die Treibersituation neulich ebenfalls verbessern. Beackert wurde das Thema bei…
Da haben wir selber geringfügig Hand angelegt, das ist aber schon länger her.
Habe jetzt nochmal an Clemens Panel nachgelegt.
Jetzt werden dort auch die Anzahl der Werte der DS Sensoren angezeigt.
allerdings kann man mit meiner Formel leider nicht eine zu große Zeitspanne wählen, da dann die Werte mehrer Messungen addiert werden.
1 Like
Nein keine Außreißer. Allerdings eine andere Beobachtung, wie drüben bei Solarregler regelt ab geschildert.
1 Like
Exzellent. Die Aufzeichnungen vom 4. August bis zum 10. August zeigen weiterhin keine Ausreißer, stimmts?
Coole Darstellung! Wer hat denn die gebastelt!
Man sieht die Anzahl der uploads / Datensätze und die Anzahl der übermittelten DS18B20-Sensoren, wenn es 6 sind werden alle korrekt gelesen und hochgeladen, wenn es 5 oder weniger sind nicht. Pfff … ja, keine Ausreißer mehr, aber eine ganze Menge verworfener, da falscher Messungen.
Considered to be a good thing™
Ich würde der genauen Ursache dafür gerne auf die Spur kommen. Die Wahrscheinlichkeit ist hoch, dass es am 1-wire Treiber liegt, der leider vollständig in Python implementiert ist. Innerhalb dessen, was da im SDK steckt, waren solche Ergebnisse fast zu erwarten.
Fazit: Hätte schlimmer kommen können.
Drüben bei Kontinuierliche Verbesserungen des Terkin-Datenloggers (600er) - #116 by Andreas fragte @Andreas, welche weiteren Dinge für
Ein weites Feld, essentiell sind für mich korrekte Messungen. Da wir die drop outs des DS18B20 wie hier berichtet Untersuchung und Verbesserung des Timings bei der Ansteuerung der DS18B20 Sensoren unter MicroPython - #61 by Andreas nicht kurzfristig in den Griff bekommen, würde ich für einen workaround auf Stromkosten plädieren, etwas so:
Falls CRC nicht passt, nochmal messen, begrenzt auf maximal 5x damit wir nicht uferlos in eine Schleife kommen. Das kostet uns dann max. gut 5 Sekunden Zeit und Strom für 5 Sekunden ohne deep sleep.
Vielleicht kommen wir auch günstiger bzgl der Zeit weg und müssen die Messung nicht neu anstoßen, sondern nur den Wert nochmal vom Sensor holen, weiß nicht, wo das timing schief läuft. .
Absolut. Für mich ist hier mit dem aktuellen Stand das korrekteste erreicht, was hier zu erzielen ist. Workarounds halte ich für keine gute Idee.
Da könnte schon noch weiter geforscht werden, ja. Da wir aber bereits so viel Zeit reingesteckt haben und nun ja absolut korrekt unterwegs sind, sehe ich weitere Arbeiten daran nicht als Bestandteil der Version 0.6.0.
Sehe ich anders, wenn Messwerte fehlen ist das alles andere als absolut korrekt und auf jeden Fall einen workaround wert.
Solange die Probleme mit dem Onewire- und/oder DS18B20-Treiber nicht gelöst sind, sollte man auf jeden Fall versuchen, fehlerhafte Messwerte zu erkennen, sei es durch CRC-Check oder Messwert-Toleranzen. Als Workaround würde ich im Fehlerfall den alten Wert übernehmen, denn die Temperatur kann sich gar nicht sprungartig verändern.
Ich werde meine BOB-Sensoren noch einmal an einem Raspi testen. Da sind mir solche Messwert-Ausreisser nur beim HX711 aufgefallen.
Wäre nicht eine Lücke oder null-Value deutlich sinnvoller? Lücken kann auch das Flux im Grafana (oder welche-Software-auch-immer) mit dem jeweils letzten Wert füllen (wenn einem die etwas längere Linie zwischen zwei Punkten doll stören sollte); aber nen alten Wert mit nem neuen Timestamp (schon in der Datenbank) zu versehen klingt in meinen Augen wesentlich unsauberer als ehrlich keinen Wert zu haben. (Wir wissen ja an genau diesem Punkt schon, dass der Wert nicht richtig ist.)
2 Likes
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 - #2 by Andreas 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.
-
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? ↩︎