Le Potato with DHT22

Well the good news is your not alone - I get the full buffer was not returned error so it seems that there is an issue with the CircuitPython DHT Library for this sensor.

I hooked up the DHT22 to a NodeMCU ESP8266 (along with an ILI9431 which is another frustration) and in about 1/2 an hour I had a fully functioning system with a color 320x240 display using the Arduino ILI9431 library and the Arduino Adafruit DHT sensor library. In the process I confirmed my Hardware was ok.

I’ll dig into the CircuitPython DHT 22 library to see if I can figure out the problem as it would be great to have appropriate solutions for such common activities on the Le Potato.

Well that’s good to know - here is some information I was able to gather that may assist you:

By looking for the error message in the source module (adafruit_dht.py) I figured out that not all of the pulses are making it back, so I modified the the module to print the number of pulses in the array when the condition that triggers the buffer error is met and I found that the number of returned pulses is wildly different each time.

In my tests I only get about 70 of the required 81 pulses.

This definitely seems to be more of a problem with the Library and Linux Architecture.

There does seem to be some comparable sensors with I2C capability for the same sort of price range as the DHT11 so it seems like that is the better route to go - but it doesn’t help you !!

It will be a good opportunity to dig out the Oscilloscope to try to get a bit more information. I do know that the circuitpython library can’t use pulseio with Linux and so is forced to use a cruder routine which clearly isn’t reliable.

I left a script running over the weekend that just polled 2 sensors constantly - alternating between each every second or so and would break once it returned a valid reading. It did manage to finally get one valid reading over the weekend after many runs (19,344 to be exact). My goal here is to have a temp/humidity sensor in a room different to the Le Potato. The DHT22 in theory should be perfect for that, I read somewhere on a spec sheet that it can transmit down a considerable length of wire. If I’m not mistaken, I2C is only good for a very short distance right? What do you think may be another viable alternative if this sensor doesn’t work out? I’ve read about one wire, and maybe that’s something to look in to but (granted I’m not entirely sure what I’m looking for) I could only find sensors such as the DS18B20 that don’t include humidity.

image

AHT10/20 seem like pretty good options for an I2C board and there is a library for them.

adafruit-circuitpython-ahtx0 · PyPI

My old Xmas light Pi2 based led matrix has been going up for the last 10 years and the cables are at least 20ft long to an MCP23017 based I/O expander driving 32 outputs to create multiplexed characters & patterns so I would say its pretty reliable !

Going off of that, we will give this sensor a try. Once they arrive and I give them a try I will update this thread. Thanks again!

Update as promised:

The AHT20 sensor arrived, however it gives pretty inaccurate readings, I will mess with my script and see if I can get it reading correctly.

However, I also got some DS18B20 sensors that use the 1-wire protocol and those are working perfectly! I have multiple sensors with their data lines both leading back to the same pin on the Le Potato and am able to read each sensor’s value accurately. The only downsides to these sensors are that they don’t have humidity reading capabilities and also that since they have a larger thermal mass they are slower to respond to changes in temperature. If only I could get a 1-wire humidity sensor then we’d be in business…

DS18B20 (one in a light fixture for testing, the other just getting an ambient temp):
image
These seem pretty spot-on.

AHT20 (in ambient temp, near the ‘cool’ DS18B20):
image
The humidity may be accurate, but the other measurements for sure aren’t.

Glad you at least got some values. I will take a deep dive into the DHT22 some time but busy on a few other projects at the moment.

I too, have the same exact problem “A full buffer was not returned. Try again.” Same sensor as well.

Also same here :smile: - if you have a moment, can you share how you were able to get 1-Wire devices to work on the AML-S905X-CC / Le Potato?

So far, I’ve tried adding dtoverlay=w1-gpio to boot/config.txt, but cannot get anything to show up after:

sudo modprobe w1-gpio
ls -l /sys/bus/w1/devices/

Did you have to do anything special with pin outs?

Thanks in advance!!

Did you read about the Libre Wiring Tool ?

Libre Computer Wiring Tool - Hardware - Libre Computer Hub

Normally you can just enable the Overlay using the tool and you don’t have to mess with any other configuration.

There does appear to be a w1-gpio overlay, which I suspect Michael used but he can comment further !!

thank you @Iain_R - normally i’m better at digging (was a long night :sweat_smile:) - appreciate it!

ldto enable w1-gpio

did the trick on GPIOCLK_0 #7

Evening,

Be nice people! this is my first try all this.

Couple things confusing me. here’s my set up.

Le potato with debian from their website.
I enabled GPIO from the rasp-config menu
I ensure the Config.txt has that famous line.
to be sure, I enable w1-gpio

I’m currently trying to set a DS16B20.
I made a mistake when I ordered my resistor and currently only have a 2ohm. maybe that the core issue? the 4 Ohm is on its way.

First questions

  • Should I use 5.5 or 3V, the sensor seems to support both. FYI, I will have 2 sensors connected to one wire. Simply tring to get one going.

  • which pin!?!? pin 5 seems to be for GC0:4 would that be the one? I also notice people connecting to pin 7. I tried both, doesn’t seem to work.

Because I’ll be using openhab to report my value, I need to have (unless you have better idea) w1/device/XYZ configure. When I ls ondevice, I don’t see anything.

Please help!

I just found this:

It should be possible to use the sensor with an overlay.

EDIT:

I’ve been trying to look at DHT-11/DHT-22 DTO’s for other boards. So far I’ve only found a RPi overlay, and contains some Pi specific weirdness per usual. This is what I’ve come up with. It compiles and enables, but nothing new shows up in /sys/bus/iio/devices/ :

/*
 * Overlay to enable DHT-11/DHT-22 Temperature/Humidity Senor
 */

/dts-v1/;
/plugin/;

#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/gpio/meson-gxl-gpio.h>

/ {
	compatible = "libretech,cc", "amlogic,s905x", "amlogic,meson-gxl";

	fragment@0 {
		target-path = "/";
		__overlay__ {
				dht11: dht11@0 {
					compatible = "dht11";
					gpios = <&gpio GPIOCLK_0 GPIO_ACTIVE_HIGH>;
					status = "okay";
			};
		};
	};
};

Thank everyone used to make a comment on this topic.
I’m trying make DHT11 work too these days on Le Potato, and my platform is raspbian 11 installed on emmc5.0.

To me, I don’t think adafruit_dht under python is possible to work, because I found out that after sending out pull-down signal 18ms to dht11, the corresponding gpio pin takes like 5ms to switch to INPUT status and catch the voltage signals from DHT11. Under such circumstances, a few signals slip away thus the pulses can hardly reach 80 and causes error “a full buffer is not returned”.

After the above struggle, I got inspired by the comment left by angus. I think c can be faster and straightforward unlike python sometimes needs to load functions from other packages. So I started to combine these 2 things I found during my research. FYI, AVR-DHT/Files at master · efthymios-ks/AVR-DHT · GitHub and mraa/include/firmata at 8b1c54934e80edc2d36abac9d9c96fe1e01cb669 · libre-computer-project/mraa · GitHub.

In short, the programmer wrote his own dht library on avr device, and I tried to make it work on le potato board. The current major issue is where to include the files defining digitalwrite/read, bitset, pinmode and etc. for le potato?

Besides, so as to say Arduino IDE, I cannot find compatible board in board manager. I guess I just give up on this approach.

Also, If anyone has made successful readings from dht11 (80%+ plausible data per run) on le potato please guide me here. Thank you.

  1. MCU code will never work with Linux.
  2. DHT11 is already part of the Linux kernel. Check what the driver is doing here: linux/dht11.c at master · torvalds/linux · GitHub
  3. Use device tree overlays (since they use fast kernel drivers and not random userspace libraries). We don’t have any device to test.
  4. DHT11 uses the gpiod_to_irq function so it needs an IRQ enabled kernel.
sudo apt update
sudo apt install linux-image-lc-lts-arm64
1 Like

Thank you for the advices which make me one step closer.
Just some updates at this stage. Desperately seeking for advice and solution.

I tried to write the dts file based on what @angus mentioned above.
As the device tree concept is quite new to me, I tried to compile the dts file by using device-tree-compiler and added the output dtbo file back to customized overlay directory via below cmd,

dtc -I dts -O dtb -o dht11.dtbo dht11-overlay.dts
cat dht11.dtbo > /sys/kernel/config/device-tree/overlays/dht11/dtbo
/* dth11-overlay.dts 
 * Overlay to enable DHT-11/DHT-22 Temperature/Humidity Senor
 * I applied gpiox_7 with default high voltage, i.e. 86 0, as the dts is not including dt-bindings files
 */

/dts-v1/;
/plugin/;

/ {
	compatible = "libretech,cc", "amlogic,s905x", "amlogic,meson-gxl";

	fragment@0 {
		target-path = "/";
		__overlay__ {
				dht11: dht11@0 {
					compatible = "dht11";
					gpios = <&gpio 86 0>;
					status = "okay";
			};
		};
	};
};

By doing these I can find the corresponding overlay in two places,
“/proc/device-tree/dht11@0”;
“/sys/bus/iio/devices/iio:device1/”;

After all these have been done, I created a Demo.c to see how far I went,

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <errno.h>


typedef unsigned char u8;
typedef unsigned short u16;

typedef struct	DHT11_SENSOR_DATA
{
	u16 temp;//temperature
	u16 hum;//humidity
}dht11_data;

int main ( void )
{
	int fd ;
	int retval ;
	dht11_data Curdht11_data;
	//fd = open ( "/proc/device-tree/dht11@0/gpios" , O_RDONLY) ;
	fd = open ("/sys/bus/iio/devices/iio:device1/subsystem/drivers_probe" , O_RDONLY);
	if ( fd == -1 )
	{
		perror ( "open dht11 error\n" ) ;
		exit ( -1 ) ;
	}
	//printf ( "open /proc/device-tree/dht11@0 successfully\n" ) ;
	printf("open /sys/bus/iio/devices/iio:device1/subsystem\n");
	sleep ( 2 ) ;
	while ( 1 )
	{
		sleep ( 1 ) ;
		retval = read ( fd , &Curdht11_data , sizeof(Curdht11_data) );
		if ( retval == -1 )
		{
			perror ( "read dht11 error" ) ;
			printf ( "read dht11 error" ) ;
			exit ( -1 ) ;
		}
		if(Curdht11_data.temp != 0xffff)
			printf ( "Temperature:%d.%d C,Humidity:%d.%d %%RH\n",Curdht11_data.temp>>8,Curdht11_data.temp&0xff,\
																 Curdht11_data.hum>>8,Curdht11_data.hum&0xff ) ;
	}
	close ( fd ) ;
}

However, the readings are still incorrect. I’m contemplating those drivers_probe and drivers_autoprobe file under subsystem folder at the moment…

One more thing to add…I just tried drivers_autoprobe
Shall I doubt my dht11 is broken?

EDIT: the dht11.ko has been found and “insmod” on path “/lib/modules/6.1.30-06317-g8f5da1e8aa88/kernel/drivers/iio/humidity” which is the current running kernel.

Some relevant dmesg log:

# successfully added the driver to the device tree;
# no info for cmd insmod dht11.ko, but lsmod does work (refer to the above screenshot);
[  148.509641] gpio irq setup: hwirq: 0x60 irqfirst: 0x59 irqlast: 0x6B pin[86].
# failed to cat files like in_temp_input/in_humidityrelative_input
[  290.463030] genirq: Setting trigger mode 3 for irq 51 failed (meson_gpio_irq_set_type+0x0/0x60)
[  312.326090] genirq: Setting trigger mode 3 for irq 51 failed (meson_gpio_irq_set_type+0x0/0x60)
[  465.180711] genirq: Setting trigger mode 3 for irq 51 failed (meson_gpio_irq_set_type+0x0/0x60)
  1. Use the libretech-wiring-tool ldto infrastructure rather than manually doing it.
  2. Use the proper GPIO defines for the overlay rather than manually calculating it yourself.
  3. The overlay should probe the driver and load the module automatically when enabled or merged.

This means that it’s not able to set the GPIO IRQ to count the pulses so you would not get valid data. Try using a GPIOAO pin.

Hello,

  1. tried compiling it through the libretech-wiring-tool tool
  2. modified dts file to include the dt library.
  3. tried pins like GPIOX_7/GPIOCLK_0/GPIOAO_5. For gpioao it was failed at creating overlay
  4. used ldto cmd to enable dht11.

    GPIOX_7 or GPIOCLK_0:
    failed at cat /sys/bus/iio/devices/iio:device1/in_humidityrelative_input

    GPIOAO_5:
    failed at creating the overlay

    I then tried ldto enable w1-gpio
    and checked the dmesg log showing successfully installed.
    Below screenshots for comparison;

So, my decision is to give in the device dht11 and turn to ds18b20 this time since w1-gpio overlay is embedded and no need for me to create anything myself.

  1. GPIOAO uses the &gpio_ao alias rather than &gpio.
  2. See how it’s done here: https://github.com/libre-computer-project/libretech-wiring-tool/blob/master/libre-computer/aml-s905x-cc/dt/pps-gpio-7j1-12.dts
  3. DHT11 default kernel code seems to require interrupt on both edges. That’s why it wasn’t working for you. Amlogic platforms have difficulty with double edge interrupt triggers since it needs to set two triggers (one for rising and one for falling). We’re researching this to see if we can resolve.
2 Likes