Standalone Data Acquisition Systems

How long does it need to run for without interruption?

Days? Weeks? Months? Years?  The duration you need will impact your choice of hardware & operating system more than anything else. If the processor is stressed keeping up with tasks, then there is a larger chance that data flow will get backed up and errors will occur from a buffer overflow. Spinning hard drives have moving parts and will wear out. Even the internal system time battery will cease to function after a decade or so (maybe sooner).

When it crashes, do you need it to auto-restart, call the mothership, or is there no serious need to recover from a crash?

Will it have access to a power source, or does it need its own power source?

If the standalone DAQ has access to prime power, that’s obviously a much easier scenario than having to supply your own portable power, like from a battery, solar panels, or some combination of various sources.  Power and energy utilization calculations can get tricky for multi-mode operation or any scenario where the power draw varies significantly.  Be conservative, take power measurements under real-world operating conditions, and consider temperature and cycle de-ratings for battery-based applications.

Does the DAQ need to be able to transmit data remotely from the field or a plant, or is local storage sufficient?

If you’ve got access to a fiber link or copper Ethernet, great.  If not, this challenge can be often be met if:

1. There’s access to a cellular tower or Wi-Fi network (there are other public and private radio alternatives as well if needed).
2. EMI (Electromagnetic Interference) levels are below required thresholds for the link. If you really care if your link works, an RF site survey is warranted.
3. The DAQ bandwidth needs are less than what’s available from the link.

Something to think about if you do have this need is whether the DAQ system needs store-and-forward capabilities to buffer acquired data when the link goes down and continue sending once the link is back online.  And, how much storage would you need? You should consider a lower rate data stream, such as Modbus TCP, to uplink features computed from the raw data, so you at least have a view on status even if transmission bandwidth is low.

If local storage is sufficient, you’ll still want to think about what happens when the memory gets corrupted, loses sectors, or dies completely.  How much data are you going to lose, and do you need to mitigate with redundancy techniques like memory mirroring.  See our article on LabVIEW remote monitoring for more info.

Do you need to be able to access the data acquisition system remotely to configure it or check on its status?

Maybe you need to be able to modify one of the pre-trigger acquisition parameters, or maybe you find that you need to bump up the data acquisition rate, but your DAQ system is either in an inconvenient-to-access location in the plant, or maybe it’s half way around the world.

Or maybe you know some important event is happening in the next hour, and you want to view the status to make sure the DAQ is operational.

There are several ways to enable remote access to your DAQ.  Depending on your specific needs and the hardware you select, you may be able to utilize built-in software utilities, or you may need custom software developed.  See our article on LabVIEW remote monitoring for more info.

Do you need to simply acquire raw data, or do you need that data to be processed in some way post-acquisition?

Maybe you just need raw digital data to analyze on your PC after it’s acquired.  But you may run into bandwidth or storage space issues if you keep everything you acquire, or maybe that extra data will just increase your processing/analysis time more than you can tolerate.

You may want to do some filtering, windowing, or maybe even some time- or frequency-domain processing before you record the data you’ve acquired.  Depending on the amount of number crunching you need to do, a basic CPU may do the trick, or you may need a dedicated number crunching processor like a DSP, a multicore processor, or an FPGA.

What does your input channel list look like?

The biggest driving factors here will be related to:

1. Sample rates – if your data changes very slowly and you only need to acquire data at a few samples per second, that’s a very different animal than collecting at hundreds of kS/s or even MS/s.
2. # of signals/channels to acquire data from – are you just trying to measure a few TTL levels or 0-10V analog input voltages, or are you trying to measure temperature, vibration, force, pressure, etc. on dozens or hundreds of channels?
3. Min/max/range of signals – this is where signal conditioning really comes into play. If you need to measure µA or mV, you’d better understand how to appropriately amplify, filter, and isolate that signal before it becomes a digital value.
4. Synchronization – do some or all of your channels need to be digitizing measurements at the same time or can you tolerate some lag between samples across channels?

Do you like examples?  Here are some case studies of standalone data acquisition systems we’ve developed:

If you’d like to chat about your standalone data acquisition system needs, you can reach out to us here.