Open bobbie12 opened 5 years ago
Issue persists: I tried kernel 4.14.78-2 with the same result. Has there been any change in the kernel structures or timing since around 4.14.72? Anyone out there with a working lol_dht22 version?
"Data not good, skip" after updating to 4.14.79. Tried changing the timing from 1ms to 2ms as mentioned in other forums as a fix on previous versions with no success.
As this bug is bothering me, I volunteer to run tests and provide logfiles. Can some developer give me hints what to check? I can read and program at least in C ;)
@bobbie12 I've been informed in a number of places that there's some sort of fix discussed on a forum, but I've never found the relevant thread or been shown a patch.
My difficulty is I'm not a kernel developer, I can only see code used to work, and some people (but apparently not all) find it doesn't after an upgrade. Meanwhile, the hardware in question doesn't produce any logs or give us anything to debug. It's been frustrating to fix. If you can dig up a patch that someone has recommended we can certainly discuss whether it helps.
@bobbie12 @zirkleta
I've finally got my hands on another RPi, with a whole new Raspbian and kernel 4.14.79. I've pushed a series of changes to deal with autoconf warnings, and more over, I've updated timing based on this source:
https://github.com/adafruit/Adafruit_Python_DHT/blob/master/source/Raspberry_Pi_2/pi_2_dht_read.c
They feel a lot better to me, but as always, it isn't 100% reliable, and I'm as bothered as anyone by how unclear it is to get the exact code that makes this work.
I can say that on my machine, I ran this script 20 times and got valid output first try 9 times, and second try 9 more.
I ran into the same trouble, many unusable values.
Modifying the code to find out more on this revealed that it is really a couple timing issues.
Result is, that the timing is essential and depending on the hardware you use (obviously as well as the kernel) and especially current cpu load). Solution could be to have some statistical analysis after collection of all values to find out, which transition is represents what (quite expensive) or to explicitly restrict on L->H transitions (to only time the H values).
I'll adjust the code based on my observations to have as good results as possible for my hw + sw. Hopefully I'll get a fork setup with my changes shortly.
Forked to https://github.com/gmanic/lol_dht22
Hi there, everything ran fine at least two years up till yesterday, but upgrading the kernel to 4.14.72-1 (Arch Linux) got me also "Data not good" even if the 2 microseconds fix is in the code. I cloned wiringPi and lol_dht22 but didn't got better. Hardware: Raspberry 1B. I'll try another sd card to copy a backup to see if the error goes away.
Update: I verified that running the pi1b with kernel 4.14.66-1 (from my backup) lol_dht22 is working as before. So this is no hardware failure. Now with a second check on kernel 4.14.72-1, I now get (after a couple of "Data not good") always Humidity = 0.00 % Temperature = 0.00 *C Has anyone similar problems with this kernel version?