We currently use AudNet, which was developed for this project, to operate the soundcard and a patched version of xoscope to plot the streaming results. The purpose of these applications is to implement the requirements that are identified in the tools discussion.
The library operates the sound card, ensuring that there is always something to be played and retrieving the signals that were recorded. Clients submit requests for measurements, which are performed as soon as possible, then collect the responses from a queue. Many different kinds of measurement request can be submitted at any time, the library simply works through the to-do queue until it gets to the end (if it ever does). When the request queue becomes empty, the most recent request is simply repeated until a new one shows up.
Each request consists of one waveform for every electrical output channel available, normally two for most sound cards, together with the number of times that the waveform should be repeated. All the incoming signal during those repeats is collected into a single response for the client. Since many electromagnetic systems are slightly resonant, the request also specifies how many times the waveform must be performed until the probe and sample have reached a predictable state for reliable measurement. These skipped cycles are only performed when the library switches from one request to a different request definition; they are not needed when a request repeats.
Each response consists of one waveform for every electrical input channel available, normally two for most sound cards. All input and output values are scaled so that full scale is from "-1" to "+1" in the waveforms.
Since playback data has to be placed into the sound queue a second or more before it is played, and recorded data appears in the sound queue a short time after it is recorded, the library keeps track of how much data is in those sound queues. Often, the request being sent out is a different one from the one whose data is being collected into a response.
This program expects the first command line parameter to be a frequency in Hz and the second command line parameter to be the phase adjustment of the output in degrees. It requests the library generate a clean sinewave on one speaker channel and a clean cosinewave on the other channel with a frequency that is as close as possible to the requested one. The library delivers measurement responses about ten times per second.
Whenever a new result is generated, the program writes a line to the standard output and flushes the file to ensure that the recipient receives the result. The line has three numbers, corresponding to the actual frequency, the measured signal at the desired phase and the signal in quadrature to that phase. The line also contains two sections, enclosed in braces, which provide a simple text representation of each value at multiple sensitivity scales. This is generally ignored, but extremely useful for diagnosing problems without the necessity of starting the full X environment to view data.
This is much simpler than modern approaches, but many eddy current systems in industry do exactly this.
The original xoscope application is intended for use as an oscilloscope, whereby a hardware driver monitors a signal source for a specified trigger condition and hands a waveform fragment back to the main application. The user interface allows the trigger and plotting parameters to be specified, rather like an oscilloscope, and periodically asks the driver to try to find a new trigger event.
The trouble with this approach, for CanDetect's purposes, is that a real oscilloscope will discard input signal whenever it is too busy to draw to the screen and the software version does the same thing. This is fine when the goal is to monitor a high speed transient waveform, but problematic for viewing a slowly changing signal over many seconds. Initially, the linux-soundcard driver was replaced with an audnet-based one. However, when running on the NIC, the user interface often would not call the hardware driver for many seconds while some disk access or screen refresh was in progress. The maximum value of this interruption determines the necessary length of the soundcard buffer, yet a five second delay is not acceptable for a simple interactive device.
A new version of the hardware driver for xoscope was created, which reads an environment variable XOSCOPEAUDNET for a command line which is expected to provide suitable data with 10 Hz sample rate. This environment variable is initialized, before starting xoscope, to ensure that the main program above is invoked with desired settings. The floating point values are scaled so that one count of the oscilloscope waveform is 10ppm of the soundcard fullscale input, but in consequence signals in excess of 32% of fullscale are clipped due to the limited dynamic range of the application's internal storage buffers. The new driver is tracked in the src module of CanDetect's CVS as xoscope_sc_audnet.c
The necessary modifications to xoscope's CVS checkout version are also tracked in the src module of CanDetect's CVS as xoscope.patch and should be applied before configuring the package. In addition to placing that new driver into the build sequence, it modifies some of the runtime defaults (and legal value ranges) to match the CanDetect data source expectations. It also modifies the configuration script to create a new option --without-vga that forces non-detection of the svgalib support and eliminates the associated code (and library searches) from the package. This is useful when building the binary application on a computer which has svgalib support installed and the binary will be used on a computer without the library installed (such as the NIC).
The easiest way to build everything in the CanDetect project, including the custom version of xoscope, the main program and the candetect.raw CD for NICs is to use the inter-module makefile. Perform a single checkout of the whole CVS archive, run make and wait for it to complete. The CVS passwords are blank, as usual, and you will need to enter your system's root password to conduct specific operations (read each command line carefully). Note that this will create a directory called xoscope next to the one containing all the CanDetect modules (to avoid getting CVS confused).
$ mkdir candetect.sf.net $ cd candetect.sf.net $ cvs -d :pserver:firstname.lastname@example.org:/cvsroot/candetect login $ cvs -d :pserver:email@example.com:/cvsroot/candetect co . $ make