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.
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
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).
Ich versuche, die DS18B20-Treiberprobleme mit einem AZ-Delivery LogicAnalyzer einzukreisen.Dazu habe ich kleine Testprogramme geschrieben:
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.
Hi Didi,
Mit der neuen Basisfirmware von [1]
und diesen Treibern…
… bekommst Du bestimmt bessere Ergebnisse.
Viele Grüße,
Andreas.
Das scheint es gewesen zu sein: 1000 x 6 = 6000 Messungen ohne CRC-Fehler:
…
997. Werte: DS: 23.1 23.1 23.7 23.1 23.3 23.2 err: 0
998. Werte: DS: 23.1 23.1 23.7 23.1 23.3 23.2 err: 0
999. Werte: DS: 23.1 23.1 23.7 23.0 23.3 23.2 err: 0
1000. Werte: DS: 23.1 23.1 23.7 23.1 23.3 23.2 err: 0
Pycom MicroPython 1.20.1.r1-0.7.0-vanilla-dragonfly-onewire-i2s [daf40f36-dirty] on 2019-12-04; FiPy with ESP32
Auch das Timing ist OK:
Super! Braucht es für die “neuen” onewire-Treiber eine spezielle Konfigurationseinstellung in den settings?
Ich werde heute abend versuchen, die neuen Treiber in hiverize/fipy einzubinden.
Z.Z. läuft mein Testprogramm mit 13688 x 6 Messungen ohne CRC-Fehler.
