Viele DS18B20

  • Hallo zusammen,

    ich will 20 Temperatursensoren vom Typ DS18B20, über den 1-Wire Bus, an einem Raspberry Pi betreiben und die Temperatur messen. Es handelt sich bei diesen Sensoren um die wasserdichte Ausführung, welche ein 1m langes Kabel dran hat. Bis ca. 14 Sensoren klappt auch alles super und er gibt mir die Temperaturwerte korrekt aus. Wenn ich aber mehr Sensoren anschließen (20 Stück), gibt er mir zuerst die korrekten Werte für alle Sensoren aus. Nach aber ca. 100 richtigen Messungen werden die Temperatursensoren nicht mehr vom Pi erkannt. Sie werden auch im Ordner /sys/devices/w1_bus_master1 nicht mehr aufgelistet. Nach dem Herunterfahren und neu starten werden die Sensoren wieder erkannt.

    In die Datei etc/modprobe.d/1-wire.conf habe ich folgende Zeile ergänzt: options wire max_slave_count=30


    Nach folgendem Schema habe ich die Sensoren angeschlossen:

    DS18B20_bus.svg

    Ich habe schon verschiedene Sachen ausprobiert:
    - verändern des Pullup Widerstandes der Datenleitung (1,8k / 2,35k / 3,3k / 4,7k)
    - die Sensoren mit 5V Versorgungsspannung (VDD) betrieben (Datenleitung über Pullup an 3,3V)
    - externes Netzteil welches mehr Strom zur Verfügung stellt verwendet
    - GPIO gewechselt (GPIO21 statt GPIO4 verwendet) --> in /boot/config.txt habe ich dann folgendes eingetragen: dtoverlay=w1-gpio,gpiopin=21

    Die ganzen Maßnahmen haben aber keine Besserung gebracht.

    Hat von euch noch jemand Tipps, was ich noch versuchen könnte?

    Gruß Toni

  • Hallo Toni,

    ersetze bitte den Widerstand durch ein Poti (5k). Diesen stellst Du auf maximalen Widerstand ein und reduzierst dann. Nach und nach werden immer mehr DS18B20 erkannt. Bei einem optimalen Widerstand, der von der Anzahl der DS18B20, der Leitungslänge und dem Leitungsquerschnitt, ... abhängt, werden alle DS18B20 erkannt.

    Ggf. die DS18B20, die nicht erkannt werden ersetzen oder mit denen austauschen, die zuerst erkannt werden.

    Vorteilhaft ist es auch, wenn alle Leitungen gleich lang sind (gleiche Leitungsqualität vorausgesetzt).


    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (19. Oktober 2016 um 09:45)


  • Hallo Toni,

    ersetze bitte den Widerstand durch ein Poti (5k). Diesen stellst Du auf maximalen Widerstand ein und reduzierst dann.

    dem Poti unbedingt ein 1k in Reihe schalten damit 0 Ohm beim runterdrehen nie vorkommt!


    Vorteilhaft ist es auch, wenn alle Leitungen gleich lang sind (gleiche Leitungsqualität vorausgesetzt).

    gleich lang muss nicht sein nur alle in einer Reihe Bus!
    am PI hatte ich auch bei 70m gemischt Stern Bus Probleme, der Atmel macht es prima!

    Ein User schrieb am PI geht es mit 820 Ohm Widerstand, ich probiere es nicht aus!

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Hallo Jar,

    dem Poti unbedingt ein 1k in Reihe schalten damit 0 Ohm beim runterdrehen nie vorkommt!


    Ein guter Hinweis, um Schäden zu vermeiden!
    Der TE hat leider nichts zu seinen Leitungen und deren Länge geschrieben. Ich bin mir nicht sicher, ob ein Festwiderstand 1k nicht bereits zu hoch sein kann, um den optimalen Widerstand zu ermöglichen. Deswegen schrieb ich ja, er soll sich von 5k aus nähern. Wenn er dann doch 0 Ohm erreicht hat, dann läuft da eh was anderes daneben.


    gleich lang muss nicht sein nur alle in einer Reihe Bus!
    am PI hatte ich auch bei 70m gemischt Stern Bus Probleme, der Atmel macht es prima!


    Aufgrund der Probleme, die der TE hat, muss ich davon ausgehen, dass er die Leitungen nicht als Bus-System gelegt hat, sondern Strippen von den GPIO-Pins zu den einelnen Sensoren gezogen hat. Von dieser Warte aus gesehen, machen gleiche Längen schon Sinn. Funktioniert ja auch...

    Die Schaltung, die er gepostet hat, besagt allerdings, dass es eine gemeinsame Leitung gibt, an der die Sensoren hängen. In dem Fall führt ein Poti zur Lösung, den Widerstand zu optimieren.

    Was er nun gemacht hat, bleibt allerdings im Dunkeln. Lösungsvorschläge hat er jedenfalls.



    Ein User schrieb am PI geht es mit 820 Ohm Widerstand, ich probiere es nicht aus!


    Diesen Widerstand habe ich auch noch in Erinnerung. Wundert mich zwar auch, aber das hängt sicherlich von der/ Leitungslänge/n ab. Ich werde es auch nicht ausprobieren!

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • Hallo zusammen,

    vielen Dank für die Antworten.

    Die Leitungen sind alle gleich Lang (1m). Die Leitung ist eine normale ungeschirmte 3-adrige Leitung (ist bei der wasserdichten Ausführung schon angelötet).

    DS18b20-Wasserdicht-Temperatursensor-Thermometer-Temperaturf%C3%BChler-TS.jpg

    Die Sensoren habe ich momentan linear, wie auf dem Schaltbild zu sehen, geschaltet.
    Ich habe auch schon versucht diese in Stern (alle Datenleitungen auf einen GPIO) zu schalten. Mit dem linearen Aufbau habe ich aber die besseren Erfahrungen gemacht.

    Die Sensoren werden am Anfang, auch mit 4,7k Widerstand, ja alle erkannt. Erst nach einer gewissen Zeit werden sie nicht mehr erkannt.

    Wenn ich dann den Widerstand über das Poti runterfahre (auf bis zu 1k) werden die Sensoren weiterhin nicht mehr erkannt.
    Erst wenn ich die Versorgungsspannung der DS18B20kurz wegnehm werden sie wieder erkannt.


  • Die Leitungen sind alle gleich Lang (1m). Die Leitung ist eine normale ungeschirmte 3-adrige Leitung (ist bei der wasserdichten Ausführung schon angelötet).

    nur warum beschwindelst du uns dann in deiner Anfrage?


    ich will 20 Temperatursensoren vom Typ DS18B20, über den 1-Wire Bus, an einem Raspberry Pi betreiben und die Temperatur messen.

    Du zeichnest eine Busverbindung und in Wirklichkeit baust du einen Stern oder Bus mit Sternabgänge!

    Es wurde nun alles gesagt, Stern kann funktionieren am PI muss aber nicht

    Deine Skize mag funktionieren wenn pure Sensoren ohne Kabel an der Leitung hängen, aber mit soviel extra Kabel schafft ein PI die Kabelkapzität nicht!

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Villeicht nochmal kurz zu meinem Aufbau.
    Momentan ist jede Datenleitung vom Sensor an einer Lüsterklemme angeklemmt. (Abstand von Sensor und Lüsterklemme 1m Kabel)
    Die Lüsterklemmen sind dann jeweils mit einem kleinen Stück Draht mit dem jeweils nächsten Sensor verbunden.

    Somit sind meiner Meinung nach die Leitungslängen vom Pi zum Sensor schon ungefähr gleich ca. 1m +- 10cm.
    Oder habe ich da was falsch verstanden?

    Wie würdet ihr den Bus aufbauen?
    Jar, du hattest ja geschrieben alle in einer Reihe. Wie bau ich das dann praktisch auf?

    Ich hab mir auch schon diesen Artikel durchgelesen https://www.maximintegrated.com/en/app-notes/index.mvp/id/148
    Aber werd da auch nicht 100%tig daraus schlau wie ich den Bus jetzt praktisch am besten aufbeuen soll.


  • Wie würdet ihr den Bus aufbauen?
    Jar, du hattest ja geschrieben alle in einer Reihe. Wie bau ich das dann praktisch auf?

    praktisch alle Sensorkabel auf 0 kürzen an den Bus wäre eine Busverkabelung, genau wie in deiner Skizze.

    Da das aber nicht möglich scheint denke ich,

    wie hier
    https://www.maximintegrated.com/en/app-notes/index.mvp/id/148

    2 oder 3 nur sehe ich bei zuviel Kabel schwarz für den PI

    am Atmel habe ich 2,2k pullup parasitäre Speisung VCC und GND gebrückt und massiv die Software überarbeitet, Abfrage nie unter 1s wegen der 750ms rechargetime, CRC check sowieso und Wiederholug der Abfragen bis keine Fehler kommen, max. 5x aber 3x hat immer gereicht.

    So liegen die Sensoren an 2 freien verdrallten Adern der Telefonleitungen quer durch meine Wohnung. Die Sensoren lasse ich unter der Telefondose rausgucken, einer liegt draussen an den Blumenkästen auf dem Balkon.

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Hallo Toni22,


    100 richtigen Messungen werden die Temperatursensoren nicht mehr vom Pi erkannt. Sie werden auch im Ordner /sys/devices/w1_bus_master1 nicht mehr aufgelistet. Nach dem Herunterfahren und neu starten werden die Sensoren wieder erkannt.

    Wie verhält sich denn das Ganze, wenn Du die Sensoren allein mal powercyclest? Oder anders herum gefragt - wenn Du den Raspi neu bootest, hast Du den Sensoren dann auch den Saft abgedreht oder bleiben die dauerhaft unter Strom? Hintergrund der Frage ist herauszufinden, ob der Kerneltreiber klemmt oder die Sensoren (oder einer) den Bus korrumpieren. Welchen Pegel (ein Oszi hast Du vermutlich nicht, um Flankensteilheit zu überprüfen) hat denn die Data-Leitung, wenn Du einen, 10 oder 20 Sensoren im Gutfall anschließt und welchen hat sie bei 20 Sensoren im Schlechtfall? Kann man daraus einen Schluß ziehen?

    Deine AN spricht von 100-150 Ohm Widerständen pro Stub, um Reflexionen zu minimieren. Das wäre auch noch ein Gedanke.

    Allerdings ist mir Deine Verkabelung immer noch nicht klar - oder aber der praktische Anwendungsfall. Die Leitungslängen der Sensoren zu einem Bus kurz zu halten ist gut. Wie lang aber ist die Busleitung überhaupt? Entweder hab' ich das überlesen oder es steht nirgendwo?! Wenn Du die Kabel aller 20 Sensoren auf wenige cm kappst, und das BUS-Kabel nur einige cm lang wäre, dann frage ich mich, was für eine Anwendung das ist, die auf wenigen cm^2 mittels 20 Temperatursensoren die Temperatur messen muß?!

    Falls Du mit 10 Sensoren vernünftig messen kannst, dann bliebe auch noch Multiplexing (z.B. 2x10) als Lösung. Per n-Kanal Mosfet kannst Du auch noch mal versuchen, den Pegel auf 5V zu erhöhen. Und ein echter 1-wire Master ist auch gar nicht mal soooo schlecht bei der Anzahl Sensoren ;)

    So, nun hast Du noch etwas Input zum Grübeln...

    Schöne Grüße

    schnasseldag

  • Die Längen der einzelnen Sensorkabel sind unbedeutend. 1wire hat ein kapazitives Problem, zudem benötigen 20 Sensoren einiges an Strom, was der Bus nicht leisten kann. Benutze ein gesondertes Netzteil für die Versorgung der Sensoren, das hilft unheimlich weiter. Wir haben Anlagen mit weit mehr als 20 Sensoren auf über 100m verteilt mit dem RasPi laufen. Das wichtigste ist wie gesagt, den Busmaster von der Versorgungsspannung der Sensoren zu trennen. Masse natürlich gemeinsam lassen. Wir haben den PullUp über DT auf einen anderen Pin gelegt, es ist einfach störungssicherer. Die externe Stromversorgung sollte gut stabilisiert sein, weil die Sensoren auf low ziehen und dadurch im ungünstigsten Fall die Spannung am Bus in den negativen Bereich ziehen (undershoot) was den Bus komplett durcheinander bringt. Ein RC-Glied am Anfang des Busses kann das verhindern.


  • Die Längen der einzelnen Sensorkabel sind unbedeutend.


    Na, so ganz kann ich das aber nicht stehen lassen. Mit jedem zusätzlichen Kabelende handelt er sich eine Reflexionsquelle mehr ein.


    ...zudem benötigen 20 Sensoren einiges an Strom, was der Bus nicht leisten kann. Benutze ein gesondertes Netzteil für die Versorgung der Sensoren, das hilft unheimlich weiter.


    Ein eigenes Netzteil hatte er schon probiert, Allerdings nichts darüber ausgesagt, ob der Aufbau jetzt auch noch so steht und welche Welligkeit etc. dieses Netzteil hatte. Aber es stimmt schon. Werden viele 0-en übertragen, so gibt's im parasitären Mode weniger "Stromtankmöglichkeit", als bei der Übertragung von 1en. Und wenn die Abfragefrequenz und/oder die Anzahl der Teilnehmer dann noch hoch ist, erhöht sich die Wahrscheinlichkeit des "Verhungerns". Daher würde ich immer aktiv speisen, bei mehr als einer handvoll Sensoren, insbesondere wenn eine gewisse Prozeßsicherheit gefordert istl. Ich würde mich wundern, wenn sich in Deinem Shop nicht ein 5V Netzteil finden ließe?! Schau doch mal nach... :)


  • Die Längen der einzelnen Sensorkabel sind unbedeutend.

    bei 20 Stück a 1m hat er schon eine Grundlast +x Länge zu den Sensorkabel.

    Zitat


    14 Sensoren klappt auch alles super und er gibt mir die Temperaturwerte korrekt aus. Wenn ich aber mehr Sensoren anschließen (20 Stück),

    OK dann werdet ihr ja ne Lösung finden, mir ist es nicht gelungen am PI aber ich wollte parasitär.


    Wir haben Anlagen mit weit mehr als 20 Sensoren auf über 100m verteilt mit dem RasPi laufen.

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Hallo zusammen,

    sorry für die späte Rückmeldung. Ich hab in der Zwischenzeit ein paar Sachen ausprobiert. Leider ist aber immer noch keine Besserung eingetreten.

    Der momentane Aufbau sieht folgendermaßen aus:

    DS18B20_bus.svg

    Der Abstand zwischen den Sensoren (Busleitung) beträgt jeweils 0,5m. Die einzelnen Sensoren wurden direkt an die Busleitung angelötet. Im Moment habe ich 10 Sensoren im Abstand von 0,5m an der Busleitung. Die Gesamtlänge der Busleitung ist ca. 15m lang. Die Busleitung ist eine ungeschirmte 3x0,75mm² Leitung.

    Die Sensoren habe ich über DC/DC Wandler (1A) versorgt. Habe 3,3V und 5V schon ausprobiert. Das Raspberry versorge ich über ein anderes Netzteil (gemeinsame Masse mit DC/DC Wandler).

    Den Pullup Widerstand der Datenleitung habe ich zwischen 1k und 4,7k variiert.

    Das RC-Glied von raspiprojekt habe ich auch genauso aufgebaut.


    Das Problem ist leider immer noch dasselbe. Am Anfang werden die Sensoren alle noch erkannt und liefern die korrekten Daten zurück. Nach ca. 100-300 Messungen werden die Sensoren nicht mehr erkannt. Im Moment tritt das Problem schon bei 10 Sensoren auf.
    Wenn ich die Sensoren kurz von der Spannung trenne und wieder anschließe werden die Sensoren wieder korrekt erkannt (Raspberry ist so lange an).

    Denkt ihr ein externer 1-Wire Master wie der DS2484 könnte helfen?

    Danke für eure Hilfe!

    Einmal editiert, zuletzt von toni22 (28. Oktober 2016 um 12:43)

  • Hallo toni22,


    Im Moment tritt das Problem schon bei 10 Sensoren auf.
    Wenn ich die Sensoren kurz von der Spannung trenne und wieder anschließe werden die Sensoren wieder korrekt erkannt (Raspberry ist so lange an).

    Das kann (muß aber nicht) in die Richtung deuten, daß einer oder mehrere Sensoren hier das Problem darstellen. Ich hatte das oben schon mal angedeutet. Vielleicht kannst Du die "Verräter" ja isolieren und durch andere ersetzen. Wenn die aussortierten Sensoren dann auch allein betrieben das Fehlverhalten aufweisen, dann wirf sie weg. Andernfalls wird's schwieriger, weil Du es vielleicht mit weniger toleranten Sensoren nahe der Spezifikationsgrenze zu tun hast.


    Denkt ihr ein externer 1-Wire Master wie der DS2484 könnte helfen?


    Er kann, muß aber nicht. Das kommt auf die Fehlerursache an. An (teil-) defekten Sensoren kann auch ein 1wire Master nix ändern. Eine billigere Variante wäre zunächst noch der Einsatz eines Pegelwandler. Dennoch würde ein Bus-Master die Chance eher erhöhen, da er zumindest nicht mit anderen Kerneltreibern um CPU-Ressourcen konkurriert, wenn er den GPIO bitbangt...

    Generell würde ich Dir aber empfehlen, nicht gleich alles an die lange Leitung zu hängen und dann auf Fehlersuche zu gehen. Du kannst Deine Sensoren auch erst mal so kurz wie möglich am Raspi betreiben und einen Sensor nach dem anderen hinzunehmen, bis das Problem eintritt (und zur Verifikation die Sensoren wieder wegnehmen). Wenn das Problem erst mal reproduzierbar wird (und auch verschwindet, wenn man die letzte Änderung rückgängig macht), dann läßt es sich auch besser lokalisieren. "Fehlerquellen" wie ungeschirmtes Kabel etc. kann man später immer noch hinzubauen, wenn auf dem Steckbrett 20 Sensoren erst mal zuverlässig funktioniert haben.


    Schöne Grüße

    schnasseldag

  • Servus,
    nur mal so als Idee:


    Quelle

    es gibt einen Parameter, den man angeben kann. Ob der jetzt wirklich notwendig ist, vermag ich nicht zu sagen. Sicherheitshalber habe ich ihn bei einem RPi mit derzeit 15 Sensoren angegeben.

    //EDIT: wie hoch ist eigentlich Deine Lese-Frequenz?

    cu,
    -ds-

  • @ds: max_slave_count hat er schon gesetzt (stand irgendwo am Anfang des Threads). Kann man die Lesefrequenz des Kerneltreibers denn irgendwo spezifizieren?
    Ich habe >>> hier <<< einen Thread gefunden (der Code ist in etwa in der Mitte), mittels dessen ein user-space Bitbanging auf den GPIO's gemacht wird. Damit liese sich das Timing ein wenig austesten (so man systematisch vorgehen will ;) )...

  • Hi dag,
    ah ok ... dann hab' ich das mit der Sensor-Anzahl scheinbar überlesen ...

    Mit Lesefrequenz meine ich, in welchen Intervallen das Lesen angestossen wird.
    Der DS18B20 ist da eher ein gemächlicher Typ ... mit ca. 1 Sekunde bist Du da afair im Grenzbereich (wenn man die Latenzzeiten mit +/- 200 ms mal einrechnet).

    btw: Takttechnisch sollte es doch keine Probleme geben, oder? Der wird doch eh vom Raspi geliefert, ist also an evtl. Verzögerungen angepasst.

    cu,
    -ds-

  • Hi ds,

    naja, die Pulsbreiten liegen bei einigen µs bis einigen 100µs für die 1wire-Bussignale. Und das muß halt die CPU leisten, wenn kein Controller da ist. Im Bare-Metal Betrieb würde das per Busy-Wait sicher kein Problem sein, insbesondere wenn man mit einem GHz getaktet ist. Mit Betriebssystem sieht das aber anders aus. Und mit anderen Kerneltreibern, die auch um die CPU buhlen vielleicht auch?! Kann man einen Core für's Bitbanging "abstellen", klappt's (meistens) auch reibungslos aber eine Garantie auf CPU-Zeit hast Du eigentlich nie. Die Wandlungszeit ist weniger das Problem. Die liegt bei 12Bit etwa bei 750ms. Probleme würde ich also eher während der Übertragung vermuten.
    Trotzdem tippe ich hier mal eher weniger auf ein Bitbanging-Problem. Es wäre naheliegend, wenn der Kerneltreiber (Source hab' ich mir aber nicht angeschaut) alle Busteilnehmer nacheinander abklappert und das Filesystem aktualisiert. Stößt er auf ein Problem, dann kommt er halt im nächsten Roundtrip wieder vorbei. Eine gewisse Fehlertoleranz wird er wohl haben (zumindest sollte man das meinen bei der Art eines Busses gemäß: "ich zieh' da mal einen Weidezaundraht und hänge Busteilnehmer ran"). Und überdies könnte man als Kerneltreiber auch eine Worst-Caseannahme zur 0-en Übertragung anstellen und mal nicht gleich den nächsten Busteilnehmer anhauen sondern erst abwarten, bis die Kondensatoren der Slaves wieder voll sind. Diesem Problem kann man aber auch gänzlich durch aktive Speisung entgehen... Nur so ein paar Gedanken...

    Grüße in den Süden,

    Dag

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!