Foreword: — This whitepaper describes the development of a real-time data-acquisition application using a real-time Linux implementation along with an off-the-shelf data-acquisition board. It also compares the relative sampling frequencies supported respectively by RTLinux and a standard Linux kernel. Enjoy . . . !

---

Developing a real-time Linux data acquisition application

by G. Sudha Anil Kumar

A data-acquisition (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. This paper works with the PowerDAQ PD2-MF data acquisition board in RTLinux using the driver provided by the manufacturer. The installation instructions are pretty straightforward and are provided with the accompanying CD. This paper assumes that the installation process has been completed successfully. The rest of the paper concentrates on developing RTLinux applications for the PowerDAQ board.

Before getting into the coding details, let us have a quick look at the PowerDAQ's architecture. The PowerDAQ board 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 majorly 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. Let us 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 should make 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 at least in every 500 microseconds. This is termed as the 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. The experiments performed at FSMLabs 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.

The rest of the paper is organized as follows: section 2 presents two applications using the AIN and AOUT subsystems. Section 3 presents the details of the experimental setup and the results comparing the quality of digitization achieved by the RTLinux with that of the Linux. Section 4 presents the conclusions.

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. The details of the exact interfaces through two specific applications using AIN and AOUT subsystems. The DIO subsystem has very similar interfaces and hence for brevity, we avoid presenting applications using the DIO system. 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. Section 2.2 presents an application (SingleAIAO) using both the AIN and AOUT subsystems.

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. This paper however restricts itself 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 retrieves 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 accomplished 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) — Th 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 the 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. The following is a brief description of the individual components:

Figure 1: Experimental setup

• 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 Power- DAQ 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. In addition to the RTLinux driver, the manufacturer also provided a Linux driver to access the board from Linux. We used this driver for the experiments with bare Linux as the operating system. The host processor communicates with the Power- DAQ board via PCI bus and it also runs appropriate 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. More specifically, we used a slightly modified version of the SingleAI application discussed in section 2.1.
• Java GUI interface — This is a simple java applet based application which takes in the samples generated the RTLinux application program and plots them on an applet.

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

4. Quality of Digitization: RTLinux vs Linux

In order to compare the sampling quality offered by the two operating systems, four experiments were conducted. 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 reconstructed with a tolerable distortion. Similar observations can be made when the input frequency is increased to 100Hz as shown in figure 3.

Figure 2: Digitization of the input analog square waveform of frequency 50Hz
(Click to enlarge)

Figure 3: Digitization of the input analog square waveform of frequency 100Hz
(Click to enlarge)
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.

Figure 4: Digitization of the input analog square waveform of frequency 1KHz
(Click to enlarge)
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.

Figure 5: Digitization of the input analog square waveform of frequency 2KHz 6
(Click to enlarge)
5. Conclusions

This paper presented a tutorial on application development in RTLinux using the data acquisition PowerDAQ PD2-MFS hardware board. Further, an experimental demonstration was presented comparing the quality of digitization offered by the RTLinux and that of the Linux operating systems. The experimental results 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.

---

About the author — G. Sudha Anil Kumar is an PhD student from Iowa State University currently working as an intern at FSMLabs in Socorro New Mexico. His research primarily focuses on system level energy management of wireless embedded systems. He earned his BTech (Hons.) & MTech degrees in computer science from the Indian Institute of Technology, Kharagpur.

---

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.