Hallo, ich betreibe einen DS18B20 Temperatursensor an einer 10m langen "Telefonleitung" Man soll ja zwischen dem Daten-Pin und VDD einen 4,9kOhm Widerstand einbringen. Ist es wichtig an welcher Seite der Leitung der Widerstand angebracht wird (direkt am Sensor oder am Arduino)? Vielen Dank
Hallo, der 4,7k Widerstand ist der Abschlusswiderstand des 1-Wire Bus. Er gehört bei so langen Leitungen an den Arduino. Der 1-Wire Bus soll bis zu 100m Länge verkraften. Du bist mit deinen 10m also voll innerhalb der Spezifikation. Sollte also klappen. ;) Salu Hans
FYI, ich würde noch ein Rs von 100-150Ohm einbauen!
fyi, besser gleich hier lesen https://www.maximintegrated.com/en/design/technical-documents/tutorials/1/148.html
Oder dies hier Tutorial 148: Guidelines for Reliable Long Line 1-Wire Networks https://www.maximintegrated.com/en/an148
Hallo, die verlinkten Infos passen nicht zu 100% zum DS18B20. Deshalb besser das DB des DS18B20 von Maxim hernehmen : https://datasheets.maximintegrated.com/en/ds/DS18B20.pdf Salu Hans
HBose schrieb: > die verlinkten Infos passen nicht zu 100% zum DS18B20. Arbeitet der DS18B20 nicht am Dallas 1-Wire Bus oder was passt da nicht?
HBose schrieb: > Hallo, > > der 4,7k Widerstand ist der Abschlusswiderstand des 1-Wire Bus. Er > gehört bei so langen Leitungen an den Arduino. Doppelt falsch. 1.) Ein ist ein Pull-Up Widerstand, der nix mit einem (HF)-Abschluß ala Wellenwiderstand zu tun hat. 2.) man kann ihn praktisch ÜBERALL platzieren!
Hallo, ich habe den Pullup auf der Platine am Sensor Steckeranschluss sitzen. Die Sensoren sind nicht parasitär versorgt, deren Keramik Kondensatoren habe ich direkt am Sensor platziert/angelötet. Leitungslänge ist bei mir ca. 5m, darauf sitzen verteilt 4 solcher Sensoren, Kabel ist einfaches Netzwerkkabel.
Moin, ich versuche mich gerade auch mit dem Sensor und ähnlicher Kabellänge. Mein Problem dabei mit "Telefonkabel". Ich komme mit den 4,7k nicht aus. Diese sind auf dem Device fest verbaut. Ich habe jetzt 4,7k (original verbaut) und 1k Paralel was ~830ohm gibt, und funktioniert. Spannung ist ~3,5V. mit 2,2k Paralel lief es nicht... vielleicht kann mir jemand diese Berechnung erläutern? https://www.maximintegrated.com/en/design/technical-documents/tutorials/4/4255.html#:~:text=The%20most%20common%20VOL,responding%20with%20a%20logic%200.
Hat dein Sensor eine separate Stromversorgung, oder wird er über die Datenleitung versorgt (parasitär)? Wenn Letzteres, dann reicht es nicht aus, die Datenleitung während der Messung nur über einen Widerstand hochzuziehen. Sie muss aktiv versorgt werden. Bei den meisten Controllern kann man das per Programmierung des 1-Wire I/O Pins erreichen, aber nicht bei 8051&Co. Wenn das nicht geschieht, würde es deine Situation erklären. Der DS18x20 braucht in dieser Zeit nämlich offiziell mindestens 1,5 mA. Es gibt ausserdem einen Zusammenhang zwischen Pullup und Zeitverhalten. Wenn das 1-Wire Programm dem Bus zu wenig Zeit lässt, um die Leitung über den Widerstand wieder auf High zu kriegen. Das dauert umso länger, je grösser der Widerstand und je länger die Leitung ist.
:
Bearbeitet durch User
Mr.T schrieb: > Moin, ich versuche mich gerade auch mit dem Sensor und ähnlicher > Kabellänge. > > Mein Problem dabei mit "Telefonkabel". Ich komme mit den 4,7k nicht aus. > Diese sind auf dem Device fest verbaut. Ich habe jetzt 4,7k (original > verbaut) und 1k Paralel was ~830ohm gibt, und funktioniert. Spannung ist > ~3,5V. Arg niedrig. Offizielle sollte der minimal 1,2k sein, damit max. 4mA Pull Down Strom benötigt werden. Bei 10m braucht man das aber eher nicht. > mit 2,2k Paralel lief es nicht... Das kann viele Ursachen haben. Schlechte Software, Störeinkopplungen, instabile Stromversorgung am DS1820. > vielleicht kann mir jemand diese Berechnung erläutern? > > https://www.maximintegrated.com/en/design/technical-documents/tutorials/4/4255.html#:~:text=The%20most%20common%20VOL,responding%20with%20a%20logic%200. Beitrag "Re: Onewire + DS18x20 Library" Wenn alles paßt, kommt man mit OneWire DEUTLICH weiter und kann deutlich mehr Kabelkapazität verkraften. In dem Thread wurde das diskutiert, eine normale Stromversorgung des Sensor + 100nF am Sensor brachten einen stabilen Betrieb. https://www.mikrocontroller.net/topic/goto_post/4597883
erstmal Danke für die Antworten! Mein Device ist ein gekaufter LoRa Dragino Sensor. https://www.dragino.com/products/temperature-humidity-sensor/item/168-lsn50v2-d20.html https://www.dragino.com/downloads/index.php?dir=LoRa_End_Node/LSN50v2-D20/ an der Software kann, will ich aktuell, nicht soviel machen. Aber die Länge des Kabels im Original reicht eben nicht. Ich war wohl etwas leichtgläubig was die schriftlichen Möglichkeiten von 1-Wire angeht, beziehungsweise nicht im Thema wie abhängig es von der Implementierung ist. Es sind auch keine 100m sondern wirklich nur 10m, ich werde mal versuchen mit dem Oszilloskop (leider nur ein "kleines") zu messen wie das Signal aussieht. Am Device und am Sensor. Und mal schauen ob ich noch Cat5 Kabel finde, es sollte aber ja auf der Strecke mit dem "Telefonkabel" gehen. Versorgt wird der Sensor über das Dragino Device +/-/Data, gemessen habe ich dort die 3,5V. Das Kabel ist nicht fest verlegt, sondern liegt aktuell erst aufgerollt dann abgerollt auf dem Tisch. Keine großen Ströme und Geräte in der nähe. Mit dem Oszi habe ich mal kurz am Device gemessen und keine gravierenden Unterschiede erkannt, also es sah noch sehr Rechteckig mit 4,7k aus. Sensoren habe ich zwei unterschiedliche, beide funktionieren am kurzen Kabel, am langen nicht.
Hmm, was noch so ein Problem ist, wenn man OneWire mit einem normalen IO Pin eines Controllers macht, sind Signalreflektionen. Bei LOW schaltet der zu schnell und "hart". Schalte mal 50-100 Ohm in Reihe zwischen dein IO-Pin des Controllers und die Datenleitung.
Angehängte Dateien:
-
DS0005.BMP
13 KB
Hallo, ich hab mal am Sensor gemessen. Gelb ist die Linie mit 4,7k und Parallel 1k, also die ~830ohm. Weiß sind nur die 4,7k, was nicht funktioniert. Gerade beim zweiten Pegel sieht man ja einen deutlichen unterschied. Ich versuche es dann mal mit Cat5 Kabel. Zur Software, da wollte ich halt bei der original Dragino bleiben und nicht dran rum fuhrwerken, auch wenn das anscheinend geht.
Mr.T schrieb: > Hallo, > ich hab mal am Sensor gemessen. Gelb ist die Linie mit 4,7k und Parallel > 1k, also die ~830ohm. Weiß sind nur die 4,7k, was nicht funktioniert. Das ist einiges nicht ganz sauber. Der linke Puls hat eine sehr steile, steigende Flanke. Das kann nicht sein, wenn alle Busteilnehmer Open Drain sind. Denn diese Flanke macht nur der Pull-Up Widerstand. Wie es scheint, treibt aber der Master, der Dragino den Pegel aktiv nach HIGH. Ebenso am Ende der rechten, steigenden Flanke. Also mal wieder die 1001 unsaubere Onewire Implementierung. Hmmm. Vermutlich ist auch die Datenerfassung, sprich der Abtastzeitpunkt eher ungünstig. > Gerade beim zweiten Pegel sieht man ja einen deutlichen unterschied. Ja, aber an sich sehen beide Signale OK aus. > Ich > versuche es dann mal mit Cat5 Kabel. Tu das, aber das wird vermutlich nicht viel bringen. Das Problem sind nicht Störungen, sondern falsche Timings in der Software. > Zur Software, da wollte ich halt bei der original Dragino bleiben und > nicht dran rum fuhrwerken, auch wenn das anscheinend geht. Tja, probiers aus.
Angehängte Dateien:
-
DS0006.BMP
22 KB
Danke für die Hilfe, ich schau mal ob ich in der Software was finden kann... Anbei noch ein Anhang vom Auslesevorgang, ich trigger den mit einem Reset des Device. Ich hab es noch mit 1,5k Parallel versucht, wären dann ~1,2k aber damit gehts leider auch nicht...
Ergänzend noch, wenn ich dich richtig verstanden habe zieht der Dragino den Pegel beim Linken Puls Hoch. Beim rechten erkennt man das erst der Sensor das Signal hochziehen will, dann der Dragino nach "zu kurzer" Zeit (weiße Linie) den Pegel anhebt? Bei der Gelben wird der High Pegel ja früher erreicht, bei gleichem "start". Beitrag "Re: DS18B20 Problem Telfonkabel 4 polig" Deine Bilder mit 4,7k sehen dennoch steiler aus. Wurde da am Master oder an den Sensoren gemessen? Danke und Grüße.
Mr.T schrieb: > Danke für die Hilfe, ich schau mal ob ich in der Software was finden > kann... > > Anbei noch ein Anhang vom Auslesevorgang, ich trigger den mit einem > Reset des Device. Da sieht man nicht viel. > Ich hab es noch mit 1,5k Parallel versucht, wären dann > ~1,2k aber damit gehts leider auch nicht... Dann ist was grundlegend faul. Funktioniert der Sensor mit einem kurzen Kabel, so 1m und weniger? Mal eine Zwischenlöänge probiert, so 3, 5, 8m?
Mr.T schrieb: > Deine Bilder mit 4,7k sehen dennoch steiler aus. Wurde da am Master oder > an den Sensoren gemessen? Ist beides das Gleiche, weich mein Testaufbau nur aus einer 10cm Platine besteht. Die Buslast wurde durch einen Kondensator künstlich erzeugt.
Beitrag #6861082 wurde vom Autor gelöscht.
Mr.T schrieb: > Ergänzend noch, wenn ich dich richtig verstanden habe zieht der Dragino > den Pegel beim Linken Puls Hoch. Beim rechten erkennt man das erst der > Sensor das Signal hochziehen will Der Sensor kann das Signal nicht hochziehen, nur der Pullup. Und der Master darf es nicht, scheint es aber manchmal zu tun.
Falk B. schrieb: > Dann ist was grundlegend faul. Funktioniert der Sensor mit einem kurzen > Kabel, so 1m und weniger? Mal eine Zwischenlöänge probiert, so 3, 5, 8m? Ja mit kurzem Kabel geht es auch ohne weiteren Widerstand. So werden die Teile ja auch ausgeliefert. Zwischenlängen muss ich noch mal Probieren, aber ich denke da gibt es halt ähnlich wie beim Widerstand nen Wert wo es dann Funktioniert. https://github.com/dragino/Lora/blob/master/LSN50/v2.0/LoRa%20ST%20Sensor%20Node%20v2.0.sch.pdf Das ist der Schaltplan, ich hab die Widerstandswerte gemessen und laut Plan sind am Pin auch 4,7k an PB3. Ich befürchte das ist dann wirklich ein Stück software... https://github.com/dragino/LoRa_STM32/issues/13 Das problem ist auch so eine Geschichte... https://github.com/dragino/LoRa_STM32/blob/master/STM32CubeExpansion_LRWAN/Drivers/BSP/Components/ds18b20/ds18b20.c Da scheint es recht viel Timing zu geben :/
Yup, da ist es: DS18B20_Mode_Out_PP. Mit GPIO_MODE_OUTPUT_PP als Ausgang programmiert zieht die Leitung aktiv hoch. Auch GPIO_SPEED_FREQ_HIGH ist nicht unbedingt die allerbeste Idee. Den Delay-Code würde ich als "mutig" bezeichnen. Unkalibrierte Schleifen reagieren bei solchen Prozessoren stark auf die kleinste Änderung.
Martin schrieb: > Man soll ja zwischen dem Daten-Pin und VDD einen 4,9kOhm Widerstand > einbringen sagt wer? Ich sage das ist spannungs- und längen-abhängig weil für die nötigen steilen Schaltflanken die Kabelkapazität und der Umladestrom zuständig ist. Ich habe hier 6 Sensoren an 5V auf 72m verteilt und der Pullup ist 1,8k am µC. Parasitär versorgt 2-draht (freie Telefondoppelader)
:
Bearbeitet durch User
Wo/wie sind eigentlich DOUT1_0, DOUT1_1 etc definiert?
4 Sensoren mit zig Metern, 100 Ohm Serie, 5 kOhm Pullup, bei 5V, parasitär versorgt. Ab und zu stimmt die CRC nicht, was mich angesichts der Verdrahtung mit einfachster Leitung quer durchs Haus nicht weiter wundert. Ansonsten gab es in anderthalb Jahrzehnten nur Ärger, wenn ein Blitz einen Sensor vernichtete.
(prx) A. K. schrieb: > Wo/wie sind eigentlich DOUT1_0, DOUT1_1 etc definiert? Hintergrund: Wenn DOUT1_1 den Pin einfach bloss hochzieht, und zwar aktiv, das riskiert man mit dem Code zwischen Reset und Presence m.E. einen Signalkonflikt zwischen aktiv high vom Controller und aktiv low vom Sensor. Das gibt dann eine nette Sensorheizung ab. NB: Die Wartezeit von 2µs am Ende von WriteBit ist zwar formal ausreichend, aber wenn man den Code auf Open Drain umbaut, ist es für eine lange Leitung zu wenig. Die braucht u.U. für die 0=>1 Phase länger.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Wo/wie sind eigentlich DOUT1_0, DOUT1_1 etc definiert? In GitHub kann man ja suchen :D... hat bei mir aber auch gedauert :(
1 | /* --------------------------- DS18B20-1 HW definition -------------------------------*/
|
2 | #define DOUT1_CLK_ENABLE() __HAL_RCC_GPIOB_CLK_ENABLE()
|
3 | #define DOUT1_PORT GPIOB
|
4 | #define DOUT1_PIN GPIO_PIN_3
|
5 | #define DOUT1_READ() HAL_GPIO_ReadPin(DOUT1_PORT,DOUT1_PIN)
|
6 | #define DOUT1_0 HAL_GPIO_WritePin(DOUT1_PORT,DOUT1_PIN,GPIO_PIN_RESET)
|
7 | #define DOUT1_1 HAL_GPIO_WritePin(DOUT1_PORT,DOUT1_PIN,GPIO_PIN_SET)
|
Sorry... https://github.com/dragino/LoRa_STM32/blob/f343116c708b5f25e7ca3acb152879776d1cbf5c/STM32CubeExpansion_LRWAN/Projects/Multi/Applications/LoRa/DRAGINO-LRWAN(AT)/inc/stm32l0xx_hw_conf.h um genau zu sein da...
Weiter im Text: Wenn der Sensor mit separater Stromversorgung angeschlossen ist, liefert er einen low-Puls, wenn er fertig ist. Leider ist zu diesem Zeitpunkt die Leitung aktiv auf high. Also besser nur parasitär versorgen.
:
Bearbeitet durch User
Mr.T schrieb: > um genau zu sein da... Hübsch über die Welt verteilt. Aber nach Code eines geübten Controller-Programmierers sieht das sowieso nicht aus. Umständlicher gehts kaum. Und die Nutzung der HAL für Zeug, wo es auf die Mikrosekunde ankommt, ist auch nur was für schnelle Prozessoren.
(prx) A. K. schrieb: > Hübsch über die Welt verteilt. Aber nach Code eines geübten > Controller-Programmierers sieht das sowieso nicht aus. Umständlicher > gehts kaum. Und die Nutzung der HAL für Zeug, wo es auf die Mikrosekunde > ankommt, ist auch nur was für schnelle Prozessoren. https://de.wikipedia.org/wiki/Bloatware
(prx) A. K. schrieb: > Weiter im Text: Wenn der Sensor mit separater Stromversorgung > angeschlossen ist, liefert er einen low-Puls, wenn er fertig ist. Der DS18B20? Nö. Nur wenn man den fragt. "If the DS18S20 is powered by an external supply, the master can issue read-time slots after the Convert T command and the DS18S20 will respond by transmitting 0 while the temperature conversion is in progress and 1 when the conversion is done. In parasite power mode this notification technique cannot be used since the bus is pulled high by the strong pullup during the conversion." > Leider > ist zu diesem Zeitpunkt die Leitung aktiv auf high. Also besser nur > parasitär versorgen. NEIN! Das ist nicht nötig! Normale Versorgung geht problemlos!
(prx) A. K. schrieb: > Hübsch über die Welt verteilt. Aber nach Code eines geübten > Controller-Programmierers sieht das sowieso nicht aus. Jap ich finde es auch sehr unübersichtlich gemacht. Das delay wird auch in einer Schleife mit weiterem Zähler abgearbeitet wo mir noch nicht klar ist welche zeit nun "750" ist. Ich erkenne beim Starten nicht die Reset Zeit :(. https://www.maximintegrated.com/en/design/technical-documents/app-notes/1/126.html Hilft aber nichts, das ding habe ich nun.
Torsten S. schrieb: > Fake Chip? davon gehe ich mal nicht aus, der eine Sensor war beim Dragino dabei. Die anderen Sensoren sind Anlegesensoren von einem Deutschen Hersteller. Und ich dachte die Fakes Sensoren funktionieren wenn sie alleine am Bus hängen?
Such mal etwas hier im Forum, da gabe es einen Faden der mich erschüttert hat. Die Chips die man jetzt kaufen kann sind praktisch nur noch Fakes - bis auf wenige Ausnahmen.
Torsten S. schrieb: > Such mal etwas hier im Forum, da gabe es einen Faden der mich > erschüttert hat. Mich erschüttert eher deine Übersetzung des Worts "Thread"
Beitrag #6861306 wurde vom Autor gelöscht.
Moin, mir hat es keine ruhe gelassen... ESP32 Dev Device, 4.7k https://lastminuteengineers.com/multiple-ds18b20-esp32-web-server-tutorial/ Den Code kopiert... und selbst in Stern Topologie kommen die Daten bei zwei Sensoren... ja auch am langen Telefonkabel. IMHO liegt es wie schon vermutet am timing im Code. Danke und Grüße
Sorry to reply in English. I've worked with DS18b20's for a long time. Did anyone notice there are no disable/enable interrupts in the STM code? The timings for 1-wire basically require it. The best way to use 1-wire over any distance is to use MOSFETS to beef up the signal strength. I've used 200m cables before without any difficulty but it also requires 3 FETS and a BJT. Simon
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.