weekly report-4: Sonic Anemometer

What I have done:

  • figured out algorithm to find out delay once tx and rx waveform is received, by using correlation.This was the one of main challenges of this project, and with this algorithm, we can find delay in case of noisy signal too.Although it might be improved further also, but that we are going to do at later stage

  • almost completed a program that can start eHRPWM to generate 40kHz wave and load PRU binaries that would read samples from PRUDAQ
    To be done:

  • tweak above program to work for two dimensions of wind velocity

  • create a circuit to interface sensors with beagle bone black board, first with simple rx and tx pair, until I receive maxq sonic board

I used numpy library to perform required calculations.

  • performed normalisation as following:
    mean = np.mean(tx)
    norm_tx=tx-mean
    norm_rx=rx-mean

  • then performed correlation b/w them using following function:
    res_corr=np.correlation(norm_tx,norm_rx,‘same’)

  • the length of norm_tx,norm_rx,res_corr are:
    len(norm_tx),len(norm_rx),len(res_corr)=2048

  • and argmax(res_corr)=1038

  • and therefore delay is:
    delay=argmax(res_corr)-(round(len(norm_tx)/2))

=14

Here 14 consists of 14 time unit, which if sampling rate is 5MHz, then is 1 unit=2x10^-7s .

Please provide your valuable suggestions or if I missed anything.I have attached the simulated wave forms that I performed my experiment, they have calculations in them, annotated with red rectangle where first line denotes the length of each sample file.

original rx and tx delay.png

chopped rx and tx.png

demo for delay algo.png

WEEKLY REPORT 5

  • I have created program to sample input, output for two channels and a temp sensors in round robin manner

  • created program to receive and process samples for time of delay
    Next thing to do:

  • Arrange a sensor for temp. measurement

  • assemble sensor for temp and sound waves and prudaq and check out the program consistency

WEEKLY REPORT 6

  • Have created and pushed PRU0 assembly code for generating clock required for sampling and to round robin the channel inputs

  • Have created and pushed PRU1 assembly code to add other two new channels in ring pointer transferring data to host program

  • edited round robin.c file to store six sample values and reboot PWM module after every 4000 loops
    Next thing:

  • To test above changes and make them work, since kernel structure has changed than from the time they were created in their src repository

  • Make another arrangement to perform above functions as Stephen asked me to do, by using last year code developed in beagle-sonic-anemometer GSoC project

If the changes I pushed to repo today, starts to work, than the major thing to encounter would be just hardware interfacing, which involves some digital electronics and circuits knowledge, and then some nice method to use sampled data, currently we are using method from last year, that uses a library zeroMq, it is an low level API that transfers data using sockets principle, but in last year method it required us to use two instances of shell.

Once we create a program to process raw sample data to find TOF and temp, I would start testing and debugging these set of program.

This might take only a week or two at max, then we work on enhancing other aspects, like accuracy and sensitivity etc.

Weekly Report 7

  • created a python program to process the temp and sampled wave-forms from PRUdAQ to find time of flight, ultimately the wind speed.
  • configured setup.sh to enable PWM module, and nerdboy figured out workaround for requirement of uio_pruss which was deprecated and disabled in ti kernel images in favour of remote-proc method.

To be Done:

  • test the programs for tx and rx part
  • implement a micro-server like flask to provide calculated results i.e. wind speed and other data like temp
  • test the accuracy of algorithm and method for determining TOF and then calculation of wind speed
  • a slight hiccup: I wanted to know how to share internet connection from mac to beaglebone black wireless, I tried from settings option to share internet to other ports but that messed up with DHCP and disrupted the SSH connection and iptables command is not available in mac

In windows , I was able to share internet but git is always unable to fetch files, hence I can’t execute any apt-get command or update-script

Any suggestions are welcome regarding the transfer of sampled data from C program to python program, currently we are relying on last year GSOC method using ZMQ library, it creates tcp connection ports that can be used to transfer data but I feel they are not reliable in maintaning the sequence of sampled data, and this can introduce serious errors in calculation as for ex. tx samples gets appended into rx waveform.

Thanks!
Naveen Saini

Weekly Report 8

  • Completed the code required for single axis sample analysis, once debugged completely it would be very easy to extend for two axis, the goal we have to achieve

  • Testing the code with hardwares using scope and other sensors like temp sensor and hc-sr04
    To be Done:

  • extend code for two axis sampling,

  • check out the efficiency with diff type of temp sensors like lm-35 and dot

  • accuracy of wind speed

Weekly Report 9

  • completed code for multi axis sample analysis
  • fixed the setup script for setting up pwm module in different versions of kernel
  • fixed some bugs during calculation of Time of flight
  • checked out hardwares and circuit set-up

To be done:

  • create a interfacing setup and portable experiment version of anemometer
  • refine the flow of data sampling and result
  • create user interface to set up freq and other parameters

Weekly report 10:

What I have done:

  1. modified capture pattern for prudaq, now in every 2 seconds one calculation is done, for this I have used sleep function in c program, that pauses program for every 2 seconds. I would like to know if there is any much more better way or if this is good.

  2. checked lm-35 temp sensor and dht sensor, with dht sensor we can also get humidity but it is UART type, so we have to wait for its output like 1-2 sec and in LM-35 we have to sample it with prudaq. I consider going ahead with DHT

What is to be done:

  1. Extremely sorry abt documentation , last week along with gsoc, I was busy with family festival and college, so I would do it this week

  2. Circuit part should be completed by this week , using opamps for rx amplification and hc-sr04 for tx, once this works, we could focus again on s/w part.

Sent with Mailtrack

Weekly report 11:

Now the software part is almost complete, I have started the documentation for testing out the apparatus, currently I have created the wiki page to test using arduino uno for simulating waveform.

What I have done

  • Completed the multi axis program, such that the samples are collected in every 2 seconds, and are sent to python program

  • Earlier I was sending the whole buffer transferred from PRU to the python program which was I guess unnecessary, now the samples to be used for cross correlation are taken care during transfer from python to C
    What is to be done:

  • Test the apparatus for TOF calculation

  • complete the documentation for the anemometer, working the principle we are using in this code.

Weekly Report 12:

  • I made out lots of minor improvements to code for better result calculation in both single and double axis anemometer,
  • completed some of documentation to explain the whole concept, and software modules I have implemented
  • tested with arduino, while the results indicate the logic part of software is correct but requires some more minor tweaks like time interval sampling rate for better results

Now I have to complete documentation for test circuit implementation and explanation of software part so that anyone new can pick up to contribute into this project.