Sensor connection with NI DAQ

[Chowdhury_Milon]

Hi, I have attached 2 pictures here. I usually connected sensors as shown in picture 1. How can I connect picture 2 type sensors? TIA. 

[Bob_Schor]

This is "yet another time" where some text describing the DAQ Device (I think it is a USB-6009, but the image quality is not sufficient to be sure, and I certainly can't tell the names of the input channels you are using) and the sensor (in this case, I could look up "AM2315", and see its description as "Encased I2C Temperature/Humidity Sensor").

With these two facts alone, I can say "You cannot hook this up in any way that will give you meaningful data".

Do you know about I2C devices?  Have you learned about "Serial Protocols" (such as RS-232, TCP/IP, I2C, SPI, etc.)?  Most (all?) serial protocols are digital in nature, encoding information in (increasingly-rapid) digital (voltage) transitions.  A Multi-function DAQ device (such as the USB-6009 and its cousins) are not designed for, and incapable of, handling these Protocols.

All is not lost -- if you search the Web for Analog Temperature Humidity Sensors, you can find some that should work and are inexpensive (< $10).  

Bob Schor

[cbutcher]

Assuming the awesome image reading is correct (and you are using a USB-6009 or similar), then I'd say although not fundamentally impossible to do this, it is so close to that as to be entirely unreasonable.

The digital I/O you have available appears to be static, that is, you set it to be True or False one step at a time. For these serial digitial systems (e.g. I2C), you're looking at changing the value of your data and clock lines many times to transfer just a single piece of "useful" information.

Although it's possible, the programming work required would be quite considerable and the maximum data rate would probably be very low. Depending on your sensors' maximum data rate, this may be acceptable (I wrote SPI code for X-Series USB DAQmx devices, which are admittedly a much more powerful I/O device than the 6009 from the specs), but it took quite a bit of work.

If your sensor requires a very regular clock, or has narrow tolerances on timing variation, it may be completely impossible with that hardware.

Decide if this is really what you want to do, and if not, go ahead and search for an analog sensor. You'll probably prefer that.

If you're really stuck with digital communication, and you can't get something capable of waveform digital I/O, plan to spend a lot of time programming this.