17 replies to this topic

[RvBCrS]

Hi guys!

I bought this sensor: DHT11 from nuelectronics. Does anyone have any experience connecting this device to the Netduino? I tried to port the C++ code from the Arduino, but to be honest I have no idea how to do it! I really hope someone can help me out here!

Here is the arduino example: http://www.nuelectro...r_pde/dht11.pde

Here is the datasheet: http://www.micro4you...ensor/DHT11.pdf

Hope to here from you guys! Thanks in advance!

Ramon

[CW2]

I bought this sensor: DHT11 from nuelectronics. Does anyone have any experience connecting this device to the Netduino? I tried to port the C++ code from the Arduino, but to be honest I have no idea how to do it! I really hope someone can help me out here!

This sensor uses proprietary 'one-wire' interface (not to be confused with Dallas/Maxim 1-Wire), which requires microsecond delays - unfortunately, this is not possible to do in managed (C#) code, you'd need to implement a native (C++) driver in the firmware.

[Chris Walker]

CW2, Would the "bit banger" driver work for RvBCrS's requirements? Chris

[CW2]

Would the "bit banger" driver work for RvBCrS's requirements?

Unfortunately, not without modifications, because the communication requires sampling the input (the current implementation of BitBanger can only output clock and data). According to the device datasheet, after an initial 'reset' pulse (similar to 1-Wire Reset, but much longer >18 ms) and response, the sensor starts sending 40-bit data in form of '0' and '1' slots, where '0' is represented as 50 µs LOW followed by 26-28 µs HIGH, and '1' as 50 µs LOW + 70 µs HIGH.

Perhaps with clever sampling the native driver could be rather simple (e.g. wait and sample just to detect ~27 µs vs. 70 µs HIGH pulse), but IMHO it would still need some edge synchronization - depending on the actual HIGH signal duration deviance, it may be 40*2 µs worst case, which is the whole slot.

Or, it may be possible to do it via UART (similarly to 1-Wire), but I have not calculated the required baudrates; and in all likelihood an external circuitry (two transistors) is necessary to support open-drain data line (Tx and Rx wired together).

[RvBCrS]

Damn! Thanks for the response guys! I'm not going to be able to write a native driver, so unless someone has too much free time I'm going to give up on this sensor. Anyone wants to buy a DHT11 sensor

[CW2]

Anyone wants to buy a DHT11 sensor

Would you consider using an 8-bit microcontroller (such as ATtiny or ATmega) as a 'bridge' between Netduino and the sensor?

[RvBCrS]

Would you consider using an 8-bit microcontroller (such as ATtiny or ATmega) as a 'bridge' between Netduino and the sensor?

Yes that would be a fine solution, the only problem is don't it need to be a Arduino then? And in all cases I need to write C++ or C witch is a problem for me as I don't know how It would be even better if I could combine it with a 433Mhz wireless transmitter and receiver to wireless transmit the temperature.

[mishoboss]

Any news about supporting DHT11/DHT22 senors? I use now a regular Arduino Uno with 5 DHT22 sensors, using this library: https://github.com/n...o/Arduino-DHT22 However I would like to migrate to a more powerful board and using C# is like a dream coming true! But (there's always "but"), as far as I understand I can't just interface DHT22 with C# because of the strict timing needed for the communication. Is there any chance NetDuino to support these great and cheap sensors?

[Chris Walker]

Hi mishoboss, Are these OneWire sensors? If so, CW2 built some really nifty OneWire-enabled firmware for Netduino. Perhaps you could try this out and see if it works for you? Chris

[mishoboss]

Hi Chris, no, they're not one-wire. They use some own protocol.

[Chris Walker]

Hi Chris,
no, they're not one-wire. They use some own protocol.

You could build a native driver and build it into your firmware...or perhaps use SimpleNGEN from Corey Kosak (if it supports reading values yet--not sure on that one).

Chris

[mishoboss]

You could build a native driver and build it into your firmware...or perhaps use SimpleNGEN from Corey Kosak (if it supports reading values yet--not sure on that one).

Chris

Not sure if I could do this. Maybe I will use one Atmega168 just for DHT22 reading and pass the data via serial to NetDuino.
However I think a nice DHT11/22 support in NetDuino is essential.

[angrybirds]

I agree, wish there was some way to use these sensors with Netduino. I bought a pair of RHT03 from Sparkfun, http://www.sparkfun.com/products/10167 (which are the same as DHT22), only to find out I can't use them with Netduino.

[CW2]

I bought a pair of RHT03 from Sparkfun, http://www.sparkfun.com/products/10167 (which are the same as DHT22), only to find out I can't use them with Netduino.

Have you tried DHT11/22 sensor sample application? There have been a few cases where the communication did not work reliably, in all likelihood due to the deviations of the signal waveforms, but in most cases it works reasonably well.

[<Jeremy>]

Hi there I've been working on a DHT11 as well - I wonder if the the problem is interrupt information going missing from the queue. Basically I've tweaked CW2's code on my development machine to look at the DHT11 signal in a different way - as each falling interrupts edge comes through, I put the number of ticks since the last one into an integer array. If the number of ticks is greater than the BitThreshold, then it's a 1 - less than the BitThreshold means it's a 0. So according to the datasheet (and my experimentation), we should expect 43 trailing edges in a complete signal (3 during the initial handshaking, and then 40 for each bit of temperature/humidity/checksum information. (For my Netduino, 640/853/854 ticks represents a logic 0, and 1067/1280 represents a logic 1. This pattern is very consistent on my hardware, but YMMV.) Under Netduino firmware 4.1.0.6, I usually saw 43 trailing edges before communication stopped, but sometimes saw 42 - it seemed to lose one bit of data around position 23 for me. The failing position would usually have a value like 2560 ticks, which I guess meant it was two logic 1s that run into each other. So I think that somehow the falling edges are not being queued correctly. I've just updated my Netduino to firmware version 4.2.0.0 RC5, and now I'm only seeing a max of 30 - 40 falling edges before communication stops. Does anyone have any thoughts on this - is it a problem that's been solved? Or is there a maximum number of interrupts that can be queued in the buffer before it overflows? Or should I be posting this question in the 4.2.0.0 RC5 Firmware Beta page? Thanks for any help! Jeremy

[CW2]

I've just updated my Netduino to firmware version 4.2.0.0 RC5, and now I'm only seeing a max of 30 - 40 falling edges before communication stops.

Would it be possible for you to determine what interrupts are lost - at the beginning or at the end? There is one [IMHO breaking] change in .NET MF 4.2, which could be related (issue 1073, fixed in changeset 12496): if the interrupt queue is full, the oldest entries are removed to make room for new ones. If I remember it correctly, the Netduino queue size is 128.

[<Jeremy>]

The short answer is that I am sure the interrupts are being lost in the middle of the signal. Longer answer - I've been writing the values of pulse durations to the console, and one example is below: 1(7893120) // presence pulse 1(207573) // presence pulse 1(1707) // presence pulse 0(853) 0(853) 1(1067) 1(1280) 0(853) 0(854) 0(640) 1(1280) 0(853) 0(640) 0(853) 0(854) 0(640) 0(853) 0(853) 0(640) 0(854) 0(853) 0(640) 1(6187) // suspect 0(640) 0(853) 0(853) 0(640) 0(854) 0(853) 0(640) 0(853) 1(1280) 0(854) 0(640) 0(853) 1(1280) 1(1280) 1(1067) 0(0) // never populated 0(0) // never populated 0(0) // never populated 0(0) // never populated 0(0) // never populated (Timing values in ticks are in brackets for the 43 positions, preceded by the corresponding derived logic values.) So you can see that the netduino only reckons there were 38 falling egdes - the last five positions in the array have empty timing values because they're never populated by an interrupt event. At edge 23, it believes the length of the pulse is 6187 ticks. This is why I believe that the interrupts are being lost mid-stream, rather than at the beginning or the end. My guess is that is actually 6 successive pulses of length 1280 + 854 + 1280 + 1280 + 853 + 640 being rolled into one, but I can't tell what order (I guess it should end up being 101100). So the 5 bytes I actually try to process are: 00110001 00000000 // 49 Relative Humidity - about right 00010000 00001000 // 2064 degrees Celcius - bit warm 11100000 // checksum indicates the numbers are wrong And I think the 5 bytes I should be processing are: 00110001 00000000 // 49 Relative Humidity - about right 00010110 00000000 // 22 degrees Celcius - about right 01000111 // checksum indicates numbers are right So I'm not sure if this related to the FIFO change to the interrupt queue - but I'm not sure that I understand how that change fixes BitFlipper's issue 1073 either! Might this be a new bug? Jeremy

[johnflem]

I have the same problem that others seem to be having; it appears to be hooked up correctly, I had to change the latency from 18 to 70 to get checkPins to return true for ExpectedTrue, but it sill doesn't return a temperature or humidity..