Hardware Reference
In-Depth Information
You may have noticed I mentioned the fact that the data signal is proprietary. When I say proprietary I don't
mean it in the sense that all documentation is locked away under a nondisclosure agreement, although some is.
What I mean in this case is that it's not using a well-known bus or protocol, say, like, 1-wire or the I2C bus. While
this makes it slightly harder to use, it's not impossible. The DHT11 is very sensitive with timing. When you first start
communicating with the sensor the following must occur.
1.
First, the controlling device must pull the data bus low. When the controlling device pulls
this bus low it must take at least 18 ms. Otherwise, the DHT11 will not detect that the
controlling device wants to do something.
2.
After this 18 ms the controller then pulls the data bus high. The controller must do this for
between 20 and 40 ms. During this time the DHT11 will send out a response.
3.
As soon as this occurs the DHT11 will then pull the data bus low for 80 ms. If the controller
attempts to pull this bus high at this time the start process would be aborted.
4.
After the 80 ms is up without interference, the DHT11 will then pull up the data bus.
5.
The DHT11 will keep the data bus high for another 80 ms. At the end of this time frame the
DHT11 will finally start to transmit actual data.
Take a look at Figure
3-4
and you can see an example of the start signal.
Vcc
Vcc
Gnd
Gnd
Controller pulls
data bus low for
18ms
Controller pulls
data bus high for
20us to 40us
DHT11 pulls
data bus low for
80us
DHT11 pulls
data bus high
for 80us
DHT11 starts
transmission
Figure 3-4.
The start signal for the DHT11
You can see that the DHT11 is quite timing-sensitive. This is where the first issue under Linux comes in. Linux
will do its best to abstract the hardware from you, by providing device nodes from the kernel. In normal situations
this is a very good thing. For example it makes it simple to access your serial port and use it as a TTY terminal. Where
it's not very good is for low-level hardware operations, for example, a timing-sensitive temperature sensor. The only
real way to ensure that the DHT11 works correctly under Linux would be to write some C code to handle the low-level
timing that is required. This type of sensor is best used on a micro-controller like the Arduino. Because I have an
Arduino, this was the first sensor I picked out for this chapter, only to come to the conclusion it's not the best fit for the
Raspberry Pi. So if the DHT11 is not a good fit, what is and why?
Introducing the DS18B20
The DS18B20, of course! The what? The DS18B20 is a 9 to 12-bit temperature sensor; unlike the DHT11 it's just a pure
temperature sensor and is not capable of sensing humidity, although the sensitivity of the DS18B20 is much better
than the DHT11 with a range from -55
°
C to +125
°
C. With the sensor being so small you could place it anywhere; it's
about the size of your common TO-92 transistor. There is one feature that the DS18B20 has that the DHT11 is missing
and that is a temperature alarm. The DS18B20 can alert you over its bus when it hits a user-set temperature. You can
set one high-temperature alarm and one low-temperature alarm. For its voltage and current draw, it's perfect for the
Raspberry Pi, only needing +3 V and under 1.8 mA. You could power and drive this sensor with one wire from the
