Using PowerDAQ Board for Data Acquisition Applications in RTLinux

Posted in Applications on July 24, 2006

Abstract
Data acquisition (DAQ) technology plays an important role in a variety of disciplines including health monitoring in medical treatment and research, factory infrastructure monitoring, off-vehicle testing of transmission controls, etc. At the lowest level of detail, these applications typically require sampling of the continuously moving input analog signal which for example may be cardiac condition of a patient or simply sound generated by a machine on a factory floor. The acquired samples are stored on to non-volatile storage device like disk or flash memory for further offline analysis. The frequency at which the samples are collected i.e, the sampling frequency determines the quality of the reproduced analog signals and the subsequent offline analysis. Performing deterministic, accurate and sharp sampling will require a hard real-time operating system in place. In this paper, we present the details for application development in RTLinux for a specific DAQ board. We also demonstrate how RTLinux [1] excels in accomplishing the required data acquisition performance and compare it with the performance of bare Linux through a series of experiments.

1 Introduction
A DAQ system typically consists of a data acquisition hardware board, a host processor, a storage device, an operating system driving the host processor and a driver software to interact with the DAQ hardware board. In this paper, we use the PowerDAQ PD2-MFS data acquisition board. The PowerDAQ board in turn consists of three major subsystems namely, Analog Input (AIN) subsystem, Analog Output (AOUT) subsystem and the Digital Input-Output (DIO) subsystem. Each component performs its own functionality and each can be operated by different independent applications without affecting the other. The following is a brief description for each of the subsystems:

Analog Input (AIN) subsystem: The AIN subsystem samples the input analog signal and writes the samples into its FIFO buffer. It can sample a maximum of 16 input analog signals/channels in a single scan. The channels of interest are selected using a multiplexer. In addition, the AIN also consists of an interrupt mechanism that notifies the application of special conditions.
Analog Output (AOUT) subsystem: The AOUT majorily consists of a FIFO to hold the samples that need to written to the analog output, a D/A converter that converts digitized input waveform values to analog output voltages and an interrupt mechanism similar to that of the AIN subsystem.
Digital Input-Output (DIO) subsystem: The DIO consists of registers to read input lines, and write values to output lines. It also has an interrupt mechanism to notify special conditions.

AIN is the most important subsystem for typical DAQ applications. We take a closer look at its interaction with the applications. As soon as the AIN subsystem writes the samples into its FIFO buffer, it is up to the sampling application to read out the values from the FIFO before the data is overwritten by the subsequent samples. The sampling application invokes the PowerDAQ driver to get the samples from the FIFO to the host’s memory so that samples can be used for further offline signal reconstruction and analysis. In order to be able to perform offline reconstruction of the input analog signal, the sampling application makes several such invocations periodically. The frequency of these invocations is the sampling frequency and it determines the quality of the reconstructed signal.

For a given input analog signal, there is a minimum sampling frequency defined by the sampling theorem. In its simplest sense the sampling theorem states that, in order to sample and reproduce an analog signal of highest frequency f, the sampling frequency should be at least 2f. For example, in order to reproduce a square waveform of frequency 1KHz, the sampling frequency should be at least 2KHz. In other words, a sample should be collected for at least in every 500 microseconds. We call this as inter-sample period in the rest of the paper.

Given the sampling theorem, in order to achieve good sampling quality the operating system should support short and deterministic timing facilities of the order of few microseconds depending on the input signal. Our experiments show that RTLinux can support an inter-sample period as small as 35 microseconds while the bare Linux fails to get any closer to that. Before getting into the details of the experiments, we present the application development details in RTLinux using the PowerDAQ board.

The rest of the paper is organized as follows: in section 2, we present applications using the AIN and AOUT subsystems. In section 3, we present the details of our experimental setup and the results comparing the quality of digitization in RTLinx versus Linux. We present our conclusions in section 4.

2 Applications
Applications over the PowerDAQ in RTLinux use one or more of the PowerDAQ subsystems described in section 1. The general structure of an application program using a subsystem S_A is as follows:

Step 1: Acquire the subsystem S_A;
Step 2: Reset S_A;
Step 3: Configure S_A;
Step 4: Use S_A;
Step 5: Release S_A;

Where S_A could be one of the three PowerDAQ subsystems. We present the details of the exact interfaces through two specific applications using AIN and AOUT subsystems. A typical RTLinux application may insert the code for the above five steps in the real-time thread’s code area.

The following subsection presents the SingleAI application details which uses the AIN subsystem to perform a single scan of the PowerDAQ FIFO periodically. We present an application (SingleAIAO) using both the AIN and AOUT subsystems in section 2.2.

2.1 Using the AIN subsystem
The goal of the SingleAI application is to trigger sampling on the AIN subsystem and acquire the samples stored in the FIFO periodically and store them on to the memory possibly for offline signal reconstruction.

The following are the necessary PowerDAQ board specific calls involved in the SingleAI application in that order.

PdAcquireSubsystem(boardID, AnalogIn, 1): This function basically reserves the AIN subsystem for the calling process and the AIN can be used by the other processes only after it is released by the calling process. The return value of this function is a handle to the AIN subsystem to be used for the subsequent references to the subsystem. Essentially, the SingleAI application now performed the step 1 of the above five step generic structure.
_PdAInReset(handle): After acquiring the input subsystem, we need to reset the subsystem so that all old values in the FIFO are flushed out. This function achieves this by taking the handle returned by the PdAcquireSubsystem system call. It returns zero on success and a negative error code on failure. The SingleAI application is now done with the step 2 of the above five step generic model.
_PdAInSetCfg(handle, configBits, 0, 0): This function sets the operating configuration of the AIN subsystem. The first argument is the handle to the subsystem, the second argument is a DWORD which consists of the configuration settings. The third and fourth arguments are pre-trigger scan count and posttrigger scan count which need to be set to zero always. The AIN subsystem can be operated in different modes the details of which can be found in the hardware board manual available at [2].In RTLinux, we typically use the software clock mode for which the configuration double word is set as the logical OR (|) of the following macros: AIB_CVSTART0, AIB_CVSTART1, AIN_RANGE_10V, AIN_SINGLE_ENDED, AIN_BIPOLAR and TRIGGER. Where TRIGGER variable is typically set to zero. It is important to note here that even if we need to modify one attribute of the setting, we still need to specify all of them. For example, if we want to change the input range from 10V to 5V, we need to set the configuration as logical OR of the following: AIB_CVSTART0, AIB_CVSTART1, AIN_RANGE_5V, AIN_SINGLE_ENDED, AIN_BIPOLAR and TRIGGER.
PdAInSetChList(handle, nbOfChannels, (DWORD*)channelList): The AIN subsystem of the PowerDAQ board can sample 16 input channels for each scan. Before using the AIN subsystem we need to specify and configure the channels of interest. This function specifies the channels to be sampled and their settings. Each channel is specified by its ID and its gain factor. The third argument to this function contains these specifications. In this paper, we restrict ourselves to the single channel data acquisition for simplicity. The channel specifications on PowerDAQ PD2-MFS board can be made as follows:gain = 0;
for(i=0; i
channelList[i] = i | (gain << 6);
_PdAInEnableConv(handle, 1): After the number of channels and their specifications have been set, we need to enable the AIN’s analog-to-digital conversions by calling this function. We can also disable the conversions by passing zero as the second argument.Now the SingleAI application is done with the step 3 of the above generic five step model.
_PdAInSwStartTrig(handle): This function triggers the AIN subsystem to start the sample acquisition. Once this function returns successfully, samples will be available in the FIFO which can be retrieved by the sampling application by making the following function call.
_PdAInGetSamples(handle, nbOfChannels, buffer, & numScans): This call retrives the samples from the FIFO and stores them in the memory location specified by the third argument. The function writes the number of valid samples read into the fourth argument. One can access digitized values in the buffer offline. This function needs to be called as long as we want to sample the input analog signal.
_PdAcquireSubsystem(boardID, AnalogIn, 0): Once we are done with the sampling, we need to release the AIN subsystem, so that it can used by other applications. This can be acomplished by this function call with the third argument as a zero. Now the SingleAI application is done with the step 5 of the above five step generic model.

2.2 Using the AOUT subsystem
The AOUT subsystem of the PowerDAQ board can be used for writing digital values of a signal to generate an analog signal on the output lines. In this section we present an application called SingleAIAO which uses both the AIN and AOUT subsystems. The goal of the SingleAIAO application is to digitize an analog input signal using AIN subsystem and reproduce the analog signal onto the analog output lines using the AOUT subsystem. Since we discussed the details of handling the AIN subsystem, in this section, we assume the digitized values are available in an array variable called buffer.

The following are the necessary PowerDAQ board specific calls involved in the part of the SingleAIAO application which writes the values available in the buffer to the analog output lines.

PdAcquireSubsystem(boardID, AnalogOut, 1): Similar to the SingleAI application, the AOUT subsystem needs to be acquired before working with it. This function call is used to achieve it.
_PdAOutReset(handle): Again similar to the earlier case, we reset the subsystem to flush out the buffers.
_PdAOutSetCfg(handle,configBits, 0, 0): The AOUT system can be configured using this call. The different possible configuration settings can be found in the hardware board manual available at [2].
_PdAOutSwStartTrig(handle): This function triggers the AOUT subsystem to start the value output. Once this function returns successfully, samples can be written onto the AOUT system using the following function.
_PdAOutPutValue(handle, buffer[i]): The digital value in the buffer[i] is written on to the analog output. In order to produce a continuous analog output the SingleAIAO application calls this function periodically and writes the values available in the buffer location to the AOUT and thereby generate an analog output signal.
_PdAcquireSubsystem(boardID, AnalogOut, 0): When the application is done with the AOUT subsystem, it needs to be released using this function call with the third argument set to zero.

3 Experimental setup
Figure 1 shows the schematic of our experimental setup. It consists of the following components: signal generator, PowerDAQ data acquisition hardware board, AMD Opteron host processor and an oscilloscope to check the input signal. We present a brief description of the components in the following:

Signal Generator: The functionality of this component is to generate signals of required frequency. Although many hardware based signal generators are available in the market, we decided to generate signals through software running in RTLinux over the Intel P4 processor. Our signal generator is basically a simple RTLinux application program which writes a one and zero to the parallel port’s data register at a predetermined frequency. We have also implemented a similar application in the linux environment. However, it was difficult to obtain a square wave with frequency higher than 1KHz. On the other hand, we could generate a square wave of frequency 100KHz in RTLinux. We routed the data from the parallel port both to an oscilloscope and the PowerDAQ board. In each experiment, we verified in the oscilloscope that the signal generator generates the square waveform of the required frequency.
PowerDAQ board: This is basically the data acquisition board, PD2-MFS, manufactured by the United Electronic Industries company. This board is driven by a software driver which can be invoked by the RTLinux applications as described in the previous section.
Host Processor: In our experiments we used the AMD Opteron Dual Core processor which runs either RTLinux or bare Linux based on the type of experiment. It communicates with the PowerDAQ board via PCI bus and it also runs PowerDAQ software driver.
Sampling Application: This is an application program which periodically calls the appropriate interface of the PowerDAQ driver and acquires the samples from the board.
Java GUI interface: This is a simple java applet based application which takes in the samples generated the RTLinux application program and plots them.

Using the above experimental setup, we conducted several experiments to demonstrate the sampling quality offered by RTLinux as compared to that of Linux. We present our results in the following section.

4 Quality of Digitization: RTLinux vs Linux
In order to compare the sampling quality offered by the two operating systems, we conducted four experiments. In each experiment, a square waveform of different frequency was generated by the signal generator and routed to the PowerDAQ board. Figures 2, 3, 4 and 5 show the reconstructed signals for different input frequencies.

In figure 2, the input square waveform is of 50Hz frequency, according to the sampling theorem the required inter-sample period is 20 milliseconds. RTLinux generates a very accurate reconstruction of the input signal. On the other hand, Linux cannot produce such an accurate reconstruction, although the signal can be reconstruced with a tolerable distortion. Similar observations can be made when the input frequency is increased to 100Hz as shown in figure 3.

However, when the input frequency is further increased to 1KHz Linux completely fails to perform any reasonable sampling and the reconstructed signal completely misses out the input signal as shown in figure 4. According to the sampling theorem, the required inter-sample period is 1 millisecond and Linux cannot provide such sharp timing. On the other hand, RTLinux can provide short, deterministic timing guarantees and hence it could still reproduce the input waveform accurately. Similar observations can be made with 2KHz input square waveform signal as shown in figure 5.

5 Conclusions
In this paper, we gave a tutorial of how to develop RTLinux applications using the data acquisition PowerDAQ hardware board. We also demonstrated the quality of digitization offered by the RTLinux and compared with that of the Linux. Our experiments show that the RTLinux with its hard real-time characteristics excels in achieving the excellent digitization of the input signal while the bare Linux fails to reconstruct the signal for frequencies higher than 1KHz.

6 Figures

Figure 1. Experimental setup

Figure 2. Digitization of the input analog square waveform of frequency 50Hz

Figure 3. Digitization of the input analog square waveform of frequency 100Hz

Figure 4. Digitization of the input analog square waveform of frequency 1KHz

Figure 5. Digitization of the input analog square waveform of frequency 2KHz

Comments are closed.