Click here for the DS18B20 Arbiter frame format.
The DS1820 is obsolete, but seems to be freely available. It is superseded by the DS18B20.
With the Arbiter wired up to the PC, the serial data from each temperature sensor can be examined.
The format is the same as described in the DS1820 Dallas datasheet. The ROM code is read, followed by the scratch pad memory.
This is an conscious decision on my part. The PIC code should be as simple as possible, with the more complicated code performed in a higher level language, C++, within the Windows application HotBox.
The Dallas DS1820 datasheet explains the format of the response from the DS1820 when the 64-BIT lasered ROM code ID is requested and the memory map is requested. I trivially concatenate the two frames together.
I do no processing on the actual thermometer data within the PIC. I merely serialize it for RS232.
The PIC sends serial frames to the PC.
Run Terminal, or HyperTerminal, or a VT52 using "19k2, 8 none and 1" and you will see:
The DS18B20 device has a different initial byte and temperature encoding. Instead of 0x10 we have 0x28. Click here for the DS18B20 Serial frame description.
When testing a arbiter it is a useful first step to verify the serial link and operation of the PIC by using HyperTerminal or any other serial VDU emulator, or even a VDU! If you get a screen similar to the above, you can be pretty sure you've got a working Arbiter.
Don't attempt to run both HyperTerminal and Hotbox - communication ports cannot be shared. Close HyperTerminal when you are confident the hardware works, then use Hotbox, or tempsvc.
Device address and temperature is sent as "readable" hex data frames. The PC application Hotbox, or tempsvc validates the frame CRC's. These frames are described in the DS1820 device documentation.
Let's pull apart the first frame show in the above image.
The top row reads:
10,9A,29,13,00,00,00,3E,09,00,07,05,FF,FF,18,4E,C4
| The 64 bit ROM code: | 10,9A,29,13,00,00,00,3E |
| The scratch pad: | 09,00,07,05,FF,FF,18,4E,C4 |
Each DS1820 contains a unique ROM code that is 64 bits long.
BYTE 0 is always 0x10 for the DS1820. If you see a 0x28 look
here: you have a DS18B20 part!
BYTE 7 is the CRC - a method to verify there has been no data corruption in
the path between the DS1820 and the PC.
The intermediate bytes comprise the unique serial number.
| Scratch Pad | BYTE | Example |
| Temperature LSB | 0 | 09 |
| Temperature MSB | 1 | 00 |
| User Byte 1 | 2 | 07 |
| User Byte 2 | 3 | 05 |
| Reserved | 4 | FF |
| Reserved | 5 | FF |
| Count Remain | 6 | 18 |
| Count per °C | 7 | 4E |
| CRC | 8 | C4 |
The temperature is read in 0.5°C units. (Our example reads 4.5°C.) Bytes 6, 7 may be used to get a higher resolution.
I've reproduced the following table from the DS1820 Datasheet:
|
TEMPERATURE/DATA RELATIONSHIP TEMPERATURE DIGITAL OUTPUT Reading ------Binary----- -Hex- +85°C* 0000 0000 1010 1010 00AAh +25°C 0000 0000 0011 0011 0032h +4.5°C 0000 0000 0000 1001 0009h +0.5°C 0000 0000 0000 0001 0001h 0°C 0000 0000 0000 0000 0000h -0.5°C 1111 1111 1111 1111 FFFFh -25°C 1111 1111 1100 1110 FFCEh -55°C 1111 1111 1001 0010 FF92h *The power-on reset value of the temperature register is +85°C |
I've added the example for 4.5°C to help explain my above sample data frame.
It is beyond the scope of this page to explain binary and hexadecimal notation.
Please tell us at the forum if you have any question regarding this.