Difference between revisions of "GSoC2017 sonic anemometer proposal"

From eLinux.org
Jump to: navigation, search
(Error Analysis)
(add quote)
Line 251: Line 251:
  ''Great project for the Aspiring Weather Scientist.''
  ''Great project for the Aspiring Weather Scientist.''
                             Michael Welling('''m_w''')  
                             Michael Welling('''m_w''')  
''A working/documented FOSS implementation would be a huge''
''plus for both the open source and weather communities.''
                                Steve Arnold('''nerdboy''')
  ***'''''Mentors!!! please add your Quote here.'''''***
  ***'''''Mentors!!! please add your Quote here.'''''***

Revision as of 11:49, 31 March 2017

Proposal for Sonic Anemometer

Write program for PRU present in BeagleBoard and to create a portable device able to measure the wind speed and temperature reliably in outdoor environments.It delivers the result by analyzing the time of flight or phase difference of sound waves between two points, deliver the final results in terms of ambient Temperature,Wind speed and direction.

Idea as Quoted from GSoC Ideas page:

Working prototype sonic anemometer using BeagleBone, PRUDAQ, and ultrasonic sensors. Analyze methods for accuracy/sensitivity 
(eg, time-of-flight vs. phase difference) and implement "best" method. Use PRUs for independent real-time control of ultrasonics.

Student: Naveen Saini

Mentors: Steve Arnold(nerdboy), Stephanie Lockwood-Childs

Code: N/A

Wiki: http://elinux.org/GSoC2017_sonic_anemometer_proposal



The proposal for Sonic Anemometer was accepted in GSoC 2016, but the chosen ADC(Analog to Digital Converter), THS1206, proved to be inefficient for sampling at high frequency and hard to create a trigger for generating Ultrasonic pulse.This year ADC is proposed to be PRUDAQ,hence most of the code developed last year is not useful now and also the final arrangement implemented for only one axis remained untested.


I have completed the task required as described on Ideas page, and created a pull request, as listed here.

About Me

GitHub: @thetransformerr

IRC: thetransformerr

elinux: thrtransformerr

Linkedin: Naveen Saini

School: JECRC,Jaipur

Country: India[The mystical wonderland ;)]

Primary language: English,Hindi

Typical work hours: 08AM-10AM , 09PM-01AM Indian Standard Time(+5:30)

GSoC participation: I haven't participated before.One of the most important reason to be part of this event is to create a project that I can be proud of and could mark it as special achievement in resume in bold letters.Secondly I am greatly interested in field of Machine learning and Big Data, which are going to have a great future with IOT.I want to develop a smart system to control and perform various task related to home and have successfully used Arduino for various applications like controlling electrical appliances,ambient lighting system.Finally to make our world more open source and much better.

Skills(proficient): C,Ruby,Javascript

Experience: Java,Python,Arduino,Node.js,Scala,Matlab,CAD.

Sonic Anemometer

Anemometer, derived from greek word anemos(wind), is a device used for measuring the wind speed.While the first known description, we encounter dates far back to 1450, the widely used, cup anemometer was created in 1845 by Dr.John Thomas and hasn't changed much since then in its fundamental concept. Since the cup anemometer consist of mechanical moving parts, it is adversely affected by various environmental factors like salty air or dust.To counter these affects, a better alternative was developed known as, Sonic Anemometers, and it uses ultrasonic sound waves to measure wind velocity.

Principle of Sonic Anemometer:

The basic principle used in sonic anemometer is that when the wind flows in the same direction as sound, the velocity of sound increases and when is in opposite direction, the velocity gets reduced accordingly.Therefore along a axis two transducers are placed and Time of Flight is calculated in both directions as explained by equations. This pair of transducers act alternately as transmitters and receivers, exchanging high-frequency ultrasound pulses between themselves. The times of flight in each direction t1 and t2, are measured. If c is the speed of sound in air, and L ,is the distance between the transducers and there is an airflow of velocity v along the line of the transducers, the following relationship is readily derived:

t1 and t2 calculation

By combining Eqns (1) and (2) and solving for ` v`, the following equation is obtained:

t1 and t2 calculation

Above calculations were only for one axis, but we can add more axis making devices 2D or 3D anemometer.This proposal, aims first for 2D sonic anemometer, which measures the time taken for an ultrasonic pulse of sound to travel from the North transducer to the South transducer, and compares it with the time for a pulse to travel from S to N transducer. Likewise times are compared between West and East, and East and West transducers.

2D axis(to be aligned with compass to true north)
3D axis(for reference)

The projected horizontal wind vector,`u `,specified by its magnitude in m/s and direction in degrees (0° is the direction of the north, the angle was counted positively in an easterly direction and negatively in a westerly direction) Now following Equations are involved here,

u calculation

Now from above equations it is clear that speed of sound calculated this way is independent of factors such as temperatures.

Now with this device we can calculate the wind speed as well as temperature as described below-

Temperature(virtual temperature)

here R is the universal gas constant (8314.34 mJ/mol K), C is speed of sound, M is the molecular weight (grams/mol) of the gas, and γ is the ratio of heat capacities Cp and Cv; Cp and Cv are the specific heats at constant pressure and constant volume of the gas, respectively.

The sonic temperature, Tv (in Kelvin), may differ from the absolute temperature by an amount equal to the water vapor content in the air measured. This difference amounts to ±1°C at 20°C and decreases as the temperature decreases.


DAQ are the Data Acquisition devices which are used to acquire data from sensors and acts as a bridge between sensors and host computer.

PRUDAQ is a fully open source 40MSPS Data Acquisition (DAQ) cape for the BeagleBone Black or Green designed by Jason Holt and his team at Google Research with a software collaboration from the BeagleLogic creator, Kumar Abhishek(one of the mentors this year).PRUDAQ was created to address a need not currently addressed by the market for a portable and low-cost DAQ system that doesn't compromise on performance.

Since linux is a non-preemptive Operating system,which means it can't be used for realtime measurements we would be using the PRU(Programmable Real-time Unit), for realtime measurements, they are inbuilt and pretty much powerful for our task.PRU is like a typical microcontroller, small memory, small processor.

They are programmed with assembly instructions and hence can be customised as per our Requirements, and can transfer information with User-Space programs and hence we would be using the Two PRU in beagle, one for ADC and I don't have actually any plans for Second PRU, because as far as impression I got by going through various documentation, I understand that only first one is enough and by saying this, I am open to all suggestions. We can probably use second one for calibration and other tasks.

Requirement Analysis

Following table depicts the effects of temperature and humidity on sound speed (In the region between the air pressures 95 and 104 kPa there is no noticeable changing of the speed of sound, change is in order of 10-3order)

Temperature and Humidity effects

Following graphs represents deviations of speed of sound :

Temprature and Humidity Deviation
Pressure variation

At draft level, let us assume final resultant device provides results at rate of 20 Hz, then we have 50 ms roughly to pipeline the data acquired from ADC and process it to receive temperature and wind velocity.

PRU in Beaglebone has rate of 200 MHz, hence instruction cycle of 5ns, following table shows approximate cycle required for various assembly code operations,

Instruction Cycles

Then, considering transducers of 40kHz, we proceed our requirement analysis with two sampling rates, 400k and 200k samples per second, although nyquist rate requires just double of highest frequency, but that is not useful as we aren't sure about highest frequency in our sample, due to noise and other reasons, hence a rate of ten times is recommended for ADC purpose.

Following table shows some observations

Some raw observations

Different Suitable DAQ

Some DAQ cost and capacity

And this graph shows attenuation of waves according to their frequency, generally, higher the frequency, earlier it attenuates,

Attenuation Characteristics of Sound Pressure by Distance

Hence following are the hardware that we can start with:-

  • Beaglebone Black/Green(1)
  • PRUDAQ/ADC having rate higher than 400ksps per channel(1/2)
  • Transducers(40kHz,Waterproof)(4)

Min. Time required before new set measurement:

A gap of about 35 ns is required with round robin arrangement in PRUDAQ, for calculation, we assume it to be 50 ns, then we have to wait for atleast 0.8 microsecond for wave to travel one end to another, and then considering delay in executing PRU assembly codes ranging from one instruction cycle to even 46 instruction cycles, we take average overhead 3microseconds, hence total time for one set till PRU is (2.5+5+890)×2=1795 𝜇s or 1.795 ms.

Pin Diagram
Data Acquisition Cycles

Hence we can assume approx time between trigger for new set of values about 4-8 milliseconds.As we have assumed initially device to provide refresh rate of 20Hz i.e. 50 milliseconds, the time we calculated here is much less, hence there is scope for increase in refresh rate but before that we should take into calculation other real world problems around PRU and user space.

Error Analysis

Following are the equations defined in thermodynamics for values calculated from the data:

c2 =403T(1+0.32e/p)

where c is the velocity of sound (m s-1) in air, T is the temperature (K), and e and p are respectively the vapor pressure of water in air and absolute pressure. The humidity effect on the measured sonic temperature,

Ts [= T(1 + 0.32 e/p)]

resembles very closely the virtual temperature Tv defined by meteorologists as the temperature at which dry air has the same density as moist air at the same pressure:

Tv =T(1+0.38e/p)

Clearly, Ts more closely approximates Tv than it does T, the error being on the order of ±0.01°C in assuming T′ =Tv′(virtual), compared to ±0.05°C for T′ =T′(absolute). Since virtual temperature is used sometimes in boundary layer calculations, we can safely assume sonic temperature as virtual temperature within safe experimental assumptions.

u calculation
t1 and t2 calculation

According to above formulas, the we are providing length and time duration, and resolution for time is very high and the length using can have resolution of 1mm considering the apparatus involved, therefore we can have resolution of wind speed in order of 10-2ms-1.


I would be having my semester finals from 26 april to 10 may, and after that I can commit myself fully for this project.As per the GSoC timeline, coding period starts from 30 may, though I plan to gather and go through all documentations and book like "Exploring BeagleBoard" by "Derek Molloy" from 15 may and following is the proposed timeline and milestones by me

This program is of 12 Weeks-With Evaluation phase on June 26 - 30, 2017 and July 24 - 28, 2017

First Week:

Get acquainted with Beagle GPIO,PRU, PRUDAQ, and gather all other related Open Source works that can be utilised for our project like Beagle Logic, GSoC 2016 portions of reusable codes.Taking valuable suggestions from others who have implemented this project already on other boards.

Second Week:

Connect the Prudaq and take sample readings as described on their wiki example. As far as I have knowledge by now, we are able to take samples at high rate using the Beagle Logic for PRUDAQ, and as it was pointed out in the final report of GSoC, the major obstacle he faced was the inability of PRU to control the BeagleBone mux

Third Week:

Program the PRU to read the sample results from PRUDAQ and trigger successive generation of two axis sonic transducers.

Fourth Week:

Make the PRU able to streaming the data to User Space from PRU memory and make a user space program to store this results into a possibly text file and create related testing units.

Evaluation Goals 1:
The device is able to stream the results of successive measurements after every specified interval to
the user space and it is stored into text file.Software Testing Units are created for possible errors.

Fifth Week:

This week we will build the structure as portable, possibly as described in below pictures.

PVC for easy and flexible implementation
Made of Copper and steel to heat during Cold

Sixth Week:

Testing the above apparatus into a wind tunnel (if accessible in my university) and outdoors and Finetuning the discrepancies and calibrating the device structure and distance between transducers.

Seventh Week:

Making corrections for delays incurred between triggering of measurement and the final velocity of a axis and then the correction for factors that may affect the pipeline and creating test units.

Eighth Week:

Making the final model of hardware to be used in this anemometer , depending upon the the reliability and Quality of delivery by various accessories like transducers or if other arrangements are required like power sources, supplies etc.

Evaluation Goals 2:
Apparatus is tested extensively for outdoors, and is able to perform functional tasks in various possible 
conditions and output reliable data with accuracy and have test units defined but other factors like azimuth angle 
or other correction algorithms would be  applied in the next stage.

Ninth Week:

Processing the stream on the fly to produce final results, into text File created into user space that can be uploaded or monitored real time,if possible(currently I am unaware with this capability as I don't have any idea how much latency may it create between the final result and first detection).

Tenth Week:

Build arrangements for calibration creating a setup script, to define true north direction, magnetic declination and make calibration possible easily by just filling the address or (long, lat). Other modifications like variable sampling frequency in case if required later by developers.

Eleventh Week:

Review all the test units created earlier during program and modify them or build new.

Final Week:

Create a REST API sort of thing that enables the reading and logging of results into remote machines and proof check all modules

Final Goals:

A 2D/3D sonic anemometer able to calculate and project the wind speed and its angle, Temperature of its surroundings,having calibrated for all its measuring positions and providing results after the required corrections suggested by research papers.Ready to be deployed in field experiments.

Future/Additional Goals:

When all above goals are achieved at commercial level during the program or at conclusion of program, we work to add third axis, z and create the required modifications.

Other Goals that can be helped or created by us or other open source contributors

1. Make A python script type to create the graph and other possible representations of the data processed.

2.The Temperature reported here,have a factor of relative humidity, hence the device is expected to deliver the temperature accurate in case of dry environment mostly where as for humid environments, a separate device reporting humidity in realtime is required. Therefore support for other measurements like Humidity,Magnetometer, IMU that can be sampled realtime and improve and increases the utility of this anemometer as portable weather station.

Experience and Approach

As part of my graduation program of Computer Science Engineering at bachelor level, I am already familiar and aware of almost all the concepts and technology used in this project.The Physics used here was present in our curriculum.Also we got a hands-on experience with microprocessor 8085, and I have developed a project with Arduino to control electrical appliance using relays and created other project for Ambient lighting system.

As the most fundamental part for being a CS engineer, I have learnt "C" language and I usually program with Ruby but is also familiar with python.I have also learnt Node.js as a javascript and have knowledge of other web technologies like CSS,HTML,Bootstrapping, Ruby on Rails and have earned certificate from Coursera.These all technologies are useful for the part of developing User interface of Anemometer and implement of REST API.


  • Smart Switch: Used Arduino,Relay and ESP8266 to create a wifi controlled switch for electrical appliances.It was helpful to On or Off appliances like geysers, water pumps, whenever required and could also be scheduled.Planning to integrate this with other applications like Digital assistant , voice recognition.
  • Chat window: Implemented with Node.js as server I created this project to connect visitors with the website directly to ask their queries, and this application could be connected with various API like firebase to keep storage of Chat Records and customer interactions.
  • Sentiment Analyser: Working currently at this project as an intern in organisation Celebal Corp, this project aims to find the sentiment of the user message with help of various machine learning tools and techniques like NB Classifer, SVM, TF-IDF et.


  • Participated in Workshop by IBM, on "Big Data and Analytics", and created a application on Bluemix platform, that can extract the information from trending topics on twitter.
  • Participated on National level, in TopCoder Open Finals organised by TopCoder.


During the duration of GSoC, I won't be having any academic activities hence my whole time could be devoted in completing this project.I would work, minimum of 40 hours per week, and would surely give more time due to great interest of mine, in the knowledge that I would be gaining from this project.I believe in principle of bootstrapping, i.e. rather than acquiring the whole concept theoretically at once, I start with a small practical application and then further keep progressing with that small concept to create a better and efficient application.

Hence rather than aiming for final version of device initially, I would like to create first a rough prototype and then keep refining it until we reach the quality, that we had expected from the proposal.To gain the required knowledge I have started reading various research papers published in this field, and a book on beagle bone.The book which I am currently planning is "Exploring BeagleBone" by "Derek Molloy".You can also suggest me any other sources from which I can knowledge about this field.

Finally,the reason I believe(some bragging about me :)), for which I should be chosen ,is my deep interest and love with Computer Systems, I can spend happily my all nights awake with them, but only when I am on project and on many occasions I have learnt all new technology, to create a project that interested me, way before the timeline prescribed it to be complete.I am at ease with all new concepts and love to learn them.


As I described above, all these concepts are covered in my curriculum, therefore in case I can't reach mentors in some case, I can refer and take help from my college faculty and also can use Labs for experiments related to ADC, and lastly there is our programmer's friend StackExchange, filled with many experts happy to help on any issue.Also I can refer to the research papers and Google Search.


Considering the costs of commercial products available at this time in market, this open source project would provide a very useful and reliable anemometer to help universities and students/hobbyists during their meteorological research by providing them results in real time and format that can be further processed by user using languages like python etc.

What community members speak -

Great project for the Aspiring Weather Scientist.
                            Michael Welling(m_w) 
A working/documented FOSS implementation would be a huge
plus for both the open source and weather communities.
                               Steve Arnold(nerdboy) 
***Mentors!!! please add your Quote here.***


Nothing For Now...