Untersuchung und Verbesserung des Timings bei der Ansteuerung der DS18B20 Sensoren unter MicroPython

wtf · November 23, 2019, 12:54pm

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.

didilamken · December 17, 2019, 9:34pm

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.

Andreas · December 17, 2019, 9:38pm

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.

didilamken · December 17, 2019, 9:44pm

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

didilamken · December 17, 2019, 9:49pm

Beispiel für 6 Sensoren:

Detailausschnitt:

Andreas · December 17, 2019, 9:54pm

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:

github.com

hiveeyes/terkin-datalogger/blob/f35d9a665d700a7d0c1408a542cb436a0b535530/tools/setup.mk#L85-L88


      
          	# Genuine MicroPython driver for Pycom MicroPython 1.11.
          	# https://github.com/micropython/micropython/tree/v1.11/drivers/onewire
          	@test -e $(target_dir)/onewire_native.py || $(fetch) $(target_dir) --output-document=$(target_dir)/onewire_native.py https://raw.githubusercontent.com/hiveeyes/micropython/ds18x20-power-on-reset-value/drivers/onewire/onewire.py
          	@test -e $(target_dir)/ds18x20_native.py || $(fetch) $(target_dir) --output-document=$(target_dir)/ds18x20_native.py https://raw.githubusercontent.com/hiveeyes/micropython/ds18x20-power-on-reset-value/drivers/onewire/ds18x20.py

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.

didilamken · December 17, 2019, 10:34pm

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

Andreas · December 17, 2019, 10:44pm

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.

didilamken · December 17, 2019, 11:06pm

Das ist alter Code, die Änderungen von @robert-hh wg. CRC-Check sind da nicht drin.

Andreas · December 17, 2019, 11:18pm

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).

didilamken · January 6, 2020, 11:11pm

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.

Andreas · January 6, 2020, 11:16pm

Hi Didi,

Mit der neuen Basisfirmware von ^[1]

https://packages.hiveeyes.org/hiveeyes/foss/pycom/vanilla/FiPy-1.20.1.r1-0.7.0-vanilla-dragonfly-onewire-i2s.tar.gz

und diesen Treibern…

… bekommst Du bestimmt bessere Ergebnisse.

Viele Grüße,
Andreas.

Dragonfly firmware for Pycom/ESP32 ↩︎

didilamken · January 7, 2020, 10:17am

Danke @Andreas, werde ich testen.

didilamken · January 7, 2020, 9:28pm

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:

kurzer Befehl convert_temp

750 msec warten
Daten von 6 Sensoren

130 msec Ausgabe auf OLED
nächster Befehl convert_temp

clemens · January 8, 2020, 10:05am

Super! Braucht es für die “neuen” onewire-Treiber eine spezielle Konfigurationseinstellung in den settings?

Andreas · January 8, 2020, 10:27am

github.com

hiveeyes/terkin-datalogger/blob/bbede7c3/settings.example.py#L333-L340


      
          {
              "id": "bus-onewire-0",
              "family": "onewire",
              "number": 0,
              "enabled": True,
              "pin_data": "P11",
              #"driver": "native",
          },

didilamken · January 8, 2020, 11:59am

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.

clemens · January 9, 2020, 8:39am

Gestern hat uns Guido diese Beobachtung berichtet:

Folgendes ist mir zu den Abbrüchen aufgefallen:
Ich hatte trotz update bjs zum 20.12 regelmässig (fast täglich) Abbrüche.
Am 20.12 wurde nach dem öffnen der Beute die Temperatur der Einzellfühler nicht mehr angezeigt. (Warum have ich nicht nicht geprüft).
Also nur noch Waage, Luftfeuchte inkl. Temperatur.
Interessant ist aber, dass ich seit dem keinen Abbruch mehr hatte.
Vielleicht gibt es einen Zusammenhang

Vielleicht hilft uns die Treiber-Verbesserung der DS18B20-Temperatur-Sensoren auch das gesamte Laufzeitverhalten der BOB-Software zu stabilisieren.

didilamken · January 9, 2020, 9:03am

Ich hatte im Herbst den Fall, dass die DS18B20 plötzlich ausfielen, und dann das Wlan. Der Fipy lief dann noch wochenlang ohne Absturz. Die Ursachen konnte ich nicht ermitteln.
Der Test der neuen DS18B20-Treiber verläuft so erfolgreich, dass ich noch keine Fehlmessung beobachten .konnte. Ich befürchte aber, dass ich noch etwas übersehen habe.

didilamken · January 21, 2020, 9:29pm

Für den Einbau der neuen DS18B20-Treiber in hiverize/FiPy brauche ich etwas Hilfe. Die Testprogramme nur mit DS18B20 und OLED laufen, aber in der BOB-Firmware gibt es Instabilitäten.
Im Testprogramm BOB-DS18B20.zip (24,2 KB) gibt es 3 Varianten:
onewire_a.py und ds18x20_a.py von @vinz,häufige Fehlwerte, CRC-Fehler nicht abgefangen
onewire_b.py und ds18x20_b.py von @robert-hh, häufige CRC-Fehler
onewire_c.py und ds18x20_c.py von @andreas, sehr seltene Messfehler, aber häufige Reboots in Hiverize/FiPy.
Leider sind x_c.py nicht ganz softwarekompatibel zu x_a.py und x_b.py