DS18B20 Question

[ozarkshermit]

I am using a DS18B20, with Bruce Reynolds program, a 18f14k22 running at 16 mhz internal osc.

I notice that when the temperature "changes direction", in other words, when it first starts to increase or decrease, the first reading of the DS18B20 does not change. After that it works fine, updates each time a new read takes place.

I noticed this a couple of years ago, and disregarded it, because it was more of a nuisance than anything. However, now I want to detect the temperature change immediately.

To definitely confirm this, I placed a short delay (say 5 seconds or so) following the "Start_Convert" line, to allow warming or cooling the DS18B20. To indicate the delay I simply used a LED, which is turned on for that time, and then briefly turned turned off ( 1 second) after the Convert_Temp subroutine return, prior to the GOTO back to Start_convert.

I tried using a different MODE number on the OWIN, either a 0 or 1 for the reset pulse, with no change.

This seems to be some weird characteristic of the DS18B20 -

Anyone else experienced this ?

Ken

[Acetronics2]

I notice that when the temperature "changes direction", in other words, when it first starts to increase or decrease, the first reading of the DS18B20 does not change. After that it works fine, updates each time a new read takes place.


Ken

1) what the hell do you mean by that ???

2) reading your datasheet may show you the conversion need some time to be read ... depending on the resolution you use.

3) This one ( by bruce ... ) is correct, but for DS1820 - the old model without "B" or "S" - see Datasheet for end of conversion condition


temperature VAR WORD ' Temperature storage
count_remain VAR BYTE ' Count remaining
count_per_c VAR BYTE ' Count per degree C

DQ VAR PORTC.0 ' One-wire data pin


' Define LCD registers and bits
DEFINE LCD_DREG PORTD
DEFINE LCD_DBIT 4
DEFINE LCD_RSREG PORTE
DEFINE LCD_RSBIT 0
DEFINE LCD_EREG PORTE
DEFINE LCD_EBIT 1


ADCON1 = 7 ' Set PORTA and PORTE to digital
Low PORTE.2 ' LCD R/W line low (W)


mainloop: OWOut DQ, 1, [$CC, $44] ' Start temperature conversion

waitloop: OWIn DQ, 4, [count_remain] ' Check for still busy converting
IF count_remain = 0 Then waitloop

OWOut DQ, 1, [$CC, $BE] ' Read the temperature
OWIn DQ, 0, [temperature.LOWBYTE, temperature.HIGHBYTE, Skip 4, count_remain, count_per_c]

' Calculate temperature in degrees C to 2 decimal places (not valid for negative temperature)
temperature = (((temperature >> 1) * 100) - 25) + (((count_per_c - count_remain) * 100) / count_per_c)
LCDOut $fe, 1, DEC (temperature / 100), ".", DEC2 temperature, " C"

' Calculate temperature in degrees F to 2 decimal places (not valid for negative temperature)
temperature = (temperature */ 461) + 3200
LCDOut $fe, $c0, DEC (temperature / 100), ".", DEC2 temperature, " F"

Pause 1000 ' Display about once a second

GoTo mainloop ' Do it forever



Alain

[ozarkshermit]

What I mean by that is simply this:

When the temperature increases from any temperature, (GOES UP) , Say from 72 degrees to 73 degrees,
OR when the temperature decreases from any temperature (GOES DOWN), Say from, 74 degrees to 73 degrees . . .

On the FIRST READ of the DS18B20 AFTER that event : INCREASE (Go up in temperature) or DECREASE (Go down in temperature) , the temperature READ FROM THE DS18B20 does not change. It will change correctly on subsequent reads.

I read the data sheet.

I am using the program developed by Bruce Reynolds. It uses:

waitloop: OWIn DQ, 4, [count_remain] ' Check for still busy converting
IF count_remain = 0 Then waitloop

Why is the conversion time OK for everything EXCEPT for the FIRST READ after a temperature INCREASE or DECREASE ?

Ken

[Amoque]

When the temperature is changing from, say 72 degrees to 73 degrees or from 74 to 73 degrees I would expect it would take some time for the epoxy casing to heat/cool through to where the sensor is actually sensing. The datasheet indicates a conversion time of .1 - .75 seconds; are you allowing adequate time for the temperature change to propagate? Even as the sensor continues in the "correct" direction, there must be some lag between the actual temperature and the sensing element.

If it is truly a hardware issue - and it requires a read/ write or some other electronic trigger to affect the suspect reading - then the problem should persist over several seconds or minutes. If you read say... once a minute... does the problem remain? What if you change the temperature rapidly - perhaps using "freeze spray" - to speed the temperature change of the body of the sensor, does this effect your results?

[Archangel]

If this part was capable of tracking temp that fast they would use them as MAF sensors in cars instead of investing hundreds of dollars, pounds,euros whatever in those "hot wire" devices. That little T092 case has mass, and it takes a bit to change it's temp.

[ozarkshermit]

Sorry - I should have added that I am using 9 bit resolution . Things work fine using 12 bit.

I use 9 bit since the conversion time is 93.75 ms, compared to 750 ms for 12 bit. At least, that is according to the data sheet that I have for the DS18B20. I do not want the program waiting 750 ms to convert.

I guess it will be best just to close this thread. I will come up with some kind of work-around.

Ken

[ozarkshermit]

Problem Solved - -
The problem was in my code - - As I mentioned, I have the DS18B20 configured for 9 bit resolution.

In my code, I sent the command $CC, $44 to do the Temperature conversion, AND THEN sent the 9 Bit configuration command.

By placing the Configuration command BEFORE the temperature conversion command, it works just fine.

Ken