A stud sensor can be purchased for as little as $10.00 (US), so why would anyone try to use their Linux computer to look inside walls for power cables, nails, rebar, studs or anything else?

The CanDetect Project came into existence as a side effect of working on a more difficult problem, one where $10.00 of equipment wasn't going to get the job done. Short for Corroding Aircraft Non Destructive Evaluation using software Tools and an Eddy Current Tester, CanDetect aims to provide AMTs (aviation maintenance technicians) with an inexpensive means of performing corrosion inspections on aircrafts. CanDetect seeks to eliminate the expense of specialized computers, external amplifiers, modulators and power supplies, yet still allows an AMT to find tiny defects in metals buried under paint and even under other metals.

Our approach consists of software that can run on any Linux-supported platform and an inspection probe designed to be plugged directly in to the connectors for /dev/dsp—the character device corresponding to the sound card. An application-specific bootable CD-ROM image was developed for the Embedded Linux Journal's NIC contest. If you have a NIC and/or plan to inspect an aircraft, the SourceForge site (candetect.sourceforge.net) has more details. For how to find what is in your walls, read on.

Important Warning: The simple home improvement device described in this article is not approved for use in aviation. Do not use this device in aviation.

In earthquake-prone areas, such as California, construction using bricks would be unsafe. Instead, a strong yet lightweight frame consisting of wood or aluminum vertical beams (with approximately 40cm spacing) is covered by a thin, flat layer of particle board, plaster or similar material with enough strength to support only itself. During an earthquake, such a wall would push adjacent furniture over, unless the top of each item has been securely fastened to the wall. When attaching furniture or cabinets to framed walls, it is important to align the screws with the stronger internal structure that can bear a load. Walls also contain pipes and electrical wiring, and it's best to avoid them (obviously) when driving long screws through the wall.

Figure 1. Inductive coil pair, optimized for 10KHz and 2cm depth.

Figure 2. Construction details for the probe shown in Figure 1.

The probe shown in Figure 1 was built by my colleague, Brian Whitecotton. His work is much more photogenic than mine. The probe consists of two coils, whose centers are 2.4" apart, glued to a piece of wood, as shown in Figure 2. Each coil has a diameter of 2.2" and 80 turns of insulated wire. The coils are soldered in series, such that the current rotates in opposite directions, between the left and right signal-out wires. The midpoint between the coils is connected to the mono microphone input. The grounds of the output and input are connected together, as shown in Figure 3. That design has resistance of 6.2 and inductance of 0.8mH.

Figure 3. Schematic of the electrical connections for the probe shown in Figure 1.

When building the probe it is important to verify that the electrical connections are the same and that the two coils are as identical as you can manage. Don't use any other metal in the construction, no matter how tempting, because this probe is designed to detect any metal in nearby walls. By the way, this probe is useless for NDE (nondestructive evaluation) on aircraft.

Non-physicist Linux users are sometimes intimidated by the physics of these concepts, but don't let that stop you from trying out this project. If nothing else in this section makes sense, know that point sources, such as nails, tend to give rounded signals and line sources, such as power cables, tend to give much more pointy signals.

Figure 4. Prostar notebook 1KHz, linear scan of an invisible dry wall nail.

As it scans across a wall to find invisible nails, the software reports a positive signal when the nail is inside the circle of one coil or a negative signal when the nail is inside the circle of the other coil. This is shown in Figure 4. When trying to examine a large wall area, the coils can travel next to each other so that the sign of the signal indicates which coil encountered a nail. When trying to determine the exact position of a nail, the coils travel along the same path so that the central symmetry with no signal will indicate the location to within a few millimeters.

Figure 5. Prostar notebook 1KHz, linear scan of an invisible 110V> power cable.

Power cables, as shown in Figure 5, or metal structural components obviously will have much larger signals. The shape of the signal distinguishes a point (such as a nail head) from a line (such as a wire). A point has almost the same signal when it's anywhere within the circle of the coil, so the plot has a flattened peak. A line has a signal that varies with the length of the line that is inside the circle, reaching a maximum when it is the diameter. Therefore, the plot has a more pointed peak.

Although a cheap stud sensor can find objects, you must buy a more sophisticated unit if you want more than that basic location. In addition, a cheap sensor cannot distinguish between a water pipe, a structural beam and a power cable.

Figure 6. The phase of the signal suggests what type of metal each object is. Iron and steel are highest, copper and aluminum are lowest, brass and the like are in the middle. Around 1KHz, the phases are clearly separated into three groups.

Figure 7. The signal size suggests how large each object is. Aluminum gives a relatively small signal compared to steel.

More expensive and capable sensors compress their detection results into simple displays. Our software-based sensor can benefit from the better display and adjust the measurement to identify classes of objects. Once an object has been found somewhere inside the wall, the phase of the signal, as shown in Figure 6, indicates what the material is. The size of the signal suggests how big the object is, as shown in Figure 7. The way these two vary with frequency can be used to recognize the shape of the object.

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.

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.

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.

You can quickly try the current project software by building a bootable floppy, as shown here:

$ mkdir candetect.sf.net
$ cd candetect.sf.net
$ cvs -d :pserver:anonymous@cvs.candetect.sf.net:
/cvsroot/candetect login
$ cvs -d :pserver:anonymous@cvs.candetect.sf.net:
/cvsroot/candetect co .
$ make /dev/fd0

This leaves you with all the source code ready for modifications. The project top-level Makefile:

This process will prompt you for the root password when it needs root rights; be sure to review the proposed command line. Note that this will create a directory called xoscope next to the one containing all the CanDetect modules (to avoid confusing CVS).

The Makefiles will detect missing utilities and automatically try to install them on a Debian-based system. On other distributions, you either need to resolve dependencies first or modify the Makefiles.

The kernel is truly multiplatform. Development was done using desktop and lab workstations, targeting laptop and embedded computers for field use. These share exactly the same kernel API. The driver architecture is multidevice, with standard support for up to eight installed sound cards. A computer can make many simultaneous measurements using different sound cards, all sharing a simple code API.

Audio is accessed as a simple character device using the same file descriptors as for open network links. No special calls are needed to control remote sound cards. This situation is especially valuable for simple computer platforms where screen size or processor resources would require adaptation of the software.

Possibly the most time-consuming part of developing nondestructive testing systems is validating them. This involves running the electronics and processing software against a broad range of samples in a variety of operating environments to demonstrate that the algorithms are robust. The Open Sound System, when integrated with other Linux kernel functionality, provides a common execution environment for the software across a wide range of computer hardware. This allows software validation results to be applicable because no source changes were made.

The latency associated with kernel buffering limits the adaptability of the algorithms, thereby requiring the measurement of potentially extraneous values and leading to a lower useful rate for the aviation user. Ongoing kernel development is mitigating this inefficiency, and in any case, it isn't relevant for wall inspection use.

CanDetect is not ready to be certified for aviation use. Interpretation of the results remains extremely challenging. We also wish to support sound cards with many more channels and apply the same software to measurements, such as:

The NIC unit was donated to the project when it was selected as a finalist in the Embedded Linux Journal contest in 2001. More information about our winning entry can be found in the May/June 2001 issue of Embedded Linux Journal (embedded.linuxjournal.com/advertising/press/nic_winners.php) and on our web site (candetect.sourceforge.net). The inductive probe, after assembly by Brian Whitecotton, was photographed by Keith Ostrom.