Hardware Reference
In-Depth Information
The checksum is a simple sum of the first 4 bytes. Any carry overflow is simply
discarded. This checksum gives your application greater confidence that it has received
correct values in the face of possible transmission errors.
Software
The user space software written to read the DHT11 sensor on the Raspberry Pi uses the
direct register access of the GPIO pin. The challenges presented by this approach include
the following:
•
Short timings: 26 to 70
ms
•
Preemptive scheduling delays within the Linux kernel
One approach is to count how many times the program could read the high-level
signal before the end of the bit is reached (when the line goes low). Then decide on 0 bits
for shorter times and 1s for longer times. After some experimentation, a dividing line
could be drawn, where shorter signals mean 0 while the others are 1s.
The difficulty with this approach is that it doesn't adapt well if the Raspberry Pi is
accelerated. When the CPU clock is increased through overclocking, the program will
tend to fail. There is also the potential for future Raspberry Pis to include CPUs with
higher clock rates.
The signal emitted by the sensor is almost a Manchester encoding. In Manchester
encoding, one-half of the wave form is shorter than the other. This allows counting
up for the first half and counting down for the second. Based on whether the counter
underflows, a decision is made about the value of the bit seen.
The DHT11 signal uses a fixed first half of 50 ms The bit is decided based on how long
the signal remains at a high level after that. So a “bit bang” application could get a relative
idea by counting the number of times it could read the low-level signal. Based on that,
it can get a relative idea of where the dividing line between a short and long high-level
signal is.
This is the approach that was adopted by the program
dht11.c
. It counts the
number of times in a spin loop that it can read the signal as low. On a 700 MHz nonturbo
Raspberry Pi, I saw this count vary between 130 and 330 times, with an average of
292. This time period is supposed to be exactly 50 ms, which illustrates the real-time
scheduling problem within a user space program. (The program did not use any real-time
Linux priority scheduling.)
If the sensor waveform is true, a max count of 330 suggests that the Raspberry Pi can
read the GPIO pin a maximum of
330
50
= .
66
reads
m
/
But the minimum of 130 GPIO reads shows a worst case performance of
130
50
= .
26
reads
m
/
