Hi,
ich habe mir eine 1 Wire Bib geschrieben und habe nun mehrere
Temperatursensoren des Typs DS18B20 daran hängen.
Aktuell habe ich 6 Sensoren in Verwendung.
Alle Sensoren lassen sich einzeln angeschlossen abfragen.
Dabei funktioniert es einzeln auch mit den Sensoren, die über eine lange
Leitung angeschlossen sind.
Mehrere im Verbund funktionieren auch, jedoch nicht alle im Verbund.
Siehe auch Anhang über die verschiedenen Konstellationen. Grün sind die
Sensoren, die in der jeweiligen Konstellation kommunizieren. Die in weiß
antworten nicht.
Elektronisch kann ich mir das Ganze nicht ganz erklären.
Was mache ich falsch?
Was kann ich verbessern?
Vielen Dank schon Mal um jeden Hinweis!
Thomas Frosch schrieb:> ich habe mir eine 1 Wire Bib geschrieben und habe nun mehrere> Temperatursensoren des Typs DS18B20 daran hängen.
abgesehen davon, dass der Hinweis auf den fehlenden Quelltext deiner Lib
schon mal richtig ist... --> mit welcher Variante hast du die DS18B20 am
Bus (parasite power oder nicht...)?
Thomas Frosch schrieb:> Elektronisch kann ich mir das Ganze nicht ganz erklären.> Was mache ich falsch?
Du rätselst herum, statt einfach mal zu messen, ob das Bussignal so
aussieht, wie es die Spec und die Datenblätter der verwendeten Bauteile
verlangen. Dazu ist ein Oszilloskop nötig. Hast du sowas?
Arduino Fanboy D. schrieb:> Andreas B. schrieb:>> Zeile 42> Ich schätze, dass der fehlende Pullup und die ebenso fehlende> Stromversorgung, das Problem ist.
Ja, das ist aufgrund der Informationsüberflutung seitens des TO wirklich
schwer zu sagen.
Oh sorry, diese Infos hatte ich vergessen.
Alle Sensoren hängen an 5V also nicht parasitär.
Egal ob mit oder ohne 4,7kOhm Pullup gleiches Ergebnis.
Source Code ist mit angehängt.
in der "hmi.c" ist die Funktion Owaf_StateMachine die wichtigste, welche
die Abfrage der einzelnen Sensoren hintereinander durchführt.
owaf.c ist die "Bib"
Ja habe ein Oszi.
Natürlich verändern sich die Verläufe leicht, wenn ich weitere Sensoren
anschließe.
Am auffälligsten ist jedoch nur der Presence Puls, der bei mehreren
Sensoren stärker auf Low fällt (macht ja Sinn) alle anderen Pegel
scheinen sich nicht groß zu verändern.
In meiner Software wird zunächst eine Messung an alle Sensoren
getriggert. Anschließend wird mittels MATCH ROM jeder einzelne Sensor
abgefragt.
Hierbei kann ich feststellen, dass zum Beispiel in Konstellation #1 in
der alle Sensoren dran hängen die ersten 3 Sensoren nicht einmal diesen
Befehl verstehen. Es liegt also erstmal noch nicht an der Adressierung
der Teilnehmer, sondern schon daran, dass der Befehl gar nicht von den
ersten drei Sensoren richtig empfangen wird. Der Presence Pulse scheint
aber von auch von den ersten drei Sensoren "gesendet" zu werden, nachdem
sich wie oben beschrieben der Puls verstärkt.
Ich komme darauf, dass der Messungs-Trigger Befehl nicht durch geht,
indem ich nach dem Trigger die hinteren drei Sensoren abziehe.
Anschließend kommunizieren die ersten drei Sensoren ja mit meinem
Master, aber die Temperatur ist auf 85° was dem Defaultwert entspricht.
Mal auf die Schnelle: Hast Du mal die Sensoren vertauscht, ob das
Problem mit den Sensor wandert oder sicher auf die Entfernung
zurückzuführen ist?
Was passiert, wenn alle Sensoren weiter weg sind?
Timing überprüft?
Ist der 4k7 Pullup am letzten Sensor in der Kette?
Abfragereihenfolge mehrfach vertauscht. Es melden sich immer die
Sensoren so wie in dem Bild gezeigt.
Sensoren selber habe ich nur bedingt vertauscht, mach ich aber jetzt
gleich mal.
Timing mehrfach mit Oszi überprüft.
Wenn Timing nicht passen würde, würde sich denke ich gar kein Sensor
melden. Seltsam ist ja, dass in Konstellation #1 die hinteren Sensoren
sich melden aber nicht die ersten drei und dass sich die hinteren drei
nur melden wenn die vorderen drei angeschlossen sind. Wobei die hinteren
drei Sensoren aus Konstellation #1 auch funktionieren, wenn Sensor 7F
fehlt aber Sensor4E und 3B angeschlossen sind. Entferne ich 4E oder 3B,
antwortet nur EC.
Thomas Frosch schrieb:> Wenn Timing nicht passen würde, würde sich denke ich gar kein Sensor> melden.
Der Weg in die Debugginghölle ist mit falschen Annahmen gepflastert.
Geringste Überschreitungen der tolerierten Abweichungen stellen dir fix
ein Beinchen.
Arbeitsweise von Open Drain Ausgängen von 1-Wire bei AVRs während
normaler Kommunikation: Das Output-Register permanent auf 0 festnageln,
und nur die Richtung schalten: output/low=1, input/high=0. Einzig bei
parasitärer Versorgung während der Messung ändert sich das. Die internen
Pullups lohnen nicht, sind dafür zu schwach.
A. K. schrieb:> Arbeitsweise von Open Drain Ausgängen von 1-Wire bei AVRs während> normaler Kommunikation: Das Output-Register permanent auf 0 festnageln,> und nur die Richtung schalten: output/low=1, input/high=0. Einzig bei> parasitärer Versorgung während der Messung ändert sich das. Die internen> Pullups lohnen nicht, sind dafür zu schwach.
Puh.
Hatte mir auch schon gedacht, dass das so nicht ganz toll ist. Hab die
Eingänge eingelesen mit DDR noch als Output. Das ging auch zum Teil und
hat im Oszi schönere eckige Kurven gebildet, deshalb hatte ich erst so
gelassen.
Jetzt umgestellt wie von dir beschrieben und nur Direction geändert.
PIN register setze ich jetzt immer auf 0.
Kurven wurden dadurch erstmal richtig schlecht.
4,7k Pull up rein -> schonmal verbessert. Die ersten drei Sensoren gehen
ohne die hinteren drei anzuschließen.
Anschluss der hinteren drei Sensoren über die Lange Leitung verschleift
das Signal zu sehr. Mit einem 1k Pull up statt 4,7k gehen jetzt die
ersten drei Sensoren in der gesamten Strecke, aber die hinteren noch
nicht.
Pulszeiten in SW verlängert -> Alle Sensoren werden angesprochen und
antworten.
Jetzt muss ich in der SW noch alles wieder sauber machen, im Prinzip
geht es jetzt aber wunderbar und ich kann im Oszi nun auch auf die Güte
der Strecke rückschließen.
Ob es was ausmacht, dass ich einen 1k Pullup statt 4,7k verwende? Bis
auf Ruhestrom hoffentlich nicht.
Vielen vielen Dank für den Hinweis! Läuft jetzt super!!!! Bin mal
gespannt, wie viele Sensoren ich insgesamt drauf bekomme. Zieht sich
durchs ganze Haus, wird also noch viel mehr Leitungslänge.
Nochmal dickes Danke!
Thomas Frosch schrieb:> Ob es was ausmacht, dass ich einen 1k Pullup statt 4,7k verwende?
Das Limit im Datasheet sind 4mA bei 0,4V. Ob das reicht, darfst du in
Abhängigkeit von der Versorgungsspannung selbst rechnen.
Thomas Frosch schrieb:> Timing mehrfach mit Oszi überprüft.
Da wäre dann so ein Oszibild deiner Messungen auch interessant gewesen.
Da hätte man dann wahrscheinlich gleich gesehen, dass die "Kurven" zu
gut und steilflankig sind.
Thomas Frosch schrieb:> Hab die Eingänge eingelesen mit DDR noch als Output. Das ging auch zum> Teil und hat im Oszi schönere eckige Kurven gebildet
Nicht umsonst sind die Kurven (im Besonderen die steigende "Flanke") in
den Datenblättern extra nicht "zackig" sondern recht "flach"
eingezeichnet.
Dieses Verhalten wirst du auch beim I2C beobachten können, denn auch der
hat passive High-Pegel.
Dort sind übrigens ein paar Betrachtungen zur Verdrahtung und den
Signalformen auf einem 1W Bus:
https://www.maximintegrated.com/en/design/technical-documents/tutorials/1/148.html
A. K. schrieb:> Das Limit im Datasheet sind 4mA bei 0,4V. Ob das reicht, darfst du in> Abhängigkeit von der Versorgungsspannung selbst rechnen.
Diese Angabe verstehe ich nicht ganz. Im Datenblatt steht da was von
Sink Current IL. Und mindestens 4mA.
Ist IL der Strom, der vom Temperatursensor mindestens "gezogen" werden
muss, damit er auf Low schaltet?
Was bedeutet die Abhängigkeit von 0,4V?
Thomas Frosch schrieb:> Im Datenblatt steht da was von Sink Current IL. Und mindestens 4mA.> Ist IL der Strom, der vom Temperatursensor mindestens "gezogen" werden> muss, damit er auf Low schaltet?> Was bedeutet die Abhängigkeit von 0,4V?
Wenn der Sensor einen Pegel 0 ausgibt (also den Pullup gegen GND zieht),
dann ist bei einer Restspannung von 0,4V der Strom, den er ziehen kann
mindestens 4mA. Ergo musst du bei 5V rechnen: Rpumin = (5V-0,4V)/4mA
> Was bedeutet die Abhängigkeit von 0,4V?
Wenn du weniger als 0,4V willst, dann muss der Strom geringer sein.
M.E. ist es wichtig und sinnvoll, an jedem Sensor direkt an die Beinchen
einen 100nF-Kerko zu löten. Das habe ich bei meiner Topologie so gemacht
und das funktioniert perfekt.
Bei langen Leitungen kann es zu Reflexionen kommen, wenn die Flanken zu
steil sind. Abhilfe, ein 47..100R in Reihe mit dem IO-Pin des AVR.
1k Pullup ist in der Regel ein gute Wahl.
Thomas Frosch schrieb:> Meinst du zwischen GND und VDD?>> Welche Probleme hattest du? Welchen Effekt hat es damit gelöst?
Ja, zwischen GND und VCC.
Der DS18x20 funktioniert ja so, daß man eine Konversion anstößt (Code
44h, siehe Datenblatt) und nach einiger Zeit das Ergebnis ausliest.
Liest man direkt nach dem Einschalten aus ohne vorherige Konversion, so
bekommt man "85.0 Grad" gemeldet. Das ist der Power-On-Reset-Wert (siehe
Datenblatt).
In meiner (langen) Verkabelung bekam ich sporadisch solch einen
85-Grad-Wert, aber da alles an der Heizung hängt, kann es diesen Wert
nie geben. Das trat 1-2 mal pro Tag auf, manchmal öfter, manchmal
weniger oft. Dann kam ich auf die Idee, daß es vielleicht
Spannungseinbrüche an einem DS18x20 gibt direkt nach einem
Konversionsanstoß, die zu einem internen Reset führen und dadurch den
Wert 85 Grad laden, und der wird dann ausgelesen. Nachdem ich an allen
DS18x20 so einen 100nF-Kerko angelötet hatte, verschwanden diese
85-Grad-Fehler vollständig.
Thomas Frosch schrieb:> Egal ob mit oder ohne 4,7kOhm Pullup gleiches Ergebnis.
ohne ist schon mal der erste Fehler!
Thomas Frosch schrieb:> 4,7k Pull up rein -> schonmal verbessert. Die ersten drei Sensoren gehen> ohne die hinteren drei anzuschließen.
je kürzer die Leitung umso weniger die Kabelkapzität umso größer darf
der pullup werden wegen -> T = R x C.
Da man die Kabelkapzität meist nicht verändern kann muss R kleiner
werden je länger das Kabel ist.
Ausserdem kommen in langen Leitungen viel mehr Störungen rein also muss
der Signalstrom größer werden, d.h. auch wieder der pullup verkleinert
werden!
Andreas B. schrieb:> Ist der 4k7 Pullup am letzten Sensor in der Kette?
das ist egal weil irgenwo ist immer Ende, entweder am µC wenn der DS
sendet oder am DS wenn der µC sendet, man kann die eine Hälfte am µC
anklemmem, die andere Hälfte am letzten DS.
Also bei 1k -> 2k am µC und 2k am letzten DS gibt parallel 1k
A. K. schrieb:> Die internen> Pullups lohnen nicht, sind dafür zu schwach.
ganz genau!
Günter R. schrieb:> In meiner (langen) Verkabelung bekam ich sporadisch solch einen> 85-Grad-Wert
85°C und >120° (genauer Wert vergessen, ich glaube 129°C) sind
Datenfehler zusätzlich zum CRC und müssen von der Software ausgesiebt
werden!
Mit einem Port der VCC schalten (AVR und ESP können locker 10mA treiben,
nur der PI ist weniger stark) lässt kann man sogar alle in den power on
state reset setzen, falls einer mal aus der Reihe tanzt!
Der DS hat aber ein powerlimit, auch deswegen darf der pullup nicht zu
klein werden -> VCC vom DS / 4mA gibt den kleinsten pullup ja vor.
ESP und PI mögen an den Daten keine > 3,3V also ist der pullup an 5V
ebenfalls tabu auch wenn der DS mit 5V versorgt werden könnte!
Bei mir laufen 6 Sensoren an 72m gemischt Stern- Bus- zuerst an 5V
parasitär mit 2,2k, nach einem Jahr stotterte es (run in,
Bauteilealterung?) und ich musste den pullup auf 1,5k verkleinern.
Nun stieg der letzte DS an der längsten Leitung aus, da muss ich noch
mal ran.
Peter D. schrieb:> Abhilfe, ein 47..100R in Reihe mit dem IO-Pin des AVR.> 1k Pullup ist in der Regel ein gute Wahl.
Kommt gut hin. Bei mir waren es 10 Ohm und 2k2.
Joachim B. schrieb:> 85°C und >120° (genauer Wert vergessen, ich glaube 129°C) sind> Datenfehler zusätzlich zum CRC und müssen von der Software ausgesiebt> werden!
Meinst du damit, man könne die Temperatur 85,0 Grad nicht messen, weil
dieser Wert grundsätzlich als Fehler zu betrachten ist? Das wäre ja
schlimm.
Im Datenblatt gibt es unter "DC Electrical Characteristics" den
Parameter "Thermometer Error"; dort stehen die oberen Temperaturen 85
Grad und 125 Grad; meintest du vielleicht das? Allerdings sind das nicht
Meßwerte, sondern bezeichnen obere Grenzen von Bereichen, in denen
bestimmte Genauigkeitsabweichungen gelten. Hat also überhaupt nichts mit
Datenfehlern zu tun.
Günter R. schrieb:> dort stehen die oberen Temperaturen 85> Grad und 125 Grad; meintest du vielleicht das?
genau und wie du schreibst:
Günter R. schrieb:> den> Parameter "Thermometer Error";
also kein Messwert!
Günter R. schrieb:> sondern bezeichnen obere Grenzen von Bereichen, in denen> bestimmte Genauigkeitsabweichungen gelten. Hat also überhaupt nichts mit> Datenfehlern zu tun.
???
Ein Error ist kein Datenfehler?
Das muss man mir erklären!
Joachim, ich will mich mit dir doch nicht streiten, nur ein evt.
Mißverständnis richtigstellen. Mit dem Begriff "Error" an der genannten
Stelle im Datenblatt ist kein serieller Datenfehler gemeint in dem
Sinne, daß fehlerhafte Bits über die Leitung übertragen werden und in
einem Programm ausgefiltert werden müßten, wie du schriebst, etwa dann,
wenn vom Sensor die Temperatur 85.0 Grad gemeldet wird. Sondern es sind
Ungenauigkeitsabweichungen vom wahren Temperaturwert, ähnlich wie ein
analoges oder digitales Meßgerät auch immer Ungenauigkeiten hat. Wenn
also der Sensor "85.0 Grad" meldet, kann die Temperatur in Wirklichkeit
auch 85.5 oder 84.5 Grad sein, da muß man nichts ausfiltern, im
Gegenteil, da darf man nichts ausfiltern, sonst ist das Programm
unbrauchbar. Denn es gibt ja die Möglichkeit, daß man den Aufheizvorgang
von Wasser bis zum Siedepunkt messen will, und da kommt dann natürlich
irgendwann der Meßwert 85.0 Grad vor. Den muß man nicht ausfiltern. Vor
allem dann nicht, wenn man das Problem so leicht lösen kann, wie ich es
beschrieben habe (Kerko 100nF).
Daß im Datenblatt an betreffender Stelle "85 Grad" steht und an anderer
Stelle der Power-On-Reset-Wert im Datenregister "85.0 Grad" ist, ist
m.E. entweder Zufall oder hat mit vollkommen unterschiedlichen
Sachverhalten zu tun.
Okay?
Wünsche dir einen schönen restlichen Feiertag.
Gruß, Günter
2020-04-30_135603.png
(62 KB)
