6 posts were merged into an existing topic: Diskussion über die Ansteuerung der Sensordomäne auf Pycom Geräten
Untersuchung und Verbesserung des Timings bei der Ansteuerung der DS18B20 Sensoren unter MicroPython
Hallo nocheinmal,
P.S.: Bitte nicht vergessen, den Garbage Collector während der Messung abzuschalten.
Viele Grüße,
Andreas.
Korrekt, das müssen wir noch nachreichen.
@robert-hh was so kind to upload his improved 1-Wire/DS18X20 driver to a repository on GitHub.
This will enable us to contribute some minor improvements. Thank you so much!
Wir haben hierzu gerade noch entsprechende Eingaben gemacht.
- DS18B20: Mask power-on reset value 0550h within the scratch memory of the temperature register · Issue #7 · robert-hh/Onewire_DS18X20 · GitHub
- DS18B20: Mask power-on reset value 0550h by amotl · Pull Request #8 · robert-hh/Onewire_DS18X20 · GitHub
- drivers/onewire/ds18x20.py: Mask power-on reset value 0550h by amotl · Pull Request #5338 · micropython/micropython · GitHub
Vielen Dank für Eure Rückmeldungen und Verbesserungsvorschläge dazu!
Finally, we have been able to make this work on Pycom MicroPython.
We have published respective firmware images called 0.7.0-vanilla-dragonfly-onewire. See also Inofficial firmware bakery for Pycom/ESP32 devices - #2 by Andreas.
Die Testhardware läuft ab sofort mit FiPy-1.20.1.r1-0.7.0-vanilla-dragonfly-onewire, die Meßwerte können unter amo-fipy-workbench betrachtet werden.
Die Implementierung der Maskierung der 85°C auf Treiberebene geht u.U. doch einen Schritt zu weit:
@robert-hh said within #8:
In the new version I intentionally did not implement this test. 85°C is a valid result, which must not be suppressed by the driver. Checking must be done by the calling code, which knows the context.
I see your point here. Thanks!
Slight out-of-band signalling using a semaphore. Good thing. Danke!
So kann man die Implementierung der Spezifikation im Treiber selbst unterbringen, aber der calling code kann dann selbst je nach Kontext unterscheiden, wie Robert es vorschlägt.
Danke für diesen Hinweis, ich habe ihn weitergegeben [1][2][3]. Da wir dort im 1-Wire/DS18X20-Treiber derzeit leider nur einen diskreten Rückgabewert haben und keine Datenstruktur, wird es momentan vermutlich schwierig, das entsprechend unterzubringen.
Vielen Dank @weef!
DS18B20: Mask power-on reset value 0550h within the scratch memory of the temperature register · Issue #7 · robert-hh/Onewire_DS18X20 · GitHub ↩︎
DS18B20: Mask power-on reset value 0550h by amotl · Pull Request #8 · robert-hh/Onewire_DS18X20 · GitHub ↩︎
drivers/onewire/ds18x20.py: Mask power-on reset value 0550h by amotl · Pull Request #5338 · micropython/micropython · GitHub ↩︎
Die ersten Tests mit 200 Messungen an 5 DS18B20 mit den überarbeiteten Onewire-Treibern sehen sehr gut aus.
1 Like
Exzellent, vielen Dank für die Rückmeldung. Mittlerweile sind wir schon eine Runde weiter: @wtf konnte bestätigen, dass die neuen C-level Treiber auch ordnungsgemäß laufen, siehe Dragonfly firmware for Pycom/ESP32 - #6 by Andreas sowie Annapurna firmware images for Pycom/ESP32.
P.S.: Die aktuellste Variante des pure-Python Treibers von Robert beherrscht nun auch Parasite Power Mode, siehe GitHub - robert-hh/Onewire_DS18X20: Classes for driving the DS18x20 sensor with the onewire protocol for Pycom MicroPython.
Das ist das aktuelle Ergebnis hierzu, @robert-hh hat es der Dokumentation des Treibers hinzugefügt. Danke nochmals an @weef!
Diskussion
Dokumentation
Der DS18B20-Treiber ist deutlich verbessert worden. Z.Z. wird bei ca. jeder 500. bis 600. Messung ein CRC-Fehler erkannt. Die kann man gut behandeln, durch Auslassen oder den letzten Wert.
Das Problem mit den 85°C ist kaum eins, vor jeder Messung gibt es “convert_temp”, “read_temp” ergibt dann einen Wert oder bei CRC-Fehler “None”.
Nicht erkannte Fehler habe ich bislang noch nicht gesehen.
Danke an @amotl und @robert-hh
1 Like
@robert-hh just shared this very interesting analysis with me. Thanks a bunch!
2 Likes
Mittlerweile haben wir den modonewire C-level Treiber für uns erschließen können und wir sind zuversichtlich, dass etwaige Timing-Probleme damit endlich der Vergangenheit angehören.
Aktiviert werden kann der “native”-Treiber über folgende Konfigurationseinstellung im Terkin-Datenlogger.
Dank @wtf’s Testaufbau konnten wir bereits vorsichtige Erfolge dazu verzeichnen.
I just wanted to share this piece just recently observed by @wtf, @roh and @weef even with the C-level modonewire driver. It’s probably not timing related but… no idea - is it a borked counterfeit!?
?? Hmm!? Grafana artefact? Had someone a look at the raw data? Looks like an other resolution, not 12 bit but … but why exactly 0.5 steps??
I don’t believe in Grafana artefacts here. When you look closely: Rarely there are /some/ readings which are not .0 or .5 … according to some document about counterfeit DS18B20 all DS18B20 we got from Bremen have to be assumed to be counterfeits: When we had some timing-problems in the beginning we got for 5 of 6 sensors the reading “25” which shall be a counterfeit-indicator (original DS18B20 state “85”). (For the sixth sensor we had a correct timing/reading.)
We should probably do some switch-devices-tests. But so far we only have these six sensors.
Ich teste in hiverize/fipy mit ATOM die von @robert-hh modifizierten DS18B20-Treiber. Da sind mir einige Ungereimtheiten aufgefallen, die ich aber noch nicht präzise formulieren kann.
Grob kann man sagen:
In reinen Testprogrammen nur mit DS18B20 und OLED-Display gibt es selten CRC-Fehler, die den eindeutigen Wert “None” ausgeben, während der alte Treiber beliebige Fehlwerte (Ausreisser) ausgab.
Im vollen Messprogramm sind die CRC-Fehler deutlich häufiger, mit der Firmware 1.20.xx häufiger als mit Firmware 1.18.xx
Die Methode ds18b20.scan() findet nicht immer alle Sensoren.
Ich kann mit dem Mini-LogicAnalyzer von az-delivery sauber das Protokoll decodieren, habe aber noch keine Fehlerursache gefunden.