Ultrasonic Anemometer Part 30: Downsized Hardware

In my last post of this series I’ve looked at different transducers and finally decided on a entirely waterproof 14mm model. The much lower signal level from those kind of transducers makes it  necessary to reduce the distance between the transducers in order to still receive a reasonable signal amplitude.
So I took my previous lasercut design and reduced it in size so that the distance between the transducers is only 120mm. I went to the local FabLab and and lasered two copies of the downsized design.

Since the new transducers are only 14mm in diameter but those plastic pipes are only available in 16mm I had to pad the transducers with short sections of aluminium tube with an outer and inner diameter of 16 and 14mm, respectively.
I previsously connected the wind meter to an Arduino with a LCD display to test the I2C functionality as well as to read the wind speed and direction without having to connect the anemometer to a PC. Now I have used my I2C user interface for that purpose. It is powered from the wind meter’s 3.3 volt rail and is controlled via I2C including the backlight brightness and display reset. The user interface usually also includes a rotary encoder with push-button not present in this application.

In an attempt to boost signal amplitude I’ve also changed the first stage op amp’s gain from 11 to 31 by replacing the 10k resistor with a 30k one. I’ve argued in my last post that this is probably about as far as you can safely push it.
Even with the lowered transducer distance and increased gain the signal amplitude after the first stage is less than impressive. But we knew that already. And we have a second variable-gain stage at our disposal. Setting the second stage’s gain sufficiently high we hopefully get the 3 volts peak-to-peak amplitude we are aiming for.

By the way, I’ll started from scratch with the firmware. The reason for that is mainly USB. Currently, the anemometer acts as a HID device. While working on my solar charger I started to play around with HID / MSD (human interface device / mass storage device) composite devices. They still act as HIDs with all the functionality just like before. But when you plug it into a PC it also enumerates as a mass storage device, i.e. it behaves just like a memory stick. You can read and write the files on it from any computer, irrespective of the operating system and without needing any particular softwar or driver installed. So you can put all the configuration parameters in a text file that resides on what looks like a memory stick. I guess that’s the most user friendly way of dealing with those user-specific configuration parameters. Just plug it in, open a text file, change what you need, save the file and you’re done. This is how the solar charger will operate and  I’ve decided to implement the same here.
Microchip’s Harmony library includes all that functionality so I have no doubt it’s doable. But I’ve figured that it’s likely easier to do this as a new project and then add the previously implemented functionality step-by-step.

And then there’s another USB-related feature that I had in mind right from the start but which I haven’t event started to implement so far: A USB boot loader. That would enable people to do a firmware update without needing a in-circuit programmer such as the PICKit 3. Users could just download a new HEX file and upgrade the firmware without needing any special hardware or even skills.
USB boot loaders come in various flavours. The Harmony library includes support for an HID boot loader. But that’s not really ideal if you ask me. It means that you need to run some software on your PC that communicates with the anemometer and sends the new firmware via USB. The need for software means that it matters what kind of operating system you run. And needing additional software is undesirable in the first place.

There are also MSD bootloaders which do not have all those downsides. The device acts as a memory stick to the PC. The user then just copies the HEX file to that memory stick and that’s it. Just drag-and-drop, no extra software, no matter what OS.

The problem is that the Harmony library does not support that out of the box. Indeed, Microchip doesn’t seem to have implemented that for any of their chips. That’s kind of strange because other chip manufacturers have done so long time since. There is at least one implementation for PICs out there in the web but I haven’t looked at it yet because the website it was hosted on no longer exists it seems. Probably I’ll have to implement this myself but the Harmony support for MSD will hopefully do much of the heavy lifting.

So that’s the plan. Implement a bootloader, preferably of the MSD variety. And then run the anemometer appliction as a HID/MSD composite device. You may say that I set the wrong priorities given the fact that the actual measuring is not yet as good as it needs to be. But this kind of fundamental architecture is easier to get right from the very beginning. So that’s why.
If you’re interested in this lasercut design you can find iton github.com or more precisely on https://github.com/soldernerd/AnemometerLasercut. This version is called Anemometer_03.scad and the PDF that was used for the actual laser cutting is Anemometer_03.pdf.

20 thoughts on “Ultrasonic Anemometer Part 30: Downsized Hardware”

  1. As always, really happy to hear from you with your amazing progress about this project! Your methodic and precise evaluations (and resolutions) to the issues are impressive.
    Still amazed by your analog/digital (uController) closed-loop approach.

    Question: Have you ever considered using car bumper style sensors (Parking Assist Sensors)?
    They sometimes come with their own circuitry, which may be of use here.
    Car sensors are very rugged, have quite a large range, und must work under a variety of enviroments.

    http://www.al-eds.com/Rydeen-Mobile-BF450PM-p27414.html
    http://www.autopartswarehouse.com/parking_assist_sensor~pop.html

    Thank you also for reducing size, that is always desirable.

    And another question, would it be possible to “talk” to your Anemometer via simple serial? For those of us who would LOVE to integrate your excellent unit, this would be much more desirable than going to USB (and back). Most of us have some sord of microcontroller available, and they all talk (TTL or 3.3V) serial natively.

    Thank you, Lukas!!

    1. Hi Jimmy

      What precisely do you mean by serial? Serial as in USART / RS232 serial port? For a simple connection to another micro I’d suggest SPI which is available on the anemometer board. I find SPI a much simpler and straight forward protocol than USART. An explicit clock and no plus/minus 12V signals.

      Lukas

    1. Hi Jimmy

      Thank you for the links and the useful suggestion. I’ll need to check if this kind of transducers is similarly ubiquitous here in europe. I haven’t seen any on mouser or farnell but maybe I’ll have more luck on ebay…

  2. Hi Lukas,
    Excellent, as always.
    Do u have kits available?
    I offer myself as hard tester (sailing) and developer.
    Regards,

      1. Hello and great work Lukas!
        I am interested in your kit. Please let me know how best to proceed. How to contact you for order?

  3. Hi Lukas
    I’m interested in building one, too. Please contact me via email, thanks!
    Jimmy

  4. Hi Lukas!
    Congrats on the great work and thanks for sharing it!

    Minimising the transducers distance is good way to solve the signal level issue with the waterproof sensors.
    But does going down to 100-120 mm affect the measurement quality?
    At high wind speeds the opposite sensor can be in the lee of the first one.
    Not sure about the size/form of the created vortex as well but probably it may affect the measurement as well.
    Most of the commercial units doesn’t go under 16-18 cm as far as I can get from the pictures/proportions. And they do have a very thin and streamlined sensor housing.

    This one for example:
    http://gillinstruments.com/data/datasheets/1390-0030%20Iss%203%20WindObserver%20II.%20270217pdf.pdf

    Cheers,
    Stavel

    1. Hi Stavel
      Minimizing distance definitely comes at the price of distorting/hindering the air flow. However, this should be something that can be corrected for in software I hope. I think once calibrated this can be fixed by scaling the readings by a factor depending on the direction of wind.
      Lukas

  5. Hi Lukas,
    Nice job! Do you think in the future I can get a working one version to use as data-logger inside a cave?

    Thanks Andrea

    1. Hi Andrea
      I haven’t worked on that project for a while I must admit. While it’s relatively easy to get it to work once, it is surprisingly difficult to make it work reliably every single time. So it’s still really for people who want to get their hands dirty and try their own software tweaks.

  6. Hi Lukas,

    Great job on this project.

    I’m here with a question or two.

    So, I am working on the same project, and I have a little problem with the cross talk on the 4052 MUX. Once the sensors switch, they are hughely infected with the PWM signal. I would like to use only one or maybe two of them if needed, but I cannot get them to work properly. I tried setting 2 sensors on 1 mux and other 2 on the other, so that when a sensors on MUX1 TX, the opposite sensors is located on the MUX2 for RX and etc. Do you think this could work? Cause I was trying little experiments today and I could not get rid of that strong pwm signal anyway…
    I saw couple projects online where people used only 1 MUX, and I was thinking maybe you came across the same issue and could spare a minute to give me an advice on that ?

    best wishes!

    1. The original design by Carl (I’ve referenced him in the first or one of the first posts of this series) used 3 mux in order to elliminate cross-talk. That’s one way of dealing with the issue.

      My approach more relies on the fact that whenever we switch sensors or send a PWM signal, we don’t care about the received signal at all. We select a sensor, send the PWM signal, wait a little bit until the sound waves had a chance to reach the opposite sensors and only then we start to care about the received signal. That delay is only in the hundreds of microseconds but it’s long enough to safely ingore that cross-talk issue…

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.