Trouble with kernel DHT11 driver on Orange PI

Hello! Can anybody please help me?

I'm using armbian on Orange PI 3B v2.1, chip RK3566 and have troubles reading value from DHT11

Kernel: Linux orangepi3b 6.1.115-vendor-rk35xx
Sensor driver: kernel driver drivers/iio/humidity/dht11.c

I'm attaching DHT11 to GPIO3_D0 pin, and create node in DTB. But when trying to read value from it, I get errors (after enabling debug):

[ 2504.491143] dht11 dht11@0: current timeresolution: 41ns
[ 2508.023547] dht11 dht11@0: 45 edges detected:
[ 2508.023607] dht11 dht11@0: 1: 69125 ns low
[ 2508.023640] dht11 dht11@0: 2: 161875 ns low
[ 2508.023668] dht11 dht11@0: 3: 67958 ns high
[ 2508.023696] dht11 dht11@0: 4: 13125 ns low
[ 2508.023724] dht11 dht11@0: 5: 47834 ns high
[ 2508.023751] dht11 dht11@0: 6: 47541 ns low
[ 2508.023778] dht11 dht11@0: 7: 160417 ns high
[ 2508.023804] dht11 dht11@0: 8: 67375 ns low
[ 2508.023831] dht11 dht11@0: 9: 49291 ns high
[ 2508.023857] dht11 dht11@0: 10: 46083 ns low
[ 2508.023883] dht11 dht11@0: 11: 160417 ns high
[ 2508.023910] dht11 dht11@0: 12: 65625 ns low
[ 2508.023936] dht11 dht11@0: 13: 51916 ns low
[ 2508.023963] dht11 dht11@0: 14: 161584 ns low
[ 2508.023989] dht11 dht11@0: 15: 67083 ns low
[ 2508.024015] dht11 dht11@0: 16: 12250 ns low
[ 2508.024041] dht11 dht11@0: 17: 160708 ns low
[ 2508.024067] dht11 dht11@0: 18: 67083 ns low
[ 2508.024094] dht11 dht11@0: 19: 163333 ns low
[ 2508.024121] dht11 dht11@0: 20: 67375 ns low
[ 2508.024147] dht11 dht11@0: 21: 165084 ns high
[ 2508.024173] dht11 dht11@0: 22: 15166 ns low
[ 2508.024199] dht11 dht11@0: 23: 172083 ns high
[ 2508.024225] dht11 dht11@0: 24: 66209 ns high
[ 2508.024252] dht11 dht11@0: 25: 12541 ns high
[ 2508.024278] dht11 dht11@0: 26: 168875 ns high
[ 2508.024303] dht11 dht11@0: 27: 66208 ns low
[ 2508.024331] dht11 dht11@0: 28: 161875 ns low
[ 2508.024357] dht11 dht11@0: 29: 66792 ns low
[ 2508.024383] dht11 dht11@0: 30: 162458 ns low
[ 2508.024409] dht11 dht11@0: 31: 74958 ns high
[ 2508.024436] dht11 dht11@0: 32: 54542 ns high
[ 2508.024463] dht11 dht11@0: 33: 58333 ns low
[ 2508.024489] dht11 dht11@0: 34: 163041 ns low
[ 2508.024515] dht11 dht11@0: 35: 16625 ns high
[ 2508.024542] dht11 dht11@0: 36: 74375 ns high
[ 2508.024568] dht11 dht11@0: 37: 47542 ns high
[ 2508.024595] dht11 dht11@0: 38: 43750 ns low
[ 2508.024621] dht11 dht11@0: 39: 160708 ns low
[ 2508.024647] dht11 dht11@0: 40: 65333 ns low
[ 2508.024675] dht11 dht11@0: 41: 47834 ns high
[ 2508.024701] dht11 dht11@0: 42: 45208 ns low
[ 2508.024726] dht11 dht11@0: 43: 11375 ns high
[ 2508.024752] dht11 dht11@0: 44: 156333 ns low
[ 2508.024780] dht11 dht11@0: Only 45 signal edges detected

Testing with oscilloscope shows that communication is correct, firstly 20 ms pause, then 42 pulses with data. But driver misses edges of pulses. It uses IRQ on GPIO to detect edges, but misses part of them. Reading /proc/interrupts show the same amount of detected edges, as dht11 driver.

Have anybody encountered same trouble with gpio edges detection?

There are many things that can affect how accurately edges are detected by software. Some are hardware related, and some depend on how software configures the GPIO hardware.

I usually check these kinds of things.

• Check signal voltage and termination requirements. Things can look great on an oscilloscope, but the voltage levels or input current might not be correct for the GPIO to cleanly detect an edge. Make sure that you understand the requirements and check that they are met by the hardware you use. For example it is common for GPIO to detect 5V or 3V logic levels, and that changes the level where signals are seen as high or low. You may need to configure the software or hardware for the correct logic levels.
• Use the oscilloscope to look for overshoot or ringing that might make the GPIO input detect the same edge multiple times. To see that you often need an oscilloscope that can sample much faster than the serial data rate. Excessively long or short connections or incorrect termination resistors can cause problems. Make sure that you understand the distance limits and don't exceed those.
• Don't assume that the hardware is good. Check that other people have success with the hardware and that you are using the same setup. If you built the hardware, make sure that you did that correctly. If possible test the hardware on something else to see if you see the same behavior or different behavior.
• The Orange Pi uses different GPIO assignments and might even use different configuration for individual GPIO signals. If you are using software for a Raspberry Pi, check that you have correctly converted the software to work on an Orange Pi.
• GPIO pins can be configured to interrupt on either or both edges. The software that you use to decode the data may require a specific setting for which edges to detect. You may need to configure the software or driver for the correct modes to detect the correct edges.
• Test the GPIO input using a signal generator or some other device to verify whether the problem is the hardware device.
• Test the edge detection at a slower rate to verify whether the software detects edges properly at a slower rate.
• Some hardware and drivers depend on interrupt response times to function properly. Things like interrupt priority assignments or other high priority processing can delay interrupt processing for detecting edges. Eliminate as much other system activity as possible, especially interrupts.
• My other suggestion is to start out with an inexpensive, bare bones Raspberry Pi even if you plan to use other SOCs for your project. When I develop embedded applications I usually try to have at least two systems, preferably different kinds of systems to test hardware interfaces and software. The Orange Pi and other Pi clones are not actually similar hardware to the Raspberry Pi. They have similar kinds of devices, but the actual hardware and software interfaces are different.
• Orange Pi and other clones often have their own OS distributions and they may have out of date or modified drivers for devices. Check that you are actually using the driver you expect and that it is at least recent. Check which Linux kernel you are using. You may also want to look at bug reports for the driver and kernel.

If you are not getting closer to solving a problem, change something and observe the effect. Try to verify individual assumptions using other hardware or software. Re-read documentation or find other sources of documentation to see if they agree. Problems can be frustrating but they are also how we get experience and learn things.

Hi Erik!
Thank you for response!

1. voltage level correct - 3.3 volts. Communication speed about 10 kHz, and datasheet doesn't specify termination resistors
2. edges looks pretty good. Problem is not in too much false edges, but otherwise, orange pi doesn't detect some of edges - should be 83 edges detected (42*2-1)
3. I've tested dht11 with arduino, there it works absolutely ok
4. I use built-in vanilla kernel driver for dht11, no extra software
5. driver always explicitly configures gpio to detect both edges - rising and falling
6. yes, I will try to reproduce edge detection troubles with other source
7. changing rate is impossible, dht11 uses it's own encoding method for sending data: 25 us peak for transmitting 0, 70 us peak for transmitting 1
8. driver uses interrupts for detecting edges, so I'm trying to understand how set interrupt priority
9. I tried on arduino and stm32, but I'll try on RPi too
10. I use linux 6.1.15, driver's logic didn't modified since then, but it looks that problem not in driver itself, but in edge detecions

From Post #1:

Hello Vlad. I'm a hardware guy and there's only one way to find out what's going on. Beg/borrow or hire an oscilloscope. History lesson: In the beginning, logic was TTL, and specified

* V≤0.8V Guaranteed Logic Low
# V@0.8-2.0V Intermediate, Undetermined. In fact, as you descended from 2.0V the Voltage stayed High but usually switched either side of 1.0-1.2V, but not cleanly.
* Voltage≥2.0V Guaranteed Logic Level High.

Electronically, that was the stone age. In practise now for 3.3V circuitry, below about0.7V is low, above a volt is high, but you don't want to see thresholds. You want clean levels away from thresholds.

This is why you need the oscilloscope. Stick a clip on ground, poke the gpio pins and let them run - don't synch or trigger the trace, As the low levels and high levels run past, check the levels. This sort of thing comes from low levels that are not actually low or high levels that are not high, or high enough.

Originally Posted by business_kid From Post #1: Hello Vlad. I'm a hardware guy and there's only one way to find out what's going on. Beg/borrow or hire an oscilloscope. History lesson: In the beginning, logic was TTL, and specified * V≤0.8V Guaranteed Logic Low # V@0.8-2.0V Intermediate, Undetermined. In fact, as you descended from 2.0V the Voltage stayed High but usually switched either side of 1.0-1.2V, but not cleanly. * Voltage≥2.0V Guaranteed Logic Level High. Electronically, that was the stone age. In practise now for 3.3V circuitry, below about0.7V is low, above a volt is high, but you don't want to see thresholds. You want clean levels away from thresholds. This is why you need the oscilloscope. Stick a clip on ground, poke the gpio pins and let them run - don't synch or trigger the trace, As the low levels and high levels run past, check the levels. This sort of thing comes from low levels that are not actually low or high levels that are not high, or high enough.

Hi! I've already tested it (see original post), voltage levels are good (a bit higher than 3.3, but not critically), edges are clear

But may be slow raising edge matters, it has no spikes or ringing, just slow

How High are the LOW levels? That's the critical point. It's when your low levels are interpeted as high that things go crazy. Change your 'scope to 0.2V/cm and check again. Oscilloscopes are tolerant of overload. It might just be a few pins - that's why the free running trace is best.

Just FYI, modern cpus (AMD for sure) can run with cpu core VDD (= + Volts, literally 'Drain Voltages') as low as 0.8V. With a PN junction, nothing gets through without 0.5V bias. I'd expect a FET gate to need more, but probably between 0.55-0.8V everything happens, low, intermediate, high. This is at the cpu core. The voltages go up further out, but the speeds go down. I did a project with 74HCAUC Logic, which handled 250MHz but it ran on 2.5V.

Of interest is the wafer fab size? Can you find the spec? And where are you measuring the voltages? GPIO Pins would probably be safest.

How High are the LOW levels? That's the critical point. It's when your low levels are interpeted as high that things go crazy. Change your 'scope to 0.2V/cm and check again. Oscilloscopes are tolerant of overload. It might just be a few pins - that's why the free running trace is best.

Just FYI, modern cpus (AMD for sure) can run with cpu core VDD (= + Volts, literally 'Drain Voltages') as low as 0.8V. With a PN junction, nothing gets through without 0.5V bias. I'd expect a FET gate to need more, but probably between 0.55-0.8V everything happens, low, intermediate, high. This is at the cpu core. The voltages go up further out, but the speeds go down. I did a project with 74HCAUC Logic, which handled 250MHz but it ran on 2.5V. Of interest is the wafer fab size? Can you find the spec? And where are you measuring the voltages? GPIO Pins would probably be safest.

I looked at your trace. That's good. There's 10-15pF in the gate input capacitance, (externally) and a resistive looking pull-up. It could be a mosfet or resistor. I don't know the impedance, so I'll guess 10k for the example. Now there's a techie's approximation for the time to raise 2/3 VDD. Just multiply R x C, in this case
10^3 = 1^4x 12^-12 = 1.2^-7 or 0.12µS. But that's to get 2/3 way up your waveform, (=2.2V)whereas the switching would have taken place ≤1.5V, so you only need to get up to about halfway on the curve to guarantee switching in worst case scenarios.

I would: Connect the probe to earth, and adjust your trace vertically to be exactly on a horizontal line.Set to 0.2V/cm, don't trigger, and let it run free. You should see clear lows or highs, but a faulty component may cause intermediate levels. Finding that is another matter(!), but knowing it's faulty allows you to replace.I would set zero on the bottom but one line, so you could see -0.2V if it came. It shouldn't! You should see 1 volt or more onscreen. Check your low levels & report back.

Originally Posted by business_kid How High are the LOW levels?

No more than 0.2 V

Originally Posted by business_kid but a faulty component may cause intermediate levels

I've checked multiple times, no bad levels, sensor output signal always looks clear

Right. Your hardware gets a clean bill of health, the rise time is to be expected. The top speed of the logic comes when the rise time isn't finished before the negative edge, if you follow me. But your hardware looks fine.

I worked in Industrial Electronics, and never met GPIO. Industrial Electronics used discrete ICs, but the modern cpu is most unsuited to the task of switching GPIO pins.

Make sure the GPIO pins will operate on 3.3V. They might need 5V pull-ups, if the cpu is 5V tolerant. But usually it's a software issue. After my experience in the 1980s, I made a note to self never to use/repair GPIO. I've seen folks go grey over the duration of a project.

There is help online, software, etc. Use it. There are also microcontrollers, which are ideal for driving GPIO. You have 8 (or 16 bit) ports. They also have I²C serial ports, and an adress/data bus. You can issue a port instruction to set the GPIO legs. But I'd read, try support forums, give all relevant information (unlike here!) and take the advice.

EDIT: You'll find Raspberry Pi much better documented than Orange Pi. Good guides - even on gpio.

EDIT_2: You're always better off using level detection than edge detection with GPIO. GPIO is not timing sensitive. Each switching needs it's own song & dance routine.