9 replies to this topic

[Paul Bates]

I would like to use an AM2302 temp/humidity sensor with a Netduino+

They offer source code for the Arduino that I am going to try porting to Netduino+, but I need a few pointers

1) I would like comments on this as Temp / Humidity sensor if anyone has experience
2) I have a background in micro controller programming, but it has been along time and hardware has changed:
- I see how to connect power
- How to what type of input/# do I connect the data input wire on the Netduino+
- Any special settings in the netduino to access the AM2302 in prepartion to reading it /
coding?

Thanks in advance to any comments you have

Paul

[Stefan W.]

Reading that sensor is a bit tricky with the netduino, as it requires microsecond timing while reading the data. Are you restricted to that sensor?

[CW2]

I would like to use an AM2302 temp/humidity sensor with a Netduino+

If this is DHT22 sensor, you may want to check out DHT11/22 sensor driver sample.

[Paul Bates]

Reading that sensor is a bit tricky with the netduino, as it requires microsecond timing while reading the data. Are you restricted to that sensor?

Hi, No I am not restricted to that one. I did like the fact it was wired and seemed accurate. It had code to review which gave me a logical flow of what to do .net wise

Please suggest others, thank you

[Paul Bates]

If this is DHT22 sensor, you may want to check out DHT11/22 sensor driver sample.

Hi, Yes it is.

The application is a temperature / humidity sensor for an attic. I don't need split second changes. This information will partially be used to activate/deactivate an attic fan. Readings less than 5 minutes apart have to be "de bounced" when the fan comes on because the fan cools the attic back down for the first couple of minutes, and then it warms back up. There is no advantage to running the big 30" for less than 5 minutes.

If the downside of getting the timing wrong is that a number of readings come back as errors because interpretive .net isn't ready, I can deal with that. However if it is tricky to get a reading at all, that's a different story.

Thank you both for your replies and any additional direction you can provide

Paul

[Mario Vernari]

I don't own a similar sensor (which has a particular interface), so I can't make any experiment. Anyway, it seems that -once the master starts the message- the remaining of the bits are totally driven by the slave (the one-wire protocol is master driven instead). Well, what if we wire the sensor data to the MISO input of the Netduino? Suppose to set up the SPI so that the sample rate (i.e. clock frequency) is about 50KHz (20us), although is not critical. Just forget the "start" marker for a while...Then, the software should start a SPI (write+)read of a certain number of bytes. According to the sensor's specs, the worst case is when it outputs 40 bits at logic "1", which means 120us * 40 = 5ms (approx). If the SPI is sampling at 50KHz, for instance, it collects 100 bits (13 bytes) for 5mS. Let's consider 16 bytes (or more) to be safe. So, the SPI should start a WriteRead of 16 bytes. Upon completion, the read stream should contain the sampled data line of the sensor, which may be analyzed with a C# algorithm of reconstruction. How to start the message? It should be easy, I think. The MOSI pin (i.e. output data) would be unused, since the communication is over one wire. By the way, since we perform a SPI write+read at same time, the MOSI data is available at no cost for any purpose. Now, suppose to wire the MOSI to the MISO by a normal diode, so that when the MOSI is going low will pull the MISO as well. The sensor requires at least 500us of low-level to detect the start of the message: at 50KHz it's at least 10 bits. So, consider the output buffer having the heading bytes (16 bits) as 0x00, and all the remaining at 0xFF. The result should be compliant to the sensor expectancy, and the collected incoming data should be decoded with a relative simplicity. Of course, this is much like a hack, and a more elegant way is surely preferable, but...if anyone wish to try, I think would be really interesting. As stated, I can't try, being without such a sensor. Cheers

[CW2]

Of course, this is much like a hack, and a more elegant way is surely preferable, but...if anyone wish to try, I think would be really interesting. As stated, I can't try, being without such a sensor.

Originally, I was thinking about [ab]using SPI too, but as it turned out, the interrupt-based communication works rather well (better if the firmware clock resolution is increased). I have both (DHT11 and DHT22) sensors, which I used during development, there are slight differences between the specification timing and real device.

[Mario Vernari]

There's no doubt about a native way or a quick-sampling trick. My goal is toward who's asking for a decent way to read the sensor, without having to recompile the firmware. For example, who owns a N+. Anyway, I don't understand...using your super-clock firmware, are/would you able to sample this sensor's data, collecting the sample in real-time? I may believe about the clock increase, but I'm still suspicious about the managed code to store the collected data, PLUS the possible delays caused by the GC. How would you solve this particular problem?

[CW2]

Anyway, I don't understand...using your super-clock firmware, are/would you able to sample this sensor's data, collecting the sample in real-time?
I may believe about the clock increase, but I'm still suspicious about the managed code to store the collected data, PLUS the possible delays caused by the GC.
How would you solve this particular problem?

The sensor data can be read using the 'stock' firmware, no modifications are necessary. But, because the slow clock resolution is close to the length of bit pulses, it may cause false readings (also the real device does not have the timing exactly according to the specification), such errors can be detected via checksum or by checking measured values (both sensors have very limited measurement range and precision, which makes it easy to detect invalid values).

'Super-clock firmware' just decreases the error of pulse length measurement, it allows precision of ±2.7 µs instead of 'default' ±21.3 µs (which is significant, considering the bit pulses are 50 + 27 and 50 + 70 µs specified, about 54 and 73 µs in reality, depending on the particular sensor).

In my trivial application, I did not care about GC, it did not happen. You are right, GC can disturb the communication, but there is not really much we can do about that - the solution would be single-wire native driver (that can disable interrupts) or PinCapture.

[Paul Bates]

Thank you for those thoughts guys. So I have ideas on how to proceed with this sensor. To the early comment, I don't have to have this particular sensor. I found it looking at a number of them and liked it. However, if there is something you have already attached to the netduino it would be good to hear about. If my requirement is getting a reading every few minutes within an expected range, is there a device you've used that's easier to connect to the netduino? As you pointed out, managed code can deal with the results... unexpected values can be easily identified and simply dropped and the final application will get only good values.