Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.
|
Forum Index : Microcontroller and PC projects : DHT22 PicoMite 5.07.06 jumping readings
Page 2 of 3 | |||||
Author | Message | ||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6098 |
Glen, Try OPTION CPUSPEED 250000 I am beginning to think that the high speed is much more reliable. (Still don't know why) Jim VK7JH MMedit MMBasic Help |
||||
Glen0 Regular Member Joined: 12/10/2014 Location: New ZealandPosts: 86 |
Changed to 250000 and it has run for 3 minutes without a single 1000. Thanks |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1101 |
I've been able to capture both valid and invalid responses from the DHT11 with a Logic Analyser. For the same temp and humidity, the response from the DHT11 for both valid and invalid responses are identical (number of pulses, pulse widths, pulse timing). The only difference I can see is that and invalid response comes back from the DHT11 slightly quicker - varies a bit but roughly 50uS - 19.1mS after Pico takes the signal pin low for a valid response versus 19.05mS for an invalid response (ie. a temp/humidity of 1000). As best as I can determine, the 1000 figure is not coming from the DHT11? Will try to catch an invalid response at 250000. This is the test code ' DHT11 Test ' Picomite 5.07.07b10 Dim float temp,humidity,last_temp,last_humidity Dim integer i = 0,ec = 0 SetPin gp14,dout Do Bitbang humid gp13,temp,humidity,1 If temp = 1000 Then Pin(gp14) = 1 EndIf Pin(gp14) = 0 Inc i Pause 2000 CLS Box 5,20,150,120,,RGB(blue) Box 165,20,150,120,,RGB(Blue) Text 6,0,"TEMPERATURE",,2 Text 175,0,"HUMIDITY",,2 Text 10,55,Str$(temp)+Chr$(96),,5,2 Text 170,55,Str$(humidity)+"%",,5,2 If (temp < 5) Or (temp > 40) Or (Humidity < 5) Or (Humidity > 90) Then Inc ec Print "Error at " + Time$ + " The temperature is " + Str$(temp) + Chr$(96) Print "Last temperature was " Str$(last_temp) Print "Error at " + Time$ + " The humidity is " + Str$(humidity) + "%" Print "Last humidity was " Str$(last_humidity) Print "Error count is " ec " at run count " i EndIf If (i Mod 100) = 0 Then Print "Run count: " i Else Print "."; EndIf last_temp = temp last_humidity = humidity Loop > This is the pulse code for 22 degrees temp and 34% humidity Doug. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1101 |
As I go to bed for the night, 5200 loops with no errors at cpu speed 250000 and still counting. Doug. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2135 |
That's right, BITBANG HUMID generates that if it gets no response or the checksum bytes don't match. What is not clear is whether small fluctuations in the pulses sent by the DHT are enough to be misread by the Pico or, is the origin of the problem at the Pico end. |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6098 |
I shutdown my 200MHz test run with a count of 12000+ reads without error. The same setup at 133MHz gives regular errors at least every 100 readings. 150MHz was just as unreliable. I am currently testing 180MHz and up to 400 successful reads so far. Edit: 180MHz failed in two runs after 500 and 600 readings so for my current board, 200MHz is the minimum for reliable DHT reading and as it's the 16M flash one, 200MHz is also the safe maximum speed... My feeling is that there is a background task running that takes too long at the slower CPU speeds. The small timing variations coming from the DHT22/11 are not anywhere enough to upset the pico code by itself. Jim Edited 2023-01-31 07:47 by TassyJim VK7JH MMedit MMBasic Help |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1101 |
I agree with Jim, my overnight run at 250000 cpu speed was 48000 cycles with no errors. Catching both good and bad traces on the DHT11show no significant variation in timing of the pulse widths or inter pulse spacing. The initial pulse is 12.75uS give or take 500nS (sampling error). The space to the first pulse is 82.75uS +/- 500nS A wide positive pulse is 87uS The inter-pulse space is 54.25uS and the narrow positive pulse is 23.75uS The first pulse shown above is the initial pulse from the DHT11. Doug. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1101 |
This might be a load of old coblers but I think the issue with DHT11 error rates high with low cpuspeed may be as follows:- Referring to this section of code from External.c if(argc==7){ dht22=getint(argv[6],0,1); } // pulse the pin low for 1mS // *** *** 1mS for DHT22 or 19mS for DHT11 uSec(1000+dht22*18000); writeusclock(0); timeout = 400; PinSetBit(pin, CNPUSET); //#1 PinSetBit(pin, TRISSET); // ***at this point CRO indicates pin is low and stays low the whole 19mS if DHT11 uSec(5); // wait for the DHT22 to pull the pin low and return it high then take it low again //*** at this point, we have already waited 19.005mS and pin is already low for DHT11 while(PinRead(pin)) if(readusclock() > timeout) goto error_exit; // pin lo so fall thru ?? //*** at low cpu clock I think we might miss the start of the timing pulse // so the pin will now be high and thus fall thru the next line while(!PinRead(pin)) if(readusclock() > timeout) goto error_exit; // *** again at lo cpu clock, I think we have missed the timing pulse so // this next line will think it found the first data bit instead of the end // of the timing bit ??? while(PinRead(pin)) if(readusclock() > timeout) goto error_exit; // PInt(readusclock());PRet(); // now we wait for the pin to go high and measure how long it stays high (> 50uS is a one bit, < 50uS is a zero bit) for(r = i = 0; i < 40; i++) { timeout=400; while(!PinRead(pin)) if(readusclock() > timeout) goto error_exit; timeout=400;writeusclock(0); while(PinRead(pin)) if(readusclock() > timeout) goto error_exit; r <<= 1; r |= (readusclock() > 50); I make absolutely no claim to fully understanding the code but it seems like it could be an area where timing might be affected by cpu speed. Regards, Doug. Edited 2023-01-31 14:03 by panky ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6098 |
The first writeusclock(0); is after the start pulse time has finished. Jim VK7JH MMedit MMBasic Help |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1101 |
Jim, How so? For the DHT11, the delay in the code from the Pico is 1000mS + (1 * 18000) = 19mS There is an additional 5uS before the WHILE statement. All my timings on both cro and logic analyser show the delay from when the Pico pulls the pin lo to when the timing pulse starts never less than 19.4mS? Doug. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1101 |
Given that the error exit can only come from either 1 of the 3 while statements associated with establishing the timing pulse or the 2 associated with actually reading the data and all my logic catches show the data to be correct for both good and bad readings, I think the more likely place where the error may be occurring is somewhere within the first 3 while statements? Doug. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1101 |
It may be that I am completely off the track but at least I have had fun playing with the logic analyser and cro Please don't make the assumption I actually know what I am talking about - just trying to look for possible areas of where the problem may be. Doug. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6098 |
On your trace. transition 1 is the end of the 1mS or 19mS start pulse. timeout counter is reset here. Control is handed to the DHT 1-2 5uS wait then 20uS wait while pin is high. while(PinRead(pin)) if(readusclock() > timeout) goto error_exit; 2-3 wait ~80uS while pin is low. while(!PinRead(pin)) if(readusclock() > timeout) goto error_exit; 3-4 wait ~80uS while pin is high. while(PinRead(pin)) if(readusclock() > timeout) goto error_exit; 4-5 is the first ~50uS low state in the FOR loop 5 is when the timeout timer is reset. timeout=400;writeusclock(0); 7 is the next time the timer is reset ready to time the high state and watch for timeout. A working system will have a maximum time of 5+20+80+80+50 = ~235uS plus another 10-20 elongated delays so well under the 400uS timeout Jim VK7JH MMedit MMBasic Help |
||||
phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2135 |
PicomiteVGA 126MHz average 1 error per 1000 samples 378MHz 8000 samples so far no errors. |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9110 |
I hope you are all enjoying yourselves when a simple "if 1000 then ignore" solves the issue with what is a very old low-tech part of use for slow low-tech applications. The issue at low CPU speeds is almost certainly conflict with either the USB or 1mSec timer interrupt in the firmware causing a bit to misread - nothing more complicated than that. I could disable interrupts during reading the chip but this is something I only do when absolutely necessary (e.g WS2812) and disabling for 235uS is not ideal. Edited 2023-01-31 18:11 by matherp |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1101 |
@Jim, I think the issue is not that within those WHILE statement timing out, rather that for slow CPU speeds the third WHILE ends up being hung on the trailing part of the timing pulse leading to the data being wrong. I know from the logic analyser that the data sent from the DHT11 is correct. @Peter, I understand that this is easily worked around as you recommended but surely this classifies as a bug? Would not fixing it surely be the proper way to resolve? It could be achieved by scaling the delays [1mS or 18mS) by the CPU speed? Please understand that I am not questioning your judgement - it is absolutely your call so I will but out and leave the subject to you. Regards and thanks for the terrific work and contribution you make to this forum, Doug. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6783 |
erm.... but this is a cheap, plastic temperature and humidity sensor, not a precision thermocouple in PID loop. How much will those values change in a few seconds? When I was working on building management stuff we were happy with reaction times in the order of 10 mins. Even that was too fast in some cases. It can take a 3-port valve well over 30s just to move from one port to the other. :) It's all good fun though. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9110 |
The timings are, of course, scaled. As I stated above the issue is the readings being affected by the time taken in USB and/or timer interrupts. This is easy to fix by disabling interrupts but that could have other impacts on other ongoing work. Try running at CPU 48MHz and see how bad it is. I've got it running perfectly at that speed with interrupts disable |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1101 |
Thanks Peter, at 48000, failure averages 1 in 10 or sometimes even worse. At 100000, failure goes back to 1 in 100 or down to 1 in 300. At 133000, failure rate drops to 1 in 600 or better, even down to 1 in 1000+ At 250000, there were no failures, for a run of over 48000 cycles. Doug. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6098 |
80MHz gives me a failure rate of 1 in 5 It is easy enough to code around as long as the user knows that it is firmware and not their wiring or module that's faulty. Jim VK7JH MMedit MMBasic Help |
||||
Page 2 of 3 |
Print this page |