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

IngoP · July 15, 2019, 12:44pm

das macht Sinn, denn bei der 12bit Auflösung braucht der Chipp alleine 750ms zum Rechnen. Kann gut gehen mit 0.75s muss aber nicht.
Runter auf 11bit denke ich würde auch dem gelieferten Aergebnis bei 0,5 Grad Abweichung noch genüge tun.

didilamken · July 16, 2019, 7:25pm

Ich vermute ein Zeit-Problem im Treiber ds18x20.py, da (zufällig) ein oder mehrere Bit abgeschnitten werden und dadurch absurde Messwerte entstehen. Ich habe mein Programm ohne Korrektur eine halbe Stunde laufen lassen: es gab 2 Fehler

a: 6. korr> 4. Temp.: 278.1 C -> old: 22.1 C
2019-07-16 18:50:18 BME: 23.6 C 1017.6 mbar 51.2 % HX : 9.4 kg DS: 22.1 C 23.6 C 22.1 C 278.1 C 23.5 C 0.0 C

b:118. korr> 1. Temp.: 2070.1 C -> old: 22.1 C
2019-07-16 19:08:58 BME: 23.5 C 1017.6 mbar 50.5 % HX : 9.7 kg DS: 2070.1 C 23.8 C 22.1 C 22.1 C 23.6 C 0.0 C

Da alle 10 sec gemessen, aber nur alle 20 sec auf der Webseite angezeigt und alle 2 min der Graph neu gezeichnet wird, wird kräftig gemittelt, so dass man im Graph nicht den eigentlichen Fehler erkennen kann.

Der Fehler b war um 19:08:58 Kanal 1 Wert 2070.1 °C ; im Graph um 21:08 Wert 192.8°C

Da mir solche Fehler auf dem RaspberryPi mit Python 2.7 nicht aufgefallen sind, vermute ich den Fehler im MicroPython-Treiber.

Andreas · July 16, 2019, 9:20pm

Wir haben jetzt kürzlich folgendes gemacht:

Weitere Details wie oben bei fiddling with the timing in onewire.py werden folgen, vielleicht kannst Du hier schon einmal vorfühlen?

didilamken · July 16, 2019, 10:01pm

Leider sind die Treiber

ds1x20.py in hiverize/FiPy-master und
sensor_ds18x20.py in hiveeyes-micropython-firmware-master

so unterschiedlich, dass ich (noch) nicht daran etwas ändern könnte.

Andreas · July 17, 2019, 10:13am

Hi Didi,

es gibt überall tiefere Treiberschichten. Die Datei FiPy/ds18x20.py at master · Hiverize/FiPy · GitHub enspricht der pycom-libraries/onewire.py at master · pycom/pycom-libraries · GitHub, dort aber ohne die class OneWire, an der die Änderungen vorzunehmen sind.

Im Gegensatz dazu hat hiveeyes-micropython-firmware/sensor_ds18x20.py at master · hiveeyes/hiveeyes-micropython-firmware · GitHub mit dem Sensor-Auslesen selbst überhaupt nichts zu tun, das ist nur ein kleiner Wrapper.

Viele Grüße,
Andreas.

Andreas · July 18, 2019, 10:33pm

DS18B20 recap re. timing and beyond

Wir haben hier nochmal eine Bestandsaufnahme gemacht, um welche Aspekte wir uns kümmern wollen. Das Timing in den Griff kriegen führt die Liste eindeutig an.

Drüben bei Timing things on MicroPython for ESP32 findet man weitere Details zu den Hintergründen der Timing-Probleme aus nächster Nähe.

Backlog

Timing bei der Conversion verbessern, siehe DS18B20: Extend time between starting the · hiveeyes/hiveeyes-micropython-firmware@4926890 · GitHub.
Timing beim Palawer verbessern – siehe auch Timing things on MicroPython for ESP32.
- Tune Pycom’s onewire.py timing by better controlling the garbage collector.
  sowie
- Tune Pycom’s onewire.py timing by mitigating some invocations of sleep_us(1).
Asynchrone Auslesestrategie bei conversion vs. reading richtig anwenden, wie vorgesehen.
CRC-Checks überprüfen.

CRC-Checks überprüfen

Q: Srsly?
A: Ja, die Funktion def crc8 wird nämlich nirgends innerhalb der Bibliothek gerufen.

github.com

pycom/pycom-libraries/blob/master/examples/DS18X20/onewire.py#L106-L121


def crc8(self, data):
    """
    Compute CRC
    """
    crc = 0
    for i in range(len(data)):
        byte = data[i]
        for b in range(8):
            fb_bit = (crc ^ byte) & 0x01
            if fb_bit == 0x01:
                crc = crc ^ 0x18
            crc = (crc >> 1) & 0x7f
            if fb_bit == 0x01:
                crc = crc | 0x80
            byte = byte >> 1
    return crc

Meiomei.

Andreas · July 18, 2019, 11:38pm

I will check that again, but haven’t come across it yet.

Apart from following the guidelines you outlined at Timing things on MicroPython for ESP32 - #4 by roh, I really would love to have a mature system-level DS18B20 library available for Pycom MicroPython, effectively written in C or C++ and made available through safe API calls from the MicroPython runtime.

Andreas · July 19, 2019, 12:40am

Research

`onewire.py` at Pycom

It looks like tuning onewire.py already has a dedicated thread on the Pycom Forum.

Pure-Python Drivers

The first version of the library by Damien George.

https://forum.micropython.org/viewtopic.php?p=6255&sid=62efc19370fc777631385c2d0df6106f#p6255

The vanilla MicroPython drivers.

The vanilla Pycom drivers.

The OneWire library ported to MicroPython by Jason Hildebrand looks promising. It does

Another guy of Jason Hildebrand fame.

The RMT RAM variant by Yann Vernier also looks very interesting, see GitHub - lonetech/LoPy: LoPy code (MicroPython on ESP32 module). This probably works around the indeterministic timing induced by the serial RAM.

# RMT RAM is divided into 8 blocks of 64 words, each holding 2 entries. 
ram = uctypes.struct(RMT_BASE+0x800, (uctypes.ARRAY | 0x0, uctypes.UINT32 | 64*8))

Drivers written in C

Looking under the hood of the vanilla MicroPython core also brings up some things.

Miscellaneous

Some arbitrary resources about reading the DS18B20 from MicroPython.

Andreas · July 28, 2019, 3:36pm

Zu diesem Thema lief uns gerade noch die esponewire.c für ESP32 aus dem ESP32-Port des aktuellen Genuine MicroPython über den Weg, die dort timing-kritische Dinge maschinennah implementiert – gerade das Lesen und Schreiben von Bits auf den Bus und die Einhaltung des Protokolls und der Contenance.

Dass diese Angelegenheit beim Pycom MicroPython in pure-Python per onewire.py implementiert ist, mag man zwar fast nicht glauben , zeigt aber umso deutlicher, dass diese Geräte vom Hersteller nicht unbedingt dafür ausgelegt wurden, Meßdatenlogger zu sein, sondern eher, um ihren Dienst als universelle Telemetriemodembausteine zu tun.

Auch hier wäre es nett, wenn wir bei Gelegenheit auch auf die maschinennahe Programmierung der Pycom-Geräte zugehen würden. Vielleicht ist es machbar, fehlende Funktionalitäten ggf. selbst nachzurüsten.

Meow.

roh · July 28, 2019, 4:15pm

momentan patchen wir das mpy von pycom noch garnicht, korrekt?
ich befuerchte wenn wir da anfassen wollen kommen wir nicht dran vorbei.

wenn ich micropython/onewire.py at v1.11 · micropython/micropython · GitHub mit o.g. python code vergleiche, denke ich das es moeglich sein sollte den pycom kram auf den c write/reset/readbit/byte umzustellen.

das generische onewire ist auch da python, nur der lowlevel kram ist c

leider schmeisst pycom den ds18x20 support mit in das gleiche file.
bei mpy liegt das daneben als eigenes file das auf den onewire funktionen aufbaut

Andreas · July 28, 2019, 4:21pm

Genau. Irgendwann werden wir das machen und können uns dann vielleicht bessere Sachen zusammenklauben.

Ja, gerade dieses Beispiel spricht schon Bände darüber, dass das bestimmt nur eine notdürftige Lösung war, weil der echte ESP32-Port in dieser Zeit vermutlich noch gar nicht ordentlich fertig war.

Andreas · August 1, 2019, 1:48am

Hier noch ein paar Fundstücke, die teils die bereits hier erforschten Dinge widerspiegeln, aber auch in einem weiteren patch von @robert-hh auch noch CRC-checks mitbringen – die gibt’s in der aktuellen Variante noch nicht.

Only commit for onewire - Add possibility to get result as int + cleanup by livius2 · Pull Request #9 · pycom/pycom-libraries · GitHub
Remove sleep_us(1) in read_bit and write_bit by affoltep · Pull Request #51 · pycom/pycom-libraries · GitHub
onewire.py: Optimize timing, enable CRC check and slim the code by robert-hh · Pull Request #62 · pycom/pycom-libraries · GitHub

Andreas · August 1, 2019, 7:58pm

Nach onewire.py: Use library optimized for timing and with enabled CRC checks · hiveeyes/hiveeyes-micropython-firmware@226d40e · GitHub bringt Euch ein beherztes

git pull
make setup

make install
# oder
make recycle(-ng)

der Bibliothek ein Stück näher.

Bei mir konnte ich feststellen, dass manchmal von einem der beiden Sensoren kein Ergebnis zurückkam. Zusammen mit den nun eingeführten CRC-Checks würde ich das als »considered to be a good thing™« betrachten – weil es u.U. genau jenen Fall widerspiegelt, wo bisher Glitches bei der Messung übernommen/durchgereicht/nicht weggefiltert wurden, obwohl sie inkorrekt gelesen wurden.

Wir freuen uns über Eure Erfahrungsberichte – vorzugsweise mit längeren Testzeiträumen.

MKO · August 1, 2019, 10:54pm

Gut werde meinen Teststand nochmal neu starten. Hab Ihn gerade mit der Firmware von gestern Nacht am laufen. Im Gegensatz zur Org. 0.5.1 ein deutlicher Rückschritt habe ca alle 10- 20 Messungen einen Glitch.

https://swarm.hiveeyes.org/grafana/d/rgD4TVIZz/mko-teststand?orgId=2&from=1564691157367&to=1564697602770&var-STATION=AACHEN-ORSBACH&panelId=16&fullscreen

Andreas · August 1, 2019, 11:14pm

Vielen Dank für Deine Beobachtungen.

Welcher Art ist dieser denn?

Habe auf jeden Fall sicherheitshalber Revert "Adjust waiting time after resetting 1-Wire bus" · hiveeyes/terkin-datalogger@11e8eaf · GitHub nachgeschoben, der eine kürzliche Änderung wieder rückgängig macht, die u.U. dazu beigetragen hat. Da müssen wohl die Pferde mit mir durchgegangen sein. Kriegst Du die Änderung noch mit unter?

MKO · August 1, 2019, 11:25pm

Auf nahezu allen DS 1820 Sensoren geht wie bei 0.5.1 von ein paar Grad Abweichung bis zu 534°C alles vertreten. Ausbleiben einiger Werte von DS1820 Sensoren konnte ich auch schon sehen.

Andreas · August 1, 2019, 11:35pm

Ok, schade! Um sicherzugehen: Löschst Du vielleicht gerne kurz Deinen dist-packages Ordner komplett und holst Dir die Inhalte erneut per make setup? Better safe than sorry…

Andreas · August 1, 2019, 11:41pm

Einleitung

Hast Du Deine Daten auch bereits im Grafana?

Labor / FiPy Workbench 01

An jenem Gerät bei Labor / FiPy Workbench 01 sind zwar Sensoren angeschlossen, allerdings wird dort bisher nur selten bis kaum konkret auf die Werte geschaut.

Bei den Aufzeichnungen gibt es viele Lücken, weil es recht häufig recycled wird. Daher sind die Aussetzer (bei allen Sensoren) der Betriebsweise geschuldet.

Frage an die Grafana-Spezis: Würde man solche Ausreißer durch Glitches gegen 451°F oder darüber hinaus nicht auch hier bei min/max in der Legendentabelle von Grafana zu Gesicht bekommen, um eindeutig mit dem Finger drauf zeigen zu können?

Das einzige “Misreading” sehe ich oben bei system-temperature. Das war aus der Zeit, in der wir mit dem Voltage Divider und der Ansteuerung des ADC beschäftigt waren.

Rohdaten

Disclaimer

Bei diesem Gerät sind aber halt auch nur 2x DS18B20 am Bus und ich habe vermutlich auch Anfängerglück mit den Sensoren.

MKO · August 1, 2019, 11:46pm

ja hab ich eben schon gemacht. Ja Daten sind in Grafana: Baue ich aber gerade noch um