DS18B20 temperature sensor at end of 50' cat5e not reliable

frankpc

Member
I've tried three different types of ds18B20 temperature sensors at the end of a 50' piece of cat5e cable.  The cable seems to be of high quality as do the sensors.  Typically a sensor will read OK for half an hour or so, then it stops responding.
 
There is just one sensor at the end of the 50' cat5e run.  Voltage to the webcontrol board is 9 v.  voltage at the sensor is 4.67 when the sensor is idle.  It drops to 4.3 when sending data.  Is that too low?
 
My webcontrol board is a WC8, version 03.01.17d.  The board says 2.0.2.  Several years ago, I sent it in for a firmware upgrade.
 
Can anyone offer any advice insofar as adding resistors or doing something to help make this reliable?
 
Thank you.
 
From my scoping the comm line years back with a WC8 the board has no slew rate control and signals become reflected from end to end in the cable.

Try a loading resistor at the far end and an RC at the board end to slow down the slew rate pit out.
Lots of experimenting may be needed to find good values.

Sent using Tapatalk
 
Do you have any starting values for the two ends?  At the far end, the loading resistor would have to go between the Vcc line and the data line in an effort to keep the Vcc as high as possible. At the board end, perhaps the RC could go from the data lead to ground.  Does that sound right?
 
When you put the scope on the data line, could you see the reflections?
 
Thank you for the advice.
 
Put the resistor in series with the data line and the cap across that to reduce the slew rate.

I only remember the reflected signals coming back about three times the a magnitude of the end device levels and much higher than Vcc.

The cable acts like a tuned resonant circuit and amplifies the voltage on fast switching.
You can adjust the delay to experiment but it really doesn't do anything.

Sent using Tapatalk
 
frankpc said:
Thank you.  I'll experiment.

The following article has a good discussion of slew rate considerations.

https://www.maximintegrated.com/en/app-notes/index.mvp/id/148
IIRC I found the WC8 board put out a very square backed square wave signal with under a few nanoseconds slope in the wave, whereas the DS19B20's sent back a long slow ramp in comparison. I can't remember all  the timings but the fast snap signal from the WC8 echoed back off the end of a 15 foot cable and destroyed the response waveforms. I could not find the same ringing signals  from the 1-wire devices responses.
 
IIRC looking at the DS18B20 devices specs, It turns out the devices include some slew rate control inside but the WC8 was a high speed logic output. I tried diodes to power supplies at both ends of the cable, zener diodes across, terminating resistors at both ends. I had to destroy the 1-wire device signals to stop the ringing. I just remember it putting out more voltage that the power supply used????
 
This may have been upgraded/improved in the WC8 board, as there was a lot of discussion and many users just gave up trying to use the board due to this problem. I ended up using only one 1-wire device as adding a longer cable broke the system every time. One of the problems was the sheepwalk board 1-wire chip which used a completely different protocol speed,  and it drive CAI crazy trying to support both at the same time at different speeds. They had to remove support for that chip but I am not sure where it stands now. I finally gave up and settled only two DS18B20 sensors and a small R + disc cap across the board end. It has worked that way for years without fail now.
 
In that development it was also discovered a lot of the cheap supply houses left the DS18B20 devices programmed as only 8 bit resolution. CAI added a boot up check to ensure the resolution was set to 13 bits and found a few other quirks. 
 
Well....  I am glad you made the discoveries.  But hate to hear what they were.  Right now, I have a new record: one ds18b20 operating over 50' of cat5 for a day and a half on the wc8 board, which is an old one - I now assume it is one of the ones the people gave up trying to use.  But I think I would try using an Arduino before buying a new wc8.  Do you agree?
 
so the only treatment you are now using on your category cable line is a small cap on the board end?  "small cap" like a .01 ... I don't know what a "R + disc cap" is.
 
Thanks for the information!
 
frankpc said:
Well....  I am glad you made the discoveries.  But hate to hear what they were.  Right now, I have a new record: one ds18b20 operating over 50' of cat5 for a day and a half on the wc8 board, which is an old one - I now assume it is one of the ones the people gave up trying to use.  But I think I would try using an Arduino before buying a new wc8.  Do you agree?
 
so the only treatment you are now using on your category cable line is a small cap on the board end?  "small cap" like a .01 ... I don't know what a "R + disc cap" is.
 
Thanks for the information!
Series resistor and a small disc like 0.05 or something. My WC8 is in a remote building behind a lot of equipment right now. It stuffs the data into my ISY994 home automation controller and also measure wind seed and gusts from it's internal counter.
 
I have never used an ardiuno and know nothing about them. The WC8 board was modified to be very easy to interface with the ISY994 Rest interface. It talks via two  WiFi routers back to back, in different buildings by sharing an SSID. 
 
No reason for you to fight success!  I believe I have a single ds18b20 working reliably at the end of a 50' piece of cat5.  I put a 20 mf cap from ground to the Vcc line and a 4.7k pull up at the end.  I figure I'll let that simmer for a bit and then attempt to put a second ds18b20 not far from the other.  I read that the wc8 does not like a star cofiguration.  And that is pretty much what I would end up with.  I'm wondering whether I could connect the 2nd sensor at the end of a 10' or 20' (?) coil of cable from where the first one is.   That would put the two sensors at different distances from the wc8.  (maybe).
 
thanks for the advice! 
 
My longest 1-wire bus using the WebControl 8 is about 125' with seven 18B20 temp sensors.
 
I added the data pullup at the end of the line as recommended in the user manual and wired it as a bus with short cable to each sensor as recommend by the Dallas app note. Some of the cabling is Cat5 but some is larger gauge cable I had lying around (18 or 19 AWG).
 
I tried experimenting with different 1-wire timing but had trouble getting repeatable failures to bracket optimum timing. Currently I'm using 20us. 
 
Webcontrol does see occasional errors but I debounce the temp sensor in software and only report a sensor failure if the sensor is non-responsive for a long time. 
 
Tschmidt said:
My longest 1-wire bus using the WebControl 8 is about 125' with seven 18B20 temp sensors.
 
I added the data pullup at the end of the line as recommended in the user manual and wired it as a bus with short cable to each sensor as recommend by the Dallas app note. Some of the cabling is Cat5 but some is larger gauge cable I had lying around (18 or 19 AWG).
 
I tried experimenting with different 1-wire timing but had trouble getting repeatable failures to bracket optimum timing. Currently I'm using 20us. 
 
Webcontrol does see occasional errors but I debounce the temp sensor in software and only report a sensor failure if the sensor is non-responsive for a long time. 
 
I use 10 uSec.
 
If different baud rates were used changing the delay setting would makes some sense. The timing is from the last received signal edge, and adjustment for length of cable is nonsense. If a long cable incurs some  signal change delays, both parts of the signal will be delayed equally, basically. It's a self clocking protocol.
 
LarrylLix said:
I use 10 uSec.
 
I've always assumed the timing allowed a compromise between sensors at various distances from the master.  And the delay had to do with ensuring the returned pulses had a chance of falling in sync with the master's timing.  But you're saying, there is no need for that timing/adjustment. 
 
Are you using a wc8?  I have an older wc8 that does not have that option.  And I was considering buying either a wc8 or wc32 in order to get that option, thinking the adjustment would help with stability.
 
Thanks.
 
frankpc said:
I've always assumed the timing allowed a compromise between sensors at various distances from the master.  And the delay had to do with ensuring the returned pulses had a chance of falling in sync with the master's timing.  But you're saying, there is no need for that timing/adjustment. 
 
Are you using a wc8?  I have an older wc8 that does not have that option.  And I was considering buying either a wc8 or wc32 in order to get that option, thinking the adjustment would help with stability.
 
Thanks.
Yes I have a WC8. It was circa just after the newer 2.2? hardware came out, with the user upgradable Eprom system.

The time delay may be useful to avoid some reflection/noise glitches that can screw up the signal recognition, by finding the best noise free spot in the waveform.
IIRC (Can't remember the name? Manchester?)  the signal logic level switches and then waits a shorter or longer time before switching back. By waiting the correct time the polarity (0 or 1) can be detected at a fixed time after the triggering logical level switch. The length of the cable shouldn't  change the timing. All ends using the same baud rate have the same timing. There are 1-wire devices that can use a faster protocol and some slower. I am not sure they can ever live on the same line though.
 
CAI had a low cost/free? option to send back older non-user updatable boards and have them updated, making them  user eprom updatable. If you are outside of the US (ie: Canada anyway) the shipping both ways will cost you more than a new board and then trash the old one.
 
A long-time user of WC8 and WC32 boards here, with hundreds of DS18B20 sensors in use.
I have added another trick to the show - I use other devices as well (like the AM2320), and while it isn't exactly "best practice", I power the AM2320 from one output pin, and DS18B20's in pairs from their own output pins.
This lets me actually power-down the sensors. In some barely measurable way, it reduces self-heating and standby power, but it also means that each time I want to take a reading, I can power-up the sensors.
For the DS18B20, which are read as a background process by the WC firmware, I only power-down and back up the sensors if I have a doubtful reading, or no response. In most cases, this is now very rare, but seems to coincide with significant electrical activity like thunderstorms.
 
Back
Top