DS1820 Arbiter Serial Frames

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.

DS1820 Frame Format:

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

DS1820 ROM code

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. 

DS1820 Scratch pad

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.5C units. (Our example reads 4.5C.) 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-

+85C*     0000 0000 1010 1010    00AAh

+25C      0000 0000 0011 0011    0032h

+4.5C     0000 0000 0000 1001    0009h

+0.5C     0000 0000 0000 0001    0001h

0C        0000 0000 0000 0000    0000h

-0.5C     1111 1111 1111 1111    FFFFh

-25C      1111 1111 1100 1110    FFCEh

-55C      1111 1111 1001 0010    FF92h

*The power-on reset value of the temperature register is +85C

I've added the example for 4.5C 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.

Back To Therm Home Page