Temperature sensor DS 18B20

Nothing to add to the opinions about double reading, but I have had some experience with cable length and types used with the DS18B20. I have 3 used to monitor temperatures using gan Arduino Uno in a solar boiler, a wood-burning boiler and a storage boiler -a reading is taken from all three sensors about once a second. When I bought the sensors, I was unable to get the type with a long cable, so settled for ones with 1 metre of cable. I had to extend these cables, and without thinking much about it, simply used some thin twin core stuff I had. The extensions needed to be about 1 or 2 metres, so not a lot.

When I started testing, I found I was getting no readings at all from two of the sensors (using an Arduino UNO), yet they were OK in a 'rats nest' on the bench. I suspected a bad connection, but it wasn't that.

Eventually, I replaced one of the "faulty" connections with a short length of 4-core telephone cable I had lying around, more or less as a check on my connections, and the thing worked fine. In the interests of getting it all up and running, I replaced all the extensions with telephone cable, and all was well.

Later, after thinking a bit about it, I did some tests using long lengths of telephone cable to see if it had limitations. I soon found that the simple twin-core stuff I had used to begin with was useless in any length, but with telephone cable, I managed to get the sensor operating reliably with a cable length of 25 metres - very much to my surprise. This allowed me to add a sensor to the system to measure the temperature at the solar boiler outlet, which is outside the house - I used 20 metres of telephone cable to connect it, and it has been working reliably for a couple of years now.

I am sure some expert will now dive in and tell me exactly what I did wrong, and why, but I post this as an experience, for what its worth.

The experience is well worth sharing because using the wrong sort of cable is an easy way of upsetting electronics. And it's an easy mistake because one sort of wire looks much the same as any other. Common sense doesn't help; it suggests power twin or bell-wire will be OK, which it is - in very short lengths.

Cables have inductance and capacitance. Power cables work at DC and low AC frequencies, 50 or 60Hz, or maybe audio driving a loudspeaker.

The amount of capacity and inductance in a power cable has an insignificant effect on low frequency AC. 50 Hz power cables have to be about 100 miles long before issues appear. On a long wire, there's some distortion of a 50Hz sine wave, and a small power loss, often not worth fixing. Power cables rarely need to be shielded. The design of power cable is simple: sufficient copper to carry the power without overheating, and enough decent insulation to safely prevent leakage.

Electronic AC signals are different! The waveforms are typically millions of times faster than power transmission AC, and millions of times weaker too. Capacitance and inductance in the cable becomes ever more significant with rising frequency. Signals have to charge and discharge the cable as they travel along it, which absorbs power and mangles waveforms. The square waves used by computers are particularly prone to distortion. A bad cable causes an effect like a mob shouting in an echo chamber. A second major problem is the cable acting as an antenna, picking up unwanted noise and weakening the wanted signal by radiating it. Shielding is soon needed.

Signal cables are organised to minimise these effects. Old fashioned telephone and telegraph wires were often run 2 metres apart on poles to reduce capacitance. The system, then and now, also included deliberate extra capacitance and inductance carefully arranged to balance out that in the cabling.

Twisted pair works well over short distances. It looks simple, but telephone and Ethernet twisted-pair is actually high-tech design. The helix angle, dielectric properties of the insulation, wire diameter, and pair diameter are all optimised to suit the signal. Ethernet cable is almost always shielded as well. With a fair wind, telephone pair should be OK for wiring a sensor up to 25 metres away, Ethernet up to 100 metres. More or less depending on the environment, type of cable used, the sensor, and the computer. Range can be extended with a repeater.

Twisted pair pegs out with rising frequency, and is usually replaced with coaxial cable above 20MHz for UHF and Satellite TV. Above UHF, coaxial cable becomes lossy too, and waveguides take over. Best signalling option of all at the moment is fibre-optic cable, because there is no Copper wire in it! But fibre-optics are over the top for most ordinary purposes.

Dave

If the DS18B20 reading is initiated by the software in the Arduino, then the problem surely lies in the software?

SoD gives a reasonable list of possibilities, but specific to the Arduino - if relying on the 'millis()' function to determine delays, the counter overflows every ~49 days (for a 16MHz device) which can result in unintended consequences. Your problems occur more often than that, but something similar may be happening - do all your timing related variables have sufficient precision? For example: storing time related values in a LONG type variable could result in overflow in ~24.5 days (should be UNSIGNED LONG).

Once the software is off it's intended course, the results could be anything - e.g. failing to zero a variable resulting in values accumulating and giving a false reading.

As I have a project with the Dallas DS18B20 on a (very slow) back burner, I would very much like to know how Mr. AnOther connected the (3-wire) chip to the (4-wire) telephone cable. Was it just as simple as leaving one wire unconnected?

Inquiring minds...

Hans

I found this article which covers many aspects of getting reliable one-wire communication - not sure how many of the points covered are relevant to the OP's application.

just as an update, something is making the Arduino re-boot (I think). The field xxx is just a record counter and would range from 1 to 720 for this sample (number of days per month x 24).

Time is taken from the RTC using the function rtc.now() and now.hour(). The record counter is reset on change of the month where a new file is written to the memory card and the record count is re-set back to 1. The only other time it is re-set back to 1 is when the program starts.

I am now inclined to be thinking about the power supply and noise ??

DDHh,xxx,YYYYMMDD,Hh,,t1,t2

2007,348,20220920,07,,7,17,
2008,349,20220920,08,,8,16,
2009,350,20220920,09,,8,16,
2010,351,20220920,10,,12,16,
2011,352,20220920,11,,16,16, This is the record for 20/09/2022 at 11:00. Record counter should be 480 + 11
2011,1,20220920,11,,16,38, False
2011,1,20220920,11,,16,37, False
2012,2,20220920,12,,20,16,
2013,3,20220920,13,,23,16,
2014,4,20220920,14,,25,16,

To Versaboss,

You guessed it, Hans. I only had 4-wire telephone cable available, so I simply used 2 wires as ground, one as +5v and one as the signal connection. If I remember correctly, the cable had White, Brown, Green and Yellow wires, so I used Brown for +5v, White for signal and Green and Yellow as ground - I mention this, because I didn't even check for twisted pairs, I was more interested in getting it working. I never did try it in 2-wire 'parasitic' mode, so I don't know if you can use 2-wire telephone cable for that. Incidentally, not a good thing to do, but the DS18B20 seems very robust - I managed to connect it incorrectly a couple of times but apparently did no damage.

I did try parasitic mode with a short length of co-axial cable (from an old microphone), and it also would not work - which is partly why I dropped the idea of using parasitic mode.

Referring to my earlier post, about getting it to work with a 25 metre length of cable - I had a 25 metre telephone extension cable (I sort of hoard stuff!), and I simply cut the connectors off it, and used that, because it was available. Its possible that it would work over a longer distance, but I never got that far.

I was using the waterproof version of the sensor, like a metal slug with a cable attached, not the 'separate' integrated chip version, but the connections are the same.

edited to add chip version used.

Edited By An Other on 04/01/2023 14:45:57

I still think this is more likely to be software than PSU and noise, though they are both possibilities.

Resetting the CPU coupled with data corruption is characteristic of a buffer overrun, incorrect pointer, or stack overflow. They're difficult to spot because the logic of the program is OK, but the machine malfunctions due to a timing or memory allocation issue. The cause is usually obvious once identified, but tricky to see in the first place.

Happy to look at the code if Speedy is comfy with sharing it. PM me if the offer is useful.

Dave

Dave - PM sent

Bob