Hi Clemens.
Das ist interessant, vielen Dank! Gib es doch bitte auch an @robert-hh weiter, am besten direkt bei GitHub - robert-hh/Onewire_DS18X20: Classes for driving the DS18x20 sensor with the onewire protocol for Pycom MicroPython.
Viele Grüße,
Andreas.
wird kaum nötig sein: er höchstselbst hatte dieses Fundstückt verlinkt. ;)
… es sei denn, Du wolltest ihn speziell auf die Möglichkeit der Unterscheidung zwischen Original und Fälschung per Treiber hinweisen. Ob er allerdings ein undokumentiertes feature dafür einbauen wollen würde?!
Wir hatten die Diskussion bei den 85 °C-Werten, die ja nicht durch die CRC-Checks rausgefiltert werden, sondern als valide Messungen in der Datenbank landen. Mein damaliger Vorschlag war Werte mit 85 einfach zu ignorieren, d.h. statt dessen missings einzutragen. Für unsere Domäne wäre das kein Problem, weil wir weder beim Wetter noch bei den Bienen auf so hohe Temperaturen kommen. Robert wollte diese Ersetzung aber nicht generell machen, zu Recht, da es ja Anwendungsdomänen gibt, die schon mal auch genau 85,00 °C messen könnten. Nun ist die Frage, ob wir mit diesem Fundstück “richtige” Messungen von Fehlercode-85 unterscheiden können und die dann nicht als Messwerte behandeln.
Wie denn? Das ginge nur bei den Originalen, - und die hat hier ohnehin keiner: wir brauchen uns nichts vormachen, praktisch alle vergossenen 18B20 in Hülsen aus China zum Preis des Einzelbauteil-Originals sind Fälschungen / clones. Bei diesen funktioniert dieser Test ohnehin nicht, also ist er lediglich dazu geeignet, Original von Fälschung zu unterscheiden - immerhin.
Ahh, so pessimistisch war ich bisher noch nicht, hab auch die “teuren” für 5 EUR gekauft. :-) Aber ja, du wirst leider richtig liegen mit der Annahme … Das würde dann aber doch dafür sprechen, dass wir die 85,00 °C als missing definieren, weil sie vermutlich nur seeehr selten real auftreten und deutlich wahrscheinlicher als Fehlercode aufkommen.
@didilamken hast du bei deinen Messungen nach Einführung der CRC-Checks die realen Werte aufgezeichnet – im BOB backend werden Ausreißer ja seit einiger Zeit gefilter, d.h. ein Blick darauf bringt bei meinen Daten nichts – und kannst sagen wie häufig die 85,00 °C noch auftauchen?
Die 85.00 °C Fehler ohne CRC-Check tauchen (vermutlich) bei mir nie auf, da ich immer
aufrufe. Die realen Werte zeichne ich auf SD-Karte auf.
Some note about using a GPIO pin instead of the 3V rail for supplying power…
Perhaps DS18B20 has been “reseted” every time before reading due to power cycle and so it seems to be more stable under an unstabel (software) driver but I see really no need to use a GPIO pin for power especially for the DS18B20 because it consumes – even in deep sleep and in ultra low power relations – nearly no power! So it’s a workaround for bad software but not a solution!
Weiter unten steht ja auch
After further investigation it seems like output current of 3V3 is not enough to supply all sensors on the board or the chinese prototype circuit board is just so thin that it is limiting the current. We moved the 5V to be supplied the battery directly and now it works, so clearly hardware related.
Finde so ein posting hier ist eher missleading und hat mit unserem Problem hier nichts zu tun. Didi hatte ja auch schon berichtet, dass es mit gleicher Hardware und dem Arduino-Sketch stabile Daten gibt, muss also ein Software-Problem sein!
Hi Clemens,
das Timing-Problem ist ja schon seit hundert Jahren dank Support modonewire from vanilla MicroPython by amotl · Pull Request #356 · pycom/pycom-micropython-sigfox · GitHub gelöst worden. Ich wollte nur drauf hinweisen, dass andere auch ihre Problemchen haben und niemanden in die Irre führen.
Viele Grüße,
Andreas.
