Antiath
commented
4 years ago I sure didn't expect to be notified out of nowhere about this subject. So...about my part. First of all, my version of this project is, as of today, still unfinished. I got together a prototype on perfboard that was kind of working. A lot of work and multiple revisions had already been done. I decided to tanslate this prototype on a proper pcb but those pcb didn't work and destroyed a bunch of pricey components. I got extremely frustrated and stopped working on it. I do plan on getting back to it (the device is actually just beside me right now) when motivation and time are available.
Now for what I can contribute on this, here are a few things I can mention:
1) My design is heavily inspired by Lukas's and carl's versions. It's a mix of both with my own tweaks. But as the pcb files are clearly no good, there is no point in sharing my schematics. Sorry.
2) This is a crucial point : I use fully enclosed waterproof transceivers similar to these ( in shape only, not necessarly in performance): https://im01.itaiwantrade.com/b6707fc1-c8f0-43e2-8f2c-90ac3ec62dbf/sensor_40CA-18S-2_thumb_630_447-480x480.jpg I think this is important because those things will go outside and they have to survive even in nasty conditions ( like heavy wind and heavy rain). Hardy Lau also used similar ones. This way, I get signals that are way way lower in amplitude compared to the kind of open transceivers used in the HC-SRO4. It is still manageable but this means I need to crank up as much as possible the amplitude of the signal I send . And also I need to put extra care on the amplifier on the receiving end. Fortunatly for us, we deal with onely one frequency (40khz) so it is not impossible to extract from a noisy signal.
3) You are right, I did decide to use a Teensy 3.6 in the end. It can be programmed using the arduino environment (altough it needs special C code for the square signal generation, the kind of thing you won't find in arduino libraries or on the arduino forums) and it is blasing fast for a microcontroller ( and now the teensy 4 is even faster). That or Lukas's pic32 give plenty of margin to be able to do some math without slowing the whole system down. And, most importantly, they can actually output 40khz square signals without issues. The arduino can barely do it on it's own and most importantly it just can't sample the received signals fast enough with its slow adc.
4) The phase detection part is hard. Very hard. For a lot of tricky reasons. The working prototype I have( the one on perf board) is using Lukas' method of detection. I fiirst detect the actual packet with the treshold method. Then I detect the zero crossings of each 40 khz oscillations and I use those to trigger the adc to do a sample of the received ( amplified) signal on the maximums and minimums of the packet ( so at least one sample at every 40 khz oscillation, on the high and low peaks). This gives me a very rough measure of the shape of the packet. To mesure the phase, you have two options:
-you try and find the maximum of the whole packet, wich may not be the highest peak, it is probably somewhere in between two oscillations. So anywhere in a 25 µs span... Not very good... the peaks of those oscillation almost form a parabola so you can try to calculate the position of the maximum of this parabola with a bit of math ( method described in chapter 2.1 of this article: https://www.imeko.org/publications/wc-2006/PWC-2006-TC4-028u.pdf) That would be nice if the packet wan't so spread out. Around the maximum, the peaks are so close to each other in amplitude that it becomes hard to and questionnable to do this calculation. Add to this the fact that this is the real world. So you have noise messing with those amplitudes.
-you can try Lukas's way and do what is called a cross correlation of the packet with an packet measured at zero wind ( the values ar stored in memory) . This is a bit more math involved as you calculate an integral but in theory, it is more precise as you take the shape of the whole packect into account. I won't go into the details here, this is a bit too complicated for this kind of post. -----> In the end, both methods give pretty much the same results because there is just too much noise to tell them apart. It is still usable with a LOT of average over as much packets as possible ( right now, my version i averaing over 2 or 3 seconds and I send a packet every 1.5 ms or so.). My prototype still has weird quirks and glitches that I didn't manage to resolve but it can measure wind speed that make sense ( tested with a big fan blowing over the apparatus and calibrated with a cheap handheld anemometer) and directions. To resolve a lot of issues, like you suggested, it may be important to use faster transceivers ( like 80 kHz or higher). They could give cleaner packets that are less spread out. It could allow easier measurement of the maximum. I know that commercial anemometers similar to what we are doing are using such ultrasonic cells. But this also means faster electronic, so more cost and more complexity. Also, they drive at something like 100 V peak to peak. I'm not going over 12V p-p.
5) Another issue is impedance matching. Right now , my version has no method of matching the impedance of the transceivers and I don't recall Lukas and Carl talking about that. Hardy Lau did mention it but he has access to the expensive tech ( that vector network analyzer) needed to do that kind tweaking. But in theory, this would allow to drive the tranceivers in a more suitable way so that the ultrasonic packets ar sharper, cleaner with less spread.
Finally, as I already mentioned, Signal to noise ratio is an issue for me. But if people could assure me that open transceivers can be used outside without risking to destroy them as soon as it rains, I sure would like to use them.
SO... as you can see, there is a LOT to talk and think about.
As i understand, you want to simplify the device by using the HC-SRO4 as the driver and deal yourself with only the analog receiver part. If we forget about the open cells, it may be a good idea actually. Just verify that the driver is consistent ( meaning that it always need the same amount of time to send a packet when you trigger it with the arduino) . If not, it will be tricky.
Whatever you decide to do, I bid you good luck because this is not an easy project to make at low cost.
jaka87
The plan is to create cheap ultrasonic anemometer with good stability in all weather conditions and reasonable accuracy around 1 m/s or less.
Unfortunately my knowledge in this area is lacking but Im slowly learning and i hope that one day we will have working product. The principle is quite simple. Transmitter sends ultrasonic signal to receiver which measure time it took for this process. I first tried to use HC-SRO4 ultrasonic arduino module
which is cheap an aveliable. I did some measurements and got accuracy of 1%. I thought this will be enough until i did some calculations. As it turns out i would need repeatability of less than 1 us but in reality my results were +- 5 us. Then I came up with neet idea to make 100 measurements, order it by time and use only 40-50 on that list to calculate average. That did improve results but not near enough for needed accuracy.
I found out that HC-SRO4 transmitter uses 40KHz and has amplitude of 25us and that this is just not enough to accurately measure time of flight - "tof". I search online and find couple of similar projects. I read them many times since its difficult topic for me. My knowledge did improve but im still not certain that i understand it well enough. The most important part of the design is analog component that amplifys signal detect envelope and phase changes. Counting phase changes should give much more repeatable results.
There are three projects aveliable online
I also find some simple design but im not sure if it worked well http://n1qq.com/blog/2015/ultrasonic-anemometer-part-1/ there is also one on easyeda (site that im familiar and know how to use) https://easyeda.com/AndySmithersHome/ultrasonic-anenometer but once again i dont know how well it worked. I send msg to the author but unfortunately did not get response. Here is also interesting link with calculations http://trekker.customer.netspace.net.au/wind.htm im interested in 3 transducer type.
The on from Lucas probably has the best documentation and is also one of the latest, but it uses pic32 microcontroler that im not familiar with at all. I would rather use arduino compatible MCU. There is user @Antiath that commented on Lukas blog quite a lot and from what i understand build the project using teensy 3.6 which is arduino compatible. Unfortunately i couldn't reach that user aswell.
My plan is to first make analog component with one sensor as receiver and using the HC-SRO4 as transmitter. Im planing to replicate analog part from Lukas and from Andy and then compare them. For now I would use simple ATmega328 just to try out but migh change it for more capable arduino compatible MCU or even PIC32.
The design of the anemometer is yet to be determinated but im thinking of using the one with bouncing beam from flat surface since most comercial anemometer system use them
I also have one broken ultrasonic anemometer from WeatherFlow. Im pasting PCB if it may be useful to somebody. Let me know if you want any details about it.