# Ultrasonic Anemometer Part 19: Testing the Analog Circuit

In my last post I went through the design of the analog part of the ultrasonic anemometer. Today we will see how the circuit designed last time performs in practice.

Active Full Wave Rectifier

Let’s first look at the active full-wave rectifier. As a first test I fed the input with a 40kHz sine wave from the scope’s signal generator. Here’s what I got to see on the scope.

The input signal is shown in yellow. The pink signal is calculated as the absolute value of the input and is what we are trying to archieve. Finally, the blue signal shows what we actually get on the rectifier’s output. What do you think? The basic wave form is obviously right but the precision leaves quite something to be desired.  So I tried the same setup with an input signal 10 times slower, i.e. 4kHz.

As you can easily see, things look much better at 4kHz. That doesn’t make it much better for us since we need it to operate at 40kHz but there doesn’t seem to be anything fundamentally wrong with the design per-se. I think a faster op amp might be that is needed to make this thing work properly at 40kHz, too.

Zero-Crossing Detector

The zero-crossing detector is by far the simplest element of this circuit and has hardly changed since the Arduino anemometer shield. It’s output is shown in blue above. It works just as expected, no surprise here. Well, in the end it’s just a comparator so the sources for error are limited.

Peak Detector Sample And Hold

The input to the peak detector is the rectifier’s output so we should expect to see at least some inaccuracy carried over from the rectifier.

Below is what I got. Again, yellow is the 40kHz sine wave input. Blue and red are the peak detector of the positive and negative half-wave, respectively. Green is the output, i.e. either the blue or red singnal as chosen by the 2:1 multiplexer.

The good news is that the circuit basically works as designed. Each peak detector gets zeroed at just the right time. From the screen shot above one might even conclude that the peak detector is fairly accurate. Both half-waves show very similar amplitudes and the output is nicely held stable during the hold period. No droop is visible at least at this level of magnification.

Once you zoom in, things start to look less pretty. There is in deed no droop but the opposite. The output signal rises during the hold period. If you look closely in the screen shot above you can even see it – the segments of the green signal are slightly rising. We’re talking  maybe 10mV here, far from dramatic but still.

Conclusion

My conclusion is as follows:

• Zero crossing detector: perfect
• Active rectifier: poor performance as is but can probably be fixed with a faster op-amp.
• Peak detector: ok but not good enough. might need lots of trial-and-error to improve it.

I have mentioned in a previous post that I’m still unsure if I should stick to the predominantly analog signal processing or if I should make the switch to a more contemporary, digital, DSP like approach. After having spent an evening or two testing and tweeking this circuit the answer became clear – go digital.

If you’ve followed my blog for even just a short while you have likely noticed that I enjoy designing and building hardware.  Probably more than I enjoy writing software. But there are several good reasons to to more in software and less in hardware when it comes to this project.

• The circuit as described above works kind of. But it might take a loooong time to improve it until it really performs well. Chances are that it will never perform as well as I’d like it to.
• Board space. All this circuitry takes up considerable board space. A later version might use smaller components but this thing will always take up quite a bit of space – maybe a third of the total board area.
• Even with most of the heavy lifting done in hardware the Arduino is likely not fast enough. We’d need to sample the amplitude at 80kHz which is out of reach for the Arduino’s Atmega328 even when sacrificing some resolution.
• Further development. Chosing a digital approach enables users to actively contribute to the further development and improvement of this project.
• Versatility: Eqiping the anemometer with a dedicated microcontroller makes this project much more versatile. It no longer has to be Arduino specific. If you’re an Arduino lover I promise you it will always be Arduino compatible. No need to worry. But equiping it with a easy-to-use SPI or I2C interface makes it useful beyond the Arduino community.
• Cost.  My analog design uses two op amps among other things. Precision op amps are relatively costly components. It’s not an expensive circuit but it will always cost several dollars for the components alone. And improving the circuit is unlikely to make it cheaper.
• Processing power is cheap. You might rightly say that a few bucks is not a lot of money to spend on some nice analog circuitry. I fully agree. But one can buy a lot of processing power for far less money nowadays.

Let me elaborate on some of these points:

Versatility: Arduino Only vs. Anyting, including Arduino

The arduino is a great platform with a great user community. But the Arduino Uno might not be the best choice for this project. A on board microcontroller gives user the option to use this anemometer from whatever platform they chose. Besides: An arduino is a very expensive device even when compared to a quite high-end microcontroller.  32-bit microcontrollers running at frequencies of 40MHz and higher are available for less than 2 or 3 dollars even in small (say, 10 pieces) quantities.  More advanced models might cost, say, 5 dollars.  In comparison, an Atmel Atmega328 as used on the Arduino currently costs CHF 3.10 (USD 3.18 at the time of writing) at Farnell. Not really value for money if you ask me.

Community Driven Developement

There are lots of creat coders out there. I can write decent code but there are plenty of people way better at that than I ever will be.  I see this as an opportuinity to greatly improve this project. Once I get this thing up-and-running I’d like to build a small series and let users share their experience and contribute to the code. Have an idea on how it could be improved? Try it yourself if you have the skills. Share your code if it works. Or share your thoughts and ideas if writing emedded softwar is not for you. So the anemometer could get better and better without having to get new hardware. Just update the firmware.

Next steps

In the weeks to come I will work hard to find a suitable microcontroller and to design and build a board with all that is needed for a stand-alone ultrasonic anemometer.

# Ultrasonic Anemometer Part 18: Analog Signal Processing

Recently, I’ve sucessfully tested the new driver ciruit for my ultrasonic anemometer. It performed even better than I expected and I will be happy to use it pretty much as it is.

By the way: If you want to get an overview over how this project has developed over time check out the overview page. If you’re more interested in my latest design, this link will take to my new attempt.

So we have a circuit that can send powerful ultrasonic pulses from the right transducer, receive the signal from the opposite transducer and route it through an amplifier. The next task is to tell the time-of-flight from the received signal. A contemporary  approach would probably involve some sort of DSP and software. My last approach used some analog circuitery to detect the zero crossings as well as the envelope of the received signal. Since most of the heavy lifting was done in hardware, a simple 8-bit microcontroller like the one on the Arduino UNO could be used to do the measurements.

For my new approach I haven’t quite decided which route to take.  To me they both have a certain appeal. And over the last year or so I’ve had quite some ideas on how to process the signal in hardware so I’ll give it a try and see how it works out.  In this post I’ll go through this new circuit and explain how it works (or is supposed to work) step-by-step.

The zero crossing detector (ZCD) is almost identical to to my last design. The amplifier output is biased to half the positive supply voltage and fed into a fast comparator (Microchip MCP6561R). On the comparator’s output we get a precise digital signal indicating if we are currently looking at the positive or negative half-wave. Right at the logic edge we observe a zero crossing which can then be used to very precisely determine the phase shift relative to the transmitted singal.

The more challenging part is to tell the absolute phase – this is where my last project was only partly successful. It used an active low-pass filter to get the envelope of the received singal. This envelope was then compared to some threshold and the time from the transmition of the singal to when the envelope exceeded the threshold was measured. With plenty of averaging this gave a usable but far from perfect indication of absolute phase. So this time I’ll try something entirely new.

The amplified singal is first run trough an active full-wave rectifier as found on page 257 of Horowitz and Hill’s 3rd edition of Art of Electronics. It uses two op amps as well as some resistors and diodes to produce a singal that corresponds to the absolute value of its input. The two op amps come in a single package. It’s the same type as for the amplification stage of the driver circuit – a Texas LMC6482.

Now the rest of the circuit is a bit more adventurous. It attempts to produce a signal that corresponds to the peak of the previous half-wave. So it is steady during each halv-wave period and should give a (hopefully precise) indication of the amplitude of the received signal. This singal can then sampled by an ADC at 80kHz triggered by the zero crossing detector. 80kHz is not that fast for a (say) 10-bit ADC and definitely much slower than what we’d need if we sampled the amplified signal directly.

The advantage of measuring the amplitude is the following: We can find the peak of the amplitude in simple software and use the time when the peak occured to find the absolute phase. So we are no longer dependant on the absolute amplitude (as we were with the envelope detector approach) but only care about when the peak in amplitude occured. I think (hope) this is a much more reliable approach.

In order to find the peak of each half-wave I use a pair of simple diode-plus-capacitor peak detectors. One is held stable (“hold”) and fed through an op-amp buffer to minimize droop while the other is looking for the next peak (“sample”). At the beginning of the sample period the capacitor is discharged through a n-channel mosfet that is turned on for just an instance.

The whole mechanism is controlled by the output of the zero-crossing detector so absolutely no software intervention is needed to produce it. The microcontroller can just wait for the ZCD to trigger an interrupt (as before) and take a sample of the output.

The circuit is not that complex and used an inexpensive and readily available 74HC4053 multiplexer at its center. I don’t have any idea yet how this thing will perform but I must say this little circuit was a lot of fun to design.

Until my next post I will have built and tested this cuircuit and will let you know how it performs. Until then I leave you with the eagle files as well as PDFs of the schematic and layout as a zip file.

Here’s how the final circuit looks and how it performs: Part 19.

# Temperature Controlled Fan

I’m currently mainly working on my new anemometer design but once in a while I get distracted. For example when my Keysight E3645A lab power supply was making so much noise that I could hardly concentrate. That’s when the idea of this fan controller was born.

Of course, the best temperature controlled fan in the world doesn’t help if you really need the cooling the fan is providing. But very often a small fraction of the cooling would do just fine most of the time. In my case the supply does control the speed of the fan. But it doesn’t seem to measure the temperature at all but seems to calculate the necessary cooling in a worst-case condition. An for a supply that may be rack-mounted together with lots of other heat dissipating gear the worst-case might be quite demanding. But my supply just sits on a shelf at, say, 22 degrees ambiant. And most of the time I’m hardly pulling any current. When working with microcontroller designs it’s rare for me to pull more than a few tens of milliamps. So little cooling is needed most of the time. But the E3645A (this one here does a better job) ran its fan at crazy speeds while the case still had this cold metallic feel to it.  So we can definitely do better.

So the first step was to open the supply and to see what kind of fan it uses and how it is controlled. After beaking some seals and opening the case I found a 60x60x25mm 12V fan of Chinese origin. I also found out that the supply uses linear control. So there’s no PWM or anything but the supply voltage just varies in (I think) four steps from 7.4 to 12 volts. Most surprisingly, this voltage is not ground-referenced but symmetric around ground, i.e. plus/minus 6 volts.

I was pleased to see that the fan connects to the main board by means of a standard two-pin 100mil header. So I could just plug anything in between the board and the fan.

That’s exactly what my first idea was. Stick with the original fan and just put a PWM controller in between. I’ve just recently made some LED dimmers and the technology needed here seemed to be very similar. So Rev A of my fan controller was born.

It’s simple: A linear 5V regulator, a PIC16F18325 microcontroller, an LMT86 temperature sensor and a N-channel mosfet. The PIC chosen here runs at up to 32MHz on an internal oscillator, has an internal voltage reference (of 1.024, 2.048 or 4.096V), six PWM modules and plenty of other nice features while comming in a small 14-pin package. So all I need to do is to measure the temperature, calculate the desired fan speed and set the PWM duty cycle accordingly.

My first surprise came when I first wanted to program the PIC. My trusted Mikroelectronika MikroC for PIC compiler doesn’t know that chip. And neither does my MikroProg programmer. So after a little bit of research I ordered a PICkit3 and downloaded the MPLAB IDE. As a nice side effect I can now also compile code for and program the fancier PICs like the DSPics and PIC32s. I might do that before long.

So I did the necessary programming (and debugging) and attached a small fan. It all worked but I had to chose a quite low PWM frequency in order to make the fan spin at lower duty cycles. And probably as a result of the low PWM frequency the motion of the fan didn’t look or sound very smooth.

With the larger fan from the supply things only got worse. I had to lower the PWM frequency even more into the tens of Hz range so it would spin at all. And even like this I couldn’t get it to run at low duty cycles. Of course, the low frequency caused nasty vibrations so I gave up on this approach. I read online that other people successfully use PWM on their fans but at least this model wasn’t happy to be PWM-dimmed. Does anybody know more about this? Was this an option in the old days before brushless motors were the norm? Is it that brushless motors aren’t unsuitable for this kind of control alltogether or does it depend on the specific model? Please use the comments section below if you can shead some light on this.

But I don’t give up easily so after a bit of research I ordered a four-wire fan conforming to the so-called Intel spec. Besides ground and +12V they have two control lines. A PWM line that lets you control the fan speed by means of a (25kHz nominally) PWM singal. And a so-called TACH singal that allows you to read the current fan speed. The PWM line has internal pull-ups to (depending on the fan) 3.3 or 5 volts so you just need to pull it low. The TACH signal needs an external pull-up resistor and gets pulled low by the fan twice per revolution. So you’re getting a digital signal with a frequency of twice the fan speed.

I ordered a EBM Papst 622/2 HHP which is the right size and somewhat more powerful than the original fan. The new board has a somewhat odd shape so I can use one of the fan’s mounting screws to mount the board as well. Note that all the copper has been removed around the mounting hole. The fan is attached to a heat sink which is grounded while our board runs on a split suply. So ground as our board sees it is not actually ground but a negative voltage so we have to be careful.

The new Rev B design runs on 3.3 volts in order to be compatible with any fan independent of the fan’s internal logic voltage. I’ve also used a different temperature sensor – a classic LM35.

Like the Rev A there is an LED to visually indicate what’s going on. There are also three pins on the microcontroller that are intended to be used as debug pins so I put some vias there to make it easy to connect a scope probe.

Above you get an idea of what the TACH signal looks like. It’s a quite low frequency singal since there are only two pulses per rotation. So the measured 104Hz shown on the screenshot correspond to 3120 RPM.

Having a TACH signal to measure and three debug outputs to worry about made the software development somewhat more involved but it was well worth it. I’ve used the debug pins as follows:

• Actual (i.e. mesured) fan speed. 100% corresponds to 10000RPM
• Target fan speed. 100% corresponds to 10000RPM
• Measured temperature. 100% corresponds to 100 degrees centigrade

So from the duty cycle measured by a scope you can easily read the speeds and temperature.

Of course this is only possible since there are some unused PWM modules left. But as I said, this PIC has 6 of them and only two are needed to measure the fan speed and another to control the fan.

The transfer function from temperature to fan speed can be freely defined in software. In the screenshots above the fan was running at 1500RPM up to a temperature of 30 degrees. Above that the speed would rise linearly until reaching its maximum of 9000RPM at a temperature of 55 degrees.

One could easily implement a PID control if one was so inclined but the slowly chaning nature of the temperature in such a setting makes this largely unnecessary so at least for now only the proportional part is taken into consideration when calculating the PWM frequency.

As you can see, the little board is nicely held in place by one of the fan mouning screws. By the way, the LED blinks roughtly once per second and its duty cycle corresponds to the target fan speed relative to the maximum fan speed of 9000RPM. So if the LED is on one-third of the time the target fan speed is one-third of the maximum speed or 3000RPM.

Unfortunately for my application, the supply senses the current consumed by the fan and shuts down if not enough current flows. This is probably a good idea and prevents the supply from possible damage if the fan is unplugged for example.

I found that it is possible to run the fan at a lower speed without the supply complaining but with fan speeds below about 4000RPM the there were conditions causing an error condition. So I ended up connecting a 1W 150ohms resistor in parallel to keep the supply happy even with the fan running at only 1500RPM.

I believe that my settings are very much on the safe side. At a a temperature of around 50 degrees measured inside the case the airflow matches the one of the original fan at max speed. But needless to say this kind of fiddling voids the warranty and is always done a one’s own risk. The reward is a supply that is now hardly audible and much more pleasant to use.

The zip file contains the eagle files, PDFs and software of both revisions.

# Ultrasonic Anemometer Part 17: Lasercut Mechanical Design

In my last two posts I have gone through my new anemometer circuit both in theory and practice. Click here for an overview over my ultrasonic anemometer project.

This will be a short post. Unlike most of my other posts, this one will not cover electronics but the physical design of this wind meter. As you can see, the new design all laser cut. At the Zurich Fab Lab I have access to a 75 watts Epilog laser cutter and I recently started playing around with OpenSCAD, an open-source CAD software.

I immediately liked the OpenSCAD approach of designing a 3D part in code as opposed to a graphical interface with menus and buttons and the like. Using OpenSCAD is much like writing software. If you’re more familiar with coding than you are with classic CAD tools you will instantly feel at home with OpenSCAD. But it’s pretty much love it or hate it. At least with all the people I’ve talked to.

I’ve seen some quite cool boxes  that were just laser cut and then screwed together. I found it quite compelling how you can laser cut your parts, stick them together and maybe use a few screws to hold everything in place. So I decided to give it a try myself.

The design is not too complicated with just 6 wooden parts. The material is 5mm in thickness so I looked around for screws and bolt that would be appropriate in size. I also thought that it would be nice to use square bolts both from an optical as well as a mechanical point of view. I learned that square bolts are specified by DIN562 and that M2.5 square bolts measures 5x5x1.6mm – exactly what I needed.

So the next thing to find was M2.5 screws. I found nice ones in stainless steel and especially with a Torx (T8 size) head as specified by ISO14580 as well as some matching washers (DIN125).

All the tubes are recycled from my last model. Just standard 16mm plastic pipes intended to hold electrical wiring.

As you can see in the photo above, I’ve tried two different versions for the side parts. The one at the bottom takes the path usually followed: There are cuts that can later fit the screws. The one at the top doesn’t have those cuts and relies on holes being drilled by hand.

Drilling those holes turned out to be really easy. After the parts are ready, just stick them together and drill the holes using a drill press. At the fab lab we have such a drill press and the holes were drilled within minutes. I never liked those cuts so for me this was the way to go.

The new design gives me a lot of space to mount any PCBs and hides all the wiring between the bottom and top plate. The bottom includes a large square hole so everything inside stays accessible. There are also two small drill holes to mount a 12 volts power supply. This way I can just plug it into the wall which I think might be handy.

The OpenSCAD model as well as the Adobe Illustrator (Ai) and PDF files are available as a download from the overview page. Keep in mind that this is one of my first attempts at OpenSCAD, laser cutting and solid CAD modelling alltogether. I’ve tried to keep the CAD model clean and modular but I’m not sure if I succeeded.

If you have any questions, suggestions or just your experience with this kind of thing please just post them as comments below. I’m quite new to most of this so I value your feedback and I’m always glad to help if I can.

Click here to continue to my next post where  I  talk about the second, analog part of the circuit.