DS18B20 Temperature Sensor

g3cwi

Hi all

Now getting to grips with the 1wire interface for a DS1820. There are lots of objects for this but none seems to work for me. I am reading a plausible device serial number and the CRC seems to work but the temperature is wrong (680.0 C). Some objects read 85.0 C (the switch on default for the device). It's no big deal as I was only playing with the device as I found it in a drawer but it is annoying me!

Current Object in use is Jonny Mac's JM_DS1820_Demo using JM_1wire.

...I suppose the device could be faulty but I doubt it.

Cheers

Richard

EDIT : now thinking that the B device is different to the plain vanilla

ElectricAye

I might be wrong about this, but I think that the DS1820 and DS18B20 should work with the same software. The biggest difference might be the difference in time for how long each device requires to take the temperature, so I suppose it's possible that difference could cause a problem if you don't give it enough time to make the "conversion". Also, on the DS18B20, you can change the resolution.

I'm not sure this will help but it probably wouldn't hurt to take a look at the following:

http://forums.parallax.com/showthread.php?136782-How-to-use-the-One-Wire-(1-Wire)-object-in-the-Obex&

I guess you could compare the DS1820 to the DS18S20, then compare the DS18S20 with the DS18B20. Just be sure you aren't looking at a part that is the PAR or "parasitic" version because that needs to be wired up somewhat differently.

http://www.maxim-ic.com/datasheet/index.mvp/id/3021

http://www.maxim-ic.com/app-notes/index.mvp/id/4377

g3cwi

Thanks EA.

The serial number is certainly correct as it has the device family number. I downloaded your object and also the resolution changer. So far I have not got them to talk together but I will keep going!

Regards

Richard

EDIT: I am not so sure about the serial number now as the Object prefills the bytes with the same plausible number...

Brian Riley

The DS18B20 has variable resolution. If you are willing to wait 750 msecs you get 12 bits, or you can command it to 11, 10, or 9 bits and receive divide by 2 reduction in compute time for each bit. It defaults to 12 bits. The scheme is 8 bits for degrees and 1 to 4 binary bits for fractions of a degree (corresponding to 9 to 12 bits total)

My guess is your code is setup to parse out a single binary bit as if it were only getting 9 significant bits. Three shifts is divide by 8 ... 680/8 is 85!

ElectricAye

g3cwi wrote: »

...

EDIT: I am not so sure about the serial number now as the Object prefills the bytes with the same plausible number...

Richard,

if I remember correctly, you first need to read the ROM serial number off each sensor by attaching each sensor one at a time and use a program that can read and display the ROM serial number. Then you need to manually enter the serial number of each sensor into the temperature reading code, which I think is the Object you've been using already. I think Jonny Mac has those ROM serial numbers as hex placed in the DAT section of his code. The software reads each serial number out of the DAT section because it's too large to fit into a LONG. I wish I could provide more detail but I'm away from my computer that has that software.

See the following for the link to SPIN code that has the read ROM ability.
http://forums.parallax.com/showthread.php?136782-How-to-use-the-One-Wire-(1-Wire)-object-in-the-Obex&p=1063645&viewfull=1#post1063645
It's something like DS18B20jmReadRom1a
It might display on a VGA but you should be able to get it to display the ROM on whatever else you have handy to work with, TV, or on your computer.
Another thought: the display might actually write the code backwards from the way it needs to be entered. I can't remember for sure, but look at the code and see where the family serial code ends up.

g3cwi

Thanks Brian and EA

....and I thought this was a 10 minute job!

Cheers

Richard

ElectricAye

ElectricAye wrote: »

...
Another thought: the display might actually write the code backwards from the way it needs to be entered. I can't remember for sure, but look at the code and see where the family serial code ends up.

Perhaps I should clarify this: by code, I meant the ROM serial number of the sensor. And by "backwards" I meant that the pairs of hex values will need to be entered in reverse of what the Rom display software shows. So in other words, when you run the DS18B20jmReadRom1a software and get 28934E.... etc. You might have to enter it as ...4E9328

Sorry if this is confusing. I have found that JonnyMac's code works really well once you get things set up, but unfortunately there's no comprehensive one-Object-does-it-all without difficulty in existence as far as I know.

g3cwi

An opening for a Gold Standard object perhaps!

More beer needed.

Regards

Richard

ElectricAye

g3cwi wrote: »

An opening for a Gold Standard object perhaps!...

It's on my wish list. Along with the beer and the spare liver necessary to handle the quantities I yearn to imbibe for lack thereof.

Brian Riley

Here is some code I wrote 2 years ago to read a One-Wire buss and display the device codes and serial number of all devices on the bus. If any of the devices are DS18 family (DS1820, DS1822, DS18B20, or DS18S20) temperature sensors, it reads and displays the temp in C and F.

In my experience, one of the most often overlooked features of OW sensors is the SKIPROM/START_CALC sequence. If you have a long string of temperature and/or voltage sensors, after you enumerate them, you can issue the sequence and they ALL start calculating and you wait around for up to 750 msecs and then using MATCHROM call on each sensor to send its data.

AcquaLife

Hello, I have downloaded the OneWire-MultiDropTemp1.spin. Good job. for some reason though it doesn't read the DS18S20 temperature sensors. I'm also wondering this: the ds18s20 can read a higher resolution than 9 bit. I'm stuck at a few points:
The high res formula:
real_temp = temp-0.25+(cpc-cr)/cpc
WHERE TEMP IS THE DATA IN LSB! (byte 0)

I know that the cpc and crc are located in the 7th and 8th byte. So my question is how to i use the onewire object to read the 7th and 8th byte only? I see you use temp := ow.readBits(16) but that reads the first 2 bytes. I only want the 7th and 8th byte and i want them stored in separate variables.

Thanks

Brian Riley

AcquaLife wrote: »

... I'm also wondering this: the ds18s20 can read a higher resolution than 9 bit.

I know that the cpc and crc are located in the 7th and 8th byte. So my question is how to i use the onewire object to read the 7th and 8th byte only? I see you use temp := ow.readBits(16) but that reads the first 2 bytes. I only want the 7th and 8th byte and i want them stored in separate variables.

According to the DataSheet, which I have enclosed, the DS18S20 is only 9 bits.

Getting at bytes 7 and 8 (the eight and ninth bytes) is easy ... think "bitstream" ... 9 bytes come from the scratchpad, read the first two, assign and parse out temperature, then read next four bytes and drop them on the floor, and read the last three bytes one at a time and assign them to CountsRemaining, Counts per C and CRC.

  temp := ow.readBits(16)               ' read temperature reads bytes 0 and 1

  case byte[devID]                      ' convert to floating point
    $10:    degC := F.FDiv(F.FFloat(temp), 2.0)   ' DS1820/DS18S20
    $22:    degC := F.FDiv(F.FFloat(temp), 16.0)  ' DS1822
    $28:    degC := F.FDiv(F.FFloat(temp), 16.0)  ' DS18B20
    other:  return

                                                          ' read and discard 4 bytes
  temp := ow.readBits(16)               ' reads bytes 2 and 3
  temp := ow.readBits(16)               ' reads bytes 4 and 5
   
  CntR := ow.readBits(8)                 ' reads byte 6 - Counts remain
  cntC := ow.readBits(8)                 ' reads byte 7 - Counts per C
  CRC := ow.readBits(8)                 ' reads byte 8 - CRC

AcquaLife

Thank you! Okay so quick question when i do the ow.readbit(8) does the computer or propeller chip remember that the first 8 bits have been read? Therefor, if you do ow.readbit(8) again you will read the second byte?
so could i do a loop like this?

repeat i from 0 to 7
data:=ow.readbit(8)
assuming data has been defined as long data[8]
I'm going to try this, but i posted it just in case it doesn't work.

Brian Riley

AcquaLife wrote: »

Thank you! Okay so quick question when i do the ow.readbit(8) does the computer or propeller chip remember that the first 8 bits have been read? Therefor, if you do ow.readbit(8) again you will read the second byte?
so could i do a loop like this?

repeat i from 0 to 7
data:=ow.readbit(8)
assuming data has been defined as long data[8]
I'm going to try this, but i posted it just in case it doesn't work.

YES that is pretty much it, but remember, the scratch pad is sending NINE bytes and you want the EIGHTH and NINTH, whose 0-based indexes happen to be 7 and 8.

So your code should be

   repeat i from 0 to 8
      data[i] = ow.readbits(8)

AcquaLife

Thanks! its like a for loop haha. I'm still having trouble reading the DS18S20. I know i have it hooked up correctly and it works. I have an arduino and have tested it. Did you have any trouble using a DS18S20? I'm going to continue to work on it and ill post my code later.

Also im using a DS18S20+PAR

Also when it reads the DS18S20 sensor it gives me 85 all the time. Which is the default or error value

g3cwi

Hi Acqualife

I am trying to get two 18B20 sensors working. One is fine and gives sensible readings while the other reads 85 all the time. I am beginning to think that it is faulty.

I tried various versions of:

ow.write(WR_SPAD)
ow.write($0000F1)
ow.reset

using Jonny Mac's 1 wire object to set resolution to 9 bits but nothing happened.

Cheers

Richard