DHT11

[Nathan_B.]

A quick fix would be to check to see if the data is in the range of the sensor's capabilities and if it is not within this range, discard that value or get another value until it is within the range.  It is possible that this is actually a legitimate method but that would depend on what the actual source of the issue is.

[1cecream]

How do I go about programming your mentioned "(1.) discard if out of range, (2,) retrieve new value" mechanism into Sambo's VIs?

I also wonder if this trait is exclusive to the DHT11, Perhaps buying the more advanced DHT22 might solve some of the physical issues (slow initialization)?

[Nathan_B.]

1cecream wrote:

How do I go about programming your mentioned "(1.) discard if out of range, (2,) retrieve new value" mechanism into Sambo's VIs?

Pseudocode:  if (out of range) then get new value else continue as normal, repeat.  I think that I would do this in a while loop with a timeout.

1cecream wrote:

I also wonder if this trait is exclusive to the DHT11, Perhaps buying the more advanced DHT22 might solve some of the physical issues (slow initialization)?

Well, that depends on the actual cause.  I don't believe the DHT22 is any better, IIRC it just has a bigger range and/or better accuracy.

[1cecream]

Nathan_B. wrote:

Pseudocode:  if (out of range) then get new value else continue as normal, repeat.  I think that I would do this in a while loop with a timeout.

Thanks for this! The code worked.

I'm still curious as to why the spikes are being generated in the DHT11 though. Could it be that the power supply is not decoupled? and if so, perhaps implementing a capacitor might cancel the spikes completely?

[Morvy187]

hey 1cecream how did you implement the pseudocode to override this spikes ....

[1cecream]

Hi Morvy,

I used a case structure, boolean cases that set boundaries on data report (if temp<0 or temp>100 do not report), and property nodes that report values that have passed said boolean requirements. However I should make it clear that for my particular problem, the mentioned code only "filtered" data from the DHT11 and is quite different from "overriding" unwanted spikes: I achieved the latter by setting  sampling rate of the DHT11 to 1 sample/second (which can be easily done using express VIs such as wait or delay). Another thing you might want to check is whether or not the 5V being fed to your DHT11 is additionally supplying power to other components such as motors, transistors etc... (high frequency devices), if so you should find an alternate source of power for such components.

Hope this helps!

[Morvy187]

well am wiring 4 sensors 5Vdc and GND in parallel is that might effect the reads !?
for that [property node] am not familiar how to deal with it would be very kind of you if u send me the VI or Sub.VI to do the filtering
i did it in another way but when it is out off range whether gives you a 0 or 100 ..but i need the last correct read and just ignore the Bad reads 
Thanks for your help

[1cecream]

Hi Morvy,

I'll show you screen shots instead (Don't want to have to extract the code from the unique VI I am using):

1.) Do not report data

2.) Report data

As for your question regarding....

(..4 sensors 5Vdc and GND in parallel is that might effect the reads..) - It depends on what sensors you are using. If they are low frequency components I believe it should not be a problem.

I strongly suggest that you also check your sampling rate as I had mentioned in a previous post. Though we may not share the same source of issue, lowering sample rate removed spikes in temperature report altogether.

[Morvy187]

Hi 1cecream

thanks fore your help i`ll try them its ok .....for the sensors am using the DHT22 i think they are low frequancy components .and for the sampling rate i tried several rates from 1sec - 3 sec but what seems work fine is 1 sec

[alus]

dear can u show the arduino code of this program?