Tag Archives: wind meter

Ultrasonic Anemometer Part 28: New hardware tested

20160907_standaloneanemometer_024

I last time proudly presented the new RevB board and got a lot of feedback from people who want one, too. As mentioned I have all the components here to ship up to 10 kits but I was reluctant to send anything until I had the chance to do some hardware testing. Not much had changed since the last revision but I don’t like taking chances on things like this.

20160907_standaloneanemometer_029

In the mean time I managed to do some rudimentary testing and now feel confident to take orders. These tests concern the hardware only. What I said last time about the state of the software still applies. But let me tell you what I’ve been able to test so far.

rxtx_overview

Tests performed so far

  • The PIC32 can be programmed from a PICKit3 via the ICSP header without any issues.
  • Power consumption is as expected. Like the previous version it draws 45mA@12V (programmed) and the other two rails come up with +3.310 and -3.279V, respectively. Also as expected. Regulator stays cool.
  • With the PIC controlling the AXIS, DIRECTION and SIGNAL pins, the transducers receive the 12V signal from the mosfet drivers. HOWEVER: the signals AXIS and DIRECTION are incorrectly labeled both in Eagle as well as on the silk screen. Electrically everything is fine but the names have been confused.
  • The signal from the transducers is properly received (Rec pin on the board) and amplified by a factor of 11 by the first stage of the amplifier (S1 pin on the board).
  • The PIC is able to control the digipot over the internal I2C bus and the second amplifier stage also performs as expected.
  • The zero-crossing detector (ZCD) works.
  • The input to the PIC’s ADC (ADC+ and ADC-) look fine, too. HOWEVER: the labeling on the silk screen is wrong. Eagle is correct, it’s just the silk screen. Plus should be minus and vice-versa. Again, electrically everything is fine.
  • The PIC can communicate (as a slave) with an Arduino UNO connected to the external I2C bus.
  • Communication over USB to a YAT-terminal under Win 7 works.

rxtx_north

rx_closeup

The following has not been tested so far

  • For my tests I still used the transducers already used previously. I believe the ones I ordered last week are of the same type but I haven’t tested them.
  • EEPROM. I haven’t tried the newly added memory yet. I have confirmed that it has power and is connected to the same bus as the digipot so I have no reasons to assume there are issues with it. But testing it would require some software first.
  • The external SPI bus has never been tested, neither on the Rev A board nor with the new one. I don’t expect any problems but I haven’t done any testing so far.

20160907_standaloneanemometer_028

Is there anything important that I forgot to mention? In that case just ask.  A lot still needs to be done but at this point I’m confident that the board has no major flaws and performs much like the prototype.  Want to give it a try? I have some kits left for you.

i2c1_arduino

Continue here to the next post of this series.

Ultrasonic Anemometer Part 27: Ready to take pre-orders

20160903_StandaloneAnemometer_001Good news: the boards from dirtypcbs.com have arrived and look great. I also got all the components for the 11 boards. Why 11? I ordered about 10 (they call it a protopack) and was lucky enough to get 11. Thats dirtypcbs.

Last week I also upgraded my hobbyist Eagle license to a proper Premium LS license which means I can now legally start selling stuff. So I’m basically ready to ship the first kits.

20160903_StandaloneAnemometer_002

Today I assembled one of the boards and it at least looks great. All the footprints are correct and it was a pleasure to solder. Now what I want to do is to run some tests with it just to make sure it works as intended. I didn’t change much since the last version but I want to be sure first.

20160903_StandaloneAnemometer_003

About the kit

There’s one thing I want to be absolutely clear about. At this stage of development the wind meter is not yet ready to be deployed. While I think the hardware is final now, a lot more work is needed to get the software ready. So for the time being this kit is intended for people who want to join the development and testing. I’ve done most of the low-level, register-fiddling stuff but much remains to be done at a higher level. I know there are a lot of people out there with much more experience in signal processing than me and I’m looking forward to work on this challenge together. And a challenge it is. But the PIC32 still has plenty of RAM, Flash and CPU time left to try out new ideas and approaches until we find one that works well.

20160903_StandaloneAnemometer_004

The kit contains the board and all the necessary components. Details can be found in the BOM linked on the overview page. Once assembled it should look precisely like on the photos on this page. But as the name suggests, it comes as a kit, i.e. as components that you have to solder yourself. Most components come in relatively large SOIC packages but there are a few smaller MSOP and SOT-23 packages as well. They can all be soldered with a conventional soldering iron and strain solder just like I’ve done today.

20160903_StandaloneAnemometer_005

The microcontroller is not yet programmed so you will need a suitable programmer. Microchip’s PICKit3 (USD47.95) is the obvious choice here. This is also what I’m using and matches the board’s pinout. All the software (MPLAB X IDE and XC32 compiler) are available for download from Microchip free of charge.

Taking pre-orders now

I’ll start taking pre-orders now but as mentioned I won’t ship the kits until I’ve done some tests with my own board. Once that’s done I’ll let you know and if you’re still interested by then I’ll give you my PayPal details and ship the kits.

Some have mentioned that they already have some ultrasonic tranducers and/or want to try some specific model so you are free to order your kit with or without the transducers.

20160903_StandaloneAnemometer_007

There’s no online shop or anything like that so just use the contact form on the about me page.

Pricing

Now it starts getting interesting. I’ll quote all prices in USD, EUR and CHF.  Choose what’s cheapest or most convenient for you.

  • Kit without transducers: USD 70 / EUR 63 / CHF 69
  • Kit with transducers: USD 95 / EUR 85 / CHF 93

The prices above include worldwide shipping. The kits ship by Swiss Post Priority Mail in a padded envelope.  I’ve used this service before to locations like Brazil or India and never had problems. However, there are no tracking numbers.

Any other questions? Just ask.

20160903_StandaloneAnemometer_006

 

Ultrasonic Anemometer Part 26: Rev B Board ordered

I recently ordered my first PCB at dirtypcbs.com and the result was promising. So there was nothing stopping me from finalizing the Rev B of my standalone Ultrasonic Anemometer and ordering a protopack. I’ve placed the order a few days ago and expect the boards to arrive here in 2 to 3 weeks. This should be good news for all those of you who have been asking for kits and want to contribute to the further developement of this project. I’ll build up one or two boards as soon as they get here and do some testing. If everything works as planned I can order some more components and ship some kits soon after that.

EagleSnapshot

So today I’ll go through the changes I’ve made compared to the previous version. All in all the changes are quite minor and only require minimal changes in software. But let’s go through them one by one.

Non-volatile memory

This is the biggest change from a functional point of view. The PIC32MX250 doesn’t have any EEPROM memory of its own. So in order to be able to save some settings an the like I’ve added a Microchip 24AA16 I2C EEPROM providing 16kbit (2kB) of non-volatile memory. That should be more than enough to store any settings and calibrations one might want to make. For example, this gives the user the possibility to calibrate the filter kernels to the transducers used. Of course, the software first needs to make use of that memory but I think it’s great to have the possibility to durably  store a reasonably large amount of data.

dirtypcb_top

Support for 5V I2C communication

I’ve hinted at this in a previous post. On the Rev A board the I2C signals were pulled up to the 3.3 volt rail. This was great as long as one didn’t want to interface to a 5V device such as an Arduino. The microcontroller pins are 5V compatible so you want to be able to pull those lines up to 5V whenever you interface to a 5V device. So I’ve added a diode to allow the SDA and SCL lines to be pulled higher than 3.3 volts. The I2C reference voltage of 3.3 volts minus a schottky diode drop or about 3.1 volts is accessible from the I2C header at the bottom. So just connect that to the external device’s 5V operating voltage and you have a fully compliant 5V I2C bus.

dirtypcb_bottom

Physical layout and connectors

There was a rather large 8-pin connector on the last version to connect to the transducers. Now all the connectors along the edges of the board are standard 100-mil headers. This also allowed me to slightly shrink the physical size of the board to 60x70mm.

The pinout has also slightly changed. The board is now powered from a header on the right-upper side and all three voltage rails are now externally accessible from a newly added header on the right side. The pin order on the I2C and SPI headers on the bottom side of the board has changed, mainly to accomodate an exteral I2C reference voltage.

GerberViewerScreenshot1

Power supply

The tiny (SOT23-5) 3.3 volt linear regulator on the last version worked well but got rather hot when providing close to 50mA from a 12V input voltage. I never had any issues with it at room temperature but decided to be cautious and upgrade to a LD1117 regulator in a much larger SOT223 package. This should be more than sufficient any reasonable ambient temperature..

GerberViewerScreenshot3

Miscellaneous changes

I changed the digipot used to set the amplifier gain to a Microchip MCP4531. This model only has 128 steps but this is still more than sufficient for its task and it’s quite a bit cheaper than the 256-step version.

I also had to change the crystal because the model previously used became unavailable.

GerberViewerScreenshot2

That’s it for now. I’ll let you know as soon as the boards get here.

Ultrasonic Anemometer Part 25: I2C Interfacing and more

20160706_StandaloneAnemometer_023

It’s been a long six weeks since my last post but that doesn’t mean that I haven’t done anything since. Among other things, I wrote some code to get the I2C interface working and hooked the anemometer up to an Arduino Uno with an LCD display attached. Apart from demonstrating the I2C interface this also nice for testing. For the first time I can see what this thing is measuring in real time without hooking it up to a PC over USB.

20160710_StandaloneAnemometer_025

I2C Interfacing

But let’s look at the setup in some more detail. The PIC has a total of two I2C interfaces and I’ve made both of them accessible via the 100mil headers along the edges of the board. One of them is primarily intended for internal purposes like controlling the gain via the I2C digipot. The other one can then be used to interface to some external logic without having to worry about any internal communication. This external I2C interface also comes with 5V compatible pins which means we can interface to 5V devices like an Arduino without any further logic level translation. All we need is a pair of pull-up resistors pulling the SDA and SCL lines up to 5 volts. The Arduino’s Atmega328 already has built-in (weak) pull-up resistors so that’s not a problem. I didn’t think of interfacing to a 5V device when I designed the board and pulled the I2C signals to the anemometer’s 3.3V supply. So for proper 5V operation I’d have to unsolder the two 10k resistors. Luckily, 3.3 volts is enough to almost certainly be recognized as a logic high by the Arduino so the setup works anyway. But I will think about how to improve this in the next version. I might add a diode to allow the lines to be pulled higher than 3.3 volts.

The I2C interface can be configured to act as a master or as a slave device. For now I’ve only implemented slave mode so the wind meter behaves just like a I2C temperature sensor or external ADC. The Arduino acts as a master and asks the slave for its latest measurement every 250ms. The anemometer then returns 8 bytes of data consisting of 2 status bytes, north-south wind speed, east-west wind speed (both in mm/s as signed 16-bit integers) and temperature (0.01 degrees centigrade as signed 16-bit integer). It’s also possible to send data to the anemometer. That data is then saved to a buffer is otherwise ignored.  In a future version of the software one might use this functionality to set the data format to wind speed and wind direction or to change the temperature unit to kelvin or fahrenheit.

20160710_StandaloneAnemometer_027

It would not be difficult to implement master mode as well but so far I haven’t done it yet. A lot of code could be copied from the module communicating with the digipot where the PIC acts as a master. The anemometer could then push data to an external device whenever a new measurement becomes available. Definitely something I’d like to implement at some point but no priority right now.

Bug fixes

I’ve found (and fixed) a number of bugs while testing. Among other things, the axis and direction signals were not always properly set and so the measurements did not always correspond to the direction they should. So take with a grain of salt some of the test results reported earlier. Some of them were almost a bit too good to be true and this bug might have been the cause. I suspect I might have compared two successive measurements in the same direction when I actually wanted to compare measurements taken in opposite directions. But I’ve fixed the code and I’m confident that now all the directions are set and reported correctly.

Individual filter kernels

EqualAmplitudes

As can easily be seen from the scope screenshots above, the shape of the received signal varies quite a bit from transducer to transducer. Note that the amplifier gain is dynamically adjusted to make sure the peak amplitude is the same for all of them but the shape still differs quite substantially. So the kernel for the matched filter has to be some compromise to suit them all. I have now modified the software to use four individual kernels, one for each direction. This gives us the flexibility to calibrate the kernel to each transducer and so get more reliable results for the absolute phase.

Revised board

20160710_StandaloneAnemometer_026

My main priority at the moment is to complete the revised version of the board and to order a small series of boards. Until recently I never ordered a board from a professional board house so there are quite a few things for me to learn. For the first time I have to worry about silk screen, for example. Or solder mask. On the other hand, a board house can do a lot of things I can’t. Plated-through holes for example. Or smaller vias. Or place vias under an IC. This means a lot more flexibility in my layout that I first have to get used to. But I’m making progress. I got a simple design of mine produced by dirtypcbs.com and got a batch of very usable boards. More on that in a future post.

Wind tunnel

If you’ve been following this project for a long time already you might remember my simplistic wind tunnel made of a 120mm brushless fan and a cardboard tube. I got a number of suggestions from you guys on how to build something better than that and I also found some useful material online. So I’ve started to build a much improved wind tunnel that will hopefully allow me to perform more meaningful tests. That’s also for one or more future posts.

20160706_StandaloneAnemometer_021

Software ideas

I’ve also played around with some software ideas that I believe to have potential. One is dynamically adjusting the frequency. I’m now only working at the transducer’s nominal frequency of 40kHz. But the individual transducer’s resonance frequency might be somewhat different and might change with temperature or age. So I might try to adjust the frequency dynamically using some perturbation and observation algorithm.

I’m also thinking about measuring at two slightly different frequencies (say, 39.5kHz and 40.5kHz) and using the two phase shifts to figure out the absolute time-of-flight. I’ve given it a try and was not very successful but I haven’t given up on that idea yet.

So that’s it for now. The code for the Ultrasonic Anemometer as well as the Arduino are available for download. See the overview page for the respective links.

Ultrasonic Anemometer Part 23: First successful measurements

In my last post I was happy to report that I managed to get the USB interface to work. This interface has since proved to be extremely valuable in software development and testing. While the device is taking measurements you can look at the results (or intermediate results) at your PC in real time. You can even log large amounts of data to a .csv file and inspect the results in Excel.

20160514_StandaloneAnemometer_049

But let’s look at the developements in a bit more detail. Last time the device was sending pulses and capturing some of the resulting zero-crossings but not much more than that. And in a not very structured way.

Measuring amplitude

Now it’s not only capturing the times when the zero-crossings occur but also measures the amplitude of the half-waves in between. In order to do that an interrupt is generated at every zero-crossing capture. Inside that interrupt service routine time of the zero-crossing is saved (as previously) and the ADC is started. In order to measure the amplitude at its maximum (or minimum in case of a negative half-wave), the ADC first samples the input for a 6.25 microseconds (which corresponds to a quarter-wave at 40kHz). I’ve chosen the sampling period slightly shorter to compensate for the time from when the zero-crossing occured unil the ADC is started. After the sampling period the internal sample-and-hold amplifier switches from sample to hold and the actual analog-to-digital conversion takes place.

The PIC’s datasheet advertises a maximum sampling rate of 1 million samples per second. Beware, though, that this requires separate Vref+ and Vref- connections and doesn’t work in differential mode anyway. In my configuration without separate analog references and differential measurements the maximum sampling rate drops to 400k samples per second. And the reported conversion time doesn’t include the sampling time yet. I wasn’t aware of that but luckily the PIC’s ADC is still more than fast enough for what I’m doing here.

20160428_StandaloneAnemometer_028

Finding the absolute phase

Capturing the zero-crossings is relatively easy and the results are very precise. But there’s a challenge: there are hundreds of zero crossings for each burst of pulses sent. How do you know which zero-crossings to use?

The Arduino-based anemometer used an analog envelope detector to solve this problem. After averaging plenty of samples this works most of the time. But even after many attempts to tweek the analog circuit the envelope detector approach was never as reliable as I wanted it to be.

My standalone anemometer has an entirely different approach. Being able to digitally measure the amplitude of each half-wave we can tackle the challenge in software. We have a series of measurements and we have an idea of that the signal we are looking for looks like. Looking the scope screenshot below you could easily and reliably determine where the maximum amplitude occurs. That’s what we need to teach the software to do.

ZCD_Capture

One could, of course, just loop through the all the amplitudes and find the maximum. But there are a lot of similar amplitudes and so any noise would make the result unreliable.

I did a bit of reading on digital signal processing (DSP) and realized that this is a classic DSP problem. The solution is a matched filter. You take the signal you are looking for (also known as kernel or template) and multiply it sample by sample with the captured signal and sum up the results. Do that for every possible (or reasonable) overlap of signal and kernel and find the position where the result reaches its maximum.

If you’re new to the subject (like I am), Steven W. Smith’s Digital Signal Processing is a great place to start. It’s even available online for free at dspguide.com. The method is also referred as convolution or correlation depending on who you ask. This wikipedia article gives a nice introduction to the subject.

Implementing the matched filter

I’ve parameterized the software to capture 34 zero crossings as well as the n=33 amplitudes in between them. The kernel consists of k=17 data points with a peak in the middle.

There are n-k+1=17 possibilities to entirely overlap the kernel with the signal. We can skip all the odd numbers where a negative kernel value would be multiplied with a positive sample value and vice versa. This leaves us with 9 possible positions to chose from.

For each position we need to do 17 multiplications and 16 additions. And we need to do that for every single measurement, i.e. 512 times per second. That sounds like a lot of work and it probably is. Luckily, since this is a very common DSP task, microcontrollers like the PIC32 have a special instruction for this. It’s called MAC – Multiply Accumulate and executes in a single clock cycle. The result is just amazing. The corresponding ISR takes less than 30 microseconds, including some housekeeping tasks as can be seen in the screenshot below.

Once the maximum amplitude is found, the 16 zero-crossings around it (i.e. the 8 before and the 8 after) are summed up and the sum is saved as the result of that measurement.

ConvolutionTime

Averaging measurements

The goal is to report wind speed and temperature four times per second. Since there are 512 measurements per second we can use up to 128 individual measurements  (32 in each direction) to do our calculations.

So we have plenty of data to identify and exclude outliers and do some averaging of the remaining samples. Robust statistics is the key word here, click here for the corresponding wikipedia article.

For now I’m doing something reasonably simple: First the 32 results per direction are sorted. The 12 lowest and 12 highest results are ignored and only the 8 results in the middle are summed up.

This might seem wasteful but it makes the average very robust against outliers and still results in 16 x 8 = 128 zero-crossings being averaged. The resolution of each zero-crossing is equal to 1 / 48MHz or about 20.83 nanoseconds. Summing up 128 of them gives us a resolution of far below a nanosecond. Beware however that resolution doesn not imply accuracy.

As a last step, the resulting sum is multiplied with 125 and then divided by 768 to make the unit 1 nanosecond. So every 250 milliseconds we finally have 4 time-of-flight measurements with a resolution of 1 nanosecond. That’s what we will use to calculate the winds speed as well as wind direction and temperature.

This sorting and averaging step is a bit more costly in terms of computation time. It takes around 600 microseconds to complete (see below). But unlike the convolution, it only has to be performed 4 times per second so this is more than fine.

CalculatingAverageToF

Calculating wind speed

We are finally in a position to calculate the actual wind speed. There are various ways of doing this. For now I’ve just done the simple approach of taking the difference in time-of-flight, assuming room temperature and solving for wind speed. This means solving a quadratic equation for which I have resorted to floating point math and using <math.h> for the square root function.

I don’t have my wind tunnel any more so doing any testing was difficult. But one thing was soon obvious: at zero wind speed, the time-of-flight measurements match extremely well and are extrordinary stable from measurement to measurement. Also, looking at the intermediate results (i.e. the 128 single measurements before averaging) shows that there are basically no outliers present. I could randomly pick a measurement and still get a very reasonable value.

Something seems to be systematically wrong with the first of the 128 measurements but I haven’t had time to look into this. Otherwise, the results are impressively stable. And I’m only using a relatively primitive kernel for the matched filter.

USB data logging

As I’ve mentioned at the beginning, the USB interface lets me do some serious data logging even at this early stage of development. Here’s a list of what I can do by sending a character to the device from a USB terminal.

  • ‘Z’: Get all the 34 zero-crossings of a single measurement
  • ‘A’: Get all 33 amplitudes of a single measurement
  • ‘F’: Get a full single measurement, i.e. 34 zero-crossings plus 33 amplitudes
  • ‘T’: Get all the 4 x 32 = 128 time-of-flights for a measurement series
  • ‘R’: Get the 4 averaged time-of-flights as well as wind speed and temperature

Some versions of these commands also let you specify the direction you’re interested in as well as how many sets of data you want to receive. This makes it easy to log large amounts of data that you can use to test possible algorithms on your PC before you implement them on the PIC.

20160428_StandaloneAnemometer_025

Next steps

The next step is to get the I2C digipot working so I can control the amplification in software. My idea is to aim for a maximum amplitude of around 3 volts independent of wind speed and so on.

There’s also plenty of work to do to improve the algorithm that calculates wind speed and temperature. And then I also have to implement the I2C and SPI interfaces that let the anemometer communicate to other embedded devices like an Arduino or Raspberry Pi.

Having used floating point math and <math.h> I’m also running out of flash memory. I’m currently using 93% of flash (32kB total) and 52% of ram (8kB total). There will be a slightly revised board (Rev B) that uses a PIC32MX250 which is identical to the MX220 used here but has four times as much flash and ram.

That’s it for today. On the overview page you find the software at the stage of developement just described as well as some examples of logged data (all at zero wind speed) as .csv files.

The next post on this project is here: Part 24.

Ultrasonic Anemometer Part 20: Standalone Anemometer Design

Last time I outlined my reasons to ‘go digital’ by adding a powerful on-board microcontroller and designing a standalone wind meter.

20160426_StandaloneAnemometer_001

In the weeks that followed that decision I tried to find a suitable microcontroller and to design a prototype. Today I’ll show you the result of that work.

20160426_StandaloneAnemometer_003

I looked at various series of microcontrollers from different manufacturers and finally decided to go for the Microchip PIC32 series. It offers everything I could possibly ask for: 32 bit architecture, inexpensive, vectored interrupts, integer division, any interface you want (depending on the model of course) , available in large, low pin count, hobbyist friendly packages and so on.

20160426_StandaloneAnemometer_011

As you can see above, the model chosen for my prototype is a PIC32MX220. This is low to mid-end representative of this series but even so the specs are quite impressive. CPU clock up to 50MHz, one instruction per clock cycle, full-speed USB 2.0, 32kB flash, 8kB RAM and all of that in a SOIC28 package at a price of CHF 3.58 in single quantities.

20160426_StandaloneAnemometer_005

After having chosen a chip the next task was to come up with an actual design. I took my anemometer driver design and tried to integrated the new PIC32. That driver circuit had performed extraordinary well so I changed very little. I left away the RELEASE signal since my tests had shown it to be unnecessary. I also replaced the LM5111-1M mosfet drivers by LM5111-2M. The difference is that the 2M is inverting while the 1M is not. The reason for changing this is because the 2M is available at a significantly lower price of CHF 1.35 vs CHF 2.25. Not a big deal if you just build a single prototype but I thought it might be smart to change this anyway. This also required some resistors to be changed from pull-downs to pull-ups. Except these details everything stayed the same with the drive circuit.

20160426_StandaloneAnemometer_012

I also had to re-design the power supply since the PIC needs a 3.3 volt rail as opposed to 5 volts in the driver test circuit. Since I had to re-design it anyway I also downsized the power supply somewhat. I’ve otherwise resisted all temptations to use smaller components but the power supply was just a bit too big with the two  SOIC8 chips and four size C tantalum caps.

The prototype now uses an MCP1755 linear 3.3V regulator in a SOT23-5 package with a 33uF size B tantalum cap at its input and a 10uF 0805 size ceramic cap at the output. A TCM829  (also in a SOT23-5 package) and two more 10uF caps produce the -3.3 volts output. So there is a total of three supply rails: +12V, +3.3V and -3.3V.

20160426_StandaloneAnemometer_006

A major challenge was to make do with the very limited number of I/O pins on the PIC. 28 pins seem like a lot for the task at hand but plenty of them are already used for things like supply voltages and the like.

In the end I managed to still get three independent interfaces to the outside world: USB 2.0, I2C and SPI. All these interfaces as well as just about any other signal of interest is easily accessible from one of the numerous 100mil headers along the edges of the board.

20160426_StandaloneAnemometer_007

The amplifier still uses a LMC6482 dual op amp , now running on a+/- 3.3 volt supply. The first stage amplifies the ground-referenced input signal by a fixed factor (currently 11 but this might change). The output signal is then biased to 1.65 volts and amplified once again. This time the gain can be adjusted digitally via a MCP4561 I2C digipot.

20160426_StandaloneAnemometer_008

Before I forget: The PIC gets its system clock from a 8MHz crystal. That might seem low but there are two (variable)  PLLs inside the PIC that (together with a number of pre- and post-scalers) let us produce the 48Mhz signal needed for USB as well as a reasonable clock speed to run the CPU and peripheral bus on (probably also 48MHz but we’ll see).

20160426_StandaloneAnemometer_013

The board layout proved to be a bit tricky because there isn’t that much space on the board and I had quite clear ideas where I wanted certain headers to be. So I was more than happy when all the traces were finally laid out.

As you can see, the PCB is already milled and the vias soldered. I can’t wait to build this thing up and start to do some programming. That will be the topic of my next post.

20160426_StandaloneAnemometer_014

As always, a zip file with the eagle files and PDFs of the schematic and board layout can be found on the overivew page.

And here‘s the finished board.

Ultrasonic Anemometer Part 19: Testing the Analog Circuit

20160323_AnemometerAnalog_016

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.

20160323_AnemometerAnalog_015

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.

Rectifier_40kHz

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.

Rectifier_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

input_rectifier_zerocross

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.

PosPeak_PosGate

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

20160323_AnemometerAnalog_012

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.

20160323_AnemometerAnalog_014

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.

20160323_AnemometerAnalog_011

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.

It’s now ready, click here.

Ultrasonic Anemometer Part 18: Analog Signal Processing

20160320_AnemometerAnalog_001Recently, 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.

20160320_AnemometerAnalog_005

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.

20160320_AnemometerAnalog_003

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.

20160320_AnemometerAnalog_002

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.

20160320_AnemometerAnalog_008

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.

20160320_AnemometerAnalog_006

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.

20160320_AnemometerAnalog_007

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.

Ultrasonic Anemometer Part 17: Lasercut Mechanical Design

20160228_Projekte_133

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.

20160228_Projekte_110

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.

20160228_Projekte_102

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.

20160228_Projekte_099

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.

20160228_Projekte_132

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.

20160228_Projekte_109

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).

20160228_Projekte_130

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

20160228_Projekte_104

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.

20160228_Projekte_127

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.

20160228_Projekte_128

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.

20160228_Projekte_135

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.

20160228_Projekte_100

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.

20160228_Projekte_110

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

Ultrasonic Anemometer Part 16: Testing the new driver circuit

20160303_AnemometerDriver__007

Last time I’ve presented my new design for the ultrasonic anemometer driver circuit. So now it’s time to see how it performs. If you’re new to this project you might want to check out the overview page or at least my last post.

20160303_AnemometerDriver__002

By now I had the time to build up the board and to do some testing. My main struggle was with the power supply. The linear regulator LM2931 comes in both fixed and variable voltage configurations. Unfortunately there is absolutely no way to tell them apart from their markings. So I accidentially used the variable voltage variant resulting in an almost 12 volts output voltage blowing up half of my circuit. I later noticed that I was out of 5V parts alltogether and had to use a LM7805 in a TO-92 package as you can see from the photo below.

20160303_AnemometerDriver__006

After having fixed the blown-up components, the circuit worked quite well. The first thing I did was to write some basic software for the PIC16F1936 to output a burst of40kHz PWM pulses every 2 milliseconds. After every burst the Axis and Direction signals are changed so the transducers take their turns in a clockwise order (North-East-South-West-…). The screenshot below shows part of such a burst sent from the South transducer. Note that the signal is a precise 40kHz with a duty cycle of 50% as it should be.

BasicOutputTest_withMeasurement

Below you see a full burst of 10 pulses. The number of pulses to send will be something to optimize in software once the hardware is finalized.

SendingCloseup

From the following screenshot you can nicely see how the transducers are selected by means of the Axis and Direction signals.  The microcontroller always outputs its PWM burst from the same pin. All the signal routing is controlled by means of these two signals so there is not much of a software burdon.

SendingOverview

So sending pulses is easy and works well. But that’s the easy part. Now let’s see how the circuit performs in receiving and amplifying singals.

Below you see a complete send-receive cycle. A number of pulses is sent (red) and somewhat later received (yellow) and amplified (green). Notice the different scales. Despite being only slightly larger in amplitude on the screen, the ampified signal is about 15 times larger in amplitude. Remember from the last post that the gain is controlled by a pot so this is just a temporary setting.

The distance between the transducers is 230mm so the time delay should be roughly 700us. Looking at the screenshot below this seems to be the case.

SendReceiveCloseup

Note that I’m sending much more pulses this time and that there is a larger-than-usual gap after the 18th pulse. As mentioned, I’m still experimenting with how many pulses should be sent and how. Here I’ve sent 18 pulsed plus 7 more pulses 180 degrees out-of-phase. My hope was that the received signal will decrease more rapidly in amplitude after reaching its peak which would make the peak easier to identify. This is still work in progress but I think this might be a simple way to improve the reliability of this wind meter.

Below you see an overview over a round of measurements. Note how different transducers produce different patterns. There seems to be quite a bit of manufacturing spread between them even though they are presumably from the same production lot.SendReceiveOverview

Now let’s look at these signals in a bit more detail. There is a significant amount of noise present in the received signal but it seems to be largely gone after the amplifier stage. The amplifier is a single op amp with a DC-coupled input and a pot acting as resistive divider setting the gain. That’s about as simple as it gets. There are no filters or anything up to this point. But the output looks nice and clean.ReceiveAmpoutCloseup2

Here’s a close up making this even easier to see. There are narrow spikes present in at the input but the limited slew rate of the op amp seems to filter them all out. So the output is clean as a whistle without any filtering. Much better than expected. Wow.

ReceiveAmpoutCloseup

If you’ve read my last post you know that there is a second op amp which I intended to use for a active band pass filter. But there seems to be no need for that at all. Simplifies the circuit, saves an op amp as well as quite a bit of board space. Great.

Nevertheless you might have noticed that there is a wider and much larger spike in the received signal every time the axis and direction signals change. The cause of this is most likely charge injection through the p-cannel Mosfets that are used as switches between the Mosfet drivers and the transducer. ReceiveSpikeCloseup

Being much slower and wider than the noise we’ve looked at so far, this spike makes through the amplifier with only slight attenuation. The good thing is that this spike occurs when we switch from one transducer to the next. That’s a time when we won’t want to look at the received singal anyway. We haven’t even sent any pulses yet. The spike abates long before the received singal starts being of interest. So I’m confident that this spike causes no real harm and can savely be ignored.

20160303_AnemometerDriver__001

All in all I’m positively surprised how well this design has performed. I’m obviously getting a much stronger gate drive of 12 volts as opposed to 5 volts with my old design. And not only that. The Mosfet drivers used can source and sink several amps so there is reason to hope that the signal is not only larger in amplitude but also cleaner and more square. I’ll have to look at the shape of the wave form at the transducers in more detail to verify if this is really the case.

20160303_AnemometerDriver__003

But I’m most surprised of how well the simple op amp performs. Using this super-simple setup I’m getting an output signal that’s just as clean as what I got from the rather complex two-stage tuned common emitter amplifier. No need to tune this thing making it much more production friendly. And it saves plenty of board space as well.

20160303_AnemometerDriver__009

So this is the way to go I think. The next step will be to come up with some circuitry to process the received and amplified signal. I have some ideas in my mind and will elaborate on them shortly. But first I’ll take a closer look at the new lasercut mechanical design.