Liebes Forum, ich habe Probleme mit meinem OneWire Bus an einem RasPi Zero - vielleicht habt ihr eine Idee. Angeschlossen sind zwei DS18B20 (diese im Metallstift) mit einem Y-Kabel, die drei Arme jeweils ca. 1-2m. Also ca. 1,5m vom RasPi zu einem Verteiler, von dort jeweils 2m zum Sensor. 4k7 pullup zwischen 3.3V und Daten (GPIO4), Versorgung ebenfalls über 3.3V. (Pin1) Es funktioniert für ein paar Stunden bestens, danach ist der Raspi zwar da, aber die Sensoren sind einfach weg. Auch ein Reboot hilft dann nicht, ich muss einfach das gesamte Teil vom Strom nehmen. Probiert habe ich den Eintrag in /etc/modules mit und ohne pullup, ich habe keine Statistik, aber der erste Versuch ohne diesem Pullup-Eintrag brachte gefühlt ein paar mehr Stunden Stabilität - geholfen hat es aber auch nichts. Die Verbindung ist ungeschirmt, für die Leitungslängen und Anzahl der Sensoren sollte das ja eigentlich nicht das Problem sein. 1. Hat jemand eine Idee, woran das liegen könnte ? 2. Wie kann ich den 1wire resetten, ohne das gesamte Teil vom Strom zu nehmen ? Das wäre natürlich erstmal eine Notlösung. Vielen Dank, Tom
Tom W. schrieb: > Wie kann ich den 1wire resetten, ohne das gesamte Teil vom Strom zu > nehmen ? Laut 1Wire-Protokoll erfolgt vor jedem Paket ein Reset, d.h. Du brauchst kein extra Reset. Es wird wohl ein Bug in der 1Wire-Lib sein und die stürzt dann ab. Die einzige Möglichkeit, einen Sensor abstürzen zu lassen sind Datenkämpfe, d.h. Fehler im Protokoll. Dann zündet ein parasitärer Thyristor, es fließt viel Strom, der Sensor wird heiß und schließlich zerstört. Der Master darf nie aktiv high treiben, außer bei parasite Power.
Peter D. schrieb: > Tom W. schrieb: >> Wie kann ich den 1wire resetten, ohne das gesamte Teil vom Strom zu >> nehmen ? > > Laut 1Wire-Protokoll erfolgt vor jedem Paket ein Reset, d.h. Du brauchst > kein extra Reset. > Es wird wohl ein Bug in der 1Wire-Lib sein und die stürzt dann ab. > > Die einzige Möglichkeit, einen Sensor abstürzen zu lassen sind > Datenkämpfe, d.h. Fehler im Protokoll. Dann zündet ein parasitärer > Thyristor, es fließt viel Strom, der Sensor wird heiß und schließlich > zerstört. > Der Master darf nie aktiv high treiben, außer bei parasite Power. Danke Peter, Software Probleme schließe ich Mal aus, da ein reboot nicht hilft. Der Bus muss komplett von der Spannung getrennt werden, dann laufen die Sensoren wieder für ein paar Stunden. Ich überlege, ob ich die Sensoren über gpio versorge, damit ich die zum Messen einschalte....
Tom W. schrieb: > Software Probleme schließe ich Mal aus, da ein reboot nicht hilft. Der > Bus muss komplett von der Spannung getrennt werden, dann laufen die > Sensoren wieder für ein paar Stunden. Das ist genau der Effekt, wenn ein SW-Fehler vorliegt, d.h. das Protokoll verletzt wird. Der Master darf niemals high senden, wenn der Slave low sendet. Der Master darf nur low oder hi-Z senden. Wenn das Protokoll eingehalten wird, laufen die Sensoren 24/7. Es kann auch sein, daß eine andere Funktion den Pin versehentlich auf high setzt, weil sie andere Pins des selben Ports benutzt. Tom W. schrieb: > Ich überlege, ob ich die Sensoren über gpio versorge, damit ich die zum > Messen einschalte.... Das würde nicht den SW-Fehler beseitigen, d.h. die Sensoren könnten trotzdem Schaden nehmen.
:
Bearbeitet durch User
Du kannst die 3.3V auf einem GPIO legen und diesen immer auf High setzten wenn du misst und danach wieder auf low, Nach high würde ich 10 Sekunden sleep einfügen.So deaktivierst bzw. aktivierst du den BUS je nach Bedarf.
Peter D. schrieb: > Wenn das Protokoll eingehalten wird, laufen die Sensoren 24/7. 1. 4,7k ist bei längeren Leitungen zu hochohmig, die Kabelkapazität muss ja umgeladen werden! (am PI sollte man eher mit 3,3k starten und manchmal auch auf 1k runtergehen) 2. Sternverkabelung klappt zwar (bei mir) ist aber lt. Datenblatt unzulässig. 3. Arbeitspunkte an den DS verschieben sich, zuerst klappte bei mir 2,2k nach 1 Jahr keine Daten mehr, ich musste auf 1,8k pullup runter gehen, danach lief es wieder! 4. CRC Prüfung vornehmen und 85°C Fehlermeldung ignorieren dann läuft es auch.
Joachim B. schrieb: > Arbeitspunkte an den DS verschieben sich, zuerst klappte bei mir 2,2k > nach 1 Jahr keine Daten mehr, ich musste auf 1,8k pullup runter gehen, > danach lief es wieder! Da verschiebt sich gar nichts. Das klingt eher nach einem schleichenden ESD-Schaden.
Tom W. schrieb: > Es funktioniert für ein paar Stunden bestens, danach ist der Raspi zwar > da, aber die Sensoren sind einfach weg. Auch ein Reboot hilft dann > nicht, ich muss einfach das gesamte Teil vom Strom nehmen. Welchen Pegel hat der Bus dann? Möglicherweise verklemmt sich ein Slave und hält den Bus dauerhaft auf LOW. Ein Workaround wäre, die 3,3V Versorgung der Sensoren schaltbar zu machen und alle X Stunden einfach einen Power ON Reset auszuführen.
Tom W. schrieb: > ich habe Probleme mit meinem OneWire Bus an einem RasPi Zero - > vielleicht habt ihr eine Idee. Schau mal bitte, ob es ggf ein Problem mit der Spannungsversorgung gibt. Für einen ersten Test in dieser Richtung schalte einen 10uF über die Versorgung der Sensoren. Als nächstes schau bitte nach, ob einer der Sensoren eine Macke hat. Betreibe die Sensoren einzeln. Wenn das alles nicht hilft, betreibe die 1wire Komponenten mit 5V und einem Levelshifter, um die Datenleitung von 3,3V auf 5V umzusetzen. Mit 5V ist das System meines erachtens robuster ggü Stör-Einstrahlungen. Ansonsten: Der Raspi kann das an sich - bei mir funktionieren 1wire Komponenten seit Jahren 24/7 problemlos.
Joachim B. schrieb: > 2. Sternverkabelung klappt zwar (bei mir) ist aber lt. Datenblatt > unzulässig. Der Punkt ist bei Dallas aber eher schwammig gehalten, ebenso die maximale Ausdehnung des Netzwerkes. Die Fa. Hygrosens hatte ein Meßsystem mit rein passiven Verteilern und 4adrigem Flachband"telefon"kabel, wo jeder Sensor mindestens 5m stichleitung hatte. Hat bei uns nachweislich mit 60 Sensoren ein Jahr lang funktioniert. Daraus folgere ich, daß der Bus jetzt nicht sooo empfindlich sein kann. Ich verwende auch den 4k7 Pull-Up, allerdings am ATmega mit 5V. Und das Problem mit dem überhitzten Sensor hatte ich auch schon, war aber nicht reproduzierbar. Mein Verdacht ist, daß die Chinaclone des DS18B20 vielleicht nicht 100% zuverlässig arbeiten.
Tom W. schrieb: > Angeschlossen sind zwei DS18B20 (diese im > Metallstift) mit einem Y-Kabel, die drei Arme jeweils ca. 1-2m. Also ca. > 1,5m vom RasPi zu einem Verteiler, von dort jeweils 2m zum Sensor. Diese Sternverkabelung ist falsch, die müssen auf einer Leitung sitzen.
bingo schrieb: > Diese Sternverkabelung ist falsch, die müssen auf einer Leitung sitzen. Unsinn! Das ist ein schnarchlangsamer Bus mit Open Drain! Da gilt das Thema Wellenwiderstand und Reflektionen nicht! Es sei denn, man nimmt ein normales IO-Pin und schaltet rattenschnell von HIGH auf LOW und erzeugt damit Reflektionen, die im Extremfall einen Sensor irritieren könnten. Ja, viele Master, wie auch der Raspberry Pi, nutzen natürlich ein normales IO-Pin, das eigentlich zu schnell schaltet, in den allermeisten Fällen funktioniert das aber dennoch ziemlich gut und stabil. Summa Sumarum. Eine Sternverdrahtung ist bei OneWire unkritisch! Es dürfen auch Stichleitungen mit nennenswerter Länge vorkommen. Es muss KEIN durchgehender Bus ohne Stichleitungen sein.
:
Bearbeitet durch User
Falk B. schrieb: > bingo schrieb: >> Diese Sternverkabelung ist falsch, die müssen auf einer Leitung sitzen. > > Unsinn! Das ist ein schnarchlangsamer Bus mit Open Drain! Da gilt das > Thema Wellenwiderstand und Reflektionen nicht! Also mein Raspi war da anderer Meinung, der wollte keine Sternverkabeleung meiner drei DS18B20
Falk B. schrieb: > Ja, viele Master, wie auch der Raspberry Pi, nutzen natürlich ein > normales IO-Pin, das eigentlich zu schnell schaltet, in den allermeisten > Fällen funktioniert das aber dennoch ziemlich gut und stabil. Sollte man vielleicht einen Kerko am IO/Pin vorsehen? Ich habe mich das bisher nicht getraut, da sonst evtl. die Entladeströme zu hoch werden könnten.
Falk B. schrieb: > Das klingt eher nach einem schleichenden > ESD-Schaden. ach [/Loriot] und deswegen läuft es nnun wieder seit weitere 4 Jahre ohne irgendeine Änderung? Das hätte ich gerne erklärt! An der Verkabelung nichts geändert, Sensoren nicht getauscht. Mit dem 1,8k ist also der schleichende ESD Schaden weg? Nun ja du weisst ja mehr über meine Installation als ich, wie dumm von mir.
bingo schrieb: > Also mein Raspi war da anderer Meinung, der wollte keine > Sternverkabeleung meiner drei DS18B20 Das kann viele Ursachen haben. Hast du ein Oszi drangehängt und mal RICHTIG gemessen? Wer sagt, daß die Software im Raspi optimal ist?
svensson schrieb: > Sollte man vielleicht einen Kerko am IO/Pin vorsehen? Kann man probieren, so 0,1-1nF. > Ich habe mich das bisher nicht getraut, da sonst evtl. die Entladeströme > zu hoch werden könnten. Das geht schon.
Joachim B. schrieb: > Nun ja du weisst ja mehr über meine Installation als ich, wie dumm von > mir. Du weißt genauso wenig über die WAHRE Ursache! Du kennst bestenfalls die Wirkung, daß es mit 1k8 wieder läuft. Alles andere ist bestenfalls eine Hypothese!
Falk B. schrieb: > Das kann viele Ursachen haben. Hast du ein Oszi drangehängt und mal > RICHTIG gemessen? Dadurch bin ja draufgekommen: Sternverkabelung: Signal scheisse, Bus: Signal gut > Wer sagt, daß die Software im Raspi optimal ist? Raspbian hat dafür ein Kernelmodul, das funktioniert sehr gut
Alter RasPi, ein halbes Dutzend Sensoren in Sternverkabelung, teils 2m teils 5m Kabel, über mindestens eine Woche => problemlos.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.