DS18B20 code wont compile

Hi I have a situation where I need to measure humidity & temperature in a contaminating environment. Electronic sensors only last a matter of days at best before drifting. Want to use wet & dry bulb temperature probes. Done this in the past using JED STD 800, STD801 & Tiger boards but want something cheaper & lighter.
Problem is all the sketches I've been able to download for these sensors wont compile. The compiler hangs about halfway through the compile. (green bar about 1/2 way) Only way out is to close the compiler.
Anyone got any ideas?
Don

Hi Maintann

Can you post the code you are trying to compile. Put it in code tags by using the “</>” button.

Which type of Arduino are you using? Which version of the Arduino IDE? Running on Windows, Mac, Linux?

Regards

Ray

PC running 32 bit Win 7.
Arduino compiler 1.6.4
Arduino Uno (actually freetronics Eleven with lcd shield)
I have just been doing a trial compile without trying to upload at this stage so not checking compatibility of the Eleven, though it has worked fine with a few other programs.

Have tried to compile all of the “Dallas Temperature” Examples listed under Files as given, without any changes. Compiler starts, the green band extends about 1/2 way then stops (actually waited 1/2 hr once just in case). Only way out is to close the window.
If I comment out all references to OneWire I at least get error messages. Often just “Error Compile”
I suspect a conflict between the compiler & the OneWire library, have updated the compiler & looked for alternative libraries.

<#include <OneWire.h>
#include <DallasTemperature.h>

// Data wire is plugged into port 2 on the Arduino
#define ONE_WIRE_BUS 2

// Setup a oneWire instance to communicate with any OneWire devices (not just Maxim/Dallas temperature ICs)
OneWire oneWire(ONE_WIRE_BUS);

// Pass our oneWire reference to Dallas Temperature.
DallasTemperature sensors(&oneWire);

void setup(void)
{
// start serial port
Serial.begin(9600);
Serial.println(“Dallas Temperature IC Control Library Demo”);

// Start up the library
sensors.begin();
}

void loop(void)
{
// call sensors.requestTemperatures() to issue a global temperature
// request to all devices on the bus
Serial.print(“Requesting temperatures…”);
sensors.requestTemperatures(); // Send the command to get temperatures
Serial.println(“DONE”);

Serial.print("Temperature for the device 1 (index 0) is: ");
Serial.println(sensors.getTempCByIndex(0));
}>

Your code compiles OK. Commenting out the references to one wire is a bad idea. I'm not familiar with the eleven but there may be a driver installation issue. Also, check the verbose output option in the preferences. There is a possibility that something will show up there.

ended up completely removing all Arduino software & reinstalling, now it compiles fine. Next question. I brought the sensors some time ago. They are potted in a stainless housing with red yellow & green wires - have lost the information of which wire is which. Can anyone help?

Your guess is as good as anybody else's
Red 5v, green gnd, yellow signal. Red would surely never be ground.

Never say never - old Chinese proverb.
Time to get the meter out or take a punt on it. Three wires? how many permutations is that?
Better solution, buy a pukka DS18B20, put your own leads on it, write it down. Black ground, Red 5V, Blue, Yellow or whatever for data. A very wise and very capable electronics engineer once instilled in me the wisdom of star grounding, the resistivity of stainless steel and a colour coding scheme for all the lines and voltage levels likey to be encountered. I remembered the first two and forgot the last.

Thanks Nick p & tigger. Made the same assumptions re colours as suggested. No output. Tried all the permutations & no output. A suggestion elsewhere that mis connection leads to a fried chip - uncommon these day but... Tried another - same result. Ordered a couple of naked DS18B20s & will have a play when they arrive. (there is a question re the quality of some of the sensors out of China - maybe I got a bad batch??

I had two powered the wrong way round. They got seriously hot but survived and, while it is obviously possible to fry one that way, you do have to work at it. Those sensors are still in use.

There is nothing pukka about a naked DS18B20 chip if you want to use one properly encapsulated in a stainless tube, which likely to be the most obvious choice.

There can always be duds, but I have never heard any question of quality problems with DS18B20s out of China, except perhaps from paranoid rich idiots who buy Chinese-made made sensors from suppliers in other countries, thereby smugly deluding themselves that they aren't using sensors made by those dreaded Chinese - but probably are.

You might check your wiring

note that there are two programmes to use, one to sniff the address and the other to use the sensor

You also should get some sort of result, not nothing, so do you?

There is nothing pukka about a naked DS18B20 chip if you want to use one properly encapsulated in a stainless tube, which likely to be the most obvious choice.

Depends where you want to stick it.
If you want to increase your chances of success, start with a chip from from from a reputable supplier (Digikey, Farnell, RS). Read the data sheet. If you want to cut corners and buy some crap from Alibaba then good luck.
All it means is that Maintann has wasted a load of time with a possibly dud sensor.
We all know that Dallas Semiconductors probably aren't made in good ol' Dallas any more, but these forums are stuffed full of "bought it on Ebay, doesn't work, please help" - what do you expect?

tigger:
but these forums are stuffed full of "bought it on Ebay, doesn't work, please help" - what do you expect?

Yes, and its amazing how such "please helps" turn out to have nothing to do with the eBay sensor and lot to do with user incompetence, to the point indeed, where that is what you expect, and paying $15 for one from Farnells fixes nothing. I suppose now is the time for them all to come out of the woodwork, but I have been following DS18B20s for a few years and have never heard of one that is a proven dud. Quite the opposite, they have proven pretty robust - and able to stand abuse from users like me.

Maintann's code compiles, but that doesn't mean his setup is kosher. His deafening silence on the matter of returns makes me suspect the problem is somewhere else and, needless to say, the sensor is innocent..

Silence not actually deafening but :slight_smile:
After uninstalling & reinstalling most recent Arduino programming including libraries, my original code, no changes complies & loads OK. Problem No1 solved.
95% of my programming experience has been with multiple dialects of BASIC & assembler for the Z80. I've built up & installed about 30 industrial systems using STD buss & the mini Tiger controller over the last 25 years so I'm not a complete novice (though this is my first crack at C+)
Currently have 6 of these cheap sensors. Tried three of them - have activity on the data line (pin 3) but all of the prewritten sketches I've downloaded return no data. Whether it's the "0ne_number_address_finder, the DS18x20 tester or Simple" sketches I get no output. Much as I agree its usually finger or code problems that are the problem I've ordered a couple of DS18B20 from RS to check.
I WILL post the results even if it is finger problems

Try this address finder. Use one sensor at a time.

// This sketch looks for 1-wire devices and
// prints their addresses (serial number) to
// the UART, in a format that is useful in Arduino sketches
// Tutorial: 
// http://www.hacktronics.com/Tutorials/arduino-1-wire-address-finder.html

#include <OneWire.h>
OneWire  ds(3);  // Connect your 1-wire device to pin 3

void setup(void) {
  Serial.begin(9600);

  discoverOneWireDevices();
}

void discoverOneWireDevices(void) {
  byte i;
  byte present = 0;
  byte data[12];
  byte addr[8];
  
  Serial.print("Looking for 1-Wire devices...\n\r");
  while(ds.search(addr)) {
    Serial.print("\n\rFound \'1-Wire\' device with address:\n\r");

    for( i = 0; i < 8; i++) {
      Serial.print("0x");
      if (addr[i] < 16) {
        Serial.print('0');
      }
      Serial.print(addr[i], HEX);

      if (i < 7) {
        Serial.print(", ");

      }
    }
    if ( OneWire::crc8( addr, 7) != addr[7]) {
        Serial.print("CRC is not valid!\n");
        return;
    }
  }
  Serial.print("\n\r\n\rThat's it.\r\n");
  ds.reset_search();
  return;
}

void loop(void) {
  // nothing to see here
}

thanks Farraday, your code brought two of the three up. First one I tried is still dud. (the one I did most of my trialing with - though it never got even warm to the touch)
The others worked out red V+, yellow GND & Green data.
Two out of Three aint bad?

Definitely not, and I think we can write the third off to user abuse without speculating too deeply about the details of same.

So, now is the time to look at returns, as I think there has been some misunderstanding about that.

I understand you are now past any compiling issues but on running, you have never seen anything but the addresses from the above sniffer - nothing, nix, nada.

You should be getting something, no matter what, either a reading or an error message. This applies even if the sensor is disconnected and, in the light of that, you can safely conclude that you should get a return if sensor is a dud. That return is -127, which translates as “nothing to read”. Needless to say, that comes from the software, not the sensor. Getting nothing implies that the sensors are probably innocent, along with eBay, Alibaba, and the dreaded Chinese.

OK, you have two sensors operational and with known addresses, so I suggest that, while you are waiting for the golden goose to fly in from RS, you might try the following code.

This code is more or less the same as in the Hacktronics tutorial q.v.

/* Basic 2xDS18B20 code for serial monitor, bluetooth, Excel or w.h.y.
Derived from Hacktronics. Use their address sniffer and substitute your 
numbers. Use Hacktronics connections diagram. \
Resolution is 12bit by default, prints to two decimal places
Stay away from using parasite power
 85 means you haven't gotten a read yet, probably wrong order of commands
-127C means bad connection
*/

#include <OneWire.h>
#include <DallasTemperature.h>

// Data wire is plugged into pin 3 on the Arduino
#define ONE_WIRE_BUS 3

// Setup a oneWire instance to communicate with any OneWire devices
OneWire oneWire(ONE_WIRE_BUS);

// Pass our oneWire reference to Dallas Temperature.
DallasTemperature sensors(&oneWire);

// Assign the addresses of your 1-Wire temp sensors.  
byte Thermo1[8] =  {0x28, 0x39, 0xFD, 0x50, 0x04, 0x00, 0x00, 0X69};
byte Thermo2[8] = {0x28, 0x09, 0xA9, 0xC0, 0x03, 0x00, 0x00, 0x95};

float Temp,Temp1,Temp2;  

void setup(){
  Serial.begin(9600);
  sensors.begin();
  delay(750);//Wait for newly restarted system to stabilize
}

void loop() {
 sensors.requestTemperatures();  // call readings from the addresses
  Temp1 = sensorValue(Thermo1);
  Temp2 = sensorValue(Thermo2);  

Serial.print(" Thermo1 = ");
Serial.print(Temp1);
Serial.print("     Thermo2 = "); 
Serial.println(Temp2);

delay(1000);
}

//sensorValue function
float sensorValue (byte deviceAddress[])
{
     Temp = sensors.getTempC (deviceAddress);
}

thanks Nick - just what's needed.
Already got the humidity calculations & display working, just need to add in parts of your prog instead of using A1 & A2 (& provision for calibration - need the probes to track within 0.1ºC even if actual temp is out by 0.5)

Maintann:
(& provision for calibration - need the probes to track within 0.1ºC even if actual temp is out by 0.5)

OK, that's good. It looks like this all about software then, and the sensors were fine, despite their price!

I don't understand the above, I assume this is to do with wet/dry bulb thermometers. I use 12 bit resolution by default as it is the obvious thing to do, but be aware that the resolution can be changed, and you might get some value from that. See the Hacktronics tutorial.

There is a humidity sensor DHT22. I don't know anything about it, but I understand it is also a one-wire device.

yes but accuracy of the DHT22 is about 5%.
The application I'm wanting them for (salami manufacture) the oils in the air contaminate the electronic sensor quite rapidly leading to bad readings. & rooms full of mouldy salami. Direct calibration is NOT simple either.
Relative humidity can be calculated from the difference in temperature between a dry thermometer & one with a wet "sock" on it. The calculation is NOT simple but can be approximated by a straight line over a limited range of temperature & humidity. The range I'm looking at a difference of 0.1ºC can be as much as 5% %RH. (more usually ~1%)