circuitcellar.com
Magazine Support   Digital Library   Products & Services   Suppliers Directory 
 
 





 

January 2006, Issue 186

Internet-Connected Sonic Anemometer


IMPLEMENTATION

I built a three-transducer, three-path sonic anemometer. Each transducer can see the other two transducers by arranging them in a triangle (60° angles). Three paths is a good compromise between minimizing the number of transducer channels and maximizing the number of paths for measuring the wind speed. The aforementioned two-path, four-transducer anemometer needs one of the transducers.

The transducer I selected is optimized for transceiving. It has a beam angle wide enough to see the others with a 3-dB signal reduction. For transmitting an AC signal, up to 20 VPP is applied to the terminals. When the transducer is connected to a high-impedance input, it behaves like a microphone and generates a voltage in the load.

The transducer’s design dictates the resonant frequency (40 kHz) and beam angle. I could have used a different frequency transducer (125 or 250 kHz), but there is less absorption loss in the air at a lower frequency. Furthermore, lower frequencies make the processing requirements less demanding.

The transducers are mounted in a PVC pipe structure (see Photo 1). PVC tube is great for building these structures because it’s easy to work with and a variety of fittings are available. The transducer fits in the tip of each arm and is held in place with a little RTV. I originally used twisted-pair cable to connect to the transducers, but that was a mistake. I’ve since switched the wiring to two conductors with shield microphone wire. The two conductors are isolated from the ground-shielding wire. The shield is terminated on the electronics end. This reduces crosstalk between the transmit and receive wires and it eliminates ground-loop oscillations.

(Click here to enlarge)

Photo 1—I built my three-point anemometer with PVC pipe. The distance between the adjacent sensors is 0.36 m.

The front-end electronics were the most difficult to come up with. I had to switch the transmission circuitry, which is relatively low impedance with the high-impedance inputs to the receiver. After trying a different scheme, I finally settled on a solution featuring a Scenix SX28/20 microcontroller (see Figure 5). The SX28/20 microcontroller has attractive features like symmetric CMOS outputs, which can source and sink up to 30 mA each. I used the CMOS outputs as push-pull drivers and a supply voltage of 5 V to drive the transducer with a 10-V voltage differential with plenty of current.

(Click here to enlarge)

Figure 5—The transmit/receive circuit is based on a Scenix SX20/28 processor. The transducer is attached to the pins that serve as both an analog comparator for receiving and digital I/O, which drive the transducer in a push-pull configuration. I used two-conductor microphone cable to reduce crosstalk.

I can switch off or tristate the outputs to put them into a high impedance state. A built-in analog comparator has a low offset voltage (10 to 20 mV) and short delay (25 ns) that make it suitable for a sensitive zero-crossing detector. The processor can read the comparator’s output directly. The output can be routed to a separate output pin. The input pins can be shared with the output pins.

In order for the received signals to be in the comparator’s voltage range, a simple resistor network must bias the inputs to a point approximately halfway between VCC and GND when the pins are in a tristate condition. It turns out that the 10- to 20-mV offset voltage is perfect for this application. Under normal conditions, the received signal has up to approximately 100 mV for the selected range and driver voltage. That’s enough to give a reliable zero-crossing detection, but isn’t too sensitive to pick up noise transients.

The front end has two interface signals for control. When the *SND/RCV pin is pulled low, the front end enters Transmit mode. A 16-cycle, 40-kHz square wave burst is then sent to the transducer. When the *SND/RCV pin is pulled up, it switches to Receive mode and sends the comparator’s output back via the Rx line.

The SX28/20 microcontroller is available in a 20-pin SSOP package, so you can integrate the entire front end in a package that can be soldered directly to the transducer and fit inside the PVC tube that holds it. This approach eliminates the need for high-impedance wires in the anemometer. Four wires (5V, *SND/RCV, RX, and GND) can be routed via twisted-pair wire to the sensor and front-end electronics with an SBC (see Figure 6). If RS-485 drivers and receivers are used, it’s possible to route the signals for long distances.

(Click here to enlarge)

Figure 6—The system is divided into three subsystems. The SBC handles all of the communications. The transmit/receive circuit interfaces and modulates the transducers. The transducers are in the tips of the actual sonic anemometer assembly.

I used a Rabbit Semiconductor RCM3000 development board for the front-end electronic interface. The processor has a high-speed pulse capture that enables me to take precise measurements of the time of flight. In addition, it has an Ethernet interface and an optional Wi-Fi connection kit. The prototype board has a regulator that accepts 9 to 12 VDC, which enables me to connect it to a sealed lead acid battery in case I want to run the system disconnected from the main.

For portability, economical solar panels and a charger are available for 12-V systems. With a Wi-Fi connection, I can use my laptop to connect to the instrument and communicate with it using a ’Net interface or FTP to upload wind data.

In addition to the aforementioned features, the software library comes with fairly fast floating-point routines. The TCP/IP stack and web server is also included.

The SBC continuously goes through an acquisition cycle to measure the TOF delays between each transducer. For each ping, you can collect two paths by using the two pulse capture registers. So, with a round-robin cycle of three pings, you can collect six path times. There are forward and backward times for each of the three physical paths (T12, T21, T13, T31, T23, and T32). The path lengths for the three segments are measured (D12, D23, and D31) and adjusted for processing delays.

The pulse capture happens to be in the hardware, so there aren’t any real time constraints on the system other than the transition from sending the transmission pulse and the arming of the capture time register. But this is a short time that can be handled by simply turning off the interrupts for a few instructions. It doesn’t affect the performance or add delays in processing when dealing with the TCP/IP protocol stack and web server.

To measure wind speed with resolution of 1 meter per second, I need a timing resolution of 1 part in 300. The path is 0.36 m in my instrument, which results in a 1.2-ms TOF delay. A 1/300 resolution implies a timing resolution on the order of 6 µs, which the hardware capture in the RCM3000 has no problems with.

The system uses a different geometry than a traditional cross anemometer using orthogonal paths. The math is a bit more involved, but you can add all of the vector components and use trigonometry.

Assume that the transducer is anchored at the origin and two and three are anchored at 0° and 60° angles (see Figure 7). You must first compute each wind vector:

Following this, add all of the vector components:

Lastly, compute the absolute wind and angle.


(Click here to enlarge)

Figure 7—Computing the vectors in a three-point anemometer is a bit more involved, but it’s still manageable.