Click here for the DS1820 Arbiter frame format.
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 DS18B20 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 DS18B20 datasheet explains the format of the response from the DS18B20 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 initial byte of value 0x28. If you see 0x10 you have a DS1820 part.
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:
28,3A,54,1B,00,00,00,1A,A0,01,4B,46,7F,FF,10,10,6E
| The 64 bit ROM code: | 28,3A,54,1B,00,00,00,1A |
| The scratch pad: | A0,01,4B,46,7F,FF,10,10,6E |
Each DS1820 contains a unique ROM code that is 64 bits long.
BYTE 0 is always 0x28 for the DS18B20.
BYTE 7 is the CRC - a method to verify there has been no data corruption in
the path between the DS18B20 and the PC.
The intermediate bytes comprise the unique serial number.
| Scratch Pad | BYTE | Example |
| Temperature LSB | 0 | A0 |
| Temperature MSB | 1 | 01 |
| User Byte 1 | 2 | 4B |
| User Byte 2 | 3 | 46 |
| Reserved | 4 | 7F |
| Reserved | 5 | FF |
| Count Remain | 6 | 10 |
| Count per °C | 7 | 10 |
| CRC | 8 | 6E |
The temperature is read in 0.0625°C units. (Our example reads 26°C.) Bytes 6, 7 may be used to get a higher resolution.
I've reproduced the following table from the DS18B20 Datasheet:
|
TEMPERATURE/DATA RELATIONSHIP TEMPERATURE DIGITAL OUTPUT Reading ------Binary----- -Hex- +125°C 0000 0111 1101 0000 07D0h +85°C* 0000 0101 0101 0000 0550h +26.0°C 0000 0001 1010 0000 01A0h +25.0625°C 0000 0001 1001 0001 0191h +10.125°C 0000 0000 1010 0010 00A2h +0.5°C 0000 0000 0000 1000 0008h 0°C 0000 0000 0000 0000 0000h -0.5°C 1111 1111 1111 1000 FFF8h -10.125°C 1111 1111 0101 1110 FF5Eh -25.0625°C 1111 1110 0110 1111 FE6Fh -55°C 1111 1100 1001 0000 FC90h *The power-on reset value of the temperature register is +85°C |
I've added the example for 26°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.