What Do You Have in Your Walls?

Alex describes how to find out, using only the sound card in your Linux computer and some wire loops.
Computer Platforms

The CanDetect Project has modest system requirements, and it doesn't require a dedicated Linux computer. You can even borrow a Windows machine as booting into Linux from CD-ROM or floppy disk is an established technique. We used the inexpensive, CD-booting New Internet Computer (NIC, www.thinknic.com) in our Embedded Linux Journal competition entry.

In order to simultaneously output and input a waveform, the sound card (or sound chip integrated on to the motherboard) must be capable of full duplex operation. Many older sound cards and more recent notebook computers are often unable to achieve full duplex status without reducing the sample resolution and/or sample rate. The card needs to operate in 16-bit mode. This is equivalent to each voltage reading being nominally capable of resolving 16ppm of full scale. For this project, it is worth avoiding old designs and ones that don't sound good. Also, there should be no audible hiss from the microphone at full volume.

When choosing between many computers, you can add the measuring program into the Linux Terminal Server Project (LTSP, www.ltsp.org), as a service under inetd. After preparing EtherBoot (www.etherboot.org) floppies for relevant network card types, you could evaluate hundreds of computers in an evening. Simply network boot each computer using a floppy, use its X terminal to log in to your remote workstation and run a script. That script parses the DISPLAY variable to find the IP address, connects to the inetd service on the computer, runs the tests and then logs and displays a summary.

Software Approach

We developed AudNet to operate the sound card. Then we patched a version of xoscope to plot the streaming results, as shown in Figure 8.

Figure 8. Block diagram showing the interconnection of program elements.

AudNet operates the sound card so there is always something to play, and AudNet retrieves the recorded signals. Keeping the play and record channels synchronized is important. Normally two input and two output electrical channels are present on most sound cards, and one waveform is used for each channel. All waveform values have full scale, -1...+1.

Many different kinds of measurement requests can be submitted at any time and are performed as soon as possible. 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 states how many times its waveforms should be repeated.

Since playback data has to be placed in 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 kernel buffers. Often, the request being sent out is a different one from the one whose data is being collected in a response.

Because 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 performed only when the library switches from one request to a different request definition; they are not needed when a request repeats.

For single frequency measurements, the sample program, main, expects two command-line parameters: a frequency in Hz and the phase adjustment of the output in degrees. main requests that AudNet generate two clean sinewaves with a frequency as close as possible to the parameter, but of opposite sign on the speaker channels. It then sets the repeat number to give new measurement responses about ten times per second.

xoscope—Graph Plotting

We use a modified version of xoscope to display our results. An oscilloscope will discard input signals whenever it is too busy to draw to the screen, and the original xoscope does the same thing. This is a problem in CanDetect regarding long duration viewing of a slowly changing signal, so we modified xoscope to fix this issue.

The driver for the Linux sound card was initially replaced with an AudNet-based one. On the NIC, any filesystem access can block while the CD-ROM spins up, and any display write could wait while the processor works on the unaccelerated video chipset. As a result, xoscope often would not call our driver for many seconds. The occasional five-second delay exceeded the kernel buffer size and caused loss of synchronization.

Figure 9. Snapshot of the xoscope window during data acquisition.

The second hardware driver for xoscope reads an environment variable, XOSCOPEAUDNET, for a command line that is expected to provide suitable data with a 10Hz sample rate. This environment variable is initialized before starting xoscope to ensure that the main program is invoked with the desired settings. Since main runs as a completely separate program and does not access the display or any files, it doesn't get blocked from execution.

The driver scales the floating-point values so that one count of the display is 10ppm of the sound card's full-scale input. Consequently, signals in excess of 32% of full scale are clipped due to the limited dynamic range of xoscope's internal storage buffers.

The changes to xoscope's CVS also are tracked in our src module, as xoscope.patch should be applied before configuration. The patch adds that new driver and modifies some defaults. The new configuration script option, --without-vga, forces nondetection of svgalib, which is useful when building on a computer with svgalib and the binary will be used on a computer without it.


Geek Guide
The DevOps Toolbox

Tools and Technologies for Scale and Reliability
by Linux Journal Editor Bill Childers

Get your free copy today

Sponsored by IBM

Upcoming Webinar
8 Signs You're Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
11am CDT, April 29th
Moderated by Linux Journal Contributor Mike Diehl

Sign up now

Sponsored by Skybot