Temperature sensor DS 18B20

I have an ARDUINO which uses a couple of Dalas DS18B20 "1-Wire" digital temperature sensors for measuring air and ground temperatures. These are read once per hour with the values displayed onto an LCD screen and also written to a Memory Card. A new file is written each month. The unit also incorporates a DS 1307 real time clock.

Power is supplied from a mains fed 9 volt supply ("Wallwart".

Generally the readings are good, BUT 2 or 3 times each month (At different times / days), the ground sensor returns the correct temperature and a second temperature (For the same date / time) which is approximately double (+- 5 or 8 degrees- but never negative) the correct temperature.

I am not aware of power glitches, machine usage at the times of error.

Any idea what may be going on ?

Bob

Bob

I made a temperature logger using a PIC micro to store the readings on a usb stick. It uses 14 DS18B20 sensors to measure the temperatures at various points on my central heating/hot water system.

I haven’t had the problem you have, but I recently disconnected it all to change to an Arduino and found I got either no readings or very high readings. I haven’t sorted out the problem fully but think it may be down to the length of cables. I have fitted a large capacitor to the remote ends and this seems to help. I need to have another go with it.

Could you change the code to take a few readings and discount any that are outside a range of say +/- 1 deg and then use an average of those left? I did a bit of a search online and found this about CRC checking but I don’t know if this would help.

**LINK**

Stuart

I did read that there can be a problem of long cables, but the sensor with the problem is using the supplied 5m cable, so I assumed it was not too long.

Thanks Stuart, when the readings are taken, there is a good reading, followed by one or more false readings

Rec xx Date Hr,, t1 t2 (t1= air temp, t2 = Soil temp- long cable)

0310,17,20220903,10,,18,21,
0311,18,20220903,11,,20,21,
0312,19,20220903,12,,22,21,
0313,20,20220903,13,,26,21,
0314,21,20220903,14,,27,21,
0314,1,20220903,14,,26,36, False read
0315,2,20220903,15,,27,21,
0315,1,20220903,15,,28,35, False read
0316,2,20220903,16,,30,21,
0317,3,20220903,17,,30,22,
0318,4,20220903,18,,30,22,
0319,5,20220903,19,,28,22,

Try swapping the two sensors at the Arduino end. If the fault stays with the recorded ground temperature (connected to air sensor) it is likely a code issue.
If issue shift with the sensor it could be interference, faulty sensor or still possibly code.
You should NOT connect capacitor across the 1-Wire connections as it will affect the signals. A ferrite sleeve (available as clip-on) at the sensor end might help. If the sensor wires are not screened they should be.
Also check the value of the pull-up resistors. A 0.1uF capacitor btween the supply end (not sensor connection) of the pull-up resistor might help if the supply is noisy.
Only way to find out for sure what is coing on is to use a oscilloscope, preferably with protocol decoding (my favorite is Picoscope https://www.picotech.com/library/oscilloscopes/serial-bus-decoding-protocol-analysis ) on the signal.
Code issues are difficult to track down with Arduino. Could be the application, a libary or even a counterfeit sensor.

Robert G8RPI.

Thanks Robert, a few things to try there. What I don't understand is why I get a double (sometimes triple) read of the sensors, when the code will only read when the hour changes. The hour is compared with the last stored hour value and if different, then the sensors are read. I think that I must have a variable which is getting corrupted (Local as opposed to global perhaps?). I am a blundering coder, but learning slowly !

Bob

Can you change the sensor read routine to feed you dummy data instead of what you get back from the sensor, that way you can determine if it’s a software issue or a hardware sensor read issue.

regards Martin

Edited By Martin Kyte on 02/01/2023 15:07:43

Sorry, I should have said that the I connected the capacitor across the ground and positive at the remote end to stabilise the supply voltage. Obviously you wouldn’t want to connect one to the signal wire. I am not using parasite power.

Stuart

Edited By Stuart Smith 5 on 02/01/2023 15:48:07

Sould the numbers I have put in bold above increment with each reading?

If so, the problem would appear to be in the software, rather than the sensor.

This may (or may not) be helpful Bob - but if you decide that your issue is S/W related, then possibly replacing the Arduino may be the solution. I am a long term user of Micromites (PIC32 based) and I am now enthusiastically moving over PicoMites, which are wonderful little devices, ideal for embeded use and (in my view) easier to debug than other simialr devices (such as Arduino).

'Mites' support a number of 'special' devies "in-language" (e.g. it's built in - no Libraries) and the DS18B20 is one of them. The software is free to download, the Pico costs very little and you already have the DS18B20s installed. Just a thought

Regards,

IanT

.....from the PicoMite Manual.

Measuring Temperature

The TEMPR() function will get the temperature from a DS18B20 temperature sensor. This device can be purchased on eBay for about $5 in a variety of packages including a waterproof probe version. The DS18B20 can be powered separately by a 3.3V supply or it can operate on parasitic power from the PicoMite as shown on the right. Multiple sensors can be used but a separate I/O pin and a 4.7K pullup resistor is required for each one. To get the current temperature you just use the TEMPR() function in an expression.

For example: PRINT "Temperature: " TEMPR(pin) Where 'pin' is the I/O pin to which the sensor is connected.

You do not have to configure the I/O pin, that is handled by MMBasic. The returned value is in degrees C with a resolution of 0.25 ºC and is accurate to ±0.5 ºC. If there is an error during the measurement the returned value will be 1000. The time required for the overall measurement is 200ms and the running program will halt for this period while the measurement is being made. This also means that interrupts will be disabled for this period. If you do not want this you can separately trigger the conversion using the TEMPR START command then later use the TEMPR() function to retrieve the temperature reading.

The TEMPR() function will always wait if the sensor is still making the measurement.

For example:

TEMPR START GP15

< do other tasks >

PRINT "Temperature: " TEMPR(GP15)

So, it is a software issue.

Are you using interrupts? How is the timing for the sensor-reading achieved?

Changing the microprocessor type to fix a fault of this type is using a sledge-hammer to to crack a nut, and a complete waste of time and money if the sensor is faulty, or it's cable is making a bad connection!

AVR chips are at least as reliable as PIC, both sell in the hundreds of millions. A bad Arduino board is possible, because some are made very cheaply, but I've used at least 20 without finding a faulty one.

Usual suspects, noise on the cable, power supply, decoupling etc, already discussed, and well-worth eliminating.

But speedy says ' I think that I must have a variable which is getting corrupted (Local as opposed to global perhaps?)', and he might be right.

Unlikely to be a global / local conflict (where the same name is used in two or more contexts, and the programmer mixes them up.)

Chief suspects when intermittent faults or weird behaviour ensues:

• Buffer overflow. This is where, for example, a block of 64 characters is allocated to hold a string, and a string bigger than 64 characters is written into it. This can cause all manner of strange effects, because this string itself might be corrupted and other variables overwritten. Cure: increase the size of buffers, or measure the size of strings before writing to them.
• Pointer errors. Rather than expensively copy objects like structures and strings, a common technique is to copy a pointer containing the object's address. The technique is fast and memory efficient, but goes haywire if the pointer is wrong. Like buffer overflow, pointer errors can corrupt other variables, causing havoc. Cure: make sure nothing in the code can overwrite a pointer with a duff address.
• Interrupt routines that take too long to complete causing problems if interrupts arrive faster than they can be processed. Results are inconsistent because what happens depends on interrupts coinciding with other work. Cure: keep interrupt routines short and fast. Don't put anything them that might take time to complete such as delay(), Serial, etc. Instead, set a flag that's detected in loop(), which does the long running stuff.
• Interrupt routines sharing variables that haven't been declared 'volatile'. This is an easy mistake! 'volatile' tells the compiler not to optimise how the variable is stored. Normally, the compiler tries to keep copies of variables in fast registers for as long as possible, rather than slowly reading and writing them from memory on every access. This speed optimisation is dangerous when an interrupt routine uses an optimised variable because loop() might be using a register copy while the interrupt function uses real memory. Or vice-versa Whether or not a variable is a register copy at a particular time depends on what else the computer is doing. Again, the symptom is weird intermittent misbehaviours. Cure: all variables used by a function called by an interrupt must be declared 'volatile'.

C versus languages like BASIC has been debated forever! Briefly, BASIC is easy to learn at the cost of being slow, needing lots of memory, and chopping out advanced programming methods. It's great up until the point that the program runs too slowly to do the job, or the chip doesn't have enough memory, or the program needs to interface with something unusual. C/C++ is a system language used to write operating systems and software tools. Speed, efficiency, and power are far more important than being beginner friendly. Like a big motorbike, it requires training and practice. And with great power comes great responsibility! You can do things with C that Nanny BASIC forbids because getting it wrong will cause a crash.

These days I much prefer Python to BASIC, but neither is a good choice when a big fast program has to be squeezed onto a tiny computer.

Dave

Yes, we've been around this house many times Dave!

The £3.60 Pico normally clocks at 133Mhz and therefore runs MM Basic at 100,000 lines per second.

However, you can also clock the Pico at 250Mhz (a MMB selectable option), use a "C-Sub" (C routine) or programme the PIOs (from MMB) for fast sampling speeds (and the PIOs are extremely fast!) if "speed" really is a problem for your application in practice.

My personal experience is that most embedded applications just sit in wait loops and that "run" speed is really not a problem. Of course, I am not trying to write databases or multi-user applications. I am trying to interface to the world in the simplest, most direct and quickest way possible. So 'run' speed is very rarely a problem for me. What is usually a problem is de-bugging code that isn't working - and (certainly in my case) that is where "speed" is really needed. This is really where MMB really scores in my view...but you have to try it to understand.

So - what speed problem does Bob have? Is his Arduino not running fast enough?

Or is he having problems getting it to work the way he wants it to?

Bob - as I said, a Picomite may (or may not) be your solution - BUT - the PicoMite is a tremendous bit of kit. It's based on MM Basic, which has been developed over years by some very clever people and is well supported by them too. Equally important, it is also very well documented.

The most recent Picomite version supports a simple filing system and callable program 'slots' - all using the on-board 2Mb of Pico 'flash' memory (and accessible from MMB). So you can data-log very simply just using a Picomite. If you need removable or more data storage, then an external SD card can provide it, again fully supported by MMB.

I have just acquired a 2.8" Waveshare LCD touch screen (with SD card holder) that a Pico(mite) simply plugs into. The display graphics, touch controls, SD card are all directly accessible from MMB. No external "Libraries" are required - the device support is already there. The Waveshare LCD touch display cost me less than £18 and (when combined with a Picomite) can deliver a very complete compute solution (see sample test graphic below). Of course, a simpler Picomite 'data-logger' would work just as well for your requirement

So, if you really can't get your Arduino to behave itself, there are other solutions available. If it helps you - here is Geoff Graham's 3-Channel Temperature Data Logger programme in MMB. All 29 Pico GP pins are available for this use BTW (except any dedicated to other devices of course)

Open "TemperatureLog.xls" for Output as #1

Do While Inkey$ = ""

Print #1, Date$ "," Time$ "," TEMPR(GP0) "," TEMPR(GP1) "," TEMPR(GP2)

Pause 400

Loop

Close #1

That's it! Not too complicated was it? The saved temperature data (on SD card) can be opened in Excel.

Anyway, if you would like further info on the PicoMite (Download the Manual, it's excellent) start here...

Geoff Graham - Picomite

Regards,

IanT

AVR chips may be reliable (the main driver of reliability, assuming similar packaging, is the number and size of elements on the die so a 16Fxxx PIC will be more reliable than a AVR32) but the overall auduinio "system" is not. Relying on multiple layers of open-source programming, especially 3rd party libaries, is always going to be troublesome.
Lacking complex 1-wire diagnostic tools, running up a test program using a different platform is a good way to confirm operation of the sensors.
I also take issue with your broadbrush branding of basic as slow and needing lots of memory. This may be true of interpreted implementations particuarly when running on top of an operationg system or virtual machine, but compled BASIC designed for microcontrollers is normally lightning fast. For example Pic Basic Pro (PBP3 www.pbp.com).
This is significatly faster and uses less memory than a (much more expensive) C++ complier on the same device. Yes it has it's limitations but for most tasks like this it's more than adequate. I've used it and a PIC to read one-wire devices and much more in machines and instruments costing 6 figures and never had any problems. The same cannot be said of what the "professional" programmers did with a 32 bit CPU faced with a similar task (writing to 24 bit shift register) using C++.

I can't find any reference to Nanny BASIC (other than child care ), do you have a link?

Robert.

Andy_G, The highlighted values are the hour the reading was taken. As you highlighted, there are several (2 in this case) readings for the same hour, the first is always correct, the second (or more) is false just for the t2 temperatures. I could put a routine in to ignore any repeat reading for the same hour but the question would still remain "Why is it there in the first place"

Martin Kyte's idea would be worth following Ie; substitute known values instead of reading the 18B20 sensors. The problem for me is that the readings are stored in a file on the memory card and I can only see the errors at the end of the month. It would be interesting to modify the code and take readings more frequently over a shorter period of time. BUT, I publish these temperature recordings for our village each month and have a few followers who would not like to miss them! In any case I would have to make a second Arduino with memory card LCD display and a couple of sensors (programmed but not read) and a Real tTime Clock.

I last used BASIC 25 years ago to process EDI invoices and orders from major super markets, I don't think I am going that way any time soon. Although the C language is new to me, I use it at a very basic level and impressed with the power of it but not at the debug level !

To every one else - Its good reading and thank you for your replies.

Bob

Open source software ranges from excellent to poor, but most of it is competent. Most of the internet runs on it!

No link to Nanny BASIC, which I made up, but I've programmed for money in several languages, formally selected a few. and know the pros and cons. All BASICs have shortcomings!

For example, Pic BASIC Pro say "PBP does not use a software stack. This speeds execution of subroutine calls and limits PBP programming to a single, global namespace." 'Speeds execution' looks like an advantage, but limiting a computer language to a 'single global namespace' is a serious problem. When teams write big complicated programs! The limitation is far less obvious to individuals writing small straightforward programs, but when it bites it really hurts. All computer languages have glass ceilings of some sort or other, but BASIC has more than most.

Very naughty to compare C and BASIC on the basis of a single example! It just proves that professionals sometimes make a mess of things whilst amateurs might do a good job in the same space. Hardly news! But the experience absolutely doesn't prove that amateurs writing in BASIC outperform professionals writing in C. The real test involves millions of lines of code written by thousands of programmers over many years, not one short program. If BASIC were suitable for all purposes it would be widely used, and it isn't!

This site for example, lists the 10 top languages of 2022 plus 7 others worth considering. Their ranking is based on job opportunities, not chaps playing with microcontrollers. Python is top dog at the moment, with C#, C and C++ at 4,5 and 6. No BASIC or BASIC like language is listed. It's because BASIC languages have too many shortcomings for serious programming in a professional setting.

The best reason for choosing BASIC today is knowing it already and wanting a simple get you going entry into programming microcontrollers. Might be a good thing. I guess plenty of forum members have BASIC experience because it was extremely popular back when everyone owned an Apple II, BBC Micro, or ZX80. But apart from them knowing it already, I can't think of a good reason for recommending BASIC to a newcomer.

Dave

Dave,

All that is true. However it does not mean BASIC is slow and uses more memory. That was the assertion I was challenging.
For sure you are not going write a commercial PC program in BASIC today. Though it is surprising how many highly sucessful progarms have been in the past. Likewise you would not use it for a graphics intensive application. However it still has a place for applications on small microcontrollers.
A big issue with programmers is getting one who understands the hardware. Another example was a prototype with PBP code that sent and received some simple serial commands to a bit of existing equipment worked fine. It used the PICs built in UART which just needed bytes sent to a register. When the production code was written in C++ it ewould not fit. The comms libary used to bit-bang the ports rather than using the UART was taking up more than half the memory. It fitted once I got the programmer to read the datasheet and use the hardware rather than a bloatware multi-protocol libary.
Another advantage of a "simple" BASIC compiler like PBP3 is that is a LOT easier, and thus cheaper, to verfiy the code for safety critical applications. This can be a siginificant saving for simple applications.

In my experience 99 times out of 100 this sort of issue is down to the software. Even if the fault looks like a hardware problem. Put a 'scope on the data line and see what it looks like and if it is what is expected.

Andrew

"All BASICs have shortcomings!" - I've been told that all LANGUAGES have some shortcomings Dave...

"If BASIC were suitable for all purposes it would be widely used, and it isn't! " - Quite right but we don't need it for all purposes, just a few specific (embedded) ones and MM Basic does these very well indeed.

"It's because BASIC languages have too many shortcomings for serious programming in a professional setting" - I'm sure that's right but my "settings" aren't professional and I don't have enough spare time to be "serious".

"But apart from them knowing it already, I can't think of a good reason for recommending BASIC to a newcomer" - Well perhaps because someone has done such a great job of matching the software to the hardware and then documenting it so clearly. Or because MMB has a small but very enthusistic user group (many it would seem being software "professionals" ) that use and work hard to improve it.

It's also a little misleading to link a Picomite to 80's 'tech' (such as the ZX80 etc) because it is very much 21st Century tech - both the Pico (hardware) and MMB. But if you crave "retro" there is a version of the Picomite(VGA) that generates VGA Graphics and supports a PS2 keyboard. It uses the second ARM CPU and one of the PIOs to seamlessly generate the video, whilst the other ARM CPU delivers the 'compute' bit - delivering pretty much the same performance as the (non-VGA) Picomite. Even in 1980, £3.60 didn't buy you very much - today it gets you a great deal...

So, yes - the Picomite is a very specific tool but one that I find extremely useful. There's no point in telling me it's not suitable for this or that - I already know it's very good for the uses I put it to. I think others would find this too.

Regards,

IanT

PS - Bob, as Robert has already suggested - a Picomite, SD card and 2 AA batteries (already got a breadboard?) would give you a simple way to check your DS18B20's and cabling. Use Geoff's code - just a few lines. Cost you about £6 to do. What's your time worth?

Edited By IanT on 03/01/2023 21:24:36

My own experience of using 18B20s in external situations mirrors the results that Bob is seeing - after several years one bit in the serial stream appears to get stuck and show a wierd value on an intermittent basis - which steadily gets worse.

I have probably had 3 go in the past 7-8 years, quickest cure is unsolder old device and solder in new one. Total cost a few cents and 10 minutes in my case, not sure if Bob's is less easy to access.

HNY to all,

Simon

Ian T, thanks for the post but getting to know the Pico is one thing against using it for the moment and another, is it the DS 18D20 , or the memory card code, the RTC, the LCD ? As Simon 362 says - replace the sensor and for me, its the easier option as I already have one - just need to change the address as the sensor is inside a plastic conduit in the ground, so will be easy to extract it (Ha Ha Note the word Easy !)

Bob