DS18B20, 16F88 problem

[DynamoBen]

I have the DS18B20 connected to my pic on portB. Everything checks out electrically. However I always get a reading of 74F even when I throw the PIC into the fridge.

I have weak pullups enabled on portB and am not using parasite power. (I tried a 4.7K resistor already)

Thoughts???

The Code:

Show_Temp:
OWOut PORTB.6,1,[$CC,$44] ' Skip ROM search & do temp conversion

Wait_Temp:
OWIn PORTB.6,4,[Stat] ' Read busy-bit
IF Stat=0 Then Wait_Temp

OWOut PORTB.6,1,[$CC,$BE] ' Skip ROM search & read scratchpad memory
OWIn PORTB.6,2,[temperature.Lowbyte,temperature.Highbyte]' Read two bytes / end comms

temperature=((((temperature>>4)+50)*9)/5)-58

value = temperature/100
LCDOut $FE,LCDLine1+7,dec value,Deg,"F"
Return

[Darrel Taylor]

Ben,

Did you set the AN inputs to Digital?
ANSEL = 0, or at least ANSEL.5 = 0 (RB6 = AN5)

The way it is now, when temperature = 65535, you get 74degF. So it's reading the DS18B20 as all HIGH bits.

And the conversion is direct to deg F, so you shouldn't have to divide by 100 before displaying to the LCD.

<br>

[DynamoBen]

I already have ansel=0.

I will try updating my calculations. I was using the example off of the rentron site. http://www.rentron.com/PicBasic/one-wire2.htm

[DynamoBen]

After the calculation update I'm coming up with 0F.

Here are my defines:

@ DEVICE pic16F88, HS_OSC ' System Clock Options
@ DEVICE pic16F88, WDT_ON ' Watchdog Timer
@ DEVICE pic16F88, PWRT_ON ' Power-On Timer
@ DEVICE pic16F88, BOD_ON ' Brown-Out Detect
@ DEVICE pic16F88, MCLR_ON ' Master Clear Options (OFF=Internal/ON=External via resistor)
@ DEVICE pic16F88, LVP_OFF ' Low-Voltage Programming
@ DEVICE pic16F88, CPD_OFF ' Data Memory Code Protect
@ DEVICE pic16F88, PROTECT_OFF ' Program Code Protection

' // Fuses/Crystal Setup //
DEFINE OSC 20 ' 20mhz XTAL (change notes above)
FLAGS=0 ' Reset all flags
CMCON=%00000111 ' Disable Comparators
ANSEL=%00000000 ' force RB6 and RB7 digital (16F88 only)
ADCON0=%00000000
TRISA=%11100000 ' PORTA set to Output/Input
TRISB=%00000000 ' PORTB all set to Input
OPTION_REG.7=0 ' 0=Enable Weak Pull-Ups on PortB
INTCON=%11000000 ' enable global and peripheral interrupts (11000000)

' // USART Intiz/Setup //
DEFINE HSER_BAUD 9600 ' 9600 Baud USART
DEFINE HSER_RCSTA 90h ' Enable USART RX
DEFINE HSER_TXSTA 24h ' Enable USART TX
DEFINE HSER_CLROERR 1 ' Clear all USART errors as they happen

' // I2C Intiz/Setup //
DEFINE I2C_SLOW 1 ' Compenstate for 20mhz clock when writing to DS1307
SCL VAR PORTB.4 ' I2C clock location
SDA VAR PORTB.1 ' I2C data location

temperature VAR WORD ' Temperature byte array
Stat VAR BIT ' Busy or not bit

' // Port Settings //
DQ VAR PORTB.6 ' One-wire data pin "DQ" on PortB.6

[Darrel Taylor]

I'm trying to figure out how you got that result, and I can't find anyway to make it come up with 0Fh.

Backtracking a bit, originally you said that you were getting a reading of 74ºF.
With this formula temperature=((((temperature>>4)+50)*9)/5)-58 temperature would have to be greater that 65500 to get 74ºF.

((((65535>>4)+50)*9)/5)-58 = 7403
Then dividing by 100 before displaying on the LCD will give you 74

That's why I think you're recieving all 1's (no response) from the DS18B20.

If you removed the /100, you should get 7403 instead of 0Fh. So This is really wierd. What changes did you make?

A few things to check...
What is the actual data being received? 65535?

How many loops are executed waiting for the conversion in Wait_Temp:? My guess here is that NO loops are performed because it receives a 1, apparently indicating that the conversion is complete, even though it's not working at all.

While the program is running, ground out the data pin. Does the reading change?

The OWIN/OUT portions of the program are fine, and should work. So there's got to be something going on with the hardware.

[DynamoBen]

How many loops are executed waiting for the conversion in Wait_Temp:? My guess here is that NO loops are performed because it receives a 1, apparently indicating that the conversion is complete, even though it's not working at all.

While the program is running, ground out the data pin. Does the reading change?


I put some serial debug messages in...as expected it never actually loops at the wait. If I ground DQ out PIC processor reboots.

I have gone thru that section of the prototype and found nothing wrong with the wiring. Very Odd.

[DynamoBen]

Okay I'm stupid. The data sheet shows what I thought was a top image of the TO92 package...its actually a BOTTOM image. I have +5 and Gnd flipped. I'm allowed one mistake every once in a while.

Now that the hardware problem is corrected I'm getting a reading of zero again. I wouldn't think swapping 5V and Gnd would kill the sensor, would it?

[Bruce]

I have fried Dallas 1-wire parts before inserting them backwards for only a few seconds.

Try something super simple like reading & displaying the raw temp value returned. If that doesn't work, it's probably toast.

[Darrel Taylor]

In engineering, you're allowed to make lots of mistakes, as long as the next EC (engineering change) solves the problem.

[DynamoBen]

If I ground the DQ pin I get all 1's. When I attach DQ to the pic I get a Raw reading of 170. The problem is its still at 170 after several minutes in the freezer. I'm thinking its dead.

[bcd]

I know this is an old post - but I though I might add what I discovered as it might help someone else in this position.

I had a similar situation using Bruce Reynolds demo code. After a load of time spent trying a whole lot of stuff including swapping sensors I found this -

When the DS18B20 is running in Parasitic Power mode (ie VCC input is tied to GND) then it cannot pull the DQ line high to notify the conversion is in progress.

I reconnected the Vcc on my DS18B20 to +5 and now it runs like a charm.

Hope this helps someone else !

Bill.

[DynamoBen]

BTW my sensor turned out to be dead. :( New sensor, same code...all was well.