>> HANDS-ON WITH DALLAS SEMICONDUCTOR 1-WIRE AND ARDUINO
I was tinkering around with the 1-wire hardware and protocol a while back - time for a blog post!
designed by Dallas Semiconductor Corp is a device communications bus system
that provides low speed data, signaling and power over a single data wire. It
is typically used to communicate with small inexpensive devices such as digital
thermometers and weather instrumentation - such as the DS18B20 temperature
sensor which we will connect to an Arduino.
can be purchased at a low cost ($4.25 USD) or a
water proof version
version ($9.95 USD) that can report a temperature between -55C and +125C
with 9 to 12-bit precision; which would be sufficient for any basic temperature
monitoring setup you will ever need. You will also need a 4.7kΩ resistor,
a prototyping breadboard and some wire for connecting everything.
Information on the OneWire protocol has been published on the
Arduino Playground - where they refer to a simple easy to use
library written by
- if you want to get fancy, you could even create your own slave devices and
integrate custom 1-wire sensors into your projects.
For the purpose of this post - first we must wire up some sensors, a
fritzing diagram is provided:
The DS18B20 only requires the connection to a signal and ground channel; the
sensors are parasite power based they can obtain their power from the signal
wire which is connected to a +5V power source via a 4.7kΩ pull-up resistor.
The Arduino with all connections made via a prototyping shield is shown below:
The OneWire library provides a number of examples; even with one specific to
working with the temperature sensors. In the interest of completeness; I have
provided a version of a sketch configured to use the sensor pin as per the
fritzing diagram (PIN 3), available for download:
Let's get an understanding of what is going on in the code:
#define ONE_WIRE_PIN 3
This is the basis for working with 1-Wire - it takes care of dealing with
the complex signaling and communication to devices on the 1-wire bus. In
the loop() function; an iterator style interface is available to
cycle through each device on the bus:
// do we have no more addresses?
Serial.println("No more addresses.");
The addr variable contains a 64-bit unique identifier for the
device on the bus - the first byte represents the chip used within the sensor
(0x28 is the DS18B20) and the last digit is a CRC checksum; just
to verify that there hasn't been an interpretation of noise on the signal line.
// select the device and start the conversion with parasite power
// wait a short period of time for the conversion to be done
// read the scratch pad by powering up the line
// display the raw data
Serial.print(" Data = ");
for ( i = 0; i < 9; i++)
data[i] = onewire.read();
In order to read the data from the sensor; first the device must be selected
and since the device uses parasite power (from the signal line) a small delay
must be performed to allow the sensor to power up and generate the data for
processing. Once this period of time is done; a request to read the scratch
pad is done and nine bytes of data will be available for reading.
// convert the data to actual temperature
int16_t raw = (data << 8) | data;
byte cfg = (data & 0x60);
// at lower res, the low bits are undefined, so let's zero them
if (cfg == 0x00) raw = raw & ~7; // 9 bit resolution, 93.75 ms
else if (cfg == 0x20) raw = raw & ~3; // 10 bit res, 187.5 ms
else if (cfg == 0x40) raw = raw & ~1; // 11 bit res, 375 ms
//// default is 12 bit resolution, 750 ms conversion time
celsius = (float)raw / 16.0;
fahrenheit = celsius * 1.8 + 32.0;
The conversion of raw data to a temperature looks complicated; but it
really comes down to how much time was provided to the sensor to actually
power up and obtain the values. As can be seen, the lower the time between
powering it up and reading the scratch pad affects the resolution of the
result (accuracy). A complete first loop of the devices is shown below
on real hardware:
author: Aaron Ardiri
version: Nov 17 2015
ROM = 28 F0 74 DC 06 00 00 DC
Chip = DS18B20
Data = AC 01 4B 46 7F FF 04 10 86 CRC=86
Temperature = 26.75 Celsius, 80.15 Fahrenheit
ROM = 28 E1 CF DC 06 00 00 8F
Chip = DS18B20
Data = B4 01 4B 46 7F FF 0C 10 8E CRC=8E
Temperature = 27.25 Celsius, 81.05 Fahrenheit
ROM = 28 99 F3 DD 06 00 00 9C
Chip = DS18B20
Data = A3 01 4B 46 7F FF 0D 10 CE CRC=CE
Temperature = 26.19 Celsius, 79.14 Fahrenheit
ROM = 28 05 89 DE 06 00 00 08
Chip = DS18B20
Data = AE 01 4B 46 7F FF 02 10 AA CRC=AA
Temperature = 26.87 Celsius, 80.37 Fahrenheit
No more addresses.
It is interesting to see that even with the sensors so close in proximity
there is a slight fluctuations in the values reported (+26.17C to 26.87C) -
the specifications on the DS1820 does state that the accuracy is ±0.5C.
It may make sense to average these values to get a more consistent reading.
The protocol isn't exactly new - it has been around for a while; in fact in
1988, the Dallas Key (also known as an iButton) was integrated into a gift for
conference attendees (JavaRing) - surprisingly it is still possible to pick
one up on
eBay at a reasonable
price. You could easily integrate support for it into the above sketch and
use it as an identification mechanism!