The DAQ hat is streaming data fast, and the number of records in the data file gets big in seconds. If you run file logging in continuous mode, you'll exceed maximum number of records for popular spreadsheet applications fast. Either use in one-shot mode or import the data into a database.

The initial flow for this Road Test was displaying the wave form real time. It's a good way to show that all concepts work and that the design is reactive. In the real world, that's not why you use a DAQ. It's intended to collect lots of data an analyse it. To prove that the design is up to that, I'm building a first adaption of the initial flow: replace the real time display by a data file.

Logging to File

The easiest way to prepare the data for analysis is to log it to a structured file. That way, you can use your preferred solution to do the data crunching. Because the example design uses a LabVIEW queue to stage the retrieved data stream, it's easy to use that data in different ways. It only needs that you change the flow that dequeues data from that queue.

Here's what the inner loop of the "save to file" queue looks like:

It replaces the LabVIEW real time waveform view with a file streamer. Below is how the original waveform viewer flow looked like:

It isn't a big change, is it? The same will be true for any other strategy (like FFT bucketing, RMS calc, running average, ...) you have in mind for the data. The level of abstraction in this design allows you to plug in a fair number of algorithms and data handlers. If it doesn't fit the purpose, you can always dive a level deeper - the abstractions are a suggestion, not a restriction. With a little bit of work, you can enqueue the data to several queues and have multiple threads doing different analysis in real time.

Because a file needs opening and closing, and a wave form viewer doesn't need it, there's some work to do at the start and end of the sampling. To open/create the file and properly close it.

You can just insert these actions in the flow at the appropriate place. I've opened the file before kicking of the sample and close it when the last value of the queue is written. 

Other Customisations

It turns out that LabVIEW and network can deal with the data retrieval speeds of the DAQ hat. That means that you can keep the software on the Raspberry Pi easy, focused on the data acquisition. In LabVIEW (or other client software) you can then:

• log to  a file as we did in this post
• perform FFT analysis
• calculate RMS, average, peak detection, other statistics
• collect an enormous amount of data, e.g. by streaming the results to a database 
• manage alerts based on the data
• include it in the predictive maintenance algorithms (martinvalencia may come and help me here)
• use the DAQ in a flow with other instruments like a signal generator (more on that later, power supply, oscilloscope, load, ...

When you only look at a single aspect, building the instrument services and LabVIEW driver may look like overkill. But it opens a door to possibilities that can't be managed on a Pi. And it turns the instrument into something that LAB engineers are familiar with.

Link to all posts.