Welcome, Guest
Username: Password: Secret Key Remember me

TOPIC: DHT11 anyone?

Re: DHT11 anyone? 8 years 1 month ago #8873

  • RogerTango
  • RogerTango's Avatar
  • Offline
  • Fresh Boarder
  • Thanks received: 2
Ive gotten no where with this project, but not giving up yet.

Reading the datasheet on the DHT11, Red's code looks "right", but no readings.

I ordered some more sensors, in the event I might have a bad one...

Will post back later with more results, I hope.
Andrew

Re: DHT11 anyone? 8 years 1 month ago #8874

  • jmessina
  • jmessina's Avatar
  • Offline
  • Senior Boarder
  • Posts: 44
  • Thanks received: 189
Reading the datasheet on the DHT11, Red's code looks "right", but no readings.
It looks to me that the timing numbers are set for running at 64MHz, not 16MHz. PULSIN uses a software loop, so it counts at 2.5us@16MHz, and 625ns@64MHz

The timing constants 130 and 70 would end up being 325us/175us at 16MHz, while they look more correct if you're running at 64M (81us/43us). Try turning on the PLL.

Also, the AmicusIDE doesn't need 'All_Digital = true', but the Proton version would (I believe).

One nit-pick... it would be better to actually simulate an open-drain pin instead of driving the line high. You can do this by loading the LAT register with a 0 and setting/clearing the TRIS bit to get a '1' or a '0', something like
Send_Start:
    LATB.0 = 0		' load LAT with a 0
    TRISB.0 = 0     ' make the pin an output. This will pull down the pin making RB0 low
    DelayMS 18 		' send 18ms low
    TRISB.0 = 1		' set RB0 to input. pin will go high because of pullup, simulating open-drain
    DelayUS 40 		' DHT will respond within 20-40us

Also, one thing to watch out for, and that's the CONFIG settings. You have the MCLR pin disabled and the INTOSC set. This can be a dangerous combination. On some parts this can prevent you from ever reprogramming the part since the programmer may not be able to get it back into ICSP mode, depending on which device and programmer you use.

Re: DHT11 anyone? 8 years 1 month ago #8875

  • RogerTango
  • RogerTango's Avatar
  • Offline
  • Fresh Boarder
  • Thanks received: 2
Thanks for the info. I will look into your advice more tomorrow. I was reading the PDS doc on PULSIN and was trying to figure out the timing with clock speed.

Thanks,
Andrew

Re: DHT11 anyone? 8 years 1 month ago #8877

  • jmessina
  • jmessina's Avatar
  • Offline
  • Senior Boarder
  • Posts: 44
  • Thanks received: 189
I was reading the PDS doc on PULSIN and was trying to figure out the timing with clock speed.
At one point I thought I found an equation, but all I see now is
The units are dependant on the frequency of the crystal used. If a 4MHz crystal is used, then each unit is 10us, while a 20MHz crystal produces a unit length of 2us.
So, just do a ratio of and you come up with: count rate (in usec) = 10us * (4MHz/clock)
The following user(s) said Thank You: RogerTango

Re: DHT11 anyone? 8 years 1 month ago #8880

  • red_kooga
  • red_kooga's Avatar
  • Offline
  • Fresh Boarder
  • Thanks received: 1
Hi Roger,

I also think it could be because PULSIN and PULSOUT are crystal dependent,
you could make PULSOUT variable until you get a response from the sensor then adjust PULSIN accordingly.
I plan to use with internal OSC eventualy for a weather station so i will try your code when i get 5 mins, we are decorating so most of my stuff is boxed up.

Re: DHT11 anyone? 8 years 1 month ago #8881

  • RogerTango
  • RogerTango's Avatar
  • Offline
  • Fresh Boarder
  • Thanks received: 2
Thinking out loud...

How about a 40 step for/next loop after a start signal and 40ms of wait time...

Inside the for/next, have a do/while with 1ms delay in it, however many times
it had to loop for the logic to either switch high or low will be accumulated
and evaluated for duration.

Thus, eliminating the dependency of the osc with pulsin.

Comments requested.

Andrew
Time to create page: 0.254 seconds