Die ersten Tests mit 200 Messungen an 5 DS18B20 mit den überarbeiteten Onewire-Treibern sehen sehr gut aus.
Untersuchung und Verbesserung des Timings bei der Ansteuerung der DS18B20 Sensoren unter MicroPython
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.
Hallo Didi,
die Timing-Probleme beim Auslesen der DS18B20-Sensoren gehören seit der Einführung des nativen 1-Wire Treibers so ziemlich der Vergangenheit an. Die von @ckrohne bei Fehlende Meßwerte bei den DS18B20- und BME280-Sensoren beobachteten Lücken beim BME280 sind dem dort erwähnten, kürzlich erfolgten Beitrag Shut down peripherals regardless of using deep sleep or not · hiveeyes/terkin-datalogger@61713c7 · GitHub geschuldet – das wurde jetzt durch Power on I2C peripheral after power off · hiveeyes/terkin-datalogger@f35d9a6 · GitHub wieder gerade gezogen.
Hintergrund: Wir schalten nun nach jedem Meßvorgang die Peripherie ab, damit sich – gerade beim HX711 – die Wägezelle nicht erwärmt. Das passiert nun unabhängig davon, ob man die Firmware zum maximalen Stromsparen während der Betriebspausen in der Deep Sleep Konfiguration betreibt oder nicht.
Viele Grüße,
Andreas.
1 Like
ich benutze die files lib/onewire.py und sensors/ds18x20.py als Treiber. Es gibt die alte Version von @vinz und die neuere von @robert-hh
Hallo Didi,
Mehr über die native Version des Treibers gibt es hier oben im Gesprächsverlauf nachzulesen. Die aktuelle, abermals überarbeitete Fassung des Treibers von @robert-hh bei GitHub - robert-hh/Onewire_DS18X20: Classes for driving the DS18x20 sensor with the onewire protocol for Pycom MicroPython ist nun schnittstellenkompatibel mit beiden Varianten.
Die native Variante kannst Du über die – wie erwähnt schnittstellenkompatiblen – lowlevel Treiber ansprechen, wie wir sie an jener Stelle out-of-the-box im Terkin-Datenlogger erschlossen haben:
Damit das funktioniert, müsstest Du Dir ein aktuelles Dragonfly-Build der Pycom Firmware aufs Gerät spielen, siehe Dragonfly firmware for Pycom/ESP32. Diese Builds haben den oben erwähnten nativen Treiber per Support modonewire from vanilla MicroPython by amotl · Pull Request #356 · pycom/pycom-micropython-sigfox · GitHub an Bord.
Viele Grüße,
Andreas.
Leider kenne ich mich in github nicht so gut aus: ich habe nichts mit “onewire_native.py” und "ds18x20_native.py " gefunden.
Nur dieses Alte
und das von @robert-hh
Nativer 1-Wire/DS18B20 Treiber von Genuine MicroPython
Wir haben die Dateien bei der Beschaffung nur entsprechend benannt, damit wir wahlweise beide Varianten umschaltbar innerhalb der gleichen Codebasis betreiben können.
Das sind die richtigen, ja.
Das ist alter Code, die Änderungen von @robert-hh wg. CRC-Check sind da nicht drin.
Das ist der Python-Teil der nativen (C-Level) Implementierung des originalen MicroPython, die per Support modonewire from vanilla MicroPython by amotl · Pull Request #356 · pycom/pycom-micropython-sigfox · GitHub nun auch endlich(!) im Pycom-Universum zur Verfügung steht.
Die pure-Python Variante ist aus den bekannten und naheliegenden Gründen beim Timing Schrott – war es schon immer und wird es auch immer bleiben. Es gab bis dato halt nur nichts besseres.
Der CRC-Check passiert hier ebenfalls auf C-Level Ebene: DS18X20.read_scratch(rom) ruft per self.ow.crc8(buffer) im modonewire.c-Modul onewire_crc8(data).
1 Like
Ich versuche, die DS18B20-Treiberprobleme mit einem AZ-Delivery LogicAnalyzer einzukreisen.Dazu habe ich kleine Testprogramme geschrieben:
- DS18B20-A2.py mit lib/onewire_a.py und sensors/ds18x20_a.py von @vinz und
- DS18B20-B2.py mit lib/onewire_b.py und sensors/ds18x20_b.py von @robert-hh
und beobachte den Onewire-Bus mit dem LogicAnalyzer.
Erste Erkenntnisse:
Prog A2 startet das Messen für jeden Sensor einzeln
Prog B2 startet das Messen mit einem Befehl und ist damit schneller:
Leider tauchen die Messfehler in beiden Programmen auf:
Bei Prog A2 willkürliche Werte (88.6)
12. 24.6 24.6 24.6 24.6 24.6 24.7
13. 24.6 88.6 24.6 24.6 24.6 24.7
14. 24.6 24.6 24.6 24.6 24.6 24.7
Bei Prog B2 erkennt der CRC-Check den Fehler und gibt “None” aus ( bei mir ersetzt durch 999999 )
19. 24.7 24.8 24.5 24.7 24.8 24.8 err: 0
20. 24.7 24.8 24.5 24.7 999999 24.8 err: 1 rate: 120.0
21. 24.7 24.8 24.5 24.7 24.8 24.8 err: 1 rate: 126.0
22. 24.7 24.8 24.6 24.7 24.8 24.8 err: 1 rate: 132.0
23. 24.7 24.8 24.6 24.7 24.8 24.8 err: 1 rate: 138.0
24. 24.7 24.8 24.6 24.8 24.8 24.8 err: 1 rate: 144.0
25. 24.7 24.8 999999 24.8 24.8 24.8 err: 2 rate: 75.0
26. 24.7 24.8 24.6 24.8 24.8 24.8 err: 2 rate: 78.0
Die Fehler tauchen extrem unterschiedlich häufig auf, manchmal gibt es 100 x 6 Messungen keinen Fehler, oben gab es bei der 20. und 25. Messung Fehler.
Ich muss weiter forschen.
1 Like
Hi Didi,
Mit der neuen Basisfirmware von [1]
und diesen Treibern…
… bekommst Du bestimmt bessere Ergebnisse.
Viele Grüße,
Andreas.
2 Likes