| View previous topic :: View next topic |
| Author |
Message |
stoyanoff
Joined: 20 Jul 2011
Posts: 375
|
| DS18B20 isn`t returning correct result |
 Posted: Wed Sep 12, 2012 5:39 am |
 |
|
Hi! I`m using DS18B20 to measure temperature, but I have a problem. The result from the sensor is much bigger then the real temperature. It`s put in a epoxy glue. On room temperature I have 212 degree result. When I put the sensor on heat(when I grab it with hand) the temperature increases to 230++ degrees. If I drop it the temprature decreases to 212-208 again. I suppose it`s not correctly calibrated.
Here is my program: | Code: |
#include <16F716.h>
#FUSES HS,NOWDT
#use delay(clock=25M)
#include <1wire.c>
float ds1820_read()
{
int8 busy=0, temp1, temp2;
signed int16 temp3;
float result;
onewire_reset();
onewire_write(0xCC);
onewire_write(0x44);
delay_ms(200);
while (busy == 0)
busy = onewire_read();
onewire_reset();
onewire_write(0xCC);
onewire_write(0xBE);
temp1 = onewire_read();
temp2 = onewire_read();
tH=onewire_read();
tL=onewire_read();
Conf=onewire_read();
temp3 = make16(temp2, temp1);
result = (float) temp3 / 2.0; // 0.5 deg C resolution
//result = (float) temp3 / 16.0; //0.1 deg C resolution
delay_ms(200);
return(result);
}
void MeasureTemperature()
{
float temperature;
temperature=ds1820_read();
}
void main()
{
int n;
delay_ms(2000);
onewire_write(0xCC);
onewire_write(0x4E);
onewire_write(125);
onewire_write(-55);
onewire_write(127);
onewire_reset();
onewire_write(0xCC);
onewire_write(0x48);
while(1)
{
MeasureTemperature();
delay_ms(1000);
}
|
Can you help me?? |
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9174
Location: Greensville,Ontario
|
|
| Posted: Wed Sep 12, 2012 7:08 am |
|
|
first do you have the correct driver for the device? There's 3 different DS18x20 type devices, each has it's own special protocol.I got 'bit' by that a few months ago.
second. You really shouldn't need the 200ms delay in the read function
3rd. Are you really using a 25MHz xtal ? Just seems to be an odd piece of quartz to me.
4th. Do you have 3k3r I2C pullup resistors on the I2C buss lines?
5th Having the sensor in epoxy will only delay the readings not change them.
hth
jay |
|
|
stoyanoff
Joined: 20 Jul 2011
Posts: 375
|
|
| Posted: Wed Sep 12, 2012 7:23 am |
|
|
The driver is correct and the same program is working just fine with this sensor. I have tried many times. The only difference this time is the epoxy and cables about 1.5m long. I have pull-up resistor. The crystal is 25MHz. I can change it just for the test, but I don`t think it will change anything.
I think I have a problem with discretisation of the bits. I think controller is not reading in the correct moment. And because of that the last 2 bits are 1 and because of that I have values above 200.
Am I right or the problem is more simple?? |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9174
Location: Greensville,Ontario
|
|
| Posted: Wed Sep 12, 2012 7:40 am |
|
|
hmmm...
Since you say both program and hardware are the same as you've sucessfully used before ,then I suggest the epoxied sensor is somehow at fault.
Did you heatshrink the cable/sensor leads before you epoxied? I've used hundreds of LM34s this way,never had a problem.
Can you test another sensor without epoxy ? That'll quickly confirm/deny what's going on.
hth
jay |
|
|
stoyanoff
Joined: 20 Jul 2011
Posts: 375
|
|
| Posted: Wed Sep 12, 2012 7:57 am |
|
|
| This could be a problem because I covert all of them with epoxy. I have one working but it`s already put on a PCB |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19369
|
|
| Posted: Wed Sep 12, 2012 8:00 am |
|
|
What sort of cable?. What value pull-ups?.
With a long cable, you will have a lot of capacitance, and the pull up value needed will drop. One possibility is that the value you have is just not low enough for the long wire. The capacitance likely will depend on the cable type you have chosen.
Realistically, was this a quick-set epoxy?. Some of these can heat to the point where they can damage electronic components when they set. This is why 'potting compounds' are often significantly slower setting. I have seen potting boxes melt, when people used the wrong epoxy....
Best Wishes |
|
|
stoyanoff
Joined: 20 Jul 2011
Posts: 375
|
|
| Posted: Wed Sep 12, 2012 8:45 am |
|
|
| My pull-ups are 10kOhms. The cable is udp 1.5m long. I don`t think the problem is in the epoxy, but I can try to drop down the pull-up value. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19369
|
|
| Posted: Wed Sep 12, 2012 9:12 am |
|
|
10K, is right at the maximum allowed for fast I2C. Only allows a total bus capacitance of 36pF. Given the pins on the two chips probably give something like 5pF each, and that something like Cat6 cable is 52pF/m, you are _way_ over this.....
Best Wishes |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Wed Sep 12, 2012 12:33 pm |
|
|
| Ttelmah wrote: | | 10K, is right at the maximum allowed for fast I2C. |
The DS18B20 uses the One-Wire protocol, not I2C.
I haven't checked the pull-up requirements for One-Wire protocol.
Just a few other things to check:
- Bug: The PIC16F716 is specified up to 20MHz maximum, not 25MHz.
- In your code I'm missing initialization of the DS18B20. According to the datasheet it starts up in 12 bit resolution, i.e. 0.0625C per count, not what your code is expecting. Add initialization code!
- You write about a temperature of 212 degree. Fahrenheit I assume? The code is about degrees Celcius so this 10 times too high value surprises me a lot.
- Double check you have received the DS18B20 and not the 'S' version. In the small print this is easy to miss. The 'S' version is hard coded to 9-bits and can not be changed like the 'B' version. Thinking about it, because of your missing initialization code, I wonder if you didn't want the 'S' version instead ? |
|
|
stoyanoff
Joined: 20 Jul 2011
Posts: 375
|
|
| Posted: Thu Sep 13, 2012 1:07 am |
|
|
| I fixed it! Thanks to everyone! |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19369
|
|
| Posted: Thu Sep 13, 2012 2:03 am |
|
|
| ckielstra wrote: | | Ttelmah wrote: | | 10K, is right at the maximum allowed for fast I2C. |
The DS18B20 uses the One-Wire protocol, not I2C.
I haven't checked the pull-up requirements for One-Wire protocol.
Just a few other things to check:
- Bug: The PIC16F716 is specified up to 20MHz maximum, not 25MHz.
- In your code I'm missing initialization of the DS18B20. According to the datasheet it starts up in 12 bit resolution, i.e. 0.0625C per count, not what your code is expecting. Add initialization code!
- You write about a temperature of 212 degree. Fahrenheit I assume? The code is about degrees Celcius so this 10 times too high value surprises me a lot.
- Double check you have received the DS18B20 and not the 'S' version. In the small print this is easy to miss. The 'S' version is hard coded to 9-bits and can not be changed like the 'B' version. Thinking about it, because of your missing initialization code, I wonder if you didn't want the 'S' version instead ? |
Fair enough, I'm so used to using I2C temp sensors, didn't even bother to look....
If you read the 1wire design guide, their recommended maximum resistor on the bus is 4K7, and minimum 1K. Remember this has to provide the power to charge the capacitor in the chip to power the returned data.
I still also wonder what cable has been used. Cat5 or better is recommended for 1wire busses. Also, again in the specs, you have the important point that for any bus over just over 0.5m, you have to treat the wire as a transmission line, and you need to be thinking about line termination.....
You also have the point that driving a one wire bus, from a processor port pin, without slew rate control, is limited to a maximum of 3m. Though 1.5m is well under this, it is in the same order of magnitude, and implies that problems may begin appearing.
They also recommend a Schottky trap diode at the slave device, with the comment that some devices are _very_ prone to problems.
Searching about problems with uncontrolled spikes on the 1wire lines, found the following:
"The DS18X20 B7 chip die (found in the DS18B20, DS1820S, and DS1822 products) can experience EEPROM data corruption failures during power on reset. While this is an unusual event, this is a possibility that can happen to any device during any power up while in either normal or parasite power operation modes. This failure occurs randomly but is dependent upon fabrication lot variation and the signal noise and rise time of the VDD/DQ pin. Since the EEPROM holds internal trim values (in addition to the user data in the TH and TL registers) that control the conversion process of the DS18X20 this may show up as inaccuracy of temperature readings. And can cause temperature measurement errors of up to ±60°C."
I think this probably explains exactly what has happened.
Best Wishes |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
