When looking at the data acquisition component of a complex system, we often focus so much on the technical specifications of the analog-to-digital conversion (for example, sampling rate or number of channels) that we spend little to no time at all thinking about how it will interface with the other software components of the system. When left aside in the process of selecting the right system, the limited flexibility of the provided API can come back to haunt you, especially when the time comes to put together all the bits and pieces and make the system work as a whole.
Information Exchanged in DAQ Systems
In modern multichannel data acquisition (DAQ) systems, information needs to be exchanged between the components used for fast sampling, and a host or embedded computer used for data post processing and system control. Two types of information typically need be exchanged:
- Commands: These are typically required to control the acquisition system as well as the front end. Typical functionality can range from connecting to the system through gigabit Ethernet (GigE) or PCI Express (PCIe), to configuring the sampling rate or launching an acquisition and storing the data to the system’s memory. On Nutaq’s µDigitizer systems, commands can be sent from the PC to the µDigitizer system’s Central Communication Engine (CCE). The CCE is an implementation of a remote procedure call (RPC) library. It exposes the functions of the Nutaq software libraries to the network.
- Data: For low channel-count systems, it’s possible to stream data in real time from the acquisition system back to a PC for processing. On high channel-count systems and in most real world applications, data is processed in real time with FPGAs but also buffered by the system during acquisition, and sent back to the PC later for post processing or analysis. On Nutaq’s µDigitizer systems, data can be sent from the system to the PC or vice-versa using the Real-Time Data Exchange (RTDEx) IP Core. The main purpose of the RTDEx IP core is to provide customers a framework to exchange data with the highest bandwidth and lowest latency possible.
To fully benefit from Nutaq’s software, you can use our command line interface (CLI) or C/C++ extended API (EAPI) to interface Nutaq’s µDigitizer to your own custom application, since you’ll probably want to do more than simply acquire the data (for example, the µDigitizer is only a part of complete radar system). You can choose between interfacing to the CLI or to the C/C++ EAPI based on the architecture of your software application (whether existing or in development).
In many cases, you might choose to interface to Nutaq’s EAPI. For instance, this would be the case if you have an unmanaged C++ 32-bit Windows-based application. In other situations, the software design constraints may not allow direct access to the methods that are publicly exposed by Nutaq’s EAPI compiled object code.
Communicating with Digitizer via the CLI: Another Approach
Although interfacing an existing application to the C/C++ EAPI can be trivial, interfacing to the CLI is rather less intuitive. In this post we’ll discuss an alternative approach to creating the interface to the µDigitizer via the CLI. We’ll use Portable Operating System Interface (POSIX) stream descriptors to enable communication between two separate processes: an instance of the Nutaq CLI and a simple managed C++ .NET application run by the Common Language Runtime (CLR). POSIX is a family of standards specified by the IEEE that is supported by Windows and Linux operating systems, among others. Since Nutaq’s CLI supports commands piped from the POSIX standard application programming interface, you can use any POSIX-compliant scripting or programming language such as PHP, TCL, Ruby, or Perl to communicate with a µDigitizer via the CLI.
In this example, we’ve implemented a class for starting and stopping the Nutaq CLI process, handling the connection to the µDigitizer system, and passing command strings from the C++ code to the Nutaq CLI. The interface is defined as follows:
In our managed C++ .NET application, we use Windows Forms in Microsoft Visual Studio to create a user-friendly graphical environment to configure the µDigitizer system and trigger the data acquisition from an external host PC. In this basic example, the functionality is strictly related to the µDigitizer. However, you could also integrate functionality related to other components of a bigger system such as front-end control, data analysis and visualization software tools, and data storage management.
Windows Forms offers excellent graphical design capabilities that allow you to build a graphical user interface (GUI) in just a few minutes. The overall look of the GUI is shown in the following figure:
We can fully demonstrate the functionality of both the µDigitizer and the MI125 from a remote host simply by using functions made available by the Nutaq CLI. Let’s look at how it works.
A Walkthrough of the Example
All individual parameters can be configured from drop down menus where supported values for each parameter are listed. Since we used two Nutaq MI125 cards with 16 ADC channels, the user must select either 16 or 32 channels. For 16 channels, only card number 1 is used.
For the number of samples, we made four arbitrary values available, as shown in the figure below. At the sampling rate of the MI125 card, these options correspond to times of 0.0328 ms, 0.5243 ms, 8.3886 ms, and 134.2177 ms respectively.
Both internal and external options of the trigger source and the clock source of the MI125 card are supported.
In order to configure the system and trigger the acquisition, the IP address previously assigned to the system must be provided. In this example, we used gigabit Ethernet to communicate between the PC and the µDigitizer system.
We provide a file name so the collected data can be brought back to the host for visualisation.
Once we’ve set all the parameters, we click the Start button. An event handler method that uses the parameter values we supplied in the GUI sends a series of commands via a POSIX pipe to Nutaq’s CLI to automatically:
- Configure the µDigitizer’s MI125 cards with the specified parameters
- Trigger the acquisition (data is stored is buffered in the systems DDR3 RAM)
- Transfer the data back to the PC via gigabit Ethernet
- Create a file on disk containing the raw data acquired by the system for all channels
The output console prints the commands as they are sent to the Nutaq CLI, as shown below:
Immediately after the acquisition is completed, our program creates the raw data file on disk.
We then use MATLAB® from MathWorks® to visualize the acquired signal for each of the 16 or 32 channels.
Looking at the frequency spectrum from one of the channels in this example, we see that it was used to sample a 30.74 MHz square wave.
The flexibility offered by the provided API is a key feature to consider when selecting a multichannel data acquisition component of a bigger system. Nutaq’s EAPI and CLI combined offer several possibilities for integrating µDigitizer to other software components of a complex system.
Nutaq’s EAPI is a good choice to use with an unmanaged C++ 32-bit Windows-based application. In this example, however, we demonstrated how to use POSIX stream descriptors as an alternative interface between an application and Nutaq’s CLI. This is a good solution for cases when software design constraints don’t allow direct access to the publicly exposed methods in Nutaq’s EAPI compiled object code. We also demonstrated a Windows Forms graphical user interface that we built using the .NET framework, and showed how to invoke µDigitizer and MI125 functionality from a remote host PC simply by using functions made available in Nutaq’s CLI.
Windows, Windows Forms, Visual Studio, and Microsoft .NET are trademarks of Microsoft Corporation in the United States and other countries.