https://elinux.org/api.php?action=feedcontributions&user=Thrtransformerr&feedformat=atomeLinux.org - User contributions [en]2024-03-29T12:23:16ZUser contributionsMediaWiki 1.31.0https://elinux.org/index.php?title=BeagleBoard/GSoC/2017_Projects&diff=443416BeagleBoard/GSoC/2017 Projects2017-05-26T14:12:00Z<p>Thrtransformerr: /* Project: Sonic Anemometer */</p>
<hr />
<div>==Links==<br />
* Status reports: https://groups.google.com/forum/#!tags/beagleboard-gsoc/status<br />
* Live chat: http://webchat.freenode.net/?channels=beagle-gsoc<br />
* GSoc site: https://summerofcode.withgoogle.com/<br />
* Meeting minutes: http://elinux.org/BeagleBoard/GSoC/Meetings<br />
<br />
==Project: [[Template Project, please copy first and then edit]] ==<br />
{{#ev:youtube|fL_XMieanSc||right|Video Title}}<br />
“Project Name”. add your project description here.<br />
* Student: Joe Template<br />
* Mentors: Shirley Temple<br />
* Code: https://github.com/...<br />
* Wiki: https://github.com/.../wiki<br />
* Blog: http://<url_here>/ (not mandatory)<br />
* GSoC site: https://summerofcode.withgoogle.com/<your_project_here<br />
<div style="clear:both;"></div><br />
<br />
<br />
==Project: [[BeagleBone AVB Stack]] ==<br />
{{#ev:youtube|8FDrBt0OAdk||right|GSoC 2017 - Beagle Bone AVB Stack}}<br />
Building a AVB node,the stream reservation protocol and the precision time protocol in the linux kernel. A demo application will be included for a stereo speaker system with two individual beagle boards. The first board will decode a stereo audio file (ex: mp3 files stored in local disk) and play one channel of the audio through its speakers (ex: left channel) and then it transmits the second channel (ex: right channel) to the second device over AVB which plays back the second channel through its speakers. The objective is to achieve frame synchronization over such a system. This can be tested by recording the output from both devices and analyzing with an audio analyzer. In this case one device acts as a AVB master node and the second device acts as a AVB slave node.<br />
* Student: Indumathi Duraipandian<br />
* Mentors: Robert Manzke,Henrik Langer<br />
* Code: TBD<br />
* Wiki: TBD<br />
* Blog: TBD<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#4872428135120896<br />
<div style="clear:both;"></div><br />
<br />
==Project: [[BeagleWire software support]] ==<br />
{{#ev:youtube|Fsj81PMSOC8||right|Video Title}}<br />
The BeagleWire is an FPGA development platform that has been designed for use with BeagleBone boards. BeagleWire is a cape on which there is FPGA device - Lattice iCE40HX. The Lattice iCE40 is a family of FPGAs with a minimalistic architecture and very regular structure, designed for low-cost, high-volume consumer and system applications. The significance of FPGAs is continuously increasing, as they are more and more often used for supporting work of ARM processors. BeagleWire does not require external tools (JTAG) and the whole software is Open Source. iCE40 is an energy saving device, allowing to work with small batteries. FPGA cape allows easy and low cost start for beginners who would like to take their first steps in working with FPGAs. The developed software will be an easy and, at the same time, efficient tool for communication with FPGA. At this point FPGA will be able to meet the requirements of even more advanced applications. The BeagleWire creates a powerful and versatile digital cape for users to create their imaginative digital designs. The task is to create software support for FPGA cape (based on iCE40 device). The completed project will provide the BeagleBoard.org community with easy to implement and powerful tools for realization of projects based on Programmable Logic Device(FPGA), which will surely increase the number of applications based on it.<br />
<br />
* Student: Patryk Mężydło (pmezydlo)<br />
* Mentors: Michael Welling(m_w), Jonathan Cameron(Jic23)<br />
* Code: https://github.com/pmezydlo/BeagleWire<br />
* Wiki: TBD<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#6320798145970176<br />
<div style="clear:both;"></div><br />
<br />
<br />
==Project: [[BeagleLibs]] ==<br />
https://youtu.be/svTSmAsZD2I<br />
{{#ev:youtube|svTSmAsZD2I||right|BeagleLibs GSoC 2017 Intro Video }}<br />
My project is basically two high quality, well-documented libraries for interfacing with BeagleBone hardware in Rust and Go. These libraries will provide interfaces for common usecases like GPIO, ADC reads, PWM, UART, SPI, and I2C (I'm open to more!). The intent of the project is to bridge the gap between the lower level and the higher level languages and make using the BeagleBone accessible to a wider range of users.<br />
<br />
People trying to get into hardware projects today are faced with difficult choices, especially when it comes to the platform their project will be based on. The BeagleBone community has made an great strides toward bridging this gap by with the cheap and approachable BeagleBones, but users are still confronted with the choice of fast/difficult to use C, or easy to use/slow JavaScript.<br />
<br />
Users seeking to work on the BeagleBone shouldn't have to face this choice; which is where this project comes in. By providing a well-documented set of libraries for the common tasks that every hardware project uses, users will be able to harness the power of performant languages while still having a pleasant development process.<br />
<br />
<br />
* Student: ee (ee)<br />
* Mentors: Trevor Woerner(tlwoerner)<br />
* Code: https://github.com/ekmecic/bb-rust, https://github.com/ekmecic/bb-go<br />
* Wiki: http://elinux.org/BeagleBoard/GSoC/BeagleLibs<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#5350396523446272<br />
<div style="clear:both;"></div><br />
<br />
<br />
==Project: [[BeagleBoot]] ==<br />
{{#ev:youtube|5JYfh2_0x8s||right|GSoC 2017 - BeagleBoot}}<br />
Currently, the ways to flash images in BeagleBone hardware are not easy especially for beginners, SD card method takes up much time and manual configuration, BBBlfs flashing tool works but is CLI based, not much reliable and works on limited platforms, TI's Uniflash tool is also old and works only under older versions of Windows and Linux with a lot of manual configuration. The project is to port the BeagleBone bootloader server BBBlfs(currently written in c) to JavaScript(node.js) and make a cross platform GUI (using electron framework) flashing tool utilising the etcher.io project. This will allow us to have single code base for a cross platform tool.<br />
<br />
The tool works as:<br />
<br />
1. TFTP transfer of SPL binary and u-boot. <br><br />
2. Utilizing the ums feature of u-boot, booting the BB hardware into USB mass storage mode. <br><br />
3. Flashing the BB hardware with etcher.io like tool. <br><br />
<br />
This project project will be really helpful for everybody especially newbies, who would have a nice experience with flashing images easily and faster, so that they can focus on the more important stuff be it their robotics project, kernel development or some new PRU hack.<br />
<br />
* Student: Ravi Kumar Prasad (ravikp7)<br />
* Mentors: Jason Kridner (jkridner)<br />
* Code: https://github.com/ravikp7/BeagleBoot<br />
* Wiki: TBD<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#5007313858461696<br />
<div style="clear:both;"></div><br />
<br />
==Project: [[Sonic Anemometer]] ==<br />
{{#ev:youtube|uj8lO8G9QYU||right|GSoC 2017 - BeagleBoot}}<br />
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.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.<br />
<br />
* Student: Naveen Saini(thetransformerr)<br />
* Mentors: Stephen Arnold(nerdboy),Hunyue Yau(ds2),Zubeen Tolani(ZeekHuge)<br />
* Code: https://github.com/thetransformerr/beagle-sonic<br />
* Wiki: https://github.com/thetransformerr/beagle-sonic/wiki<br />
* GSoC site:https://summerofcode.withgoogle.com/projects/#5658335807275008<br />
<br />
==Project: [[BeagleBoard/GSoC/BeagleBone PRU DMA - Maciej Sobkowski]] ==<br />
{{#ev:youtube|H4Bywj-rr74||right|BeagleBone PRU DMA}}<br />
Most of existing PRU applications utilize (waste) one PRU core for data transfer. The goal of this project is to enable usage of EDMA controller for copying of data to and from main memory (DDR), which would allow applications to use both cores for computation. <br />
<br />
* Student: [http://elinux.org/User:Maciejjo Maciej Sobkowski]<br />
* Mentors: Kumar Abhishek (Abhishek_), Zubeen Tolani (ZeekHuge) <br />
* Code: https://github.com/maciejjo/beaglebone-pru-dma<br />
* Wiki: http://elinux.org/BeagleBoard/GSoC/BeagleBone_PRU_DMA_-_Maciej_Sobkowski<br />
* GSoC: https://summerofcode.withgoogle.com/projects/5021339281784832<br />
<div style="clear:both;"></div></div>Thrtransformerrhttps://elinux.org/index.php?title=BeagleBoard/GSoC/2017_Projects&diff=443411BeagleBoard/GSoC/2017 Projects2017-05-26T14:10:49Z<p>Thrtransformerr: /* Project: Sonic Anemometer */</p>
<hr />
<div>==Links==<br />
* Status reports: https://groups.google.com/forum/#!tags/beagleboard-gsoc/status<br />
* Live chat: http://webchat.freenode.net/?channels=beagle-gsoc<br />
* GSoc site: https://summerofcode.withgoogle.com/<br />
* Meeting minutes: http://elinux.org/BeagleBoard/GSoC/Meetings<br />
<br />
==Project: [[Template Project, please copy first and then edit]] ==<br />
{{#ev:youtube|fL_XMieanSc||right|Video Title}}<br />
“Project Name”. add your project description here.<br />
* Student: Joe Template<br />
* Mentors: Shirley Temple<br />
* Code: https://github.com/...<br />
* Wiki: https://github.com/.../wiki<br />
* Blog: http://<url_here>/ (not mandatory)<br />
* GSoC site: https://summerofcode.withgoogle.com/<your_project_here<br />
<div style="clear:both;"></div><br />
<br />
<br />
==Project: [[BeagleBone AVB Stack]] ==<br />
{{#ev:youtube|8FDrBt0OAdk||right|GSoC 2017 - Beagle Bone AVB Stack}}<br />
Building a AVB node,the stream reservation protocol and the precision time protocol in the linux kernel. A demo application will be included for a stereo speaker system with two individual beagle boards. The first board will decode a stereo audio file (ex: mp3 files stored in local disk) and play one channel of the audio through its speakers (ex: left channel) and then it transmits the second channel (ex: right channel) to the second device over AVB which plays back the second channel through its speakers. The objective is to achieve frame synchronization over such a system. This can be tested by recording the output from both devices and analyzing with an audio analyzer. In this case one device acts as a AVB master node and the second device acts as a AVB slave node.<br />
* Student: Indumathi Duraipandian<br />
* Mentors: Robert Manzke,Henrik Langer<br />
* Code: TBD<br />
* Wiki: TBD<br />
* Blog: TBD<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#4872428135120896<br />
<div style="clear:both;"></div><br />
<br />
==Project: [[BeagleWire software support]] ==<br />
{{#ev:youtube|Fsj81PMSOC8||right|Video Title}}<br />
The BeagleWire is an FPGA development platform that has been designed for use with BeagleBone boards. BeagleWire is a cape on which there is FPGA device - Lattice iCE40HX. The Lattice iCE40 is a family of FPGAs with a minimalistic architecture and very regular structure, designed for low-cost, high-volume consumer and system applications. The significance of FPGAs is continuously increasing, as they are more and more often used for supporting work of ARM processors. BeagleWire does not require external tools (JTAG) and the whole software is Open Source. iCE40 is an energy saving device, allowing to work with small batteries. FPGA cape allows easy and low cost start for beginners who would like to take their first steps in working with FPGAs. The developed software will be an easy and, at the same time, efficient tool for communication with FPGA. At this point FPGA will be able to meet the requirements of even more advanced applications. The BeagleWire creates a powerful and versatile digital cape for users to create their imaginative digital designs. The task is to create software support for FPGA cape (based on iCE40 device). The completed project will provide the BeagleBoard.org community with easy to implement and powerful tools for realization of projects based on Programmable Logic Device(FPGA), which will surely increase the number of applications based on it.<br />
<br />
* Student: Patryk Mężydło (pmezydlo)<br />
* Mentors: Michael Welling(m_w), Jonathan Cameron(Jic23)<br />
* Code: https://github.com/pmezydlo/BeagleWire<br />
* Wiki: TBD<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#6320798145970176<br />
<div style="clear:both;"></div><br />
<br />
<br />
==Project: [[BeagleLibs]] ==<br />
https://youtu.be/svTSmAsZD2I<br />
{{#ev:youtube|svTSmAsZD2I||right|BeagleLibs GSoC 2017 Intro Video }}<br />
My project is basically two high quality, well-documented libraries for interfacing with BeagleBone hardware in Rust and Go. These libraries will provide interfaces for common usecases like GPIO, ADC reads, PWM, UART, SPI, and I2C (I'm open to more!). The intent of the project is to bridge the gap between the lower level and the higher level languages and make using the BeagleBone accessible to a wider range of users.<br />
<br />
People trying to get into hardware projects today are faced with difficult choices, especially when it comes to the platform their project will be based on. The BeagleBone community has made an great strides toward bridging this gap by with the cheap and approachable BeagleBones, but users are still confronted with the choice of fast/difficult to use C, or easy to use/slow JavaScript.<br />
<br />
Users seeking to work on the BeagleBone shouldn't have to face this choice; which is where this project comes in. By providing a well-documented set of libraries for the common tasks that every hardware project uses, users will be able to harness the power of performant languages while still having a pleasant development process.<br />
<br />
<br />
* Student: ee (ee)<br />
* Mentors: Trevor Woerner(tlwoerner)<br />
* Code: https://github.com/ekmecic/bb-rust, https://github.com/ekmecic/bb-go<br />
* Wiki: http://elinux.org/BeagleBoard/GSoC/BeagleLibs<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#5350396523446272<br />
<div style="clear:both;"></div><br />
<br />
<br />
==Project: [[BeagleBoot]] ==<br />
{{#ev:youtube|5JYfh2_0x8s||right|GSoC 2017 - BeagleBoot}}<br />
Currently, the ways to flash images in BeagleBone hardware are not easy especially for beginners, SD card method takes up much time and manual configuration, BBBlfs flashing tool works but is CLI based, not much reliable and works on limited platforms, TI's Uniflash tool is also old and works only under older versions of Windows and Linux with a lot of manual configuration. The project is to port the BeagleBone bootloader server BBBlfs(currently written in c) to JavaScript(node.js) and make a cross platform GUI (using electron framework) flashing tool utilising the etcher.io project. This will allow us to have single code base for a cross platform tool.<br />
<br />
The tool works as:<br />
<br />
1. TFTP transfer of SPL binary and u-boot. <br><br />
2. Utilizing the ums feature of u-boot, booting the BB hardware into USB mass storage mode. <br><br />
3. Flashing the BB hardware with etcher.io like tool. <br><br />
<br />
This project project will be really helpful for everybody especially newbies, who would have a nice experience with flashing images easily and faster, so that they can focus on the more important stuff be it their robotics project, kernel development or some new PRU hack.<br />
<br />
* Student: Ravi Kumar Prasad (ravikp7)<br />
* Mentors: Jason Kridner (jkridner)<br />
* Code: https://github.com/ravikp7/BeagleBoot<br />
* Wiki: TBD<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#5007313858461696<br />
<div style="clear:both;"></div><br />
<br />
==Project: [[Sonic Anemometer]] ==<br />
{{#ev:youtube|uj8lO8G9QYU||right|GSoC 2017 - BeagleBoot}}<br />
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.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.<br />
<br />
* Student: Naveen Saini(thetransformerr)<br />
* Mentors: Stephen Arnold(nerdboy),Hunyue Yau(ds2),Zubeen Tolani(ZeekHuge)<br />
* Code: TBD<br />
* Wiki: TBD<br />
* GSoC site:https://summerofcode.withgoogle.com/projects/#5658335807275008<br />
<br />
==Project: [[BeagleBoard/GSoC/BeagleBone PRU DMA - Maciej Sobkowski]] ==<br />
{{#ev:youtube|H4Bywj-rr74||right|BeagleBone PRU DMA}}<br />
Most of existing PRU applications utilize (waste) one PRU core for data transfer. The goal of this project is to enable usage of EDMA controller for copying of data to and from main memory (DDR), which would allow applications to use both cores for computation. <br />
<br />
* Student: [http://elinux.org/User:Maciejjo Maciej Sobkowski]<br />
* Mentors: Kumar Abhishek (Abhishek_), Zubeen Tolani (ZeekHuge) <br />
* Code: https://github.com/maciejjo/beaglebone-pru-dma<br />
* Wiki: http://elinux.org/BeagleBoard/GSoC/BeagleBone_PRU_DMA_-_Maciej_Sobkowski<br />
* GSoC: https://summerofcode.withgoogle.com/projects/5021339281784832<br />
<div style="clear:both;"></div></div>Thrtransformerrhttps://elinux.org/index.php?title=BeagleBoard/GSoC/2017_Projects&diff=443406BeagleBoard/GSoC/2017 Projects2017-05-26T14:10:16Z<p>Thrtransformerr: /* Project: Sonic Anemometer */</p>
<hr />
<div>==Links==<br />
* Status reports: https://groups.google.com/forum/#!tags/beagleboard-gsoc/status<br />
* Live chat: http://webchat.freenode.net/?channels=beagle-gsoc<br />
* GSoc site: https://summerofcode.withgoogle.com/<br />
* Meeting minutes: http://elinux.org/BeagleBoard/GSoC/Meetings<br />
<br />
==Project: [[Template Project, please copy first and then edit]] ==<br />
{{#ev:youtube|fL_XMieanSc||right|Video Title}}<br />
“Project Name”. add your project description here.<br />
* Student: Joe Template<br />
* Mentors: Shirley Temple<br />
* Code: https://github.com/...<br />
* Wiki: https://github.com/.../wiki<br />
* Blog: http://<url_here>/ (not mandatory)<br />
* GSoC site: https://summerofcode.withgoogle.com/<your_project_here<br />
<div style="clear:both;"></div><br />
<br />
<br />
==Project: [[BeagleBone AVB Stack]] ==<br />
{{#ev:youtube|8FDrBt0OAdk||right|GSoC 2017 - Beagle Bone AVB Stack}}<br />
Building a AVB node,the stream reservation protocol and the precision time protocol in the linux kernel. A demo application will be included for a stereo speaker system with two individual beagle boards. The first board will decode a stereo audio file (ex: mp3 files stored in local disk) and play one channel of the audio through its speakers (ex: left channel) and then it transmits the second channel (ex: right channel) to the second device over AVB which plays back the second channel through its speakers. The objective is to achieve frame synchronization over such a system. This can be tested by recording the output from both devices and analyzing with an audio analyzer. In this case one device acts as a AVB master node and the second device acts as a AVB slave node.<br />
* Student: Indumathi Duraipandian<br />
* Mentors: Robert Manzke,Henrik Langer<br />
* Code: TBD<br />
* Wiki: TBD<br />
* Blog: TBD<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#4872428135120896<br />
<div style="clear:both;"></div><br />
<br />
==Project: [[BeagleWire software support]] ==<br />
{{#ev:youtube|Fsj81PMSOC8||right|Video Title}}<br />
The BeagleWire is an FPGA development platform that has been designed for use with BeagleBone boards. BeagleWire is a cape on which there is FPGA device - Lattice iCE40HX. The Lattice iCE40 is a family of FPGAs with a minimalistic architecture and very regular structure, designed for low-cost, high-volume consumer and system applications. The significance of FPGAs is continuously increasing, as they are more and more often used for supporting work of ARM processors. BeagleWire does not require external tools (JTAG) and the whole software is Open Source. iCE40 is an energy saving device, allowing to work with small batteries. FPGA cape allows easy and low cost start for beginners who would like to take their first steps in working with FPGAs. The developed software will be an easy and, at the same time, efficient tool for communication with FPGA. At this point FPGA will be able to meet the requirements of even more advanced applications. The BeagleWire creates a powerful and versatile digital cape for users to create their imaginative digital designs. The task is to create software support for FPGA cape (based on iCE40 device). The completed project will provide the BeagleBoard.org community with easy to implement and powerful tools for realization of projects based on Programmable Logic Device(FPGA), which will surely increase the number of applications based on it.<br />
<br />
* Student: Patryk Mężydło (pmezydlo)<br />
* Mentors: Michael Welling(m_w), Jonathan Cameron(Jic23)<br />
* Code: https://github.com/pmezydlo/BeagleWire<br />
* Wiki: TBD<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#6320798145970176<br />
<div style="clear:both;"></div><br />
<br />
<br />
==Project: [[BeagleLibs]] ==<br />
https://youtu.be/svTSmAsZD2I<br />
{{#ev:youtube|svTSmAsZD2I||right|BeagleLibs GSoC 2017 Intro Video }}<br />
My project is basically two high quality, well-documented libraries for interfacing with BeagleBone hardware in Rust and Go. These libraries will provide interfaces for common usecases like GPIO, ADC reads, PWM, UART, SPI, and I2C (I'm open to more!). The intent of the project is to bridge the gap between the lower level and the higher level languages and make using the BeagleBone accessible to a wider range of users.<br />
<br />
People trying to get into hardware projects today are faced with difficult choices, especially when it comes to the platform their project will be based on. The BeagleBone community has made an great strides toward bridging this gap by with the cheap and approachable BeagleBones, but users are still confronted with the choice of fast/difficult to use C, or easy to use/slow JavaScript.<br />
<br />
Users seeking to work on the BeagleBone shouldn't have to face this choice; which is where this project comes in. By providing a well-documented set of libraries for the common tasks that every hardware project uses, users will be able to harness the power of performant languages while still having a pleasant development process.<br />
<br />
<br />
* Student: ee (ee)<br />
* Mentors: Trevor Woerner(tlwoerner)<br />
* Code: https://github.com/ekmecic/bb-rust, https://github.com/ekmecic/bb-go<br />
* Wiki: http://elinux.org/BeagleBoard/GSoC/BeagleLibs<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#5350396523446272<br />
<div style="clear:both;"></div><br />
<br />
<br />
==Project: [[BeagleBoot]] ==<br />
{{#ev:youtube|5JYfh2_0x8s||right|GSoC 2017 - BeagleBoot}}<br />
Currently, the ways to flash images in BeagleBone hardware are not easy especially for beginners, SD card method takes up much time and manual configuration, BBBlfs flashing tool works but is CLI based, not much reliable and works on limited platforms, TI's Uniflash tool is also old and works only under older versions of Windows and Linux with a lot of manual configuration. The project is to port the BeagleBone bootloader server BBBlfs(currently written in c) to JavaScript(node.js) and make a cross platform GUI (using electron framework) flashing tool utilising the etcher.io project. This will allow us to have single code base for a cross platform tool.<br />
<br />
The tool works as:<br />
<br />
1. TFTP transfer of SPL binary and u-boot. <br><br />
2. Utilizing the ums feature of u-boot, booting the BB hardware into USB mass storage mode. <br><br />
3. Flashing the BB hardware with etcher.io like tool. <br><br />
<br />
This project project will be really helpful for everybody especially newbies, who would have a nice experience with flashing images easily and faster, so that they can focus on the more important stuff be it their robotics project, kernel development or some new PRU hack.<br />
<br />
* Student: Ravi Kumar Prasad (ravikp7)<br />
* Mentors: Jason Kridner (jkridner)<br />
* Code: https://github.com/ravikp7/BeagleBoot<br />
* Wiki: TBD<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#5007313858461696<br />
<div style="clear:both;"></div><br />
<br />
==Project: [[Sonic Anemometer]] ==<br />
{{#ev:https://youtu.be/uj8lO8G9QYU||right|GSoC 2017 - BeagleBoot}}<br />
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.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.<br />
<br />
* Student: Naveen Saini(thetransformerr)<br />
* Mentors: Stephen Arnold(nerdboy),Hunyue Yau(ds2),Zubeen Tolani(ZeekHuge)<br />
* Code: TBD<br />
* Wiki: TBD<br />
* GSoC site:https://summerofcode.withgoogle.com/projects/#5658335807275008<br />
<br />
==Project: [[BeagleBoard/GSoC/BeagleBone PRU DMA - Maciej Sobkowski]] ==<br />
{{#ev:youtube|H4Bywj-rr74||right|BeagleBone PRU DMA}}<br />
Most of existing PRU applications utilize (waste) one PRU core for data transfer. The goal of this project is to enable usage of EDMA controller for copying of data to and from main memory (DDR), which would allow applications to use both cores for computation. <br />
<br />
* Student: [http://elinux.org/User:Maciejjo Maciej Sobkowski]<br />
* Mentors: Kumar Abhishek (Abhishek_), Zubeen Tolani (ZeekHuge) <br />
* Code: https://github.com/maciejjo/beaglebone-pru-dma<br />
* Wiki: http://elinux.org/BeagleBoard/GSoC/BeagleBone_PRU_DMA_-_Maciej_Sobkowski<br />
* GSoC: https://summerofcode.withgoogle.com/projects/5021339281784832<br />
<div style="clear:both;"></div></div>Thrtransformerrhttps://elinux.org/index.php?title=BeagleBoard/GSoC/2017_Projects&diff=443401BeagleBoard/GSoC/2017 Projects2017-05-26T14:09:15Z<p>Thrtransformerr: /* Project: Sonic Anemometer */</p>
<hr />
<div>==Links==<br />
* Status reports: https://groups.google.com/forum/#!tags/beagleboard-gsoc/status<br />
* Live chat: http://webchat.freenode.net/?channels=beagle-gsoc<br />
* GSoc site: https://summerofcode.withgoogle.com/<br />
* Meeting minutes: http://elinux.org/BeagleBoard/GSoC/Meetings<br />
<br />
==Project: [[Template Project, please copy first and then edit]] ==<br />
{{#ev:youtube|fL_XMieanSc||right|Video Title}}<br />
“Project Name”. add your project description here.<br />
* Student: Joe Template<br />
* Mentors: Shirley Temple<br />
* Code: https://github.com/...<br />
* Wiki: https://github.com/.../wiki<br />
* Blog: http://<url_here>/ (not mandatory)<br />
* GSoC site: https://summerofcode.withgoogle.com/<your_project_here<br />
<div style="clear:both;"></div><br />
<br />
<br />
==Project: [[BeagleBone AVB Stack]] ==<br />
{{#ev:youtube|8FDrBt0OAdk||right|GSoC 2017 - Beagle Bone AVB Stack}}<br />
Building a AVB node,the stream reservation protocol and the precision time protocol in the linux kernel. A demo application will be included for a stereo speaker system with two individual beagle boards. The first board will decode a stereo audio file (ex: mp3 files stored in local disk) and play one channel of the audio through its speakers (ex: left channel) and then it transmits the second channel (ex: right channel) to the second device over AVB which plays back the second channel through its speakers. The objective is to achieve frame synchronization over such a system. This can be tested by recording the output from both devices and analyzing with an audio analyzer. In this case one device acts as a AVB master node and the second device acts as a AVB slave node.<br />
* Student: Indumathi Duraipandian<br />
* Mentors: Robert Manzke,Henrik Langer<br />
* Code: TBD<br />
* Wiki: TBD<br />
* Blog: TBD<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#4872428135120896<br />
<div style="clear:both;"></div><br />
<br />
==Project: [[BeagleWire software support]] ==<br />
{{#ev:youtube|Fsj81PMSOC8||right|Video Title}}<br />
The BeagleWire is an FPGA development platform that has been designed for use with BeagleBone boards. BeagleWire is a cape on which there is FPGA device - Lattice iCE40HX. The Lattice iCE40 is a family of FPGAs with a minimalistic architecture and very regular structure, designed for low-cost, high-volume consumer and system applications. The significance of FPGAs is continuously increasing, as they are more and more often used for supporting work of ARM processors. BeagleWire does not require external tools (JTAG) and the whole software is Open Source. iCE40 is an energy saving device, allowing to work with small batteries. FPGA cape allows easy and low cost start for beginners who would like to take their first steps in working with FPGAs. The developed software will be an easy and, at the same time, efficient tool for communication with FPGA. At this point FPGA will be able to meet the requirements of even more advanced applications. The BeagleWire creates a powerful and versatile digital cape for users to create their imaginative digital designs. The task is to create software support for FPGA cape (based on iCE40 device). The completed project will provide the BeagleBoard.org community with easy to implement and powerful tools for realization of projects based on Programmable Logic Device(FPGA), which will surely increase the number of applications based on it.<br />
<br />
* Student: Patryk Mężydło (pmezydlo)<br />
* Mentors: Michael Welling(m_w), Jonathan Cameron(Jic23)<br />
* Code: https://github.com/pmezydlo/BeagleWire<br />
* Wiki: TBD<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#6320798145970176<br />
<div style="clear:both;"></div><br />
<br />
<br />
==Project: [[BeagleLibs]] ==<br />
https://youtu.be/svTSmAsZD2I<br />
{{#ev:youtube|svTSmAsZD2I||right|BeagleLibs GSoC 2017 Intro Video }}<br />
My project is basically two high quality, well-documented libraries for interfacing with BeagleBone hardware in Rust and Go. These libraries will provide interfaces for common usecases like GPIO, ADC reads, PWM, UART, SPI, and I2C (I'm open to more!). The intent of the project is to bridge the gap between the lower level and the higher level languages and make using the BeagleBone accessible to a wider range of users.<br />
<br />
People trying to get into hardware projects today are faced with difficult choices, especially when it comes to the platform their project will be based on. The BeagleBone community has made an great strides toward bridging this gap by with the cheap and approachable BeagleBones, but users are still confronted with the choice of fast/difficult to use C, or easy to use/slow JavaScript.<br />
<br />
Users seeking to work on the BeagleBone shouldn't have to face this choice; which is where this project comes in. By providing a well-documented set of libraries for the common tasks that every hardware project uses, users will be able to harness the power of performant languages while still having a pleasant development process.<br />
<br />
<br />
* Student: ee (ee)<br />
* Mentors: Trevor Woerner(tlwoerner)<br />
* Code: https://github.com/ekmecic/bb-rust, https://github.com/ekmecic/bb-go<br />
* Wiki: http://elinux.org/BeagleBoard/GSoC/BeagleLibs<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#5350396523446272<br />
<div style="clear:both;"></div><br />
<br />
<br />
==Project: [[BeagleBoot]] ==<br />
{{#ev:youtube|5JYfh2_0x8s||right|GSoC 2017 - BeagleBoot}}<br />
Currently, the ways to flash images in BeagleBone hardware are not easy especially for beginners, SD card method takes up much time and manual configuration, BBBlfs flashing tool works but is CLI based, not much reliable and works on limited platforms, TI's Uniflash tool is also old and works only under older versions of Windows and Linux with a lot of manual configuration. The project is to port the BeagleBone bootloader server BBBlfs(currently written in c) to JavaScript(node.js) and make a cross platform GUI (using electron framework) flashing tool utilising the etcher.io project. This will allow us to have single code base for a cross platform tool.<br />
<br />
The tool works as:<br />
<br />
1. TFTP transfer of SPL binary and u-boot. <br><br />
2. Utilizing the ums feature of u-boot, booting the BB hardware into USB mass storage mode. <br><br />
3. Flashing the BB hardware with etcher.io like tool. <br><br />
<br />
This project project will be really helpful for everybody especially newbies, who would have a nice experience with flashing images easily and faster, so that they can focus on the more important stuff be it their robotics project, kernel development or some new PRU hack.<br />
<br />
* Student: Ravi Kumar Prasad (ravikp7)<br />
* Mentors: Jason Kridner (jkridner)<br />
* Code: https://github.com/ravikp7/BeagleBoot<br />
* Wiki: TBD<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#5007313858461696<br />
<div style="clear:both;"></div><br />
<br />
==Project: [[Sonic Anemometer]] ==<br />
{{#ev:youtube.com/embed/uj8lO8G9QYU||right|GSoC 2017 - BeagleBoot}}<br />
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.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.<br />
<br />
* Student: Naveen Saini(thetransformerr)<br />
* Mentors: Stephen Arnold(nerdboy),Hunyue Yau(ds2),Zubeen Tolani(ZeekHuge)<br />
* Code: TBD<br />
* Wiki: TBD<br />
* GSoC site:https://summerofcode.withgoogle.com/projects/#5658335807275008<br />
<br />
==Project: [[BeagleBoard/GSoC/BeagleBone PRU DMA - Maciej Sobkowski]] ==<br />
{{#ev:youtube|H4Bywj-rr74||right|BeagleBone PRU DMA}}<br />
Most of existing PRU applications utilize (waste) one PRU core for data transfer. The goal of this project is to enable usage of EDMA controller for copying of data to and from main memory (DDR), which would allow applications to use both cores for computation. <br />
<br />
* Student: [http://elinux.org/User:Maciejjo Maciej Sobkowski]<br />
* Mentors: Kumar Abhishek (Abhishek_), Zubeen Tolani (ZeekHuge) <br />
* Code: https://github.com/maciejjo/beaglebone-pru-dma<br />
* Wiki: http://elinux.org/BeagleBoard/GSoC/BeagleBone_PRU_DMA_-_Maciej_Sobkowski<br />
* GSoC: https://summerofcode.withgoogle.com/projects/5021339281784832<br />
<div style="clear:both;"></div></div>Thrtransformerrhttps://elinux.org/index.php?title=BeagleBoard/GSoC/2017_Projects&diff=443396BeagleBoard/GSoC/2017 Projects2017-05-26T14:08:10Z<p>Thrtransformerr: /* Project: Sonic Anemometer */</p>
<hr />
<div>==Links==<br />
* Status reports: https://groups.google.com/forum/#!tags/beagleboard-gsoc/status<br />
* Live chat: http://webchat.freenode.net/?channels=beagle-gsoc<br />
* GSoc site: https://summerofcode.withgoogle.com/<br />
* Meeting minutes: http://elinux.org/BeagleBoard/GSoC/Meetings<br />
<br />
==Project: [[Template Project, please copy first and then edit]] ==<br />
{{#ev:youtube|fL_XMieanSc||right|Video Title}}<br />
“Project Name”. add your project description here.<br />
* Student: Joe Template<br />
* Mentors: Shirley Temple<br />
* Code: https://github.com/...<br />
* Wiki: https://github.com/.../wiki<br />
* Blog: http://<url_here>/ (not mandatory)<br />
* GSoC site: https://summerofcode.withgoogle.com/<your_project_here<br />
<div style="clear:both;"></div><br />
<br />
<br />
==Project: [[BeagleBone AVB Stack]] ==<br />
{{#ev:youtube|8FDrBt0OAdk||right|GSoC 2017 - Beagle Bone AVB Stack}}<br />
Building a AVB node,the stream reservation protocol and the precision time protocol in the linux kernel. A demo application will be included for a stereo speaker system with two individual beagle boards. The first board will decode a stereo audio file (ex: mp3 files stored in local disk) and play one channel of the audio through its speakers (ex: left channel) and then it transmits the second channel (ex: right channel) to the second device over AVB which plays back the second channel through its speakers. The objective is to achieve frame synchronization over such a system. This can be tested by recording the output from both devices and analyzing with an audio analyzer. In this case one device acts as a AVB master node and the second device acts as a AVB slave node.<br />
* Student: Indumathi Duraipandian<br />
* Mentors: Robert Manzke,Henrik Langer<br />
* Code: TBD<br />
* Wiki: TBD<br />
* Blog: TBD<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#4872428135120896<br />
<div style="clear:both;"></div><br />
<br />
==Project: [[BeagleWire software support]] ==<br />
{{#ev:youtube|Fsj81PMSOC8||right|Video Title}}<br />
The BeagleWire is an FPGA development platform that has been designed for use with BeagleBone boards. BeagleWire is a cape on which there is FPGA device - Lattice iCE40HX. The Lattice iCE40 is a family of FPGAs with a minimalistic architecture and very regular structure, designed for low-cost, high-volume consumer and system applications. The significance of FPGAs is continuously increasing, as they are more and more often used for supporting work of ARM processors. BeagleWire does not require external tools (JTAG) and the whole software is Open Source. iCE40 is an energy saving device, allowing to work with small batteries. FPGA cape allows easy and low cost start for beginners who would like to take their first steps in working with FPGAs. The developed software will be an easy and, at the same time, efficient tool for communication with FPGA. At this point FPGA will be able to meet the requirements of even more advanced applications. The BeagleWire creates a powerful and versatile digital cape for users to create their imaginative digital designs. The task is to create software support for FPGA cape (based on iCE40 device). The completed project will provide the BeagleBoard.org community with easy to implement and powerful tools for realization of projects based on Programmable Logic Device(FPGA), which will surely increase the number of applications based on it.<br />
<br />
* Student: Patryk Mężydło (pmezydlo)<br />
* Mentors: Michael Welling(m_w), Jonathan Cameron(Jic23)<br />
* Code: https://github.com/pmezydlo/BeagleWire<br />
* Wiki: TBD<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#6320798145970176<br />
<div style="clear:both;"></div><br />
<br />
<br />
==Project: [[BeagleLibs]] ==<br />
https://youtu.be/svTSmAsZD2I<br />
{{#ev:youtube|svTSmAsZD2I||right|BeagleLibs GSoC 2017 Intro Video }}<br />
My project is basically two high quality, well-documented libraries for interfacing with BeagleBone hardware in Rust and Go. These libraries will provide interfaces for common usecases like GPIO, ADC reads, PWM, UART, SPI, and I2C (I'm open to more!). The intent of the project is to bridge the gap between the lower level and the higher level languages and make using the BeagleBone accessible to a wider range of users.<br />
<br />
People trying to get into hardware projects today are faced with difficult choices, especially when it comes to the platform their project will be based on. The BeagleBone community has made an great strides toward bridging this gap by with the cheap and approachable BeagleBones, but users are still confronted with the choice of fast/difficult to use C, or easy to use/slow JavaScript.<br />
<br />
Users seeking to work on the BeagleBone shouldn't have to face this choice; which is where this project comes in. By providing a well-documented set of libraries for the common tasks that every hardware project uses, users will be able to harness the power of performant languages while still having a pleasant development process.<br />
<br />
<br />
* Student: ee (ee)<br />
* Mentors: Trevor Woerner(tlwoerner)<br />
* Code: https://github.com/ekmecic/bb-rust, https://github.com/ekmecic/bb-go<br />
* Wiki: http://elinux.org/BeagleBoard/GSoC/BeagleLibs<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#5350396523446272<br />
<div style="clear:both;"></div><br />
<br />
<br />
==Project: [[BeagleBoot]] ==<br />
{{#ev:youtube|5JYfh2_0x8s||right|GSoC 2017 - BeagleBoot}}<br />
Currently, the ways to flash images in BeagleBone hardware are not easy especially for beginners, SD card method takes up much time and manual configuration, BBBlfs flashing tool works but is CLI based, not much reliable and works on limited platforms, TI's Uniflash tool is also old and works only under older versions of Windows and Linux with a lot of manual configuration. The project is to port the BeagleBone bootloader server BBBlfs(currently written in c) to JavaScript(node.js) and make a cross platform GUI (using electron framework) flashing tool utilising the etcher.io project. This will allow us to have single code base for a cross platform tool.<br />
<br />
The tool works as:<br />
<br />
1. TFTP transfer of SPL binary and u-boot. <br><br />
2. Utilizing the ums feature of u-boot, booting the BB hardware into USB mass storage mode. <br><br />
3. Flashing the BB hardware with etcher.io like tool. <br><br />
<br />
This project project will be really helpful for everybody especially newbies, who would have a nice experience with flashing images easily and faster, so that they can focus on the more important stuff be it their robotics project, kernel development or some new PRU hack.<br />
<br />
* Student: Ravi Kumar Prasad (ravikp7)<br />
* Mentors: Jason Kridner (jkridner)<br />
* Code: https://github.com/ravikp7/BeagleBoot<br />
* Wiki: TBD<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#5007313858461696<br />
<div style="clear:both;"></div><br />
<br />
==Project: [[Sonic Anemometer]] ==<br />
{{#ev:https://www.youtube.com/watch?v=uj8lO8G9QYU&feature=youtu.be||right|GSoC 2017 - BeagleBoot}}<br />
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.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.<br />
<br />
* Student: Naveen Saini(thetransformerr)<br />
* Mentors: Stephen Arnold(nerdboy),Hunyue Yau(ds2),Zubeen Tolani(ZeekHuge)<br />
* Code: TBD<br />
* Wiki: TBD<br />
* GSoC site:https://summerofcode.withgoogle.com/projects/#5658335807275008<br />
<br />
==Project: [[BeagleBoard/GSoC/BeagleBone PRU DMA - Maciej Sobkowski]] ==<br />
{{#ev:youtube|H4Bywj-rr74||right|BeagleBone PRU DMA}}<br />
Most of existing PRU applications utilize (waste) one PRU core for data transfer. The goal of this project is to enable usage of EDMA controller for copying of data to and from main memory (DDR), which would allow applications to use both cores for computation. <br />
<br />
* Student: [http://elinux.org/User:Maciejjo Maciej Sobkowski]<br />
* Mentors: Kumar Abhishek (Abhishek_), Zubeen Tolani (ZeekHuge) <br />
* Code: https://github.com/maciejjo/beaglebone-pru-dma<br />
* Wiki: http://elinux.org/BeagleBoard/GSoC/BeagleBone_PRU_DMA_-_Maciej_Sobkowski<br />
* GSoC: https://summerofcode.withgoogle.com/projects/5021339281784832<br />
<div style="clear:both;"></div></div>Thrtransformerrhttps://elinux.org/index.php?title=BeagleBoard/GSoC/2017_Projects&diff=443391BeagleBoard/GSoC/2017 Projects2017-05-26T14:07:31Z<p>Thrtransformerr: /* Project: Sonic Anemometer */</p>
<hr />
<div>==Links==<br />
* Status reports: https://groups.google.com/forum/#!tags/beagleboard-gsoc/status<br />
* Live chat: http://webchat.freenode.net/?channels=beagle-gsoc<br />
* GSoc site: https://summerofcode.withgoogle.com/<br />
* Meeting minutes: http://elinux.org/BeagleBoard/GSoC/Meetings<br />
<br />
==Project: [[Template Project, please copy first and then edit]] ==<br />
{{#ev:youtube|fL_XMieanSc||right|Video Title}}<br />
“Project Name”. add your project description here.<br />
* Student: Joe Template<br />
* Mentors: Shirley Temple<br />
* Code: https://github.com/...<br />
* Wiki: https://github.com/.../wiki<br />
* Blog: http://<url_here>/ (not mandatory)<br />
* GSoC site: https://summerofcode.withgoogle.com/<your_project_here<br />
<div style="clear:both;"></div><br />
<br />
<br />
==Project: [[BeagleBone AVB Stack]] ==<br />
{{#ev:youtube|8FDrBt0OAdk||right|GSoC 2017 - Beagle Bone AVB Stack}}<br />
Building a AVB node,the stream reservation protocol and the precision time protocol in the linux kernel. A demo application will be included for a stereo speaker system with two individual beagle boards. The first board will decode a stereo audio file (ex: mp3 files stored in local disk) and play one channel of the audio through its speakers (ex: left channel) and then it transmits the second channel (ex: right channel) to the second device over AVB which plays back the second channel through its speakers. The objective is to achieve frame synchronization over such a system. This can be tested by recording the output from both devices and analyzing with an audio analyzer. In this case one device acts as a AVB master node and the second device acts as a AVB slave node.<br />
* Student: Indumathi Duraipandian<br />
* Mentors: Robert Manzke,Henrik Langer<br />
* Code: TBD<br />
* Wiki: TBD<br />
* Blog: TBD<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#4872428135120896<br />
<div style="clear:both;"></div><br />
<br />
==Project: [[BeagleWire software support]] ==<br />
{{#ev:youtube|Fsj81PMSOC8||right|Video Title}}<br />
The BeagleWire is an FPGA development platform that has been designed for use with BeagleBone boards. BeagleWire is a cape on which there is FPGA device - Lattice iCE40HX. The Lattice iCE40 is a family of FPGAs with a minimalistic architecture and very regular structure, designed for low-cost, high-volume consumer and system applications. The significance of FPGAs is continuously increasing, as they are more and more often used for supporting work of ARM processors. BeagleWire does not require external tools (JTAG) and the whole software is Open Source. iCE40 is an energy saving device, allowing to work with small batteries. FPGA cape allows easy and low cost start for beginners who would like to take their first steps in working with FPGAs. The developed software will be an easy and, at the same time, efficient tool for communication with FPGA. At this point FPGA will be able to meet the requirements of even more advanced applications. The BeagleWire creates a powerful and versatile digital cape for users to create their imaginative digital designs. The task is to create software support for FPGA cape (based on iCE40 device). The completed project will provide the BeagleBoard.org community with easy to implement and powerful tools for realization of projects based on Programmable Logic Device(FPGA), which will surely increase the number of applications based on it.<br />
<br />
* Student: Patryk Mężydło (pmezydlo)<br />
* Mentors: Michael Welling(m_w), Jonathan Cameron(Jic23)<br />
* Code: https://github.com/pmezydlo/BeagleWire<br />
* Wiki: TBD<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#6320798145970176<br />
<div style="clear:both;"></div><br />
<br />
<br />
==Project: [[BeagleLibs]] ==<br />
https://youtu.be/svTSmAsZD2I<br />
{{#ev:youtube|svTSmAsZD2I||right|BeagleLibs GSoC 2017 Intro Video }}<br />
My project is basically two high quality, well-documented libraries for interfacing with BeagleBone hardware in Rust and Go. These libraries will provide interfaces for common usecases like GPIO, ADC reads, PWM, UART, SPI, and I2C (I'm open to more!). The intent of the project is to bridge the gap between the lower level and the higher level languages and make using the BeagleBone accessible to a wider range of users.<br />
<br />
People trying to get into hardware projects today are faced with difficult choices, especially when it comes to the platform their project will be based on. The BeagleBone community has made an great strides toward bridging this gap by with the cheap and approachable BeagleBones, but users are still confronted with the choice of fast/difficult to use C, or easy to use/slow JavaScript.<br />
<br />
Users seeking to work on the BeagleBone shouldn't have to face this choice; which is where this project comes in. By providing a well-documented set of libraries for the common tasks that every hardware project uses, users will be able to harness the power of performant languages while still having a pleasant development process.<br />
<br />
<br />
* Student: ee (ee)<br />
* Mentors: Trevor Woerner(tlwoerner)<br />
* Code: https://github.com/ekmecic/bb-rust, https://github.com/ekmecic/bb-go<br />
* Wiki: http://elinux.org/BeagleBoard/GSoC/BeagleLibs<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#5350396523446272<br />
<div style="clear:both;"></div><br />
<br />
<br />
==Project: [[BeagleBoot]] ==<br />
{{#ev:youtube|5JYfh2_0x8s||right|GSoC 2017 - BeagleBoot}}<br />
Currently, the ways to flash images in BeagleBone hardware are not easy especially for beginners, SD card method takes up much time and manual configuration, BBBlfs flashing tool works but is CLI based, not much reliable and works on limited platforms, TI's Uniflash tool is also old and works only under older versions of Windows and Linux with a lot of manual configuration. The project is to port the BeagleBone bootloader server BBBlfs(currently written in c) to JavaScript(node.js) and make a cross platform GUI (using electron framework) flashing tool utilising the etcher.io project. This will allow us to have single code base for a cross platform tool.<br />
<br />
The tool works as:<br />
<br />
1. TFTP transfer of SPL binary and u-boot. <br><br />
2. Utilizing the ums feature of u-boot, booting the BB hardware into USB mass storage mode. <br><br />
3. Flashing the BB hardware with etcher.io like tool. <br><br />
<br />
This project project will be really helpful for everybody especially newbies, who would have a nice experience with flashing images easily and faster, so that they can focus on the more important stuff be it their robotics project, kernel development or some new PRU hack.<br />
<br />
* Student: Ravi Kumar Prasad (ravikp7)<br />
* Mentors: Jason Kridner (jkridner)<br />
* Code: https://github.com/ravikp7/BeagleBoot<br />
* Wiki: TBD<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#5007313858461696<br />
<div style="clear:both;"></div><br />
<br />
==Project: [[Sonic Anemometer]] ==<br />
{{#ev:https://youtu.be/uj8lO8G9QYU||right|GSoC 2017 - BeagleBoot}}<br />
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.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.<br />
<br />
* Student: Naveen Saini(thetransformerr)<br />
* Mentors: Stephen Arnold(nerdboy),Hunyue Yau(ds2),Zubeen Tolani(ZeekHuge)<br />
* Code: TBD<br />
* Wiki: TBD<br />
* GSoC site:https://summerofcode.withgoogle.com/projects/#5658335807275008<br />
<br />
==Project: [[BeagleBoard/GSoC/BeagleBone PRU DMA - Maciej Sobkowski]] ==<br />
{{#ev:youtube|H4Bywj-rr74||right|BeagleBone PRU DMA}}<br />
Most of existing PRU applications utilize (waste) one PRU core for data transfer. The goal of this project is to enable usage of EDMA controller for copying of data to and from main memory (DDR), which would allow applications to use both cores for computation. <br />
<br />
* Student: [http://elinux.org/User:Maciejjo Maciej Sobkowski]<br />
* Mentors: Kumar Abhishek (Abhishek_), Zubeen Tolani (ZeekHuge) <br />
* Code: https://github.com/maciejjo/beaglebone-pru-dma<br />
* Wiki: http://elinux.org/BeagleBoard/GSoC/BeagleBone_PRU_DMA_-_Maciej_Sobkowski<br />
* GSoC: https://summerofcode.withgoogle.com/projects/5021339281784832<br />
<div style="clear:both;"></div></div>Thrtransformerrhttps://elinux.org/index.php?title=BeagleBoard/GSoC/2017_Projects&diff=443236BeagleBoard/GSoC/2017 Projects2017-05-24T15:42:37Z<p>Thrtransformerr: /* Project: Sonic Anemometer */</p>
<hr />
<div>==Links==<br />
* Status reports: https://groups.google.com/forum/#!tags/beagleboard-gsoc/status<br />
* Live chat: http://webchat.freenode.net/?channels=beagle-gsoc<br />
* GSoc site: https://summerofcode.withgoogle.com/<br />
* Meeting minutes: http://elinux.org/BeagleBoard/GSoC/Meetings<br />
<br />
==Project: [[Template Project, please copy first and then edit]] ==<br />
{{#ev:youtube|fL_XMieanSc||right|Video Title}}<br />
“Project Name”. add your project description here.<br />
* Student: Joe Template<br />
* Mentors: Shirley Temple<br />
* Code: https://github.com/...<br />
* Wiki: https://github.com/.../wiki<br />
* Blog: http://<url_here>/ (not mandatory)<br />
* GSoC site: https://summerofcode.withgoogle.com/<your_project_here<br />
<div style="clear:both;"></div><br />
<br />
<br />
==Project: [[BeagleBone AVB Stack]] ==<br />
{{#ev:youtube|8FDrBt0OAdk||right|GSoC 2017 - Beagle Bone AVB Stack}}<br />
Building a AVB node,the stream reservation protocol and the precision time protocol in the linux kernel. A demo application will be included for a stereo speaker system with two individual beagle boards. The first board will decode a stereo audio file (ex: mp3 files stored in local disk) and play one channel of the audio through its speakers (ex: left channel) and then it transmits the second channel (ex: right channel) to the second device over AVB which plays back the second channel through its speakers. The objective is to achieve frame synchronization over such a system. This can be tested by recording the output from both devices and analyzing with an audio analyzer. In this case one device acts as a AVB master node and the second device acts as a AVB slave node.<br />
* Student: Indumathi Duraipandian<br />
* Mentors: Robert Manzke,Henrik Langer<br />
* Code: TBD<br />
* Wiki: TBD<br />
* Blog: TBD<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#4872428135120896<br />
<div style="clear:both;"></div><br />
<br />
==Project: [[BeagleWire software support]] ==<br />
The BeagleWire is an FPGA development platform that has been designed for use with BeagleBone boards. BeagleWire is a cape on which there is FPGA device - Lattice iCE40HX. The Lattice iCE40 is a family of FPGAs with a minimalistic architecture and very regular structure, designed for low-cost, high-volume consumer and system applications. The significance of FPGAs is continuously increasing, as they are more and more often used for supporting work of ARM processors. BeagleWire does not require external tools (JTAG) and the whole software is Open Source. iCE40 is an energy saving device, allowing to work with small batteries. FPGA cape allows easy and low cost start for beginners who would like to take their first steps in working with FPGAs. The developed software will be an easy and, at the same time, efficient tool for communication with FPGA. At this point FPGA will be able to meet the requirements of even more advanced applications. The BeagleWire creates a powerful and versatile digital cape for users to create their imaginative digital designs. The task is to create software support for FPGA cape (based on iCE40 device). The completed project will provide the BeagleBoard.org community with easy to implement and powerful tools for realization of projects based on Programmable Logic Device(FPGA), which will surely increase the number of applications based on it.<br />
<br />
* Student: Patryk Mężydło (pmezydlo)<br />
* Mentors: Michael Welling(m_w), Jonathan Cameron(Jic23)<br />
* Code: https://github.com/pmezydlo/BeagleWire<br />
* Wiki: TBD<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#6320798145970176<br />
<div style="clear:both;"></div><br />
<br />
<br />
==Project: [[BeagleLibs]] ==<br />
My project is basically two high quality, well-documented libraries for interfacing with BeagleBone hardware in Rust and Go. These libraries will provide interfaces for common usecases like GPIO, ADC reads, PWM, UART, SPI, and I2C (I'm open to more!). The intent of the project is to bridge the gap between the lower level and the higher level languages and make using the BeagleBone accessible to a wider range of users.<br />
<br />
People trying to get into hardware projects today are faced with difficult choices, especially when it comes to the platform their project will be based on. The BeagleBone community has made an great strides toward bridging this gap by with the cheap and approachable BeagleBones, but users are still confronted with the choice of fast/difficult to use C, or easy to use/slow JavaScript.<br />
<br />
Users seeking to work on the BeagleBone shouldn't have to face this choice; which is where this project comes in. By providing a well-documented set of libraries for the common tasks that every hardware project uses, users will be able to harness the power of performant languages while still having a pleasant development process.<br />
<br />
<br />
* Student: ee (ee)<br />
* Mentors: Trevor Woerner(tlwoerner)<br />
* Code: https://github.com/ekmecic/bb-rust, https://github.com/ekmecic/bb-go<br />
* Wiki: http://elinux.org/BeagleBoard/GSoC/BeagleLibs<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#5350396523446272<br />
<div style="clear:both;"></div><br />
<br />
<br />
==Project: [[BeagleBoot]] ==<br />
Currently, the ways to flash images in BeagleBone hardware are not easy especially for beginners, SD card method takes up much time and manual configuration, BBBlfs flashing tool works but is CLI based, not much reliable and works on limited platforms, TI's Uniflash tool is also old and works only under older versions of Windows and Linux with a lot of manual configuration. The project is to port the BeagleBone bootloader server BBBlfs(currently written in c) to JavaScript(node.js) and make a cross platform GUI (using electron framework) flashing tool utilising the etcher.io project. This will allow us to have single code base for a cross platform tool.<br />
<br />
The tool works as:<br />
<br />
1. TFTP transfer of SPL binary and u-boot. <br><br />
2. Utilizing the ums feature of u-boot, booting the BB hardware into USB mass storage mode. <br><br />
3. Flashing the BB hardware with etcher.io like tool. <br><br />
<br />
This project project will be really helpful for everybody especially newbies, who would have a nice experience with flashing images easily and faster, so that they can focus on the more important stuff be it their robotics project, kernel development or some new PRU hack.<br />
<br />
* Student: Ravi Kumar Prasad (ravikp7)<br />
* Mentors: Jason Kridner (jkridner)<br />
* Code: https://github.com/ravikp7/BeagleBoot<br />
* Wiki: TBD<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#5007313858461696<br />
<div style="clear:both;"></div><br />
<br />
==Project: [[Sonic Anemometer]] ==<br />
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.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.<br />
<br />
* Student: Naveen Saini(thetransformerr)<br />
* Mentors: Stephen Arnold(nerdboy),Hunyue Yau(ds2),Zubeen Tolani(ZeekHuge)<br />
* Code: TBD<br />
* Wiki: TBD<br />
* GSoC site:https://summerofcode.withgoogle.com/projects/#5658335807275008</div>Thrtransformerrhttps://elinux.org/index.php?title=BeagleBoard/GSoC/2017_Projects&diff=443206BeagleBoard/GSoC/2017 Projects2017-05-23T16:38:51Z<p>Thrtransformerr: /* Project: Sonic Anemometer */</p>
<hr />
<div>==Links==<br />
* Status reports: https://groups.google.com/forum/#!tags/beagleboard-gsoc/status<br />
* Live chat: http://webchat.freenode.net/?channels=beagle-gsoc<br />
* GSoc site: https://summerofcode.withgoogle.com/<br />
* Meeting minutes: http://elinux.org/BeagleBoard/GSoC/Meetings<br />
<br />
==Project: [[Template Project, please copy first and then edit]] ==<br />
{{#ev:youtube|fL_XMieanSc||right|Video Title}}<br />
“Project Name”. add your project description here.<br />
* Student: Joe Template<br />
* Mentors: Shirley Temple<br />
* Code: https://github.com/...<br />
* Wiki: https://github.com/.../wiki<br />
* Blog: http://<url_here>/ (not mandatory)<br />
* GSoC site: https://summerofcode.withgoogle.com/<your_project_here<br />
<div style="clear:both;"></div><br />
<br />
<br />
==Project: [[BeagleBone AVB Stack]] ==<br />
Building a AVB node,the stream reservation protocol and the precision time protocol in the linux kernel. A demo application will be included for a stereo speaker system with two individual beagle boards. The first board will decode a stereo audio file (ex: mp3 files stored in local disk) and play one channel of the audio through its speakers (ex: left channel) and then it transmits the second channel (ex: right channel) to the second device over AVB which plays back the second channel through its speakers. The objective is to achieve frame synchronization over such a system. This can be tested by recording the output from both devices and analyzing with an audio analyzer. In this case one device acts as a AVB master node and the second device acts as a AVB slave node.<br />
* Student: Indumathi Duraipandian<br />
* Mentors: Robert Manzke,Henrik Langer<br />
* Code: TBD<br />
* Wiki: TBD<br />
* Blog: TBD<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#4872428135120896<br />
<div style="clear:both;"></div><br />
<br />
==Project: [[BeagleWire software support]] ==<br />
The BeagleWire is an FPGA development platform that has been designed for use with BeagleBone boards. BeagleWire is a cape on which there is FPGA device - Lattice iCE40HX. The Lattice iCE40 is a family of FPGAs with a minimalistic architecture and very regular structure, designed for low-cost, high-volume consumer and system applications. The significance of FPGAs is continuously increasing, as they are more and more often used for supporting work of ARM processors. BeagleWire does not require external tools (JTAG) and the whole software is Open Source. iCE40 is an energy saving device, allowing to work with small batteries. FPGA cape allows easy and low cost start for beginners who would like to take their first steps in working with FPGAs. The developed software will be an easy and, at the same time, efficient tool for communication with FPGA. At this point FPGA will be able to meet the requirements of even more advanced applications. The BeagleWire creates a powerful and versatile digital cape for users to create their imaginative digital designs. The task is to create software support for FPGA cape (based on iCE40 device). The completed project will provide the BeagleBoard.org community with easy to implement and powerful tools for realization of projects based on Programmable Logic Device(FPGA), which will surely increase the number of applications based on it.<br />
<br />
* Student: Patryk Mężydło (pmezydlo)<br />
* Mentors: Michael Welling(m_w), Jonathan Cameron(Jic23)<br />
* Code: https://github.com/pmezydlo/BeagleWire<br />
* Wiki: TBD<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#6320798145970176<br />
<div style="clear:both;"></div><br />
<br />
<br />
==Project: [[BeagleLibs]] ==<br />
My project is basically two high quality, well-documented libraries for interfacing with BeagleBone hardware in Rust and Go. These libraries will provide interfaces for common usecases like GPIO, ADC reads, PWM, UART, SPI, and I2C (I'm open to more!). The intent of the project is to bridge the gap between the lower level and the higher level languages and make using the BeagleBone accessible to a wider range of users.<br />
<br />
People trying to get into hardware projects today are faced with difficult choices, especially when it comes to the platform their project will be based on. The BeagleBone community has made an great strides toward bridging this gap by with the cheap and approachable BeagleBones, but users are still confronted with the choice of fast/difficult to use C, or easy to use/slow JavaScript.<br />
<br />
Users seeking to work on the BeagleBone shouldn't have to face this choice; which is where this project comes in. By providing a well-documented set of libraries for the common tasks that every hardware project uses, users will be able to harness the power of performant languages while still having a pleasant development process.<br />
<br />
<br />
* Student: ee (ee)<br />
* Mentors: Trevor Woerner(tlwoerner)<br />
* Code: https://github.com/ekmecic/bb-rust, https://github.com/ekmecic/bb-go<br />
* Wiki: http://elinux.org/BeagleBoard/GSoC/BeagleLibs<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#5350396523446272<br />
<div style="clear:both;"></div><br />
<br />
<br />
==Project: [[BeagleBoot]] ==<br />
Currently, the ways to flash images in BeagleBone hardware are not easy especially for beginners, SD card method takes up much time and manual configuration, BBBlfs flashing tool works but is CLI based, not much reliable and works on limited platforms, TI's Uniflash tool is also old and works only under older versions of Windows and Linux with a lot of manual configuration. The project is to port the BeagleBone bootloader server BBBlfs(currently written in c) to JavaScript(node.js) and make a cross platform GUI (using electron framework) flashing tool utilising the etcher.io project. This will allow us to have single code base for a cross platform tool.<br />
<br />
The tool works as:<br />
<br />
1. TFTP transfer of SPL binary and u-boot. <br><br />
2. Utilizing the ums feature of u-boot, booting the BB hardware into USB mass storage mode. <br><br />
3. Flashing the BB hardware with etcher.io like tool. <br><br />
<br />
This project project will be really helpful for everybody especially newbies, who would have a nice experience with flashing images easily and faster, so that they can focus on the more important stuff be it their robotics project, kernel development or some new PRU hack.<br />
<br />
* Student: Ravi Kumar Prasad (ravikp7)<br />
* Mentors: Jason Kridner (jkridner)<br />
* Code: https://github.com/ravikp7/BeagleBoot<br />
* Wiki: TBD<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#5007313858461696<br />
<div style="clear:both;"></div><br />
<br />
==Project: [[Sonic Anemometer]] ==<br />
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.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.<br />
<br />
* Student: Naveen Saini(thetransformerr)<br />
* Mentors: Stephen Arnold(nerdboy),Hunyue Yau(ds2),Zubeen Tolani(ZeekHuge)<br />
* Code: TBD<br />
* Wiki: http://elinux.org/GSoC2017_sonic_anemometer_proposal<br />
* GSoC site:https://summerofcode.withgoogle.com/projects/#5658335807275008</div>Thrtransformerrhttps://elinux.org/index.php?title=BeagleBoard/GSoC/2017_Projects&diff=442381BeagleBoard/GSoC/2017 Projects2017-05-19T15:29:46Z<p>Thrtransformerr: /* Project: BeagleBoot */</p>
<hr />
<div>==Links==<br />
* Status reports: https://groups.google.com/forum/#!tags/beagleboard-gsoc/status<br />
* Live chat: http://webchat.freenode.net/?channels=beagle-gsoc<br />
* GSoc site: https://summerofcode.withgoogle.com/<br />
* Meeting minutes: http://elinux.org/BeagleBoard/GSoC/Meetings<br />
<br />
==Project: [[Template Project, please copy first and then edit]] ==<br />
{{#ev:youtube|fL_XMieanSc||right|Video Title}}<br />
“Project Name”. add your project description here.<br />
* Student: Joe Template<br />
* Mentors: Shirley Temple<br />
* Code: https://github.com/...<br />
* Wiki: https://github.com/.../wiki<br />
* Blog: http://<url_here>/ (not mandatory)<br />
* GSoC site: https://summerofcode.withgoogle.com/<your_project_here<br />
<div style="clear:both;"></div><br />
<br />
<br />
==Project: [[BeagleBone AVB Stack]] ==<br />
Building a AVB node,the stream reservation protocol and the precision time protocol in the linux kernel. A demo application will be included for a stereo speaker system with two individual beagle boards. The first board will decode a stereo audio file (ex: mp3 files stored in local disk) and play one channel of the audio through its speakers (ex: left channel) and then it transmits the second channel (ex: right channel) to the second device over AVB which plays back the second channel through its speakers. The objective is to achieve frame synchronization over such a system. This can be tested by recording the output from both devices and analyzing with an audio analyzer. In this case one device acts as a AVB master node and the second device acts as a AVB slave node.<br />
* Student: Indumathi Duraipandian<br />
* Mentors: Robert Manzke,Henrik Langer<br />
* Code: TBD<br />
* Wiki: TBD<br />
* Blog: TBD<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#4872428135120896<br />
<div style="clear:both;"></div><br />
<br />
==Project: [[BeagleWire software support]] ==<br />
The BeagleWire is an FPGA development platform that has been designed for use with BeagleBone boards. BeagleWire is a cape on which there is FPGA device - Lattice iCE40HX. The Lattice iCE40 is a family of FPGAs with a minimalistic architecture and very regular structure, designed for low-cost, high-volume consumer and system applications. The significance of FPGAs is continuously increasing, as they are more and more often used for supporting work of ARM processors. BeagleWire does not require external tools (JTAG) and the whole software is Open Source. iCE40 is an energy saving device, allowing to work with small batteries. FPGA cape allows easy and low cost start for beginners who would like to take their first steps in working with FPGAs. The developed software will be an easy and, at the same time, efficient tool for communication with FPGA. At this point FPGA will be able to meet the requirements of even more advanced applications. The BeagleWire creates a powerful and versatile digital cape for users to create their imaginative digital designs. The task is to create software support for FPGA cape (based on iCE40 device). The completed project will provide the BeagleBoard.org community with easy to implement and powerful tools for realization of projects based on Programmable Logic Device(FPGA), which will surely increase the number of applications based on it.<br />
<br />
* Student: Patryk Mężydło (pmezydlo)<br />
* Mentors: Michael Welling(m_w), Jonathan Cameron(Jic23)<br />
* Code: https://github.com/pmezydlo/BeagleWire<br />
* Wiki: TBD<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#6320798145970176<br />
<div style="clear:both;"></div><br />
<br />
<br />
==Project: [[BeagleLibs]] ==<br />
My project is basically two high quality, well-documented libraries for interfacing with BeagleBone hardware in Rust and Go. These libraries will provide interfaces for common usecases like GPIO, ADC reads, PWM, UART, SPI, and I2C (I'm open to more!). The intent of the project is to bridge the gap between the lower level and the higher level languages and make using the BeagleBone accessible to a wider range of users.<br />
<br />
People trying to get into hardware projects today are faced with difficult choices, especially when it comes to the platform their project will be based on. The BeagleBone community has made an great strides toward bridging this gap by with the cheap and approachable BeagleBones, but users are still confronted with the choice of fast/difficult to use C, or easy to use/slow JavaScript.<br />
<br />
Users seeking to work on the BeagleBone shouldn't have to face this choice; which is where this project comes in. By providing a well-documented set of libraries for the common tasks that every hardware project uses, users will be able to harness the power of performant languages while still having a pleasant development process.<br />
<br />
<br />
* Student: ee (ee)<br />
* Mentors: Trevor Woerner(tlwoerner)<br />
* Code: https://github.com/ekmecic/bb-rust, https://github.com/ekmecic/bb-go<br />
* Wiki: http://elinux.org/BeagleBoard/GSoC/BeagleLibs<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#5350396523446272<br />
<div style="clear:both;"></div><br />
<br />
<br />
==Project: [[BeagleBoot]] ==<br />
Currently, the ways to flash images in BeagleBone hardware are not easy especially for beginners, SD card method takes up much time and manual configuration, BBBlfs flashing tool works but is CLI based, not much reliable and works on limited platforms, TI's Uniflash tool is also old and works only under older versions of Windows and Linux with a lot of manual configuration. The project is to port the BeagleBone bootloader server BBBlfs(currently written in c) to JavaScript(node.js) and make a cross platform GUI (using electron framework) flashing tool utilising the etcher.io project. This will allow us to have single code base for a cross platform tool.<br />
<br />
The tool works as:<br />
<br />
1. TFTP transfer of SPL binary and u-boot. <br><br />
2. Utilizing the ums feature of u-boot, booting the BB hardware into USB mass storage mode. <br><br />
3. Flashing the BB hardware with etcher.io like tool. <br><br />
<br />
This project project will be really helpful for everybody especially newbies, who would have a nice experience with flashing images easily and faster, so that they can focus on the more important stuff be it their robotics project, kernel development or some new PRU hack.<br />
<br />
* Student: Ravi Kumar Prasad (ravikp7)<br />
* Mentors: Jason Kridner (jkridner)<br />
* Code: https://github.com/ravikp7/BeagleBoot<br />
* Wiki: TBD<br />
* GSoC site: https://summerofcode.withgoogle.com/projects/#5007313858461696<br />
<div style="clear:both;"></div><br />
<br />
==Project: [[Sonic Anemometer]] ==<br />
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.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.<br />
<br />
* Student: Naveen Saini(thetransformerr)<br />
* Mentors: Stephen Arnold(nerdboy),Hunyue Yau,Zubeen Tolani(ZeekHuge)<br />
* Code: TBD<br />
* Wiki: http://elinux.org/GSoC2017_sonic_anemometer_proposal<br />
* GSoC site:https://summerofcode.withgoogle.com/projects/#5658335807275008</div>Thrtransformerrhttps://elinux.org/index.php?title=GSoC2017_sonic_anemometer_proposal&diff=440371GSoC2017 sonic anemometer proposal2017-04-04T22:16:39Z<p>Thrtransformerr: /* About Me */</p>
<hr />
<div>[[Category: BeagleBoard]]<br />
[[Category: GSoC]]<br />
[[Category: GSoCProposal]]<br />
== Proposal for Sonic Anemometer ==<br />
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.<br />
<br />
''Idea as Quoted from GSoC Ideas page:'' <br />
Working prototype sonic anemometer using BeagleBone, PRUDAQ, and ultrasonic sensors. Analyze methods for accuracy/sensitivity <br />
(eg, time-of-flight vs. phase difference) and implement "best" method. Use PRUs for independent real-time control of ultrasonics.<br />
<br />
''Student:'' Naveen Saini<br />
<br />
''Mentors'': Steve Arnold(nerdboy), Stephanie Lockwood-Childs<br />
<br />
''Code:'' N/A<br />
<br />
''Wiki'': http://elinux.org/GSoC2017_sonic_anemometer_proposal<br />
<br />
''GSoC'': [https://github.com/thetransformerr/thetransformerr.github.io/blob/master/GSoC.pdf GSoC(SonicAnem.pdf)]<br />
<br />
==Status==<br />
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.<br />
<br />
==Proposal==<br />
I have completed the task required as described on Ideas page, and created a pull request, as listed [https://github.com/thetransformerr/gsoc-application/tree/master/ExampleEntryJasonKridner here].<br />
===About Me===<br />
''GitHub:'' [https://github.com/thetransformerr @thetransformerr]<br />
<br />
''IRC:'' thetransformerr<br />
<br />
''E-mail:'' [mailto:thetransformerr@gmail.com thetransformerr@gmail.com] ; [mailto:naveensaini.cse18@jecrc.ac.in naveensaini.cse18@jecrc.ac.in]<br />
<br />
''elinux:'' thrtransformerr<br />
<br />
''Linkedin:'' [https://www.linkedin.com/in/5naveensaini/ Naveen Saini]<br />
<br />
''School:'' [http://jecrcuniversity.edu.in JECRC,Jaipur]<br />
<br />
''Country:'' India[The mystical wonderland ;)]<br />
<br />
''Primary language:'' English,Hindi<br />
<br />
''Typical work hours:'' 08AM-10AM , 09PM-01AM Indian Standard Time(+5:30)<br />
<br />
''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.<br />
<br />
''Skills(proficient):'' C,Ruby,Javascript<br />
<br />
''Experience:'' Java,Python,Arduino,Node.js,Scala,Matlab,CAD.<br />
<br />
=== Sonic Anemometer===<br />
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.<br />
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.<br />
<br />
=== Principle of Sonic Anemometer:===<br />
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.<br />
This pair of transducers act alternately as transmitters and receivers, exchanging high-frequency ultrasound pulses between themselves. The times of flight in each direction t<sub>1</sub> and t<sub>2</sub>, 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:<br />
<br />
[[File:Time.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
By combining Eqns (1) and (2) and solving for ` v`, the following equation is obtained:<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
<br />
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. <br />
<br />
[[File:Twodim.png|400px|thumb|left|2D axis(to be aligned with compass to true north)]][[File:Threet.png|400px|thumb|center|3D axis(for reference)]]<br />
<br />
<br />
<br />
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)<br />
Now following Equations are involved here,<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:Angle.png|300px|thumb|center|Angle]]<br />
<br />
<br />
Now from above equations it is clear that speed of sound calculated this way is independent of factors such as temperatures.<br />
<br />
Now with this device we can calculate the wind speed as well as temperature as described below-<br />
[[File:Temp.jpg|300px|thumb|center|Temperature(virtual temperature)]]<br />
<br />
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. <br />
<br />
The sonic temperature, Tv (in Kelvin), may differ from the absolute temperature by an amount equal to the<br />
water vapor content in the air measured. This difference amounts to ±1°C at 20°C and decreases as the temperature decreases.<br />
<br />
===Requirement Analysis===<br />
Following are the hardware that we can start with:-<br />
* Beaglebone Black/Green(1)<br />
* PRUDAQ/ADC having rate higher than 400ksps per channel(1/2)<br />
* Transducers(40kHz,Waterproof)(4)<br />
<br />
DAQ are the Data Acquisition devices which are used to acquire data from sensors and acts as a bridge between sensors and host computer.<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
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.<br />
We can probably use second one for '''calibration''' and other tasks.<br />
<br />
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<sup>-3</sup>order) '''<br />
<br />
[[File:vari.png|900px|center|Temperature and Humidity effects]]<br />
<br />
<br />
Following graphs represents deviations of speed of sound :<br />
[[File:Tsemp.gif|400px|thumb|left|Temprature and Humidity Deviation]][[File:Spres.gif|400px|thumb|center|Pressure variation]]<br />
<br />
<br />
<br />
For 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.<br />
<br />
PRU in Beaglebone has rate of '''''200 MHz''''', hence instruction cycle of '''''5ns''''', following table shows approximate cycle required for various assembly code operations,<br />
[[File:Insc.png|600px|center|Instruction Cycles]]<br />
<br />
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.<br />
<br />
Following table shows some observations<br />
[[File:Obers.png|600px|center|Some raw observations]]<br />
<br />
<br />
Different Suitable DAQ<br />
[[File:DAiQ.png|600px|center|Some DAQ cost and capacity]]<br />
<br />
<br />
And this graph shows attenuation of waves according to their frequency, generally, higher the frequency, earlier it attenuates,<br />
[[File:Atten.png|400px|thumb|center|Attenuation Characteristics of Sound Pressure by Distance]]<br />
===WorkFlow for Data Acquistion===<br />
Consider the anemometer outputs reading of temperature and wind speed at the frequency of '''''20Hz''''', then the time period for acquiring the data from transducer and performing calculation is '''''50 milliseconds''''' for each set of reading.<br />
[[File:Daqr.png|600px|thumb|center|Pin Diagram]]<br />
[[File:Wofl.png|600px|center]]<br />
<br />
<br />
<br />
<br />
===Error Analysis===<br />
<br />
Following are the equations defined in thermodynamics for values calculated from the data:<br />
<br />
'''''c<sup>2</sup> =403T(1+0.32e/p)<br />
'''''<br />
where '''c''' is the velocity of sound ('''m s<sup>-1</sup>''') 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,<br />
<br />
'''''Ts [= T(1 + 0.32 e/p)]''''' <br />
<br />
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:<br />
<br />
'''''Tv =T(1+0.38e/p)<br />
'''''<br />
Clearly, '''Ts''' more closely approximates '''T<sub>v</sub>''' than it does '''T''', the error being on the order of '''±0.01°C''' in assuming '''T′ =T<sub>v</sub>′(virtual)''', compared to '''±0.05°C''' for '''T′ =T′(absolute)'''.<br />
Since virtual temperature is used sometimes in boundary layer calculations, we can safely assume sonic temperature as virtual temperature within safe experimental assumptions.<br />
<br />
<br />
[[File:Combined.png|300px|left|u calculation]]<br />
[[File:wind_vel.png|300px|center|t1 and t2 calculation]]<br />
<br />
<br />
<br />
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<sup>-2</sup>ms<sup>-1</sup>.<br />
<br />
===Timeline:===<br />
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<br />
<br />
This program is of 12 Weeks-With Evaluation phase on June 26 - 30, 2017 and July 24 - 28, 2017<br />
<br />
====First Week:====<br />
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.<br />
====Second Week:====<br />
Connect the Prudaq and take sample readings as described on their wiki example.<br />
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<br />
====Third Week:====<br />
Program the PRU to read the sample results from PRUDAQ and trigger successive generation of two axis sonic transducers.<br />
====Fourth Week:====<br />
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.<br />
'''Evaluation Goals 1:'''<br />
''The device is able to stream the results of successive measurements after every specified interval to<br />
the user space and it is stored into text file.Software Testing Units are created for possible errors.''<br />
<br />
====Fifth Week:====<br />
This week we will build the structure as portable, possibly as described in below pictures.<br />
<br />
[[File:Sonic.jpg|300px|thumb|center|PVC for easy and flexible implementation]][[File:Unknown.jpg|300px|thumbnail|center|Made of Copper and steel to heat during Cold]]<br />
<br />
====Sixth Week:====<br />
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.<br />
====Seventh Week:====<br />
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.<br />
====Eighth Week:====<br />
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.<br />
'''Evaluation Goals 2:'''<br />
''Apparatus is tested extensively for outdoors, and is able to perform functional tasks in various possible <br />
conditions and output reliable data with accuracy and have test units defined but other factors like azimuth angle <br />
or other correction algorithms would be applied in the next stage.''<br />
<br />
====Ninth Week:====<br />
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).<br />
====Tenth Week:====<br />
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).<br />
Other modifications like variable sampling frequency in case if required later by developers.<br />
====Eleventh Week:====<br />
Review all the test units created earlier during program and modify them or build new.<br />
====Final Week:====<br />
Create a REST API sort of thing that enables the reading and logging of results into remote machines and proof check all modules<br />
<br />
==Final Goals:==<br />
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.<br />
<br />
===Future/Additional Goals:===<br />
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.<br />
<br />
Other Goals that can be helped or created by us or other open source contributors<br />
<br />
1. Make A python script type to create the graph and other possible representations of the data processed.<br />
<br />
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.<br />
<br />
==Experience and Approach==<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Projects====<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
<br />
==== Participations ====<br />
* 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.<br />
* Participated on National level, in TopCoder Open Finals organised by TopCoder.<br />
<br />
==== Approach ====<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Contingency==<br />
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.<br />
<br />
==Benefit==<br />
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.<br />
<br />
'''What community members speak -'''<br />
<br />
''Great project for the Aspiring Weather Scientist.''<br />
Michael Welling('''m_w''') <br />
<br />
''A working/documented FOSS implementation would be a huge''<br />
''plus for both the open source and weather communities.''<br />
Steve Arnold('''nerdboy''') <br />
''and the best one award goes to...''<br />
''I'll be tempted to build one!''<br />
Jonathan Cameron('''jic23''')<br />
<br />
***'''''Mentors!!! please add your Quote here.'''''***<br />
<br />
==Suggestions==<br />
Nothing For Now...<br />
<br />
Thanks.</div>Thrtransformerrhttps://elinux.org/index.php?title=GSoC2017_sonic_anemometer_proposal&diff=440366GSoC2017 sonic anemometer proposal2017-04-04T22:11:52Z<p>Thrtransformerr: /* About Me */</p>
<hr />
<div>[[Category: BeagleBoard]]<br />
[[Category: GSoC]]<br />
[[Category: GSoCProposal]]<br />
== Proposal for Sonic Anemometer ==<br />
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.<br />
<br />
''Idea as Quoted from GSoC Ideas page:'' <br />
Working prototype sonic anemometer using BeagleBone, PRUDAQ, and ultrasonic sensors. Analyze methods for accuracy/sensitivity <br />
(eg, time-of-flight vs. phase difference) and implement "best" method. Use PRUs for independent real-time control of ultrasonics.<br />
<br />
''Student:'' Naveen Saini<br />
<br />
''Mentors'': Steve Arnold(nerdboy), Stephanie Lockwood-Childs<br />
<br />
''Code:'' N/A<br />
<br />
''Wiki'': http://elinux.org/GSoC2017_sonic_anemometer_proposal<br />
<br />
''GSoC'': [https://github.com/thetransformerr/thetransformerr.github.io/blob/master/GSoC.pdf GSoC(SonicAnem.pdf)]<br />
<br />
==Status==<br />
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.<br />
<br />
==Proposal==<br />
I have completed the task required as described on Ideas page, and created a pull request, as listed [https://github.com/thetransformerr/gsoc-application/tree/master/ExampleEntryJasonKridner here].<br />
===About Me===<br />
''GitHub:'' [https://github.com/thetransformerr @thetransformerr]<br />
<br />
''IRC:'' thetransformerr<br />
<br />
''E-mail:'' thetransformerr@gmail.com ; naveensaini.cse18@jecrc.ac.in<br />
<br />
''elinux:'' thrtransformerr<br />
<br />
''Linkedin:'' [https://www.linkedin.com/in/5naveensaini/ Naveen Saini]<br />
<br />
''School:'' [http://jecrcuniversity.edu.in JECRC,Jaipur]<br />
<br />
''Country:'' India[The mystical wonderland ;)]<br />
<br />
''Primary language:'' English,Hindi<br />
<br />
''Typical work hours:'' 08AM-10AM , 09PM-01AM Indian Standard Time(+5:30)<br />
<br />
''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.<br />
<br />
''Skills(proficient):'' C,Ruby,Javascript<br />
<br />
''Experience:'' Java,Python,Arduino,Node.js,Scala,Matlab,CAD.<br />
<br />
=== Sonic Anemometer===<br />
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.<br />
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.<br />
<br />
=== Principle of Sonic Anemometer:===<br />
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.<br />
This pair of transducers act alternately as transmitters and receivers, exchanging high-frequency ultrasound pulses between themselves. The times of flight in each direction t<sub>1</sub> and t<sub>2</sub>, 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:<br />
<br />
[[File:Time.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
By combining Eqns (1) and (2) and solving for ` v`, the following equation is obtained:<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
<br />
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. <br />
<br />
[[File:Twodim.png|400px|thumb|left|2D axis(to be aligned with compass to true north)]][[File:Threet.png|400px|thumb|center|3D axis(for reference)]]<br />
<br />
<br />
<br />
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)<br />
Now following Equations are involved here,<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:Angle.png|300px|thumb|center|Angle]]<br />
<br />
<br />
Now from above equations it is clear that speed of sound calculated this way is independent of factors such as temperatures.<br />
<br />
Now with this device we can calculate the wind speed as well as temperature as described below-<br />
[[File:Temp.jpg|300px|thumb|center|Temperature(virtual temperature)]]<br />
<br />
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. <br />
<br />
The sonic temperature, Tv (in Kelvin), may differ from the absolute temperature by an amount equal to the<br />
water vapor content in the air measured. This difference amounts to ±1°C at 20°C and decreases as the temperature decreases.<br />
<br />
===Requirement Analysis===<br />
Following are the hardware that we can start with:-<br />
* Beaglebone Black/Green(1)<br />
* PRUDAQ/ADC having rate higher than 400ksps per channel(1/2)<br />
* Transducers(40kHz,Waterproof)(4)<br />
<br />
DAQ are the Data Acquisition devices which are used to acquire data from sensors and acts as a bridge between sensors and host computer.<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
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.<br />
We can probably use second one for '''calibration''' and other tasks.<br />
<br />
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<sup>-3</sup>order) '''<br />
<br />
[[File:vari.png|900px|center|Temperature and Humidity effects]]<br />
<br />
<br />
Following graphs represents deviations of speed of sound :<br />
[[File:Tsemp.gif|400px|thumb|left|Temprature and Humidity Deviation]][[File:Spres.gif|400px|thumb|center|Pressure variation]]<br />
<br />
<br />
<br />
For 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.<br />
<br />
PRU in Beaglebone has rate of '''''200 MHz''''', hence instruction cycle of '''''5ns''''', following table shows approximate cycle required for various assembly code operations,<br />
[[File:Insc.png|600px|center|Instruction Cycles]]<br />
<br />
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.<br />
<br />
Following table shows some observations<br />
[[File:Obers.png|600px|center|Some raw observations]]<br />
<br />
<br />
Different Suitable DAQ<br />
[[File:DAiQ.png|600px|center|Some DAQ cost and capacity]]<br />
<br />
<br />
And this graph shows attenuation of waves according to their frequency, generally, higher the frequency, earlier it attenuates,<br />
[[File:Atten.png|400px|thumb|center|Attenuation Characteristics of Sound Pressure by Distance]]<br />
===WorkFlow for Data Acquistion===<br />
Consider the anemometer outputs reading of temperature and wind speed at the frequency of '''''20Hz''''', then the time period for acquiring the data from transducer and performing calculation is '''''50 milliseconds''''' for each set of reading.<br />
[[File:Daqr.png|600px|thumb|center|Pin Diagram]]<br />
[[File:Wofl.png|600px|center]]<br />
<br />
<br />
<br />
<br />
===Error Analysis===<br />
<br />
Following are the equations defined in thermodynamics for values calculated from the data:<br />
<br />
'''''c<sup>2</sup> =403T(1+0.32e/p)<br />
'''''<br />
where '''c''' is the velocity of sound ('''m s<sup>-1</sup>''') 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,<br />
<br />
'''''Ts [= T(1 + 0.32 e/p)]''''' <br />
<br />
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:<br />
<br />
'''''Tv =T(1+0.38e/p)<br />
'''''<br />
Clearly, '''Ts''' more closely approximates '''T<sub>v</sub>''' than it does '''T''', the error being on the order of '''±0.01°C''' in assuming '''T′ =T<sub>v</sub>′(virtual)''', compared to '''±0.05°C''' for '''T′ =T′(absolute)'''.<br />
Since virtual temperature is used sometimes in boundary layer calculations, we can safely assume sonic temperature as virtual temperature within safe experimental assumptions.<br />
<br />
<br />
[[File:Combined.png|300px|left|u calculation]]<br />
[[File:wind_vel.png|300px|center|t1 and t2 calculation]]<br />
<br />
<br />
<br />
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<sup>-2</sup>ms<sup>-1</sup>.<br />
<br />
===Timeline:===<br />
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<br />
<br />
This program is of 12 Weeks-With Evaluation phase on June 26 - 30, 2017 and July 24 - 28, 2017<br />
<br />
====First Week:====<br />
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.<br />
====Second Week:====<br />
Connect the Prudaq and take sample readings as described on their wiki example.<br />
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<br />
====Third Week:====<br />
Program the PRU to read the sample results from PRUDAQ and trigger successive generation of two axis sonic transducers.<br />
====Fourth Week:====<br />
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.<br />
'''Evaluation Goals 1:'''<br />
''The device is able to stream the results of successive measurements after every specified interval to<br />
the user space and it is stored into text file.Software Testing Units are created for possible errors.''<br />
<br />
====Fifth Week:====<br />
This week we will build the structure as portable, possibly as described in below pictures.<br />
<br />
[[File:Sonic.jpg|300px|thumb|center|PVC for easy and flexible implementation]][[File:Unknown.jpg|300px|thumbnail|center|Made of Copper and steel to heat during Cold]]<br />
<br />
====Sixth Week:====<br />
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.<br />
====Seventh Week:====<br />
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.<br />
====Eighth Week:====<br />
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.<br />
'''Evaluation Goals 2:'''<br />
''Apparatus is tested extensively for outdoors, and is able to perform functional tasks in various possible <br />
conditions and output reliable data with accuracy and have test units defined but other factors like azimuth angle <br />
or other correction algorithms would be applied in the next stage.''<br />
<br />
====Ninth Week:====<br />
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).<br />
====Tenth Week:====<br />
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).<br />
Other modifications like variable sampling frequency in case if required later by developers.<br />
====Eleventh Week:====<br />
Review all the test units created earlier during program and modify them or build new.<br />
====Final Week:====<br />
Create a REST API sort of thing that enables the reading and logging of results into remote machines and proof check all modules<br />
<br />
==Final Goals:==<br />
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.<br />
<br />
===Future/Additional Goals:===<br />
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.<br />
<br />
Other Goals that can be helped or created by us or other open source contributors<br />
<br />
1. Make A python script type to create the graph and other possible representations of the data processed.<br />
<br />
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.<br />
<br />
==Experience and Approach==<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Projects====<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
<br />
==== Participations ====<br />
* 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.<br />
* Participated on National level, in TopCoder Open Finals organised by TopCoder.<br />
<br />
==== Approach ====<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Contingency==<br />
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.<br />
<br />
==Benefit==<br />
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.<br />
<br />
'''What community members speak -'''<br />
<br />
''Great project for the Aspiring Weather Scientist.''<br />
Michael Welling('''m_w''') <br />
<br />
''A working/documented FOSS implementation would be a huge''<br />
''plus for both the open source and weather communities.''<br />
Steve Arnold('''nerdboy''') <br />
''and the best one award goes to...''<br />
''I'll be tempted to build one!''<br />
Jonathan Cameron('''jic23''')<br />
<br />
***'''''Mentors!!! please add your Quote here.'''''***<br />
<br />
==Suggestions==<br />
Nothing For Now...<br />
<br />
Thanks.</div>Thrtransformerrhttps://elinux.org/index.php?title=File:Wofl.png&diff=439421File:Wofl.png2017-04-02T14:57:09Z<p>Thrtransformerr: Thrtransformerr uploaded a new version of File:Wofl.png</p>
<hr />
<div></div>Thrtransformerrhttps://elinux.org/index.php?title=GSoC2017_sonic_anemometer_proposal&diff=439091GSoC2017 sonic anemometer proposal2017-04-02T10:30:09Z<p>Thrtransformerr: /* Proposal for Sonic Anemometer */</p>
<hr />
<div>[[Category: BeagleBoard]]<br />
[[Category: GSoC]]<br />
[[Category: GSoCProposal]]<br />
== Proposal for Sonic Anemometer ==<br />
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.<br />
<br />
''Idea as Quoted from GSoC Ideas page:'' <br />
Working prototype sonic anemometer using BeagleBone, PRUDAQ, and ultrasonic sensors. Analyze methods for accuracy/sensitivity <br />
(eg, time-of-flight vs. phase difference) and implement "best" method. Use PRUs for independent real-time control of ultrasonics.<br />
<br />
''Student:'' Naveen Saini<br />
<br />
''Mentors'': Steve Arnold(nerdboy), Stephanie Lockwood-Childs<br />
<br />
''Code:'' N/A<br />
<br />
''Wiki'': http://elinux.org/GSoC2017_sonic_anemometer_proposal<br />
<br />
''GSoC'': [https://github.com/thetransformerr/thetransformerr.github.io/blob/master/GSoC.pdf GSoC(SonicAnem.pdf)]<br />
<br />
==Status==<br />
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.<br />
<br />
==Proposal==<br />
I have completed the task required as described on Ideas page, and created a pull request, as listed [https://github.com/thetransformerr/gsoc-application/tree/master/ExampleEntryJasonKridner here].<br />
===About Me===<br />
''GitHub:'' [https://github.com/thetransformerr @thetransformerr]<br />
<br />
''IRC:'' thetransformerr<br />
<br />
''elinux:'' thrtransformerr<br />
<br />
''Linkedin:'' [https://www.linkedin.com/in/5naveensaini/ Naveen Saini]<br />
<br />
''School:'' [http://jecrcuniversity.edu.in JECRC,Jaipur]<br />
<br />
''Country:'' India[The mystical wonderland ;)]<br />
<br />
''Primary language:'' English,Hindi<br />
<br />
''Typical work hours:'' 08AM-10AM , 09PM-01AM Indian Standard Time(+5:30)<br />
<br />
''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.<br />
<br />
''Skills(proficient):'' C,Ruby,Javascript<br />
<br />
''Experience:'' Java,Python,Arduino,Node.js,Scala,Matlab,CAD.<br />
<br />
=== Sonic Anemometer===<br />
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.<br />
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.<br />
<br />
=== Principle of Sonic Anemometer:===<br />
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.<br />
This pair of transducers act alternately as transmitters and receivers, exchanging high-frequency ultrasound pulses between themselves. The times of flight in each direction t<sub>1</sub> and t<sub>2</sub>, 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:<br />
<br />
[[File:Time.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
By combining Eqns (1) and (2) and solving for ` v`, the following equation is obtained:<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
<br />
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. <br />
<br />
[[File:Twodim.png|400px|thumb|left|2D axis(to be aligned with compass to true north)]][[File:Threet.png|400px|thumb|center|3D axis(for reference)]]<br />
<br />
<br />
<br />
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)<br />
Now following Equations are involved here,<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:Angle.png|300px|thumb|center|Angle]]<br />
<br />
<br />
Now from above equations it is clear that speed of sound calculated this way is independent of factors such as temperatures.<br />
<br />
Now with this device we can calculate the wind speed as well as temperature as described below-<br />
[[File:Temp.jpg|300px|thumb|center|Temperature(virtual temperature)]]<br />
<br />
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. <br />
<br />
The sonic temperature, Tv (in Kelvin), may differ from the absolute temperature by an amount equal to the<br />
water vapor content in the air measured. This difference amounts to ±1°C at 20°C and decreases as the temperature decreases.<br />
<br />
===Requirement Analysis===<br />
Following are the hardware that we can start with:-<br />
* Beaglebone Black/Green(1)<br />
* PRUDAQ/ADC having rate higher than 400ksps per channel(1/2)<br />
* Transducers(40kHz,Waterproof)(4)<br />
<br />
DAQ are the Data Acquisition devices which are used to acquire data from sensors and acts as a bridge between sensors and host computer.<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
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.<br />
We can probably use second one for '''calibration''' and other tasks.<br />
<br />
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<sup>-3</sup>order) '''<br />
<br />
[[File:vari.png|900px|center|Temperature and Humidity effects]]<br />
<br />
<br />
Following graphs represents deviations of speed of sound :<br />
[[File:Tsemp.gif|400px|thumb|left|Temprature and Humidity Deviation]][[File:Spres.gif|400px|thumb|center|Pressure variation]]<br />
<br />
<br />
<br />
For 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.<br />
<br />
PRU in Beaglebone has rate of '''''200 MHz''''', hence instruction cycle of '''''5ns''''', following table shows approximate cycle required for various assembly code operations,<br />
[[File:Insc.png|600px|center|Instruction Cycles]]<br />
<br />
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.<br />
<br />
Following table shows some observations<br />
[[File:Obers.png|600px|center|Some raw observations]]<br />
<br />
<br />
Different Suitable DAQ<br />
[[File:DAiQ.png|600px|center|Some DAQ cost and capacity]]<br />
<br />
<br />
And this graph shows attenuation of waves according to their frequency, generally, higher the frequency, earlier it attenuates,<br />
[[File:Atten.png|400px|thumb|center|Attenuation Characteristics of Sound Pressure by Distance]]<br />
===WorkFlow for Data Acquistion===<br />
Consider the anemometer outputs reading of temperature and wind speed at the frequency of '''''20Hz''''', then the time period for acquiring the data from transducer and performing calculation is '''''50 milliseconds''''' for each set of reading.<br />
[[File:Daqr.png|600px|thumb|center|Pin Diagram]]<br />
[[File:Wofl.png|600px|center]]<br />
<br />
<br />
<br />
<br />
===Error Analysis===<br />
<br />
Following are the equations defined in thermodynamics for values calculated from the data:<br />
<br />
'''''c<sup>2</sup> =403T(1+0.32e/p)<br />
'''''<br />
where '''c''' is the velocity of sound ('''m s<sup>-1</sup>''') 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,<br />
<br />
'''''Ts [= T(1 + 0.32 e/p)]''''' <br />
<br />
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:<br />
<br />
'''''Tv =T(1+0.38e/p)<br />
'''''<br />
Clearly, '''Ts''' more closely approximates '''T<sub>v</sub>''' than it does '''T''', the error being on the order of '''±0.01°C''' in assuming '''T′ =T<sub>v</sub>′(virtual)''', compared to '''±0.05°C''' for '''T′ =T′(absolute)'''.<br />
Since virtual temperature is used sometimes in boundary layer calculations, we can safely assume sonic temperature as virtual temperature within safe experimental assumptions.<br />
<br />
<br />
[[File:Combined.png|300px|left|u calculation]]<br />
[[File:wind_vel.png|300px|center|t1 and t2 calculation]]<br />
<br />
<br />
<br />
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<sup>-2</sup>ms<sup>-1</sup>.<br />
<br />
===Timeline:===<br />
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<br />
<br />
This program is of 12 Weeks-With Evaluation phase on June 26 - 30, 2017 and July 24 - 28, 2017<br />
<br />
====First Week:====<br />
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.<br />
====Second Week:====<br />
Connect the Prudaq and take sample readings as described on their wiki example.<br />
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<br />
====Third Week:====<br />
Program the PRU to read the sample results from PRUDAQ and trigger successive generation of two axis sonic transducers.<br />
====Fourth Week:====<br />
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.<br />
'''Evaluation Goals 1:'''<br />
''The device is able to stream the results of successive measurements after every specified interval to<br />
the user space and it is stored into text file.Software Testing Units are created for possible errors.''<br />
<br />
====Fifth Week:====<br />
This week we will build the structure as portable, possibly as described in below pictures.<br />
<br />
[[File:Sonic.jpg|300px|thumb|center|PVC for easy and flexible implementation]][[File:Unknown.jpg|300px|thumbnail|center|Made of Copper and steel to heat during Cold]]<br />
<br />
====Sixth Week:====<br />
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.<br />
====Seventh Week:====<br />
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.<br />
====Eighth Week:====<br />
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.<br />
'''Evaluation Goals 2:'''<br />
''Apparatus is tested extensively for outdoors, and is able to perform functional tasks in various possible <br />
conditions and output reliable data with accuracy and have test units defined but other factors like azimuth angle <br />
or other correction algorithms would be applied in the next stage.''<br />
<br />
====Ninth Week:====<br />
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).<br />
====Tenth Week:====<br />
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).<br />
Other modifications like variable sampling frequency in case if required later by developers.<br />
====Eleventh Week:====<br />
Review all the test units created earlier during program and modify them or build new.<br />
====Final Week:====<br />
Create a REST API sort of thing that enables the reading and logging of results into remote machines and proof check all modules<br />
<br />
==Final Goals:==<br />
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.<br />
<br />
===Future/Additional Goals:===<br />
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.<br />
<br />
Other Goals that can be helped or created by us or other open source contributors<br />
<br />
1. Make A python script type to create the graph and other possible representations of the data processed.<br />
<br />
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.<br />
<br />
==Experience and Approach==<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Projects====<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
<br />
==== Participations ====<br />
* 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.<br />
* Participated on National level, in TopCoder Open Finals organised by TopCoder.<br />
<br />
==== Approach ====<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Contingency==<br />
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.<br />
<br />
==Benefit==<br />
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.<br />
<br />
'''What community members speak -'''<br />
<br />
''Great project for the Aspiring Weather Scientist.''<br />
Michael Welling('''m_w''') <br />
<br />
''A working/documented FOSS implementation would be a huge''<br />
''plus for both the open source and weather communities.''<br />
Steve Arnold('''nerdboy''') <br />
''and the best one award goes to...''<br />
''I'll be tempted to build one!''<br />
Jonathan Cameron('''jic23''')<br />
<br />
***'''''Mentors!!! please add your Quote here.'''''***<br />
<br />
==Suggestions==<br />
Nothing For Now...<br />
<br />
Thanks.</div>Thrtransformerrhttps://elinux.org/index.php?title=GSoC2017_sonic_anemometer_proposal&diff=439086GSoC2017 sonic anemometer proposal2017-04-02T10:29:02Z<p>Thrtransformerr: /* Proposal for Sonic Anemometer */</p>
<hr />
<div>[[Category: BeagleBoard]]<br />
[[Category: GSoC]]<br />
[[Category: GSoCProposal]]<br />
== Proposal for Sonic Anemometer ==<br />
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.<br />
<br />
''Idea as Quoted from GSoC Ideas page:'' <br />
Working prototype sonic anemometer using BeagleBone, PRUDAQ, and ultrasonic sensors. Analyze methods for accuracy/sensitivity <br />
(eg, time-of-flight vs. phase difference) and implement "best" method. Use PRUs for independent real-time control of ultrasonics.<br />
<br />
''Student:'' Naveen Saini<br />
<br />
''Mentors'': Steve Arnold(nerdboy), Stephanie Lockwood-Childs<br />
<br />
''Code:'' N/A<br />
<br />
''Wiki'': http://elinux.org/GSoC2017_sonic_anemometer_proposal<br />
<br />
''GSoC'': [https://github.com/thetransformerr/thetransformerr.github.io/raw/master/GSoC.pdf GSoC(SonicAnem.pdf)]<br />
<br />
==Status==<br />
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.<br />
<br />
==Proposal==<br />
I have completed the task required as described on Ideas page, and created a pull request, as listed [https://github.com/thetransformerr/gsoc-application/tree/master/ExampleEntryJasonKridner here].<br />
===About Me===<br />
''GitHub:'' [https://github.com/thetransformerr @thetransformerr]<br />
<br />
''IRC:'' thetransformerr<br />
<br />
''elinux:'' thrtransformerr<br />
<br />
''Linkedin:'' [https://www.linkedin.com/in/5naveensaini/ Naveen Saini]<br />
<br />
''School:'' [http://jecrcuniversity.edu.in JECRC,Jaipur]<br />
<br />
''Country:'' India[The mystical wonderland ;)]<br />
<br />
''Primary language:'' English,Hindi<br />
<br />
''Typical work hours:'' 08AM-10AM , 09PM-01AM Indian Standard Time(+5:30)<br />
<br />
''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.<br />
<br />
''Skills(proficient):'' C,Ruby,Javascript<br />
<br />
''Experience:'' Java,Python,Arduino,Node.js,Scala,Matlab,CAD.<br />
<br />
=== Sonic Anemometer===<br />
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.<br />
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.<br />
<br />
=== Principle of Sonic Anemometer:===<br />
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.<br />
This pair of transducers act alternately as transmitters and receivers, exchanging high-frequency ultrasound pulses between themselves. The times of flight in each direction t<sub>1</sub> and t<sub>2</sub>, 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:<br />
<br />
[[File:Time.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
By combining Eqns (1) and (2) and solving for ` v`, the following equation is obtained:<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
<br />
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. <br />
<br />
[[File:Twodim.png|400px|thumb|left|2D axis(to be aligned with compass to true north)]][[File:Threet.png|400px|thumb|center|3D axis(for reference)]]<br />
<br />
<br />
<br />
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)<br />
Now following Equations are involved here,<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:Angle.png|300px|thumb|center|Angle]]<br />
<br />
<br />
Now from above equations it is clear that speed of sound calculated this way is independent of factors such as temperatures.<br />
<br />
Now with this device we can calculate the wind speed as well as temperature as described below-<br />
[[File:Temp.jpg|300px|thumb|center|Temperature(virtual temperature)]]<br />
<br />
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. <br />
<br />
The sonic temperature, Tv (in Kelvin), may differ from the absolute temperature by an amount equal to the<br />
water vapor content in the air measured. This difference amounts to ±1°C at 20°C and decreases as the temperature decreases.<br />
<br />
===Requirement Analysis===<br />
Following are the hardware that we can start with:-<br />
* Beaglebone Black/Green(1)<br />
* PRUDAQ/ADC having rate higher than 400ksps per channel(1/2)<br />
* Transducers(40kHz,Waterproof)(4)<br />
<br />
DAQ are the Data Acquisition devices which are used to acquire data from sensors and acts as a bridge between sensors and host computer.<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
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.<br />
We can probably use second one for '''calibration''' and other tasks.<br />
<br />
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<sup>-3</sup>order) '''<br />
<br />
[[File:vari.png|900px|center|Temperature and Humidity effects]]<br />
<br />
<br />
Following graphs represents deviations of speed of sound :<br />
[[File:Tsemp.gif|400px|thumb|left|Temprature and Humidity Deviation]][[File:Spres.gif|400px|thumb|center|Pressure variation]]<br />
<br />
<br />
<br />
For 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.<br />
<br />
PRU in Beaglebone has rate of '''''200 MHz''''', hence instruction cycle of '''''5ns''''', following table shows approximate cycle required for various assembly code operations,<br />
[[File:Insc.png|600px|center|Instruction Cycles]]<br />
<br />
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.<br />
<br />
Following table shows some observations<br />
[[File:Obers.png|600px|center|Some raw observations]]<br />
<br />
<br />
Different Suitable DAQ<br />
[[File:DAiQ.png|600px|center|Some DAQ cost and capacity]]<br />
<br />
<br />
And this graph shows attenuation of waves according to their frequency, generally, higher the frequency, earlier it attenuates,<br />
[[File:Atten.png|400px|thumb|center|Attenuation Characteristics of Sound Pressure by Distance]]<br />
===WorkFlow for Data Acquistion===<br />
Consider the anemometer outputs reading of temperature and wind speed at the frequency of '''''20Hz''''', then the time period for acquiring the data from transducer and performing calculation is '''''50 milliseconds''''' for each set of reading.<br />
[[File:Daqr.png|600px|thumb|center|Pin Diagram]]<br />
[[File:Wofl.png|600px|center]]<br />
<br />
<br />
<br />
<br />
===Error Analysis===<br />
<br />
Following are the equations defined in thermodynamics for values calculated from the data:<br />
<br />
'''''c<sup>2</sup> =403T(1+0.32e/p)<br />
'''''<br />
where '''c''' is the velocity of sound ('''m s<sup>-1</sup>''') 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,<br />
<br />
'''''Ts [= T(1 + 0.32 e/p)]''''' <br />
<br />
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:<br />
<br />
'''''Tv =T(1+0.38e/p)<br />
'''''<br />
Clearly, '''Ts''' more closely approximates '''T<sub>v</sub>''' than it does '''T''', the error being on the order of '''±0.01°C''' in assuming '''T′ =T<sub>v</sub>′(virtual)''', compared to '''±0.05°C''' for '''T′ =T′(absolute)'''.<br />
Since virtual temperature is used sometimes in boundary layer calculations, we can safely assume sonic temperature as virtual temperature within safe experimental assumptions.<br />
<br />
<br />
[[File:Combined.png|300px|left|u calculation]]<br />
[[File:wind_vel.png|300px|center|t1 and t2 calculation]]<br />
<br />
<br />
<br />
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<sup>-2</sup>ms<sup>-1</sup>.<br />
<br />
===Timeline:===<br />
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<br />
<br />
This program is of 12 Weeks-With Evaluation phase on June 26 - 30, 2017 and July 24 - 28, 2017<br />
<br />
====First Week:====<br />
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.<br />
====Second Week:====<br />
Connect the Prudaq and take sample readings as described on their wiki example.<br />
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<br />
====Third Week:====<br />
Program the PRU to read the sample results from PRUDAQ and trigger successive generation of two axis sonic transducers.<br />
====Fourth Week:====<br />
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.<br />
'''Evaluation Goals 1:'''<br />
''The device is able to stream the results of successive measurements after every specified interval to<br />
the user space and it is stored into text file.Software Testing Units are created for possible errors.''<br />
<br />
====Fifth Week:====<br />
This week we will build the structure as portable, possibly as described in below pictures.<br />
<br />
[[File:Sonic.jpg|300px|thumb|center|PVC for easy and flexible implementation]][[File:Unknown.jpg|300px|thumbnail|center|Made of Copper and steel to heat during Cold]]<br />
<br />
====Sixth Week:====<br />
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.<br />
====Seventh Week:====<br />
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.<br />
====Eighth Week:====<br />
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.<br />
'''Evaluation Goals 2:'''<br />
''Apparatus is tested extensively for outdoors, and is able to perform functional tasks in various possible <br />
conditions and output reliable data with accuracy and have test units defined but other factors like azimuth angle <br />
or other correction algorithms would be applied in the next stage.''<br />
<br />
====Ninth Week:====<br />
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).<br />
====Tenth Week:====<br />
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).<br />
Other modifications like variable sampling frequency in case if required later by developers.<br />
====Eleventh Week:====<br />
Review all the test units created earlier during program and modify them or build new.<br />
====Final Week:====<br />
Create a REST API sort of thing that enables the reading and logging of results into remote machines and proof check all modules<br />
<br />
==Final Goals:==<br />
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.<br />
<br />
===Future/Additional Goals:===<br />
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.<br />
<br />
Other Goals that can be helped or created by us or other open source contributors<br />
<br />
1. Make A python script type to create the graph and other possible representations of the data processed.<br />
<br />
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.<br />
<br />
==Experience and Approach==<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Projects====<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
<br />
==== Participations ====<br />
* 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.<br />
* Participated on National level, in TopCoder Open Finals organised by TopCoder.<br />
<br />
==== Approach ====<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Contingency==<br />
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.<br />
<br />
==Benefit==<br />
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.<br />
<br />
'''What community members speak -'''<br />
<br />
''Great project for the Aspiring Weather Scientist.''<br />
Michael Welling('''m_w''') <br />
<br />
''A working/documented FOSS implementation would be a huge''<br />
''plus for both the open source and weather communities.''<br />
Steve Arnold('''nerdboy''') <br />
''and the best one award goes to...''<br />
''I'll be tempted to build one!''<br />
Jonathan Cameron('''jic23''')<br />
<br />
***'''''Mentors!!! please add your Quote here.'''''***<br />
<br />
==Suggestions==<br />
Nothing For Now...<br />
<br />
Thanks.</div>Thrtransformerrhttps://elinux.org/index.php?title=GSoC2017_sonic_anemometer_proposal&diff=439071GSoC2017 sonic anemometer proposal2017-04-02T10:21:36Z<p>Thrtransformerr: </p>
<hr />
<div>[[Category: BeagleBoard]]<br />
[[Category: GSoC]]<br />
[[Category: GSoCProposal]]<br />
== Proposal for Sonic Anemometer ==<br />
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.<br />
<br />
''Idea as Quoted from GSoC Ideas page:'' <br />
Working prototype sonic anemometer using BeagleBone, PRUDAQ, and ultrasonic sensors. Analyze methods for accuracy/sensitivity <br />
(eg, time-of-flight vs. phase difference) and implement "best" method. Use PRUs for independent real-time control of ultrasonics.<br />
<br />
''Student:'' Naveen Saini<br />
<br />
''Mentors'': Steve Arnold(nerdboy), Stephanie Lockwood-Childs<br />
<br />
''Code:'' N/A<br />
<br />
''Wiki'': http://elinux.org/GSoC2017_sonic_anemometer_proposal<br />
<br />
''GSoC'': N/A<br />
<br />
==Status==<br />
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.<br />
<br />
==Proposal==<br />
I have completed the task required as described on Ideas page, and created a pull request, as listed [https://github.com/thetransformerr/gsoc-application/tree/master/ExampleEntryJasonKridner here].<br />
===About Me===<br />
''GitHub:'' [https://github.com/thetransformerr @thetransformerr]<br />
<br />
''IRC:'' thetransformerr<br />
<br />
''elinux:'' thrtransformerr<br />
<br />
''Linkedin:'' [https://www.linkedin.com/in/5naveensaini/ Naveen Saini]<br />
<br />
''School:'' [http://jecrcuniversity.edu.in JECRC,Jaipur]<br />
<br />
''Country:'' India[The mystical wonderland ;)]<br />
<br />
''Primary language:'' English,Hindi<br />
<br />
''Typical work hours:'' 08AM-10AM , 09PM-01AM Indian Standard Time(+5:30)<br />
<br />
''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.<br />
<br />
''Skills(proficient):'' C,Ruby,Javascript<br />
<br />
''Experience:'' Java,Python,Arduino,Node.js,Scala,Matlab,CAD.<br />
<br />
=== Sonic Anemometer===<br />
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.<br />
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.<br />
<br />
=== Principle of Sonic Anemometer:===<br />
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.<br />
This pair of transducers act alternately as transmitters and receivers, exchanging high-frequency ultrasound pulses between themselves. The times of flight in each direction t<sub>1</sub> and t<sub>2</sub>, 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:<br />
<br />
[[File:Time.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
By combining Eqns (1) and (2) and solving for ` v`, the following equation is obtained:<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
<br />
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. <br />
<br />
[[File:Twodim.png|400px|thumb|left|2D axis(to be aligned with compass to true north)]][[File:Threet.png|400px|thumb|center|3D axis(for reference)]]<br />
<br />
<br />
<br />
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)<br />
Now following Equations are involved here,<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:Angle.png|300px|thumb|center|Angle]]<br />
<br />
<br />
Now from above equations it is clear that speed of sound calculated this way is independent of factors such as temperatures.<br />
<br />
Now with this device we can calculate the wind speed as well as temperature as described below-<br />
[[File:Temp.jpg|300px|thumb|center|Temperature(virtual temperature)]]<br />
<br />
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. <br />
<br />
The sonic temperature, Tv (in Kelvin), may differ from the absolute temperature by an amount equal to the<br />
water vapor content in the air measured. This difference amounts to ±1°C at 20°C and decreases as the temperature decreases.<br />
<br />
===Requirement Analysis===<br />
Following are the hardware that we can start with:-<br />
* Beaglebone Black/Green(1)<br />
* PRUDAQ/ADC having rate higher than 400ksps per channel(1/2)<br />
* Transducers(40kHz,Waterproof)(4)<br />
<br />
DAQ are the Data Acquisition devices which are used to acquire data from sensors and acts as a bridge between sensors and host computer.<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
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.<br />
We can probably use second one for '''calibration''' and other tasks.<br />
<br />
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<sup>-3</sup>order) '''<br />
<br />
[[File:vari.png|900px|center|Temperature and Humidity effects]]<br />
<br />
<br />
Following graphs represents deviations of speed of sound :<br />
[[File:Tsemp.gif|400px|thumb|left|Temprature and Humidity Deviation]][[File:Spres.gif|400px|thumb|center|Pressure variation]]<br />
<br />
<br />
<br />
For 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.<br />
<br />
PRU in Beaglebone has rate of '''''200 MHz''''', hence instruction cycle of '''''5ns''''', following table shows approximate cycle required for various assembly code operations,<br />
[[File:Insc.png|600px|center|Instruction Cycles]]<br />
<br />
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.<br />
<br />
Following table shows some observations<br />
[[File:Obers.png|600px|center|Some raw observations]]<br />
<br />
<br />
Different Suitable DAQ<br />
[[File:DAiQ.png|600px|center|Some DAQ cost and capacity]]<br />
<br />
<br />
And this graph shows attenuation of waves according to their frequency, generally, higher the frequency, earlier it attenuates,<br />
[[File:Atten.png|400px|thumb|center|Attenuation Characteristics of Sound Pressure by Distance]]<br />
===WorkFlow for Data Acquistion===<br />
Consider the anemometer outputs reading of temperature and wind speed at the frequency of '''''20Hz''''', then the time period for acquiring the data from transducer and performing calculation is '''''50 milliseconds''''' for each set of reading.<br />
[[File:Daqr.png|600px|thumb|center|Pin Diagram]]<br />
[[File:Wofl.png|600px|center]]<br />
<br />
<br />
<br />
<br />
===Error Analysis===<br />
<br />
Following are the equations defined in thermodynamics for values calculated from the data:<br />
<br />
'''''c<sup>2</sup> =403T(1+0.32e/p)<br />
'''''<br />
where '''c''' is the velocity of sound ('''m s<sup>-1</sup>''') 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,<br />
<br />
'''''Ts [= T(1 + 0.32 e/p)]''''' <br />
<br />
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:<br />
<br />
'''''Tv =T(1+0.38e/p)<br />
'''''<br />
Clearly, '''Ts''' more closely approximates '''T<sub>v</sub>''' than it does '''T''', the error being on the order of '''±0.01°C''' in assuming '''T′ =T<sub>v</sub>′(virtual)''', compared to '''±0.05°C''' for '''T′ =T′(absolute)'''.<br />
Since virtual temperature is used sometimes in boundary layer calculations, we can safely assume sonic temperature as virtual temperature within safe experimental assumptions.<br />
<br />
<br />
[[File:Combined.png|300px|left|u calculation]]<br />
[[File:wind_vel.png|300px|center|t1 and t2 calculation]]<br />
<br />
<br />
<br />
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<sup>-2</sup>ms<sup>-1</sup>.<br />
<br />
===Timeline:===<br />
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<br />
<br />
This program is of 12 Weeks-With Evaluation phase on June 26 - 30, 2017 and July 24 - 28, 2017<br />
<br />
====First Week:====<br />
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.<br />
====Second Week:====<br />
Connect the Prudaq and take sample readings as described on their wiki example.<br />
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<br />
====Third Week:====<br />
Program the PRU to read the sample results from PRUDAQ and trigger successive generation of two axis sonic transducers.<br />
====Fourth Week:====<br />
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.<br />
'''Evaluation Goals 1:'''<br />
''The device is able to stream the results of successive measurements after every specified interval to<br />
the user space and it is stored into text file.Software Testing Units are created for possible errors.''<br />
<br />
====Fifth Week:====<br />
This week we will build the structure as portable, possibly as described in below pictures.<br />
<br />
[[File:Sonic.jpg|300px|thumb|center|PVC for easy and flexible implementation]][[File:Unknown.jpg|300px|thumbnail|center|Made of Copper and steel to heat during Cold]]<br />
<br />
====Sixth Week:====<br />
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.<br />
====Seventh Week:====<br />
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.<br />
====Eighth Week:====<br />
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.<br />
'''Evaluation Goals 2:'''<br />
''Apparatus is tested extensively for outdoors, and is able to perform functional tasks in various possible <br />
conditions and output reliable data with accuracy and have test units defined but other factors like azimuth angle <br />
or other correction algorithms would be applied in the next stage.''<br />
<br />
====Ninth Week:====<br />
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).<br />
====Tenth Week:====<br />
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).<br />
Other modifications like variable sampling frequency in case if required later by developers.<br />
====Eleventh Week:====<br />
Review all the test units created earlier during program and modify them or build new.<br />
====Final Week:====<br />
Create a REST API sort of thing that enables the reading and logging of results into remote machines and proof check all modules<br />
<br />
==Final Goals:==<br />
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.<br />
<br />
===Future/Additional Goals:===<br />
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.<br />
<br />
Other Goals that can be helped or created by us or other open source contributors<br />
<br />
1. Make A python script type to create the graph and other possible representations of the data processed.<br />
<br />
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.<br />
<br />
==Experience and Approach==<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Projects====<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
<br />
==== Participations ====<br />
* 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.<br />
* Participated on National level, in TopCoder Open Finals organised by TopCoder.<br />
<br />
==== Approach ====<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Contingency==<br />
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.<br />
<br />
==Benefit==<br />
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.<br />
<br />
'''What community members speak -'''<br />
<br />
''Great project for the Aspiring Weather Scientist.''<br />
Michael Welling('''m_w''') <br />
<br />
''A working/documented FOSS implementation would be a huge''<br />
''plus for both the open source and weather communities.''<br />
Steve Arnold('''nerdboy''') <br />
''and the best one award goes to...''<br />
''I'll be tempted to build one!''<br />
Jonathan Cameron('''jic23''')<br />
<br />
***'''''Mentors!!! please add your Quote here.'''''***<br />
<br />
==Suggestions==<br />
Nothing For Now...<br />
<br />
Thanks.</div>Thrtransformerrhttps://elinux.org/index.php?title=File:Wofl.png&diff=439066File:Wofl.png2017-04-02T10:18:03Z<p>Thrtransformerr: Thrtransformerr uploaded a new version of File:Wofl.png</p>
<hr />
<div></div>Thrtransformerrhttps://elinux.org/index.php?title=File:Wofl.png&diff=439056File:Wofl.png2017-04-02T09:01:34Z<p>Thrtransformerr: </p>
<hr />
<div></div>Thrtransformerrhttps://elinux.org/index.php?title=GSoC2017_sonic_anemometer_proposal&diff=438761GSoC2017 sonic anemometer proposal2017-03-31T20:25:22Z<p>Thrtransformerr: /* Benefit */</p>
<hr />
<div>[[Category: BeagleBoard]]<br />
[[Category: GSoC]]<br />
[[Category: GSoCProposal]]<br />
== Proposal for Sonic Anemometer ==<br />
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.<br />
<br />
''Idea as Quoted from GSoC Ideas page:'' <br />
Working prototype sonic anemometer using BeagleBone, PRUDAQ, and ultrasonic sensors. Analyze methods for accuracy/sensitivity <br />
(eg, time-of-flight vs. phase difference) and implement "best" method. Use PRUs for independent real-time control of ultrasonics.<br />
<br />
''Student:'' Naveen Saini<br />
<br />
''Mentors'': Steve Arnold(nerdboy), Stephanie Lockwood-Childs<br />
<br />
''Code:'' N/A<br />
<br />
''Wiki'': http://elinux.org/GSoC2017_sonic_anemometer_proposal<br />
<br />
''GSoC'': N/A<br />
<br />
==Status==<br />
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.<br />
<br />
==Proposal==<br />
I have completed the task required as described on Ideas page, and created a pull request, as listed [https://github.com/thetransformerr/gsoc-application/tree/master/ExampleEntryJasonKridner here].<br />
===About Me===<br />
''GitHub:'' [https://github.com/thetransformerr @thetransformerr]<br />
<br />
''IRC:'' thetransformerr<br />
<br />
''elinux:'' thrtransformerr<br />
<br />
''Linkedin:'' [https://www.linkedin.com/in/5naveensaini/ Naveen Saini]<br />
<br />
''School:'' [http://jecrcuniversity.edu.in JECRC,Jaipur]<br />
<br />
''Country:'' India[The mystical wonderland ;)]<br />
<br />
''Primary language:'' English,Hindi<br />
<br />
''Typical work hours:'' 08AM-10AM , 09PM-01AM Indian Standard Time(+5:30)<br />
<br />
''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.<br />
<br />
''Skills(proficient):'' C,Ruby,Javascript<br />
<br />
''Experience:'' Java,Python,Arduino,Node.js,Scala,Matlab,CAD.<br />
<br />
=== Sonic Anemometer===<br />
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.<br />
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.<br />
<br />
=== Principle of Sonic Anemometer:===<br />
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.<br />
This pair of transducers act alternately as transmitters and receivers, exchanging high-frequency ultrasound pulses between themselves. The times of flight in each direction t<sub>1</sub> and t<sub>2</sub>, 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:<br />
<br />
[[File:Time.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
By combining Eqns (1) and (2) and solving for ` v`, the following equation is obtained:<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
<br />
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. <br />
<br />
[[File:Twodim.png|400px|thumb|left|2D axis(to be aligned with compass to true north)]][[File:Threet.png|400px|thumb|center|3D axis(for reference)]]<br />
<br />
<br />
<br />
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)<br />
Now following Equations are involved here,<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:Angle.png|300px|thumb|center|Angle]]<br />
<br />
<br />
Now from above equations it is clear that speed of sound calculated this way is independent of factors such as temperatures.<br />
<br />
Now with this device we can calculate the wind speed as well as temperature as described below-<br />
[[File:Temp.jpg|300px|thumb|center|Temperature(virtual temperature)]]<br />
<br />
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. <br />
<br />
The sonic temperature, Tv (in Kelvin), may differ from the absolute temperature by an amount equal to the<br />
water vapor content in the air measured. This difference amounts to ±1°C at 20°C and decreases as the temperature decreases.<br />
<br />
===PRUDAQ===<br />
<br />
DAQ are the Data Acquisition devices which are used to acquire data from sensors and acts as a bridge between sensors and host computer.<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
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.<br />
We can probably use second one for '''calibration''' and other tasks.<br />
<br />
===Requirement Analysis===<br />
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<sup>-3</sup>order) '''<br />
<br />
[[File:vari.png|900px|center|Temperature and Humidity effects]]<br />
<br />
<br />
Following graphs represents deviations of speed of sound :<br />
[[File:Tsemp.gif|400px|thumb|left|Temprature and Humidity Deviation]][[File:Spres.gif|400px|thumb|center|Pressure variation]]<br />
<br />
<br />
<br />
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.<br />
<br />
PRU in Beaglebone has rate of '''''200 MHz''''', hence instruction cycle of '''''5ns''''', following table shows approximate cycle required for various assembly code operations,<br />
[[File:Insc.png|600px|center|Instruction Cycles]]<br />
<br />
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.<br />
<br />
Following table shows some observations<br />
[[File:Obers.png|600px|center|Some raw observations]]<br />
<br />
<br />
Different Suitable DAQ<br />
[[File:DAiQ.png|600px|center|Some DAQ cost and capacity]]<br />
<br />
<br />
And this graph shows attenuation of waves according to their frequency, generally, higher the frequency, earlier it attenuates,<br />
[[File:Atten.png|400px|thumb|center|Attenuation Characteristics of Sound Pressure by Distance]]<br />
<br />
Hence following are the hardware that we can start with:-<br />
* Beaglebone Black/Green(1)<br />
* PRUDAQ/ADC having rate higher than 400ksps per channel(1/2)<br />
* Transducers(40kHz,Waterproof)(4)<br />
<br />
Min. Time required before new set measurement:<br />
<br />
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'''''.<br />
<br />
[[File:Daqr.png|600px|thumb|center|Pin Diagram]][[File:Tabl1.png|500px|center|Data Acquisition Cycles]]<br />
<br />
<br />
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.<br />
<br />
===Error Analysis===<br />
<br />
Following are the equations defined in thermodynamics for values calculated from the data:<br />
<br />
'''''c<sup>2</sup> =403T(1+0.32e/p)<br />
'''''<br />
where '''c''' is the velocity of sound ('''m s<sup>-1</sup>''') 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,<br />
<br />
'''''Ts [= T(1 + 0.32 e/p)]''''' <br />
<br />
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:<br />
<br />
'''''Tv =T(1+0.38e/p)<br />
'''''<br />
Clearly, '''Ts''' more closely approximates '''T<sub>v</sub>''' than it does '''T''', the error being on the order of '''±0.01°C''' in assuming '''T′ =T<sub>v</sub>′(virtual)''', compared to '''±0.05°C''' for '''T′ =T′(absolute)'''.<br />
Since virtual temperature is used sometimes in boundary layer calculations, we can safely assume sonic temperature as virtual temperature within safe experimental assumptions.<br />
<br />
<br />
[[File:Combined.png|300px|left|u calculation]]<br />
[[File:wind_vel.png|300px|center|t1 and t2 calculation]]<br />
<br />
<br />
<br />
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<sup>-2</sup>ms<sup>-1</sup>.<br />
<br />
===Timeline:===<br />
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<br />
<br />
This program is of 12 Weeks-With Evaluation phase on June 26 - 30, 2017 and July 24 - 28, 2017<br />
<br />
====First Week:====<br />
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.<br />
====Second Week:====<br />
Connect the Prudaq and take sample readings as described on their wiki example.<br />
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<br />
====Third Week:====<br />
Program the PRU to read the sample results from PRUDAQ and trigger successive generation of two axis sonic transducers.<br />
====Fourth Week:====<br />
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.<br />
'''Evaluation Goals 1:'''<br />
''The device is able to stream the results of successive measurements after every specified interval to<br />
the user space and it is stored into text file.Software Testing Units are created for possible errors.''<br />
<br />
====Fifth Week:====<br />
This week we will build the structure as portable, possibly as described in below pictures.<br />
<br />
[[File:Sonic.jpg|300px|thumb|center|PVC for easy and flexible implementation]][[File:Unknown.jpg|300px|thumbnail|center|Made of Copper and steel to heat during Cold]]<br />
<br />
====Sixth Week:====<br />
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.<br />
====Seventh Week:====<br />
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.<br />
====Eighth Week:====<br />
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.<br />
'''Evaluation Goals 2:'''<br />
''Apparatus is tested extensively for outdoors, and is able to perform functional tasks in various possible <br />
conditions and output reliable data with accuracy and have test units defined but other factors like azimuth angle <br />
or other correction algorithms would be applied in the next stage.''<br />
<br />
====Ninth Week:====<br />
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).<br />
====Tenth Week:====<br />
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).<br />
Other modifications like variable sampling frequency in case if required later by developers.<br />
====Eleventh Week:====<br />
Review all the test units created earlier during program and modify them or build new.<br />
====Final Week:====<br />
Create a REST API sort of thing that enables the reading and logging of results into remote machines and proof check all modules<br />
<br />
==Final Goals:==<br />
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.<br />
<br />
===Future/Additional Goals:===<br />
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.<br />
<br />
Other Goals that can be helped or created by us or other open source contributors<br />
<br />
1. Make A python script type to create the graph and other possible representations of the data processed.<br />
<br />
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.<br />
<br />
==Experience and Approach==<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Projects====<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
<br />
==== Participations ====<br />
* 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.<br />
* Participated on National level, in TopCoder Open Finals organised by TopCoder.<br />
<br />
==== Approach ====<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Contingency==<br />
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.<br />
<br />
==Benefit==<br />
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.<br />
<br />
'''What community members speak -'''<br />
<br />
''Great project for the Aspiring Weather Scientist.''<br />
Michael Welling('''m_w''') <br />
<br />
''A working/documented FOSS implementation would be a huge''<br />
''plus for both the open source and weather communities.''<br />
Steve Arnold('''nerdboy''') <br />
''and the best one award goes to...''<br />
''I'll be tempted to build one!''<br />
Jonathan Cameron('''jic23''')<br />
<br />
***'''''Mentors!!! please add your Quote here.'''''***<br />
<br />
==Suggestions==<br />
Nothing For Now...<br />
<br />
Thanks.</div>Thrtransformerrhttps://elinux.org/index.php?title=GSoC2017_sonic_anemometer_proposal&diff=438676GSoC2017 sonic anemometer proposal2017-03-31T03:11:29Z<p>Thrtransformerr: /* Error Analysis */</p>
<hr />
<div>[[Category: BeagleBoard]]<br />
[[Category: GSoC]]<br />
[[Category: GSoCProposal]]<br />
== Proposal for Sonic Anemometer ==<br />
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.<br />
<br />
''Idea as Quoted from GSoC Ideas page:'' <br />
Working prototype sonic anemometer using BeagleBone, PRUDAQ, and ultrasonic sensors. Analyze methods for accuracy/sensitivity <br />
(eg, time-of-flight vs. phase difference) and implement "best" method. Use PRUs for independent real-time control of ultrasonics.<br />
<br />
''Student:'' Naveen Saini<br />
<br />
''Mentors'': Steve Arnold(nerdboy), Stephanie Lockwood-Childs<br />
<br />
''Code:'' N/A<br />
<br />
''Wiki'': http://elinux.org/GSoC2017_sonic_anemometer_proposal<br />
<br />
''GSoC'': N/A<br />
<br />
==Status==<br />
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.<br />
<br />
==Proposal==<br />
I have completed the task required as described on Ideas page, and created a pull request, as listed [https://github.com/thetransformerr/gsoc-application/tree/master/ExampleEntryJasonKridner here].<br />
===About Me===<br />
''GitHub:'' [https://github.com/thetransformerr @thetransformerr]<br />
<br />
''IRC:'' thetransformerr<br />
<br />
''elinux:'' thrtransformerr<br />
<br />
''Linkedin:'' [https://www.linkedin.com/in/5naveensaini/ Naveen Saini]<br />
<br />
''School:'' [http://jecrcuniversity.edu.in JECRC,Jaipur]<br />
<br />
''Country:'' India[The mystical wonderland ;)]<br />
<br />
''Primary language:'' English,Hindi<br />
<br />
''Typical work hours:'' 08AM-10AM , 09PM-01AM Indian Standard Time(+5:30)<br />
<br />
''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.<br />
<br />
''Skills(proficient):'' C,Ruby,Javascript<br />
<br />
''Experience:'' Java,Python,Arduino,Node.js,Scala,Matlab,CAD.<br />
<br />
=== Sonic Anemometer===<br />
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.<br />
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.<br />
<br />
=== Principle of Sonic Anemometer:===<br />
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.<br />
This pair of transducers act alternately as transmitters and receivers, exchanging high-frequency ultrasound pulses between themselves. The times of flight in each direction t<sub>1</sub> and t<sub>2</sub>, 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:<br />
<br />
[[File:Time.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
By combining Eqns (1) and (2) and solving for ` v`, the following equation is obtained:<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
<br />
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. <br />
<br />
[[File:Twodim.png|400px|thumb|left|2D axis(to be aligned with compass to true north)]][[File:Threet.png|400px|thumb|center|3D axis(for reference)]]<br />
<br />
<br />
<br />
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)<br />
Now following Equations are involved here,<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:Angle.png|300px|thumb|center|Angle]]<br />
<br />
<br />
Now from above equations it is clear that speed of sound calculated this way is independent of factors such as temperatures.<br />
<br />
Now with this device we can calculate the wind speed as well as temperature as described below-<br />
[[File:Temp.jpg|300px|thumb|center|Temperature(virtual temperature)]]<br />
<br />
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. <br />
<br />
The sonic temperature, Tv (in Kelvin), may differ from the absolute temperature by an amount equal to the<br />
water vapor content in the air measured. This difference amounts to ±1°C at 20°C and decreases as the temperature decreases.<br />
<br />
===PRUDAQ===<br />
<br />
DAQ are the Data Acquisition devices which are used to acquire data from sensors and acts as a bridge between sensors and host computer.<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
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.<br />
We can probably use second one for '''calibration''' and other tasks.<br />
<br />
===Requirement Analysis===<br />
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<sup>-3</sup>order) '''<br />
<br />
[[File:vari.png|900px|center|Temperature and Humidity effects]]<br />
<br />
<br />
Following graphs represents deviations of speed of sound :<br />
[[File:Tsemp.gif|400px|thumb|left|Temprature and Humidity Deviation]][[File:Spres.gif|400px|thumb|center|Pressure variation]]<br />
<br />
<br />
<br />
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.<br />
<br />
PRU in Beaglebone has rate of '''''200 MHz''''', hence instruction cycle of '''''5ns''''', following table shows approximate cycle required for various assembly code operations,<br />
[[File:Insc.png|600px|center|Instruction Cycles]]<br />
<br />
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.<br />
<br />
Following table shows some observations<br />
[[File:Obers.png|600px|center|Some raw observations]]<br />
<br />
<br />
Different Suitable DAQ<br />
[[File:DAiQ.png|600px|center|Some DAQ cost and capacity]]<br />
<br />
<br />
And this graph shows attenuation of waves according to their frequency, generally, higher the frequency, earlier it attenuates,<br />
[[File:Atten.png|400px|thumb|center|Attenuation Characteristics of Sound Pressure by Distance]]<br />
<br />
Hence following are the hardware that we can start with:-<br />
* Beaglebone Black/Green(1)<br />
* PRUDAQ/ADC having rate higher than 400ksps per channel(1/2)<br />
* Transducers(40kHz,Waterproof)(4)<br />
<br />
Min. Time required before new set measurement:<br />
<br />
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'''''.<br />
<br />
[[File:Daqr.png|600px|thumb|center|Pin Diagram]][[File:Tabl1.png|500px|center|Data Acquisition Cycles]]<br />
<br />
<br />
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.<br />
<br />
===Error Analysis===<br />
<br />
Following are the equations defined in thermodynamics for values calculated from the data:<br />
<br />
'''''c<sup>2</sup> =403T(1+0.32e/p)<br />
'''''<br />
where '''c''' is the velocity of sound ('''m s<sup>-1</sup>''') 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,<br />
<br />
'''''Ts [= T(1 + 0.32 e/p)]''''' <br />
<br />
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:<br />
<br />
'''''Tv =T(1+0.38e/p)<br />
'''''<br />
Clearly, '''Ts''' more closely approximates '''T<sub>v</sub>''' than it does '''T''', the error being on the order of '''±0.01°C''' in assuming '''T′ =T<sub>v</sub>′(virtual)''', compared to '''±0.05°C''' for '''T′ =T′(absolute)'''.<br />
Since virtual temperature is used sometimes in boundary layer calculations, we can safely assume sonic temperature as virtual temperature within safe experimental assumptions.<br />
<br />
<br />
[[File:Combined.png|300px|left|u calculation]]<br />
[[File:wind_vel.png|300px|center|t1 and t2 calculation]]<br />
<br />
<br />
<br />
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<sup>-2</sup>ms<sup>-1</sup>.<br />
<br />
===Timeline:===<br />
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<br />
<br />
This program is of 12 Weeks-With Evaluation phase on June 26 - 30, 2017 and July 24 - 28, 2017<br />
<br />
====First Week:====<br />
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.<br />
====Second Week:====<br />
Connect the Prudaq and take sample readings as described on their wiki example.<br />
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<br />
====Third Week:====<br />
Program the PRU to read the sample results from PRUDAQ and trigger successive generation of two axis sonic transducers.<br />
====Fourth Week:====<br />
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.<br />
'''Evaluation Goals 1:'''<br />
''The device is able to stream the results of successive measurements after every specified interval to<br />
the user space and it is stored into text file.Software Testing Units are created for possible errors.''<br />
<br />
====Fifth Week:====<br />
This week we will build the structure as portable, possibly as described in below pictures.<br />
<br />
[[File:Sonic.jpg|300px|thumb|center|PVC for easy and flexible implementation]][[File:Unknown.jpg|300px|thumbnail|center|Made of Copper and steel to heat during Cold]]<br />
<br />
====Sixth Week:====<br />
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.<br />
====Seventh Week:====<br />
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.<br />
====Eighth Week:====<br />
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.<br />
'''Evaluation Goals 2:'''<br />
''Apparatus is tested extensively for outdoors, and is able to perform functional tasks in various possible <br />
conditions and output reliable data with accuracy and have test units defined but other factors like azimuth angle <br />
or other correction algorithms would be applied in the next stage.''<br />
<br />
====Ninth Week:====<br />
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).<br />
====Tenth Week:====<br />
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).<br />
Other modifications like variable sampling frequency in case if required later by developers.<br />
====Eleventh Week:====<br />
Review all the test units created earlier during program and modify them or build new.<br />
====Final Week:====<br />
Create a REST API sort of thing that enables the reading and logging of results into remote machines and proof check all modules<br />
<br />
==Final Goals:==<br />
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.<br />
<br />
===Future/Additional Goals:===<br />
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.<br />
<br />
Other Goals that can be helped or created by us or other open source contributors<br />
<br />
1. Make A python script type to create the graph and other possible representations of the data processed.<br />
<br />
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.<br />
<br />
==Experience and Approach==<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Projects====<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
<br />
==== Participations ====<br />
* 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.<br />
* Participated on National level, in TopCoder Open Finals organised by TopCoder.<br />
<br />
==== Approach ====<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Contingency==<br />
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.<br />
<br />
==Benefit==<br />
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.<br />
<br />
'''What community members speak -'''<br />
<br />
''Great project for the Aspiring Weather Scientist.''<br />
Michael Welling('''m_w''') <br />
<br />
***'''''Mentors!!! please add your Quote here.'''''***<br />
<br />
==Suggestions==<br />
Nothing For Now...<br />
<br />
Thanks.</div>Thrtransformerrhttps://elinux.org/index.php?title=GSoC2017_sonic_anemometer_proposal&diff=438671GSoC2017 sonic anemometer proposal2017-03-31T03:10:33Z<p>Thrtransformerr: /* Error Analysis */</p>
<hr />
<div>[[Category: BeagleBoard]]<br />
[[Category: GSoC]]<br />
[[Category: GSoCProposal]]<br />
== Proposal for Sonic Anemometer ==<br />
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.<br />
<br />
''Idea as Quoted from GSoC Ideas page:'' <br />
Working prototype sonic anemometer using BeagleBone, PRUDAQ, and ultrasonic sensors. Analyze methods for accuracy/sensitivity <br />
(eg, time-of-flight vs. phase difference) and implement "best" method. Use PRUs for independent real-time control of ultrasonics.<br />
<br />
''Student:'' Naveen Saini<br />
<br />
''Mentors'': Steve Arnold(nerdboy), Stephanie Lockwood-Childs<br />
<br />
''Code:'' N/A<br />
<br />
''Wiki'': http://elinux.org/GSoC2017_sonic_anemometer_proposal<br />
<br />
''GSoC'': N/A<br />
<br />
==Status==<br />
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.<br />
<br />
==Proposal==<br />
I have completed the task required as described on Ideas page, and created a pull request, as listed [https://github.com/thetransformerr/gsoc-application/tree/master/ExampleEntryJasonKridner here].<br />
===About Me===<br />
''GitHub:'' [https://github.com/thetransformerr @thetransformerr]<br />
<br />
''IRC:'' thetransformerr<br />
<br />
''elinux:'' thrtransformerr<br />
<br />
''Linkedin:'' [https://www.linkedin.com/in/5naveensaini/ Naveen Saini]<br />
<br />
''School:'' [http://jecrcuniversity.edu.in JECRC,Jaipur]<br />
<br />
''Country:'' India[The mystical wonderland ;)]<br />
<br />
''Primary language:'' English,Hindi<br />
<br />
''Typical work hours:'' 08AM-10AM , 09PM-01AM Indian Standard Time(+5:30)<br />
<br />
''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.<br />
<br />
''Skills(proficient):'' C,Ruby,Javascript<br />
<br />
''Experience:'' Java,Python,Arduino,Node.js,Scala,Matlab,CAD.<br />
<br />
=== Sonic Anemometer===<br />
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.<br />
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.<br />
<br />
=== Principle of Sonic Anemometer:===<br />
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.<br />
This pair of transducers act alternately as transmitters and receivers, exchanging high-frequency ultrasound pulses between themselves. The times of flight in each direction t<sub>1</sub> and t<sub>2</sub>, 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:<br />
<br />
[[File:Time.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
By combining Eqns (1) and (2) and solving for ` v`, the following equation is obtained:<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
<br />
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. <br />
<br />
[[File:Twodim.png|400px|thumb|left|2D axis(to be aligned with compass to true north)]][[File:Threet.png|400px|thumb|center|3D axis(for reference)]]<br />
<br />
<br />
<br />
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)<br />
Now following Equations are involved here,<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:Angle.png|300px|thumb|center|Angle]]<br />
<br />
<br />
Now from above equations it is clear that speed of sound calculated this way is independent of factors such as temperatures.<br />
<br />
Now with this device we can calculate the wind speed as well as temperature as described below-<br />
[[File:Temp.jpg|300px|thumb|center|Temperature(virtual temperature)]]<br />
<br />
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. <br />
<br />
The sonic temperature, Tv (in Kelvin), may differ from the absolute temperature by an amount equal to the<br />
water vapor content in the air measured. This difference amounts to ±1°C at 20°C and decreases as the temperature decreases.<br />
<br />
===PRUDAQ===<br />
<br />
DAQ are the Data Acquisition devices which are used to acquire data from sensors and acts as a bridge between sensors and host computer.<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
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.<br />
We can probably use second one for '''calibration''' and other tasks.<br />
<br />
===Requirement Analysis===<br />
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<sup>-3</sup>order) '''<br />
<br />
[[File:vari.png|900px|center|Temperature and Humidity effects]]<br />
<br />
<br />
Following graphs represents deviations of speed of sound :<br />
[[File:Tsemp.gif|400px|thumb|left|Temprature and Humidity Deviation]][[File:Spres.gif|400px|thumb|center|Pressure variation]]<br />
<br />
<br />
<br />
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.<br />
<br />
PRU in Beaglebone has rate of '''''200 MHz''''', hence instruction cycle of '''''5ns''''', following table shows approximate cycle required for various assembly code operations,<br />
[[File:Insc.png|600px|center|Instruction Cycles]]<br />
<br />
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.<br />
<br />
Following table shows some observations<br />
[[File:Obers.png|600px|center|Some raw observations]]<br />
<br />
<br />
Different Suitable DAQ<br />
[[File:DAiQ.png|600px|center|Some DAQ cost and capacity]]<br />
<br />
<br />
And this graph shows attenuation of waves according to their frequency, generally, higher the frequency, earlier it attenuates,<br />
[[File:Atten.png|400px|thumb|center|Attenuation Characteristics of Sound Pressure by Distance]]<br />
<br />
Hence following are the hardware that we can start with:-<br />
* Beaglebone Black/Green(1)<br />
* PRUDAQ/ADC having rate higher than 400ksps per channel(1/2)<br />
* Transducers(40kHz,Waterproof)(4)<br />
<br />
Min. Time required before new set measurement:<br />
<br />
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'''''.<br />
<br />
[[File:Daqr.png|600px|thumb|center|Pin Diagram]][[File:Tabl1.png|500px|center|Data Acquisition Cycles]]<br />
<br />
<br />
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.<br />
<br />
===Error Analysis===<br />
<br />
Following are the equations defined in thermodynamics for values calculated from the data:<br />
<br />
'''''c<sup>2</sup> =403T(1+0.32e/p)<br />
'''''<br />
where '''c''' is the velocity of sound ('''m s<sup>-1</sup>''') 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,<br />
<br />
'''''Ts [= T(1 + 0.32 e/p)]''''' <br />
<br />
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:<br />
<br />
'''''Tv =T(1+0.38e/p)<br />
'''''<br />
Clearly, '''Ts''' more closely approximates '''T<sub>v</sub>''' than it does '''T''', the error being on the order of '''±0.01°C''' in assuming '''T′ =T<sub>v</sub>′(virtual)''', compared to '''±0.05°C''' for '''T′ =T′(absolute)'''.<br />
Since virtual temperature is used sometimes in boundary layer calculations, we can safely assume sonic temperature as virtual temperature within safe experimental assumptions.<br />
<br />
[[File:Combined.png|300px|center|u calculation]]<br />
[[File:wind_vel.png|300px|center|t1 and t2 calculation]]<br />
<br />
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<sup>-2</sup>ms<sup>-1</sup>.<br />
<br />
===Timeline:===<br />
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<br />
<br />
This program is of 12 Weeks-With Evaluation phase on June 26 - 30, 2017 and July 24 - 28, 2017<br />
<br />
====First Week:====<br />
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.<br />
====Second Week:====<br />
Connect the Prudaq and take sample readings as described on their wiki example.<br />
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<br />
====Third Week:====<br />
Program the PRU to read the sample results from PRUDAQ and trigger successive generation of two axis sonic transducers.<br />
====Fourth Week:====<br />
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.<br />
'''Evaluation Goals 1:'''<br />
''The device is able to stream the results of successive measurements after every specified interval to<br />
the user space and it is stored into text file.Software Testing Units are created for possible errors.''<br />
<br />
====Fifth Week:====<br />
This week we will build the structure as portable, possibly as described in below pictures.<br />
<br />
[[File:Sonic.jpg|300px|thumb|center|PVC for easy and flexible implementation]][[File:Unknown.jpg|300px|thumbnail|center|Made of Copper and steel to heat during Cold]]<br />
<br />
====Sixth Week:====<br />
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.<br />
====Seventh Week:====<br />
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.<br />
====Eighth Week:====<br />
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.<br />
'''Evaluation Goals 2:'''<br />
''Apparatus is tested extensively for outdoors, and is able to perform functional tasks in various possible <br />
conditions and output reliable data with accuracy and have test units defined but other factors like azimuth angle <br />
or other correction algorithms would be applied in the next stage.''<br />
<br />
====Ninth Week:====<br />
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).<br />
====Tenth Week:====<br />
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).<br />
Other modifications like variable sampling frequency in case if required later by developers.<br />
====Eleventh Week:====<br />
Review all the test units created earlier during program and modify them or build new.<br />
====Final Week:====<br />
Create a REST API sort of thing that enables the reading and logging of results into remote machines and proof check all modules<br />
<br />
==Final Goals:==<br />
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.<br />
<br />
===Future/Additional Goals:===<br />
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.<br />
<br />
Other Goals that can be helped or created by us or other open source contributors<br />
<br />
1. Make A python script type to create the graph and other possible representations of the data processed.<br />
<br />
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.<br />
<br />
==Experience and Approach==<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Projects====<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
<br />
==== Participations ====<br />
* 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.<br />
* Participated on National level, in TopCoder Open Finals organised by TopCoder.<br />
<br />
==== Approach ====<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Contingency==<br />
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.<br />
<br />
==Benefit==<br />
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.<br />
<br />
'''What community members speak -'''<br />
<br />
''Great project for the Aspiring Weather Scientist.''<br />
Michael Welling('''m_w''') <br />
<br />
***'''''Mentors!!! please add your Quote here.'''''***<br />
<br />
==Suggestions==<br />
Nothing For Now...<br />
<br />
Thanks.</div>Thrtransformerrhttps://elinux.org/index.php?title=GSoC2017_sonic_anemometer_proposal&diff=438666GSoC2017 sonic anemometer proposal2017-03-31T03:09:45Z<p>Thrtransformerr: /* Requirement Analysis */</p>
<hr />
<div>[[Category: BeagleBoard]]<br />
[[Category: GSoC]]<br />
[[Category: GSoCProposal]]<br />
== Proposal for Sonic Anemometer ==<br />
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.<br />
<br />
''Idea as Quoted from GSoC Ideas page:'' <br />
Working prototype sonic anemometer using BeagleBone, PRUDAQ, and ultrasonic sensors. Analyze methods for accuracy/sensitivity <br />
(eg, time-of-flight vs. phase difference) and implement "best" method. Use PRUs for independent real-time control of ultrasonics.<br />
<br />
''Student:'' Naveen Saini<br />
<br />
''Mentors'': Steve Arnold(nerdboy), Stephanie Lockwood-Childs<br />
<br />
''Code:'' N/A<br />
<br />
''Wiki'': http://elinux.org/GSoC2017_sonic_anemometer_proposal<br />
<br />
''GSoC'': N/A<br />
<br />
==Status==<br />
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.<br />
<br />
==Proposal==<br />
I have completed the task required as described on Ideas page, and created a pull request, as listed [https://github.com/thetransformerr/gsoc-application/tree/master/ExampleEntryJasonKridner here].<br />
===About Me===<br />
''GitHub:'' [https://github.com/thetransformerr @thetransformerr]<br />
<br />
''IRC:'' thetransformerr<br />
<br />
''elinux:'' thrtransformerr<br />
<br />
''Linkedin:'' [https://www.linkedin.com/in/5naveensaini/ Naveen Saini]<br />
<br />
''School:'' [http://jecrcuniversity.edu.in JECRC,Jaipur]<br />
<br />
''Country:'' India[The mystical wonderland ;)]<br />
<br />
''Primary language:'' English,Hindi<br />
<br />
''Typical work hours:'' 08AM-10AM , 09PM-01AM Indian Standard Time(+5:30)<br />
<br />
''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.<br />
<br />
''Skills(proficient):'' C,Ruby,Javascript<br />
<br />
''Experience:'' Java,Python,Arduino,Node.js,Scala,Matlab,CAD.<br />
<br />
=== Sonic Anemometer===<br />
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.<br />
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.<br />
<br />
=== Principle of Sonic Anemometer:===<br />
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.<br />
This pair of transducers act alternately as transmitters and receivers, exchanging high-frequency ultrasound pulses between themselves. The times of flight in each direction t<sub>1</sub> and t<sub>2</sub>, 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:<br />
<br />
[[File:Time.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
By combining Eqns (1) and (2) and solving for ` v`, the following equation is obtained:<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
<br />
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. <br />
<br />
[[File:Twodim.png|400px|thumb|left|2D axis(to be aligned with compass to true north)]][[File:Threet.png|400px|thumb|center|3D axis(for reference)]]<br />
<br />
<br />
<br />
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)<br />
Now following Equations are involved here,<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:Angle.png|300px|thumb|center|Angle]]<br />
<br />
<br />
Now from above equations it is clear that speed of sound calculated this way is independent of factors such as temperatures.<br />
<br />
Now with this device we can calculate the wind speed as well as temperature as described below-<br />
[[File:Temp.jpg|300px|thumb|center|Temperature(virtual temperature)]]<br />
<br />
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. <br />
<br />
The sonic temperature, Tv (in Kelvin), may differ from the absolute temperature by an amount equal to the<br />
water vapor content in the air measured. This difference amounts to ±1°C at 20°C and decreases as the temperature decreases.<br />
<br />
===PRUDAQ===<br />
<br />
DAQ are the Data Acquisition devices which are used to acquire data from sensors and acts as a bridge between sensors and host computer.<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
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.<br />
We can probably use second one for '''calibration''' and other tasks.<br />
<br />
===Requirement Analysis===<br />
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<sup>-3</sup>order) '''<br />
<br />
[[File:vari.png|900px|center|Temperature and Humidity effects]]<br />
<br />
<br />
Following graphs represents deviations of speed of sound :<br />
[[File:Tsemp.gif|400px|thumb|left|Temprature and Humidity Deviation]][[File:Spres.gif|400px|thumb|center|Pressure variation]]<br />
<br />
<br />
<br />
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.<br />
<br />
PRU in Beaglebone has rate of '''''200 MHz''''', hence instruction cycle of '''''5ns''''', following table shows approximate cycle required for various assembly code operations,<br />
[[File:Insc.png|600px|center|Instruction Cycles]]<br />
<br />
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.<br />
<br />
Following table shows some observations<br />
[[File:Obers.png|600px|center|Some raw observations]]<br />
<br />
<br />
Different Suitable DAQ<br />
[[File:DAiQ.png|600px|center|Some DAQ cost and capacity]]<br />
<br />
<br />
And this graph shows attenuation of waves according to their frequency, generally, higher the frequency, earlier it attenuates,<br />
[[File:Atten.png|400px|thumb|center|Attenuation Characteristics of Sound Pressure by Distance]]<br />
<br />
Hence following are the hardware that we can start with:-<br />
* Beaglebone Black/Green(1)<br />
* PRUDAQ/ADC having rate higher than 400ksps per channel(1/2)<br />
* Transducers(40kHz,Waterproof)(4)<br />
<br />
Min. Time required before new set measurement:<br />
<br />
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'''''.<br />
<br />
[[File:Daqr.png|600px|thumb|center|Pin Diagram]][[File:Tabl1.png|500px|center|Data Acquisition Cycles]]<br />
<br />
<br />
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.<br />
<br />
===Error Analysis===<br />
<br />
Following are the equations defined in thermodynamics for values calculated from the data:<br />
<br />
'''''c<sup>2</sup> =403T(1+0.32e/p)<br />
'''''<br />
where '''c''' is the velocity of sound ('''m s<sup>-1</sup>''') 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,<br />
<br />
'''''Ts [= T(1 + 0.32 e/p)]''''' <br />
<br />
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:<br />
<br />
'''''Tv =T(1+0.38e/p)<br />
'''''<br />
Clearly, '''Ts''' more closely approximates '''T<sub>v</sub>''' than it does '''T''', the error being on the order of '''±0.01°C''' in assuming '''T′ =T<sub>v</sub>′(virtual)''', compared to '''±0.05°C''' for '''T′ =T′(absolute)'''.<br />
Since virtual temperature is used sometimes in boundary layer calculations, we can safely assume sonic temperature as virtual temperature within safe experimental assumptions.<br />
<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
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<sup>-2</sup>ms<sup>-1</sup>.<br />
<br />
===Timeline:===<br />
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<br />
<br />
This program is of 12 Weeks-With Evaluation phase on June 26 - 30, 2017 and July 24 - 28, 2017<br />
<br />
====First Week:====<br />
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.<br />
====Second Week:====<br />
Connect the Prudaq and take sample readings as described on their wiki example.<br />
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<br />
====Third Week:====<br />
Program the PRU to read the sample results from PRUDAQ and trigger successive generation of two axis sonic transducers.<br />
====Fourth Week:====<br />
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.<br />
'''Evaluation Goals 1:'''<br />
''The device is able to stream the results of successive measurements after every specified interval to<br />
the user space and it is stored into text file.Software Testing Units are created for possible errors.''<br />
<br />
====Fifth Week:====<br />
This week we will build the structure as portable, possibly as described in below pictures.<br />
<br />
[[File:Sonic.jpg|300px|thumb|center|PVC for easy and flexible implementation]][[File:Unknown.jpg|300px|thumbnail|center|Made of Copper and steel to heat during Cold]]<br />
<br />
====Sixth Week:====<br />
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.<br />
====Seventh Week:====<br />
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.<br />
====Eighth Week:====<br />
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.<br />
'''Evaluation Goals 2:'''<br />
''Apparatus is tested extensively for outdoors, and is able to perform functional tasks in various possible <br />
conditions and output reliable data with accuracy and have test units defined but other factors like azimuth angle <br />
or other correction algorithms would be applied in the next stage.''<br />
<br />
====Ninth Week:====<br />
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).<br />
====Tenth Week:====<br />
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).<br />
Other modifications like variable sampling frequency in case if required later by developers.<br />
====Eleventh Week:====<br />
Review all the test units created earlier during program and modify them or build new.<br />
====Final Week:====<br />
Create a REST API sort of thing that enables the reading and logging of results into remote machines and proof check all modules<br />
<br />
==Final Goals:==<br />
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.<br />
<br />
===Future/Additional Goals:===<br />
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.<br />
<br />
Other Goals that can be helped or created by us or other open source contributors<br />
<br />
1. Make A python script type to create the graph and other possible representations of the data processed.<br />
<br />
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.<br />
<br />
==Experience and Approach==<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Projects====<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
<br />
==== Participations ====<br />
* 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.<br />
* Participated on National level, in TopCoder Open Finals organised by TopCoder.<br />
<br />
==== Approach ====<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Contingency==<br />
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.<br />
<br />
==Benefit==<br />
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.<br />
<br />
'''What community members speak -'''<br />
<br />
''Great project for the Aspiring Weather Scientist.''<br />
Michael Welling('''m_w''') <br />
<br />
***'''''Mentors!!! please add your Quote here.'''''***<br />
<br />
==Suggestions==<br />
Nothing For Now...<br />
<br />
Thanks.</div>Thrtransformerrhttps://elinux.org/index.php?title=GSoC2017_sonic_anemometer_proposal&diff=438661GSoC2017 sonic anemometer proposal2017-03-31T03:03:12Z<p>Thrtransformerr: /* Requirement Analysis */</p>
<hr />
<div>[[Category: BeagleBoard]]<br />
[[Category: GSoC]]<br />
[[Category: GSoCProposal]]<br />
== Proposal for Sonic Anemometer ==<br />
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.<br />
<br />
''Idea as Quoted from GSoC Ideas page:'' <br />
Working prototype sonic anemometer using BeagleBone, PRUDAQ, and ultrasonic sensors. Analyze methods for accuracy/sensitivity <br />
(eg, time-of-flight vs. phase difference) and implement "best" method. Use PRUs for independent real-time control of ultrasonics.<br />
<br />
''Student:'' Naveen Saini<br />
<br />
''Mentors'': Steve Arnold(nerdboy), Stephanie Lockwood-Childs<br />
<br />
''Code:'' N/A<br />
<br />
''Wiki'': http://elinux.org/GSoC2017_sonic_anemometer_proposal<br />
<br />
''GSoC'': N/A<br />
<br />
==Status==<br />
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.<br />
<br />
==Proposal==<br />
I have completed the task required as described on Ideas page, and created a pull request, as listed [https://github.com/thetransformerr/gsoc-application/tree/master/ExampleEntryJasonKridner here].<br />
===About Me===<br />
''GitHub:'' [https://github.com/thetransformerr @thetransformerr]<br />
<br />
''IRC:'' thetransformerr<br />
<br />
''elinux:'' thrtransformerr<br />
<br />
''Linkedin:'' [https://www.linkedin.com/in/5naveensaini/ Naveen Saini]<br />
<br />
''School:'' [http://jecrcuniversity.edu.in JECRC,Jaipur]<br />
<br />
''Country:'' India[The mystical wonderland ;)]<br />
<br />
''Primary language:'' English,Hindi<br />
<br />
''Typical work hours:'' 08AM-10AM , 09PM-01AM Indian Standard Time(+5:30)<br />
<br />
''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.<br />
<br />
''Skills(proficient):'' C,Ruby,Javascript<br />
<br />
''Experience:'' Java,Python,Arduino,Node.js,Scala,Matlab,CAD.<br />
<br />
=== Sonic Anemometer===<br />
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.<br />
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.<br />
<br />
=== Principle of Sonic Anemometer:===<br />
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.<br />
This pair of transducers act alternately as transmitters and receivers, exchanging high-frequency ultrasound pulses between themselves. The times of flight in each direction t<sub>1</sub> and t<sub>2</sub>, 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:<br />
<br />
[[File:Time.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
By combining Eqns (1) and (2) and solving for ` v`, the following equation is obtained:<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
<br />
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. <br />
<br />
[[File:Twodim.png|400px|thumb|left|2D axis(to be aligned with compass to true north)]][[File:Threet.png|400px|thumb|center|3D axis(for reference)]]<br />
<br />
<br />
<br />
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)<br />
Now following Equations are involved here,<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:Angle.png|300px|thumb|center|Angle]]<br />
<br />
<br />
Now from above equations it is clear that speed of sound calculated this way is independent of factors such as temperatures.<br />
<br />
Now with this device we can calculate the wind speed as well as temperature as described below-<br />
[[File:Temp.jpg|300px|thumb|center|Temperature(virtual temperature)]]<br />
<br />
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. <br />
<br />
The sonic temperature, Tv (in Kelvin), may differ from the absolute temperature by an amount equal to the<br />
water vapor content in the air measured. This difference amounts to ±1°C at 20°C and decreases as the temperature decreases.<br />
<br />
===PRUDAQ===<br />
<br />
DAQ are the Data Acquisition devices which are used to acquire data from sensors and acts as a bridge between sensors and host computer.<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
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.<br />
We can probably use second one for '''calibration''' and other tasks.<br />
<br />
===Requirement Analysis===<br />
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<sup>-3</sup>order) '''<br />
<br />
[[File:vari.png|900px|thumb|center|Temperature and Humidity effects]]<br />
<br />
<br />
Following graphs represents deviations of speed of sound :<br />
[[File:Tsemp.gif|400px|thumb|left|Temprature and Humidity Deviation]][[File:Spres.gif|400px|thumb|center|Pressure variation]]<br />
<br />
<br />
<br />
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.<br />
<br />
PRU in Beaglebone has rate of '''''200 MHz''''', hence instruction cycle of '''''5ns''''', following table shows approximate cycle required for various assembly code operations,<br />
[[File:Insc.png|600px|thumb|center|Temperature and Humidity effects]]<br />
<br />
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.<br />
<br />
Following table shows some observations<br />
[[File:Obers.png|600px|thumb|center|Some raw observations]]<br />
<br />
<br />
Different Suitable DAQ<br />
[[File:DAiQ.png|600px|thumb|center|Some DAQ cost and capacity]]<br />
<br />
<br />
And this graph shows attenuation of waves according to their frequency, generally, higher the frequency, earlier it attenuates,<br />
[[File:Atten.png|400px|thumb|center|Attenuation Characteristics of Sound Pressure by Distance]]<br />
<br />
Hence following are the hardware that we can start with:-<br />
* Beaglebone Black/Green(1)<br />
* PRUDAQ/ADC having rate higher than 400ksps per channel(1/2)<br />
* Transducers(40kHz,Waterproof)(4)<br />
<br />
Min. Time required before new set measurement:<br />
<br />
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'''''.<br />
<br />
[[File:Daqr.png|600px|thumb|center|Pin Diagram]][[File:Tabl1.png|500px|thumb|center|Data Acquisition Cycles]]<br />
<br />
<br />
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.<br />
<br />
===Error Analysis===<br />
<br />
Following are the equations defined in thermodynamics for values calculated from the data:<br />
<br />
'''''c<sup>2</sup> =403T(1+0.32e/p)<br />
'''''<br />
where '''c''' is the velocity of sound ('''m s<sup>-1</sup>''') 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,<br />
<br />
'''''Ts [= T(1 + 0.32 e/p)]''''' <br />
<br />
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:<br />
<br />
'''''Tv =T(1+0.38e/p)<br />
'''''<br />
Clearly, '''Ts''' more closely approximates '''T<sub>v</sub>''' than it does '''T''', the error being on the order of '''±0.01°C''' in assuming '''T′ =T<sub>v</sub>′(virtual)''', compared to '''±0.05°C''' for '''T′ =T′(absolute)'''.<br />
Since virtual temperature is used sometimes in boundary layer calculations, we can safely assume sonic temperature as virtual temperature within safe experimental assumptions.<br />
<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
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<sup>-2</sup>ms<sup>-1</sup>.<br />
<br />
===Timeline:===<br />
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<br />
<br />
This program is of 12 Weeks-With Evaluation phase on June 26 - 30, 2017 and July 24 - 28, 2017<br />
<br />
====First Week:====<br />
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.<br />
====Second Week:====<br />
Connect the Prudaq and take sample readings as described on their wiki example.<br />
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<br />
====Third Week:====<br />
Program the PRU to read the sample results from PRUDAQ and trigger successive generation of two axis sonic transducers.<br />
====Fourth Week:====<br />
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.<br />
'''Evaluation Goals 1:'''<br />
''The device is able to stream the results of successive measurements after every specified interval to<br />
the user space and it is stored into text file.Software Testing Units are created for possible errors.''<br />
<br />
====Fifth Week:====<br />
This week we will build the structure as portable, possibly as described in below pictures.<br />
<br />
[[File:Sonic.jpg|300px|thumb|center|PVC for easy and flexible implementation]][[File:Unknown.jpg|300px|thumbnail|center|Made of Copper and steel to heat during Cold]]<br />
<br />
====Sixth Week:====<br />
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.<br />
====Seventh Week:====<br />
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.<br />
====Eighth Week:====<br />
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.<br />
'''Evaluation Goals 2:'''<br />
''Apparatus is tested extensively for outdoors, and is able to perform functional tasks in various possible <br />
conditions and output reliable data with accuracy and have test units defined but other factors like azimuth angle <br />
or other correction algorithms would be applied in the next stage.''<br />
<br />
====Ninth Week:====<br />
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).<br />
====Tenth Week:====<br />
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).<br />
Other modifications like variable sampling frequency in case if required later by developers.<br />
====Eleventh Week:====<br />
Review all the test units created earlier during program and modify them or build new.<br />
====Final Week:====<br />
Create a REST API sort of thing that enables the reading and logging of results into remote machines and proof check all modules<br />
<br />
==Final Goals:==<br />
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.<br />
<br />
===Future/Additional Goals:===<br />
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.<br />
<br />
Other Goals that can be helped or created by us or other open source contributors<br />
<br />
1. Make A python script type to create the graph and other possible representations of the data processed.<br />
<br />
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.<br />
<br />
==Experience and Approach==<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Projects====<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
<br />
==== Participations ====<br />
* 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.<br />
* Participated on National level, in TopCoder Open Finals organised by TopCoder.<br />
<br />
==== Approach ====<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Contingency==<br />
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.<br />
<br />
==Benefit==<br />
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.<br />
<br />
'''What community members speak -'''<br />
<br />
''Great project for the Aspiring Weather Scientist.''<br />
Michael Welling('''m_w''') <br />
<br />
***'''''Mentors!!! please add your Quote here.'''''***<br />
<br />
==Suggestions==<br />
Nothing For Now...<br />
<br />
Thanks.</div>Thrtransformerrhttps://elinux.org/index.php?title=GSoC2017_sonic_anemometer_proposal&diff=438656GSoC2017 sonic anemometer proposal2017-03-31T03:00:47Z<p>Thrtransformerr: /* Requirement Analysis */</p>
<hr />
<div>[[Category: BeagleBoard]]<br />
[[Category: GSoC]]<br />
[[Category: GSoCProposal]]<br />
== Proposal for Sonic Anemometer ==<br />
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.<br />
<br />
''Idea as Quoted from GSoC Ideas page:'' <br />
Working prototype sonic anemometer using BeagleBone, PRUDAQ, and ultrasonic sensors. Analyze methods for accuracy/sensitivity <br />
(eg, time-of-flight vs. phase difference) and implement "best" method. Use PRUs for independent real-time control of ultrasonics.<br />
<br />
''Student:'' Naveen Saini<br />
<br />
''Mentors'': Steve Arnold(nerdboy), Stephanie Lockwood-Childs<br />
<br />
''Code:'' N/A<br />
<br />
''Wiki'': http://elinux.org/GSoC2017_sonic_anemometer_proposal<br />
<br />
''GSoC'': N/A<br />
<br />
==Status==<br />
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.<br />
<br />
==Proposal==<br />
I have completed the task required as described on Ideas page, and created a pull request, as listed [https://github.com/thetransformerr/gsoc-application/tree/master/ExampleEntryJasonKridner here].<br />
===About Me===<br />
''GitHub:'' [https://github.com/thetransformerr @thetransformerr]<br />
<br />
''IRC:'' thetransformerr<br />
<br />
''elinux:'' thrtransformerr<br />
<br />
''Linkedin:'' [https://www.linkedin.com/in/5naveensaini/ Naveen Saini]<br />
<br />
''School:'' [http://jecrcuniversity.edu.in JECRC,Jaipur]<br />
<br />
''Country:'' India[The mystical wonderland ;)]<br />
<br />
''Primary language:'' English,Hindi<br />
<br />
''Typical work hours:'' 08AM-10AM , 09PM-01AM Indian Standard Time(+5:30)<br />
<br />
''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.<br />
<br />
''Skills(proficient):'' C,Ruby,Javascript<br />
<br />
''Experience:'' Java,Python,Arduino,Node.js,Scala,Matlab,CAD.<br />
<br />
=== Sonic Anemometer===<br />
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.<br />
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.<br />
<br />
=== Principle of Sonic Anemometer:===<br />
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.<br />
This pair of transducers act alternately as transmitters and receivers, exchanging high-frequency ultrasound pulses between themselves. The times of flight in each direction t<sub>1</sub> and t<sub>2</sub>, 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:<br />
<br />
[[File:Time.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
By combining Eqns (1) and (2) and solving for ` v`, the following equation is obtained:<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
<br />
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. <br />
<br />
[[File:Twodim.png|400px|thumb|left|2D axis(to be aligned with compass to true north)]][[File:Threet.png|400px|thumb|center|3D axis(for reference)]]<br />
<br />
<br />
<br />
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)<br />
Now following Equations are involved here,<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:Angle.png|300px|thumb|center|Angle]]<br />
<br />
<br />
Now from above equations it is clear that speed of sound calculated this way is independent of factors such as temperatures.<br />
<br />
Now with this device we can calculate the wind speed as well as temperature as described below-<br />
[[File:Temp.jpg|300px|thumb|center|Temperature(virtual temperature)]]<br />
<br />
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. <br />
<br />
The sonic temperature, Tv (in Kelvin), may differ from the absolute temperature by an amount equal to the<br />
water vapor content in the air measured. This difference amounts to ±1°C at 20°C and decreases as the temperature decreases.<br />
<br />
===PRUDAQ===<br />
<br />
DAQ are the Data Acquisition devices which are used to acquire data from sensors and acts as a bridge between sensors and host computer.<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
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.<br />
We can probably use second one for '''calibration''' and other tasks.<br />
<br />
===Requirement Analysis===<br />
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<sup>-3</sup>order) '''<br />
<br />
[[File:vari.png|900px|thumb|center|Temperature and Humidity effects]]<br />
<br />
<br />
Following graphs represents deviations of speed of sound :<br />
[[File:Tsemp.gif|400px|thumb|left|Temprature and Humidity Deviation]][[File:Spres.gif|400px|thumb|center|Pressure variation]]<br />
<br />
<br />
<br />
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.<br />
<br />
PRU in Beaglebone has rate of '''''200 MHz''''', hence instruction cycle of '''''5ns''''', following table shows approximate cycle required for various assembly code operations,<br />
[[File:Insc.png|600px|thumb|center|Temperature and Humidity effects]]<br />
<br />
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.<br />
<br />
Following table shows some observations<br />
[[File:Obers.png|600px|thumb|center|Some raw observations]]<br />
<br />
<br />
Different Suitable DAQ<br />
[[File:DAiQ.png|600px|thumb|center|Some DAQ cost and capacity]]<br />
<br />
<br />
And this graph shows attenuation of waves according to their frequency, generally, higher the frequency, earlier it attenuates,<br />
[[File:Atten.png|400px|thumb|center|Attenuation Characteristics of Sound Pressure by Distance]]<br />
<br />
Hence following are the hardware that we can start with:-<br />
* Beaglebone Black/Green(1)<br />
* PRUDAQ/ADC having rate higher than 400ksps per channel(1/2)<br />
* Transducers(40kHz,Waterproof)(4)<br />
<br />
Min. Time required before new set measurement:<br />
<br />
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'''''.<br />
<br />
[[File:Daqr.png|400px|thumb|left|Pin Diagram]][[File:Tabl1.png|400px|thumb|center|Data Acquisition Cycles]]<br />
<br />
<br />
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.<br />
<br />
===Error Analysis===<br />
<br />
Following are the equations defined in thermodynamics for values calculated from the data:<br />
<br />
'''''c<sup>2</sup> =403T(1+0.32e/p)<br />
'''''<br />
where '''c''' is the velocity of sound ('''m s<sup>-1</sup>''') 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,<br />
<br />
'''''Ts [= T(1 + 0.32 e/p)]''''' <br />
<br />
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:<br />
<br />
'''''Tv =T(1+0.38e/p)<br />
'''''<br />
Clearly, '''Ts''' more closely approximates '''T<sub>v</sub>''' than it does '''T''', the error being on the order of '''±0.01°C''' in assuming '''T′ =T<sub>v</sub>′(virtual)''', compared to '''±0.05°C''' for '''T′ =T′(absolute)'''.<br />
Since virtual temperature is used sometimes in boundary layer calculations, we can safely assume sonic temperature as virtual temperature within safe experimental assumptions.<br />
<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
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<sup>-2</sup>ms<sup>-1</sup>.<br />
<br />
===Timeline:===<br />
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<br />
<br />
This program is of 12 Weeks-With Evaluation phase on June 26 - 30, 2017 and July 24 - 28, 2017<br />
<br />
====First Week:====<br />
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.<br />
====Second Week:====<br />
Connect the Prudaq and take sample readings as described on their wiki example.<br />
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<br />
====Third Week:====<br />
Program the PRU to read the sample results from PRUDAQ and trigger successive generation of two axis sonic transducers.<br />
====Fourth Week:====<br />
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.<br />
'''Evaluation Goals 1:'''<br />
''The device is able to stream the results of successive measurements after every specified interval to<br />
the user space and it is stored into text file.Software Testing Units are created for possible errors.''<br />
<br />
====Fifth Week:====<br />
This week we will build the structure as portable, possibly as described in below pictures.<br />
<br />
[[File:Sonic.jpg|300px|thumb|center|PVC for easy and flexible implementation]][[File:Unknown.jpg|300px|thumbnail|center|Made of Copper and steel to heat during Cold]]<br />
<br />
====Sixth Week:====<br />
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.<br />
====Seventh Week:====<br />
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.<br />
====Eighth Week:====<br />
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.<br />
'''Evaluation Goals 2:'''<br />
''Apparatus is tested extensively for outdoors, and is able to perform functional tasks in various possible <br />
conditions and output reliable data with accuracy and have test units defined but other factors like azimuth angle <br />
or other correction algorithms would be applied in the next stage.''<br />
<br />
====Ninth Week:====<br />
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).<br />
====Tenth Week:====<br />
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).<br />
Other modifications like variable sampling frequency in case if required later by developers.<br />
====Eleventh Week:====<br />
Review all the test units created earlier during program and modify them or build new.<br />
====Final Week:====<br />
Create a REST API sort of thing that enables the reading and logging of results into remote machines and proof check all modules<br />
<br />
==Final Goals:==<br />
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.<br />
<br />
===Future/Additional Goals:===<br />
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.<br />
<br />
Other Goals that can be helped or created by us or other open source contributors<br />
<br />
1. Make A python script type to create the graph and other possible representations of the data processed.<br />
<br />
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.<br />
<br />
==Experience and Approach==<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Projects====<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
<br />
==== Participations ====<br />
* 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.<br />
* Participated on National level, in TopCoder Open Finals organised by TopCoder.<br />
<br />
==== Approach ====<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Contingency==<br />
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.<br />
<br />
==Benefit==<br />
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.<br />
<br />
'''What community members speak -'''<br />
<br />
''Great project for the Aspiring Weather Scientist.''<br />
Michael Welling('''m_w''') <br />
<br />
***'''''Mentors!!! please add your Quote here.'''''***<br />
<br />
==Suggestions==<br />
Nothing For Now...<br />
<br />
Thanks.</div>Thrtransformerrhttps://elinux.org/index.php?title=File:Tabl1.png&diff=438651File:Tabl1.png2017-03-31T02:58:58Z<p>Thrtransformerr: </p>
<hr />
<div></div>Thrtransformerrhttps://elinux.org/index.php?title=File:Tabl.png&diff=438646File:Tabl.png2017-03-31T02:52:03Z<p>Thrtransformerr: </p>
<hr />
<div></div>Thrtransformerrhttps://elinux.org/index.php?title=File:Daqr.png&diff=438641File:Daqr.png2017-03-31T02:50:56Z<p>Thrtransformerr: </p>
<hr />
<div></div>Thrtransformerrhttps://elinux.org/index.php?title=GSoC2017_sonic_anemometer_proposal&diff=438606GSoC2017 sonic anemometer proposal2017-03-30T17:29:50Z<p>Thrtransformerr: /* Requirement Analysis */</p>
<hr />
<div>[[Category: BeagleBoard]]<br />
[[Category: GSoC]]<br />
[[Category: GSoCProposal]]<br />
== Proposal for Sonic Anemometer ==<br />
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.<br />
<br />
''Idea as Quoted from GSoC Ideas page:'' <br />
Working prototype sonic anemometer using BeagleBone, PRUDAQ, and ultrasonic sensors. Analyze methods for accuracy/sensitivity <br />
(eg, time-of-flight vs. phase difference) and implement "best" method. Use PRUs for independent real-time control of ultrasonics.<br />
<br />
''Student:'' Naveen Saini<br />
<br />
''Mentors'': Steve Arnold(nerdboy), Stephanie Lockwood-Childs<br />
<br />
''Code:'' N/A<br />
<br />
''Wiki'': http://elinux.org/GSoC2017_sonic_anemometer_proposal<br />
<br />
''GSoC'': N/A<br />
<br />
==Status==<br />
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.<br />
<br />
==Proposal==<br />
I have completed the task required as described on Ideas page, and created a pull request, as listed [https://github.com/thetransformerr/gsoc-application/tree/master/ExampleEntryJasonKridner here].<br />
===About Me===<br />
''GitHub:'' [https://github.com/thetransformerr @thetransformerr]<br />
<br />
''IRC:'' thetransformerr<br />
<br />
''elinux:'' thrtransformerr<br />
<br />
''Linkedin:'' [https://www.linkedin.com/in/5naveensaini/ Naveen Saini]<br />
<br />
''School:'' [http://jecrcuniversity.edu.in JECRC,Jaipur]<br />
<br />
''Country:'' India[The mystical wonderland ;)]<br />
<br />
''Primary language:'' English,Hindi<br />
<br />
''Typical work hours:'' 08AM-10AM , 09PM-01AM Indian Standard Time(+5:30)<br />
<br />
''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.<br />
<br />
''Skills(proficient):'' C,Ruby,Javascript<br />
<br />
''Experience:'' Java,Python,Arduino,Node.js,Scala,Matlab,CAD.<br />
<br />
=== Sonic Anemometer===<br />
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.<br />
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.<br />
<br />
=== Principle of Sonic Anemometer:===<br />
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.<br />
This pair of transducers act alternately as transmitters and receivers, exchanging high-frequency ultrasound pulses between themselves. The times of flight in each direction t<sub>1</sub> and t<sub>2</sub>, 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:<br />
<br />
[[File:Time.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
By combining Eqns (1) and (2) and solving for ` v`, the following equation is obtained:<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
<br />
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. <br />
<br />
[[File:Twodim.png|400px|thumb|left|2D axis(to be aligned with compass to true north)]][[File:Threet.png|400px|thumb|center|3D axis(for reference)]]<br />
<br />
<br />
<br />
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)<br />
Now following Equations are involved here,<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:Angle.png|300px|thumb|center|Angle]]<br />
<br />
<br />
Now from above equations it is clear that speed of sound calculated this way is independent of factors such as temperatures.<br />
<br />
Now with this device we can calculate the wind speed as well as temperature as described below-<br />
[[File:Temp.jpg|300px|thumb|center|Temperature(virtual temperature)]]<br />
<br />
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. <br />
<br />
The sonic temperature, Tv (in Kelvin), may differ from the absolute temperature by an amount equal to the<br />
water vapor content in the air measured. This difference amounts to ±1°C at 20°C and decreases as the temperature decreases.<br />
<br />
===PRUDAQ===<br />
<br />
DAQ are the Data Acquisition devices which are used to acquire data from sensors and acts as a bridge between sensors and host computer.<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
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.<br />
We can probably use second one for '''calibration''' and other tasks.<br />
<br />
===Requirement Analysis===<br />
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<sup>-3</sup>order) '''<br />
<br />
[[File:vari.png|900px|thumb|center|Temperature and Humidity effects]]<br />
<br />
<br />
Following graphs represents deviations of speed of sound :<br />
[[File:Tsemp.gif|400px|thumb|left|Temprature and Humidity Deviation]][[File:Spres.gif|400px|thumb|center|Pressure variation]]<br />
<br />
<br />
<br />
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.<br />
<br />
PRU in Beaglebone has rate of '''''200 MHz''''', hence instruction cycle of '''''5ns''''', following table shows approximate cycle required for various assembly code operations,<br />
[[File:Insc.png|600px|thumb|center|Temperature and Humidity effects]]<br />
<br />
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.<br />
<br />
Following table shows some observations<br />
[[File:Obers.png|600px|thumb|center|Some raw observations]]<br />
<br />
<br />
Different Suitable DAQ<br />
[[File:DAiQ.png|600px|thumb|center|Some DAQ cost and capacity]]<br />
<br />
<br />
And this graph shows attenuation of waves according to their frequency, generally, higher the frequency, earlier it attenuates,<br />
[[File:Atten.png|400px|thumb|center|Attenuation Characteristics of Sound Pressure by Distance]]<br />
<br />
Hence following are the hardware that we can start with:-<br />
* Beaglebone Black/Green(1)<br />
* PRUDAQ/ADC having rate higher than 400ksps per channel(1/2)<br />
* Transducers(40kHz,Waterproof)(4)<br />
<br />
Min. Time required before new set measurement:<br />
<br />
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'''''.<br />
<br />
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.<br />
<br />
===Error Analysis===<br />
<br />
Following are the equations defined in thermodynamics for values calculated from the data:<br />
<br />
'''''c<sup>2</sup> =403T(1+0.32e/p)<br />
'''''<br />
where '''c''' is the velocity of sound ('''m s<sup>-1</sup>''') 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,<br />
<br />
'''''Ts [= T(1 + 0.32 e/p)]''''' <br />
<br />
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:<br />
<br />
'''''Tv =T(1+0.38e/p)<br />
'''''<br />
Clearly, '''Ts''' more closely approximates '''T<sub>v</sub>''' than it does '''T''', the error being on the order of '''±0.01°C''' in assuming '''T′ =T<sub>v</sub>′(virtual)''', compared to '''±0.05°C''' for '''T′ =T′(absolute)'''.<br />
Since virtual temperature is used sometimes in boundary layer calculations, we can safely assume sonic temperature as virtual temperature within safe experimental assumptions.<br />
<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
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<sup>-2</sup>ms<sup>-1</sup>.<br />
<br />
===Timeline:===<br />
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<br />
<br />
This program is of 12 Weeks-With Evaluation phase on June 26 - 30, 2017 and July 24 - 28, 2017<br />
<br />
====First Week:====<br />
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.<br />
====Second Week:====<br />
Connect the Prudaq and take sample readings as described on their wiki example.<br />
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<br />
====Third Week:====<br />
Program the PRU to read the sample results from PRUDAQ and trigger successive generation of two axis sonic transducers.<br />
====Fourth Week:====<br />
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.<br />
'''Evaluation Goals 1:'''<br />
''The device is able to stream the results of successive measurements after every specified interval to<br />
the user space and it is stored into text file.Software Testing Units are created for possible errors.''<br />
<br />
====Fifth Week:====<br />
This week we will build the structure as portable, possibly as described in below pictures.<br />
<br />
[[File:Sonic.jpg|300px|thumb|center|PVC for easy and flexible implementation]][[File:Unknown.jpg|300px|thumbnail|center|Made of Copper and steel to heat during Cold]]<br />
<br />
====Sixth Week:====<br />
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.<br />
====Seventh Week:====<br />
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.<br />
====Eighth Week:====<br />
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.<br />
'''Evaluation Goals 2:'''<br />
''Apparatus is tested extensively for outdoors, and is able to perform functional tasks in various possible <br />
conditions and output reliable data with accuracy and have test units defined but other factors like azimuth angle <br />
or other correction algorithms would be applied in the next stage.''<br />
<br />
====Ninth Week:====<br />
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).<br />
====Tenth Week:====<br />
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).<br />
Other modifications like variable sampling frequency in case if required later by developers.<br />
====Eleventh Week:====<br />
Review all the test units created earlier during program and modify them or build new.<br />
====Final Week:====<br />
Create a REST API sort of thing that enables the reading and logging of results into remote machines and proof check all modules<br />
<br />
==Final Goals:==<br />
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.<br />
<br />
===Future/Additional Goals:===<br />
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.<br />
<br />
Other Goals that can be helped or created by us or other open source contributors<br />
<br />
1. Make A python script type to create the graph and other possible representations of the data processed.<br />
<br />
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.<br />
<br />
==Experience and Approach==<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Projects====<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
<br />
==== Participations ====<br />
* 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.<br />
* Participated on National level, in TopCoder Open Finals organised by TopCoder.<br />
<br />
==== Approach ====<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Contingency==<br />
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.<br />
<br />
==Benefit==<br />
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.<br />
<br />
'''What community members speak -'''<br />
<br />
''Great project for the Aspiring Weather Scientist.''<br />
Michael Welling('''m_w''') <br />
<br />
***'''''Mentors!!! please add your Quote here.'''''***<br />
<br />
==Suggestions==<br />
Nothing For Now...<br />
<br />
Thanks.</div>Thrtransformerrhttps://elinux.org/index.php?title=GSoC2017_sonic_anemometer_proposal&diff=438601GSoC2017 sonic anemometer proposal2017-03-30T16:51:04Z<p>Thrtransformerr: /* About Me */</p>
<hr />
<div>[[Category: BeagleBoard]]<br />
[[Category: GSoC]]<br />
[[Category: GSoCProposal]]<br />
== Proposal for Sonic Anemometer ==<br />
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.<br />
<br />
''Idea as Quoted from GSoC Ideas page:'' <br />
Working prototype sonic anemometer using BeagleBone, PRUDAQ, and ultrasonic sensors. Analyze methods for accuracy/sensitivity <br />
(eg, time-of-flight vs. phase difference) and implement "best" method. Use PRUs for independent real-time control of ultrasonics.<br />
<br />
''Student:'' Naveen Saini<br />
<br />
''Mentors'': Steve Arnold(nerdboy), Stephanie Lockwood-Childs<br />
<br />
''Code:'' N/A<br />
<br />
''Wiki'': http://elinux.org/GSoC2017_sonic_anemometer_proposal<br />
<br />
''GSoC'': N/A<br />
<br />
==Status==<br />
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.<br />
<br />
==Proposal==<br />
I have completed the task required as described on Ideas page, and created a pull request, as listed [https://github.com/thetransformerr/gsoc-application/tree/master/ExampleEntryJasonKridner here].<br />
===About Me===<br />
''GitHub:'' [https://github.com/thetransformerr @thetransformerr]<br />
<br />
''IRC:'' thetransformerr<br />
<br />
''elinux:'' thrtransformerr<br />
<br />
''Linkedin:'' [https://www.linkedin.com/in/5naveensaini/ Naveen Saini]<br />
<br />
''School:'' [http://jecrcuniversity.edu.in JECRC,Jaipur]<br />
<br />
''Country:'' India[The mystical wonderland ;)]<br />
<br />
''Primary language:'' English,Hindi<br />
<br />
''Typical work hours:'' 08AM-10AM , 09PM-01AM Indian Standard Time(+5:30)<br />
<br />
''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.<br />
<br />
''Skills(proficient):'' C,Ruby,Javascript<br />
<br />
''Experience:'' Java,Python,Arduino,Node.js,Scala,Matlab,CAD.<br />
<br />
=== Sonic Anemometer===<br />
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.<br />
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.<br />
<br />
=== Principle of Sonic Anemometer:===<br />
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.<br />
This pair of transducers act alternately as transmitters and receivers, exchanging high-frequency ultrasound pulses between themselves. The times of flight in each direction t<sub>1</sub> and t<sub>2</sub>, 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:<br />
<br />
[[File:Time.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
By combining Eqns (1) and (2) and solving for ` v`, the following equation is obtained:<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
<br />
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. <br />
<br />
[[File:Twodim.png|400px|thumb|left|2D axis(to be aligned with compass to true north)]][[File:Threet.png|400px|thumb|center|3D axis(for reference)]]<br />
<br />
<br />
<br />
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)<br />
Now following Equations are involved here,<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:Angle.png|300px|thumb|center|Angle]]<br />
<br />
<br />
Now from above equations it is clear that speed of sound calculated this way is independent of factors such as temperatures.<br />
<br />
Now with this device we can calculate the wind speed as well as temperature as described below-<br />
[[File:Temp.jpg|300px|thumb|center|Temperature(virtual temperature)]]<br />
<br />
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. <br />
<br />
The sonic temperature, Tv (in Kelvin), may differ from the absolute temperature by an amount equal to the<br />
water vapor content in the air measured. This difference amounts to ±1°C at 20°C and decreases as the temperature decreases.<br />
<br />
===PRUDAQ===<br />
<br />
DAQ are the Data Acquisition devices which are used to acquire data from sensors and acts as a bridge between sensors and host computer.<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
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.<br />
We can probably use second one for '''calibration''' and other tasks.<br />
<br />
===Requirement Analysis===<br />
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<sup>-3</sup>order) '''<br />
<br />
[[File:vari.png|900px|thumb|center|Temperature and Humidity effects]]<br />
<br />
<br />
Following graphs represents deviations of speed of sound :<br />
[[File:Tsemp.gif|400px|thumb|left|Temprature and Humidity Deviation]][[File:Spres.gif|400px|thumb|center|Pressure variation]]<br />
<br />
<br />
<br />
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.<br />
<br />
PRU in Beaglebone has rate of '''''200 MHz''''', hence instruction cycle of '''''5ns''''', following table shows approximate cycle required for various assembly code operations,<br />
[[File:Insc.png|600px|thumb|center|Temperature and Humidity effects]]<br />
<br />
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.<br />
<br />
Following table shows some observations<br />
[[File:Obers.png|600px|thumb|center|Some raw observations]]<br />
<br />
<br />
Different Suitable DAQ<br />
[[File:DAiQ.png|600px|thumb|center|Some DAQ cost and capacity]]<br />
<br />
<br />
And this graph shows attenuation of waves according to their frequency, generally, higher the frequency, earlier it attenuates,<br />
[[File:Atten.png|400px|thumb|center|Attenuation Characteristics of Sound Pressure by Distance]]<br />
<br />
Hence following are the hardware that we can start with:-<br />
* Beaglebone Black/Green(1)<br />
* PRUDAQ/ADC having rate higher than 400ksps per channel(1/2)<br />
* Transducers(40kHz,Waterproof)(4)<br />
<br />
===Error Analysis===<br />
<br />
Following are the equations defined in thermodynamics for values calculated from the data:<br />
<br />
'''''c<sup>2</sup> =403T(1+0.32e/p)<br />
'''''<br />
where '''c''' is the velocity of sound ('''m s<sup>-1</sup>''') 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,<br />
<br />
'''''Ts [= T(1 + 0.32 e/p)]''''' <br />
<br />
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:<br />
<br />
'''''Tv =T(1+0.38e/p)<br />
'''''<br />
Clearly, '''Ts''' more closely approximates '''T<sub>v</sub>''' than it does '''T''', the error being on the order of '''±0.01°C''' in assuming '''T′ =T<sub>v</sub>′(virtual)''', compared to '''±0.05°C''' for '''T′ =T′(absolute)'''.<br />
Since virtual temperature is used sometimes in boundary layer calculations, we can safely assume sonic temperature as virtual temperature within safe experimental assumptions.<br />
<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
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<sup>-2</sup>ms<sup>-1</sup>.<br />
<br />
===Timeline:===<br />
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<br />
<br />
This program is of 12 Weeks-With Evaluation phase on June 26 - 30, 2017 and July 24 - 28, 2017<br />
<br />
====First Week:====<br />
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.<br />
====Second Week:====<br />
Connect the Prudaq and take sample readings as described on their wiki example.<br />
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<br />
====Third Week:====<br />
Program the PRU to read the sample results from PRUDAQ and trigger successive generation of two axis sonic transducers.<br />
====Fourth Week:====<br />
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.<br />
'''Evaluation Goals 1:'''<br />
''The device is able to stream the results of successive measurements after every specified interval to<br />
the user space and it is stored into text file.Software Testing Units are created for possible errors.''<br />
<br />
====Fifth Week:====<br />
This week we will build the structure as portable, possibly as described in below pictures.<br />
<br />
[[File:Sonic.jpg|300px|thumb|center|PVC for easy and flexible implementation]][[File:Unknown.jpg|300px|thumbnail|center|Made of Copper and steel to heat during Cold]]<br />
<br />
====Sixth Week:====<br />
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.<br />
====Seventh Week:====<br />
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.<br />
====Eighth Week:====<br />
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.<br />
'''Evaluation Goals 2:'''<br />
''Apparatus is tested extensively for outdoors, and is able to perform functional tasks in various possible <br />
conditions and output reliable data with accuracy and have test units defined but other factors like azimuth angle <br />
or other correction algorithms would be applied in the next stage.''<br />
<br />
====Ninth Week:====<br />
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).<br />
====Tenth Week:====<br />
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).<br />
Other modifications like variable sampling frequency in case if required later by developers.<br />
====Eleventh Week:====<br />
Review all the test units created earlier during program and modify them or build new.<br />
====Final Week:====<br />
Create a REST API sort of thing that enables the reading and logging of results into remote machines and proof check all modules<br />
<br />
==Final Goals:==<br />
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.<br />
<br />
===Future/Additional Goals:===<br />
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.<br />
<br />
Other Goals that can be helped or created by us or other open source contributors<br />
<br />
1. Make A python script type to create the graph and other possible representations of the data processed.<br />
<br />
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.<br />
<br />
==Experience and Approach==<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Projects====<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
<br />
==== Participations ====<br />
* 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.<br />
* Participated on National level, in TopCoder Open Finals organised by TopCoder.<br />
<br />
==== Approach ====<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Contingency==<br />
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.<br />
<br />
==Benefit==<br />
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.<br />
<br />
'''What community members speak -'''<br />
<br />
''Great project for the Aspiring Weather Scientist.''<br />
Michael Welling('''m_w''') <br />
<br />
***'''''Mentors!!! please add your Quote here.'''''***<br />
<br />
==Suggestions==<br />
Nothing For Now...<br />
<br />
Thanks.</div>Thrtransformerrhttps://elinux.org/index.php?title=GSoC2017_sonic_anemometer_proposal&diff=438596GSoC2017 sonic anemometer proposal2017-03-30T16:37:05Z<p>Thrtransformerr: </p>
<hr />
<div>[[Category: BeagleBoard]]<br />
[[Category: GSoC]]<br />
[[Category: GSoCProposal]]<br />
== Proposal for Sonic Anemometer ==<br />
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.<br />
<br />
''Idea as Quoted from GSoC Ideas page:'' <br />
Working prototype sonic anemometer using BeagleBone, PRUDAQ, and ultrasonic sensors. Analyze methods for accuracy/sensitivity <br />
(eg, time-of-flight vs. phase difference) and implement "best" method. Use PRUs for independent real-time control of ultrasonics.<br />
<br />
''Student:'' Naveen Saini<br />
<br />
''Mentors'': Steve Arnold(nerdboy), Stephanie Lockwood-Childs<br />
<br />
''Code:'' N/A<br />
<br />
''Wiki'': http://elinux.org/GSoC2017_sonic_anemometer_proposal<br />
<br />
''GSoC'': N/A<br />
<br />
==Status==<br />
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.<br />
<br />
==Proposal==<br />
I have completed the task required as described on Ideas page, and created a pull request, as listed [https://github.com/thetransformerr/gsoc-application/tree/master/ExampleEntryJasonKridner here].<br />
===About Me===<br />
''GitHub:'' [https://github.com/thetransformerr @thetransformerr]<br />
<br />
''IRC:'' thetransformerr<br />
<br />
''Linkedin:'' [https://www.linkedin.com/in/5naveensaini/ Naveen Saini]<br />
<br />
''School:'' [http://jecrcuniversity.edu.in JECRC,Jaipur]<br />
<br />
''Country:'' India[The mystical wonderland ;)]<br />
<br />
''Primary language:'' English,Hindi<br />
<br />
''Typical work hours:'' 08AM-10AM , 09PM-01AM Indian Standard Time(+5:30)<br />
<br />
''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.<br />
<br />
''Skills(proficient):'' C,Ruby,Javascript<br />
<br />
''Experience:'' Java,Python,Arduino,Node.js,Scala,Matlab,CAD.<br />
<br />
=== Sonic Anemometer===<br />
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.<br />
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.<br />
<br />
=== Principle of Sonic Anemometer:===<br />
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.<br />
This pair of transducers act alternately as transmitters and receivers, exchanging high-frequency ultrasound pulses between themselves. The times of flight in each direction t<sub>1</sub> and t<sub>2</sub>, 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:<br />
<br />
[[File:Time.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
By combining Eqns (1) and (2) and solving for ` v`, the following equation is obtained:<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
<br />
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. <br />
<br />
[[File:Twodim.png|400px|thumb|left|2D axis(to be aligned with compass to true north)]][[File:Threet.png|400px|thumb|center|3D axis(for reference)]]<br />
<br />
<br />
<br />
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)<br />
Now following Equations are involved here,<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:Angle.png|300px|thumb|center|Angle]]<br />
<br />
<br />
Now from above equations it is clear that speed of sound calculated this way is independent of factors such as temperatures.<br />
<br />
Now with this device we can calculate the wind speed as well as temperature as described below-<br />
[[File:Temp.jpg|300px|thumb|center|Temperature(virtual temperature)]]<br />
<br />
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. <br />
<br />
The sonic temperature, Tv (in Kelvin), may differ from the absolute temperature by an amount equal to the<br />
water vapor content in the air measured. This difference amounts to ±1°C at 20°C and decreases as the temperature decreases.<br />
<br />
===PRUDAQ===<br />
<br />
DAQ are the Data Acquisition devices which are used to acquire data from sensors and acts as a bridge between sensors and host computer.<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
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.<br />
We can probably use second one for '''calibration''' and other tasks.<br />
<br />
===Requirement Analysis===<br />
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<sup>-3</sup>order) '''<br />
<br />
[[File:vari.png|900px|thumb|center|Temperature and Humidity effects]]<br />
<br />
<br />
Following graphs represents deviations of speed of sound :<br />
[[File:Tsemp.gif|400px|thumb|left|Temprature and Humidity Deviation]][[File:Spres.gif|400px|thumb|center|Pressure variation]]<br />
<br />
<br />
<br />
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.<br />
<br />
PRU in Beaglebone has rate of '''''200 MHz''''', hence instruction cycle of '''''5ns''''', following table shows approximate cycle required for various assembly code operations,<br />
[[File:Insc.png|600px|thumb|center|Temperature and Humidity effects]]<br />
<br />
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.<br />
<br />
Following table shows some observations<br />
[[File:Obers.png|600px|thumb|center|Some raw observations]]<br />
<br />
<br />
Different Suitable DAQ<br />
[[File:DAiQ.png|600px|thumb|center|Some DAQ cost and capacity]]<br />
<br />
<br />
And this graph shows attenuation of waves according to their frequency, generally, higher the frequency, earlier it attenuates,<br />
[[File:Atten.png|400px|thumb|center|Attenuation Characteristics of Sound Pressure by Distance]]<br />
<br />
Hence following are the hardware that we can start with:-<br />
* Beaglebone Black/Green(1)<br />
* PRUDAQ/ADC having rate higher than 400ksps per channel(1/2)<br />
* Transducers(40kHz,Waterproof)(4)<br />
<br />
===Error Analysis===<br />
<br />
Following are the equations defined in thermodynamics for values calculated from the data:<br />
<br />
'''''c<sup>2</sup> =403T(1+0.32e/p)<br />
'''''<br />
where '''c''' is the velocity of sound ('''m s<sup>-1</sup>''') 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,<br />
<br />
'''''Ts [= T(1 + 0.32 e/p)]''''' <br />
<br />
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:<br />
<br />
'''''Tv =T(1+0.38e/p)<br />
'''''<br />
Clearly, '''Ts''' more closely approximates '''T<sub>v</sub>''' than it does '''T''', the error being on the order of '''±0.01°C''' in assuming '''T′ =T<sub>v</sub>′(virtual)''', compared to '''±0.05°C''' for '''T′ =T′(absolute)'''.<br />
Since virtual temperature is used sometimes in boundary layer calculations, we can safely assume sonic temperature as virtual temperature within safe experimental assumptions.<br />
<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
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<sup>-2</sup>ms<sup>-1</sup>.<br />
<br />
===Timeline:===<br />
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<br />
<br />
This program is of 12 Weeks-With Evaluation phase on June 26 - 30, 2017 and July 24 - 28, 2017<br />
<br />
====First Week:====<br />
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.<br />
====Second Week:====<br />
Connect the Prudaq and take sample readings as described on their wiki example.<br />
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<br />
====Third Week:====<br />
Program the PRU to read the sample results from PRUDAQ and trigger successive generation of two axis sonic transducers.<br />
====Fourth Week:====<br />
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.<br />
'''Evaluation Goals 1:'''<br />
''The device is able to stream the results of successive measurements after every specified interval to<br />
the user space and it is stored into text file.Software Testing Units are created for possible errors.''<br />
<br />
====Fifth Week:====<br />
This week we will build the structure as portable, possibly as described in below pictures.<br />
<br />
[[File:Sonic.jpg|300px|thumb|center|PVC for easy and flexible implementation]][[File:Unknown.jpg|300px|thumbnail|center|Made of Copper and steel to heat during Cold]]<br />
<br />
====Sixth Week:====<br />
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.<br />
====Seventh Week:====<br />
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.<br />
====Eighth Week:====<br />
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.<br />
'''Evaluation Goals 2:'''<br />
''Apparatus is tested extensively for outdoors, and is able to perform functional tasks in various possible <br />
conditions and output reliable data with accuracy and have test units defined but other factors like azimuth angle <br />
or other correction algorithms would be applied in the next stage.''<br />
<br />
====Ninth Week:====<br />
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).<br />
====Tenth Week:====<br />
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).<br />
Other modifications like variable sampling frequency in case if required later by developers.<br />
====Eleventh Week:====<br />
Review all the test units created earlier during program and modify them or build new.<br />
====Final Week:====<br />
Create a REST API sort of thing that enables the reading and logging of results into remote machines and proof check all modules<br />
<br />
==Final Goals:==<br />
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.<br />
<br />
===Future/Additional Goals:===<br />
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.<br />
<br />
Other Goals that can be helped or created by us or other open source contributors<br />
<br />
1. Make A python script type to create the graph and other possible representations of the data processed.<br />
<br />
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.<br />
<br />
==Experience and Approach==<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Projects====<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
<br />
==== Participations ====<br />
* 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.<br />
* Participated on National level, in TopCoder Open Finals organised by TopCoder.<br />
<br />
==== Approach ====<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Contingency==<br />
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.<br />
<br />
==Benefit==<br />
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.<br />
<br />
'''What community members speak -'''<br />
<br />
''Great project for the Aspiring Weather Scientist.''<br />
Michael Welling('''m_w''') <br />
<br />
***'''''Mentors!!! please add your Quote here.'''''***<br />
<br />
==Suggestions==<br />
Nothing For Now...<br />
<br />
Thanks.</div>Thrtransformerrhttps://elinux.org/index.php?title=File:DAiQ.png&diff=438576File:DAiQ.png2017-03-30T16:12:12Z<p>Thrtransformerr: </p>
<hr />
<div></div>Thrtransformerrhttps://elinux.org/index.php?title=File:Atten.png&diff=438561File:Atten.png2017-03-30T13:19:59Z<p>Thrtransformerr: </p>
<hr />
<div></div>Thrtransformerrhttps://elinux.org/index.php?title=File:Obers.png&diff=438556File:Obers.png2017-03-30T13:14:03Z<p>Thrtransformerr: </p>
<hr />
<div></div>Thrtransformerrhttps://elinux.org/index.php?title=File:Insc.png&diff=438551File:Insc.png2017-03-30T13:01:35Z<p>Thrtransformerr: </p>
<hr />
<div></div>Thrtransformerrhttps://elinux.org/index.php?title=File:Spres.gif&diff=438546File:Spres.gif2017-03-30T12:45:21Z<p>Thrtransformerr: </p>
<hr />
<div></div>Thrtransformerrhttps://elinux.org/index.php?title=File:Tsemp.gif&diff=438541File:Tsemp.gif2017-03-30T12:44:52Z<p>Thrtransformerr: </p>
<hr />
<div></div>Thrtransformerrhttps://elinux.org/index.php?title=File:Vari.png&diff=438536File:Vari.png2017-03-30T12:35:22Z<p>Thrtransformerr: </p>
<hr />
<div></div>Thrtransformerrhttps://elinux.org/index.php?title=GSoC2017_sonic_anemometer_proposal&diff=438531GSoC2017 sonic anemometer proposal2017-03-30T06:32:27Z<p>Thrtransformerr: /* Projects */</p>
<hr />
<div>[[Category: BeagleBoard]]<br />
[[Category: GSoC]]<br />
[[Category: GSoCProposal]]<br />
== Proposal for Sonic Anemometer ==<br />
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.<br />
<br />
''Idea as Quoted from GSoC Ideas page:'' <br />
Working prototype sonic anemometer using BeagleBone, PRUDAQ, and ultrasonic sensors. Analyze methods for accuracy/sensitivity <br />
(eg, time-of-flight vs. phase difference) and implement "best" method. Use PRUs for independent real-time control of ultrasonics.<br />
<br />
''Student:'' Naveen Saini<br />
<br />
''Mentors'': Steve Arnold(nerdboy), Stephanie Lockwood-Childs<br />
<br />
''Code:'' N/A<br />
<br />
''Wiki'': http://elinux.org/GSoC2017_sonic_anemometer_proposal<br />
<br />
''GSoC'': N/A<br />
<br />
==Status==<br />
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.<br />
<br />
==Proposal==<br />
I have completed the task required as described on Ideas page, and created a pull request, as listed [https://github.com/thetransformerr/gsoc-application/tree/master/ExampleEntryJasonKridner here].<br />
===About Me===<br />
''GitHub:'' [https://github.com/thetransformerr @thetransformerr]<br />
<br />
''IRC:'' thetransformerr<br />
<br />
''Linkedin:'' [https://www.linkedin.com/in/5naveensaini/ Naveen Saini]<br />
<br />
''School:'' [http://jecrcuniversity.edu.in JECRC,Jaipur]<br />
<br />
''Country:'' India[The mystical wonderland ;)]<br />
<br />
''Primary language:'' English,Hindi<br />
<br />
''Typical work hours:'' 08AM-10AM , 09PM-01AM Indian Standard Time(+5:30)<br />
<br />
''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.<br />
<br />
''Skills(proficient):'' C,Ruby,Javascript<br />
<br />
''Experience:'' Java,Python,Arduino,Node.js,Scala,Matlab,CAD.<br />
<br />
=== Sonic Anemometer===<br />
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.<br />
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.<br />
<br />
=== Principle of Sonic Anemometer:===<br />
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.<br />
This pair of transducers act alternately as transmitters and receivers, exchanging high-frequency ultrasound pulses between themselves. The times of flight in each direction t<sub>1</sub> and t<sub>2</sub>, 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:<br />
<br />
[[File:Time.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
By combining Eqns (1) and (2) and solving for ` v`, the following equation is obtained:<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
<br />
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. <br />
<br />
[[File:Twodim.png|400px|thumb|left|2D axis(to be aligned with compass to true north)]][[File:Threet.png|400px|thumb|center|3D axis(for reference)]]<br />
<br />
<br />
<br />
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)<br />
Now following Equations are involved here,<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:Angle.png|300px|thumb|center|Angle]]<br />
<br />
<br />
Now from above equations it is clear that speed of sound calculated this way is independent of factors such as temperatures.<br />
<br />
Now with this device we can calculate the wind speed as well as temperature as described below-<br />
[[File:Temp.jpg|300px|thumb|center|Temperature(virtual temperature)]]<br />
<br />
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. <br />
<br />
The sonic temperature, Tv (in Kelvin), may differ from the absolute temperature by an amount equal to the<br />
water vapor content in the air measured. This difference amounts to ±1°C at 20°C and decreases as the temperature decreases.<br />
<br />
===PRUDAQ===<br />
<br />
DAQ are the Data Acquisition devices which are used to acquire data from sensors and acts as a bridge between sensors and host computer.<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
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.<br />
We can probably use second one for '''calibration''' and other tasks.<br />
<br />
===Error Analysis===<br />
Following are the equations defined in thermodynamics for values calculated from the data:<br />
<br />
'''''c<sup>2</sup> =403T(1+0.32e/p)<br />
'''''<br />
where '''c''' is the velocity of sound ('''m s<sup>-1</sup>''') 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,<br />
<br />
'''''Ts [= T(1 + 0.32 e/p)]''''' <br />
<br />
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:<br />
<br />
'''''Tv =T(1+0.38e/p)<br />
'''''<br />
Clearly, '''Ts''' more closely approximates '''T<sub>v</sub>''' than it does '''T''', the error being on the order of '''±0.01°C''' in assuming '''T′ =T<sub>v</sub>′(virtual)''', compared to '''±0.05°C''' for '''T′ =T′(absolute)'''.<br />
Since virtual temperature is used sometimes in boundary layer calculations, we can safely assume sonic temperature as virtual temperature within safe experimental assumptions.<br />
<br />
'''Sampling rate required to measure the time of flight'''<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
for 0.1 meter per second error rate in the wind speed, some conservative estimates about distance and the combined pulse speed can be made<br />
<br />
[[File:Error.png]]<br />
<br />
The change in time of flight for a pulse speed difference, even when that speed is quite high, is on the order of hundreds of nanoseconds. A sample rate of at least 10Mhz will be required.<br />
<br />
===Timeline:===<br />
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<br />
<br />
This program is of 12 Weeks-With Evaluation phase on June 26 - 30, 2017 and July 24 - 28, 2017<br />
<br />
====First Week:====<br />
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.<br />
====Second Week:====<br />
Connect the Prudaq and take sample readings as described on their wiki example.<br />
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<br />
====Third Week:====<br />
Program the PRU to read the sample results from PRUDAQ and trigger successive generation of two axis sonic transducers.<br />
====Fourth Week:====<br />
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.<br />
'''Evaluation Goals 1:'''<br />
''The device is able to stream the results of successive measurements after every specified interval to<br />
the user space and it is stored into text file.Software Testing Units are created for possible errors.''<br />
<br />
====Fifth Week:====<br />
This week we will build the structure as portable, possibly as described in below pictures.<br />
<br />
[[File:Sonic.jpg|300px|thumb|center|PVC for easy and flexible implementation]][[File:Unknown.jpg|300px|thumbnail|center|Made of Copper and steel to heat during Cold]]<br />
<br />
====Sixth Week:====<br />
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.<br />
====Seventh Week:====<br />
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.<br />
====Eighth Week:====<br />
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.<br />
'''Evaluation Goals 2:'''<br />
''Apparatus is tested extensively for outdoors, and is able to perform functional tasks in various possible <br />
conditions and output reliable data with accuracy and have test units defined but other factors like azimuth angle <br />
or other correction algorithms would be applied in the next stage.''<br />
<br />
====Ninth Week:====<br />
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).<br />
====Tenth Week:====<br />
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).<br />
Other modifications like variable sampling frequency in case if required later by developers.<br />
====Eleventh Week:====<br />
Review all the test units created earlier during program and modify them or build new.<br />
====Final Week:====<br />
Create a REST API sort of thing that enables the reading and logging of results into remote machines and proof check all modules<br />
<br />
==Final Goals:==<br />
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.<br />
<br />
===Future/Additional Goals:===<br />
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.<br />
<br />
Other Goals that can be helped or created by us or other open source contributors<br />
<br />
1. Make A python script type to create the graph and other possible representations of the data processed.<br />
<br />
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.<br />
<br />
==Experience and Approach==<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Projects====<br />
* '''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.<br />
* '''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.<br />
* '''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.<br />
<br />
==== Participations ====<br />
* 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.<br />
* Participated on National level, in TopCoder Open Finals organised by TopCoder.<br />
<br />
==== Approach ====<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Contingency==<br />
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.<br />
<br />
==Benefit==<br />
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.<br />
<br />
'''What community members speak -'''<br />
<br />
''Great project for the Aspiring Weather Scientist.''<br />
Michael Welling('''m_w''') <br />
<br />
***'''''Mentors!!! please add your Quote here.'''''***<br />
<br />
==Suggestions==<br />
Nothing For Now...<br />
<br />
Thanks.</div>Thrtransformerrhttps://elinux.org/index.php?title=GSoC2017_sonic_anemometer_proposal&diff=438526GSoC2017 sonic anemometer proposal2017-03-30T06:30:54Z<p>Thrtransformerr: </p>
<hr />
<div>[[Category: BeagleBoard]]<br />
[[Category: GSoC]]<br />
[[Category: GSoCProposal]]<br />
== Proposal for Sonic Anemometer ==<br />
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.<br />
<br />
''Idea as Quoted from GSoC Ideas page:'' <br />
Working prototype sonic anemometer using BeagleBone, PRUDAQ, and ultrasonic sensors. Analyze methods for accuracy/sensitivity <br />
(eg, time-of-flight vs. phase difference) and implement "best" method. Use PRUs for independent real-time control of ultrasonics.<br />
<br />
''Student:'' Naveen Saini<br />
<br />
''Mentors'': Steve Arnold(nerdboy), Stephanie Lockwood-Childs<br />
<br />
''Code:'' N/A<br />
<br />
''Wiki'': http://elinux.org/GSoC2017_sonic_anemometer_proposal<br />
<br />
''GSoC'': N/A<br />
<br />
==Status==<br />
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.<br />
<br />
==Proposal==<br />
I have completed the task required as described on Ideas page, and created a pull request, as listed [https://github.com/thetransformerr/gsoc-application/tree/master/ExampleEntryJasonKridner here].<br />
===About Me===<br />
''GitHub:'' [https://github.com/thetransformerr @thetransformerr]<br />
<br />
''IRC:'' thetransformerr<br />
<br />
''Linkedin:'' [https://www.linkedin.com/in/5naveensaini/ Naveen Saini]<br />
<br />
''School:'' [http://jecrcuniversity.edu.in JECRC,Jaipur]<br />
<br />
''Country:'' India[The mystical wonderland ;)]<br />
<br />
''Primary language:'' English,Hindi<br />
<br />
''Typical work hours:'' 08AM-10AM , 09PM-01AM Indian Standard Time(+5:30)<br />
<br />
''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.<br />
<br />
''Skills(proficient):'' C,Ruby,Javascript<br />
<br />
''Experience:'' Java,Python,Arduino,Node.js,Scala,Matlab,CAD.<br />
<br />
=== Sonic Anemometer===<br />
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.<br />
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.<br />
<br />
=== Principle of Sonic Anemometer:===<br />
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.<br />
This pair of transducers act alternately as transmitters and receivers, exchanging high-frequency ultrasound pulses between themselves. The times of flight in each direction t<sub>1</sub> and t<sub>2</sub>, 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:<br />
<br />
[[File:Time.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
By combining Eqns (1) and (2) and solving for ` v`, the following equation is obtained:<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
<br />
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. <br />
<br />
[[File:Twodim.png|400px|thumb|left|2D axis(to be aligned with compass to true north)]][[File:Threet.png|400px|thumb|center|3D axis(for reference)]]<br />
<br />
<br />
<br />
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)<br />
Now following Equations are involved here,<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:Angle.png|300px|thumb|center|Angle]]<br />
<br />
<br />
Now from above equations it is clear that speed of sound calculated this way is independent of factors such as temperatures.<br />
<br />
Now with this device we can calculate the wind speed as well as temperature as described below-<br />
[[File:Temp.jpg|300px|thumb|center|Temperature(virtual temperature)]]<br />
<br />
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. <br />
<br />
The sonic temperature, Tv (in Kelvin), may differ from the absolute temperature by an amount equal to the<br />
water vapor content in the air measured. This difference amounts to ±1°C at 20°C and decreases as the temperature decreases.<br />
<br />
===PRUDAQ===<br />
<br />
DAQ are the Data Acquisition devices which are used to acquire data from sensors and acts as a bridge between sensors and host computer.<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
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.<br />
We can probably use second one for '''calibration''' and other tasks.<br />
<br />
===Error Analysis===<br />
Following are the equations defined in thermodynamics for values calculated from the data:<br />
<br />
'''''c<sup>2</sup> =403T(1+0.32e/p)<br />
'''''<br />
where '''c''' is the velocity of sound ('''m s<sup>-1</sup>''') 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,<br />
<br />
'''''Ts [= T(1 + 0.32 e/p)]''''' <br />
<br />
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:<br />
<br />
'''''Tv =T(1+0.38e/p)<br />
'''''<br />
Clearly, '''Ts''' more closely approximates '''T<sub>v</sub>''' than it does '''T''', the error being on the order of '''±0.01°C''' in assuming '''T′ =T<sub>v</sub>′(virtual)''', compared to '''±0.05°C''' for '''T′ =T′(absolute)'''.<br />
Since virtual temperature is used sometimes in boundary layer calculations, we can safely assume sonic temperature as virtual temperature within safe experimental assumptions.<br />
<br />
'''Sampling rate required to measure the time of flight'''<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
for 0.1 meter per second error rate in the wind speed, some conservative estimates about distance and the combined pulse speed can be made<br />
<br />
[[File:Error.png]]<br />
<br />
The change in time of flight for a pulse speed difference, even when that speed is quite high, is on the order of hundreds of nanoseconds. A sample rate of at least 10Mhz will be required.<br />
<br />
===Timeline:===<br />
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<br />
<br />
This program is of 12 Weeks-With Evaluation phase on June 26 - 30, 2017 and July 24 - 28, 2017<br />
<br />
====First Week:====<br />
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.<br />
====Second Week:====<br />
Connect the Prudaq and take sample readings as described on their wiki example.<br />
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<br />
====Third Week:====<br />
Program the PRU to read the sample results from PRUDAQ and trigger successive generation of two axis sonic transducers.<br />
====Fourth Week:====<br />
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.<br />
'''Evaluation Goals 1:'''<br />
''The device is able to stream the results of successive measurements after every specified interval to<br />
the user space and it is stored into text file.Software Testing Units are created for possible errors.''<br />
<br />
====Fifth Week:====<br />
This week we will build the structure as portable, possibly as described in below pictures.<br />
<br />
[[File:Sonic.jpg|300px|thumb|center|PVC for easy and flexible implementation]][[File:Unknown.jpg|300px|thumbnail|center|Made of Copper and steel to heat during Cold]]<br />
<br />
====Sixth Week:====<br />
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.<br />
====Seventh Week:====<br />
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.<br />
====Eighth Week:====<br />
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.<br />
'''Evaluation Goals 2:'''<br />
''Apparatus is tested extensively for outdoors, and is able to perform functional tasks in various possible <br />
conditions and output reliable data with accuracy and have test units defined but other factors like azimuth angle <br />
or other correction algorithms would be applied in the next stage.''<br />
<br />
====Ninth Week:====<br />
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).<br />
====Tenth Week:====<br />
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).<br />
Other modifications like variable sampling frequency in case if required later by developers.<br />
====Eleventh Week:====<br />
Review all the test units created earlier during program and modify them or build new.<br />
====Final Week:====<br />
Create a REST API sort of thing that enables the reading and logging of results into remote machines and proof check all modules<br />
<br />
==Final Goals:==<br />
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.<br />
<br />
===Future/Additional Goals:===<br />
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.<br />
<br />
Other Goals that can be helped or created by us or other open source contributors<br />
<br />
1. Make A python script type to create the graph and other possible representations of the data processed.<br />
<br />
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.<br />
<br />
==Experience and Approach==<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Projects====<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
==== Participations ====<br />
* 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.<br />
* Participated on National level, in TopCoder Open Finals organised by TopCoder.<br />
<br />
==== Approach ====<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Contingency==<br />
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.<br />
<br />
==Benefit==<br />
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.<br />
<br />
'''What community members speak -'''<br />
<br />
''Great project for the Aspiring Weather Scientist.''<br />
Michael Welling('''m_w''') <br />
<br />
***'''''Mentors!!! please add your Quote here.'''''***<br />
<br />
==Suggestions==<br />
Nothing For Now...<br />
<br />
Thanks.</div>Thrtransformerrhttps://elinux.org/index.php?title=GSoC2017_sonic_anemometer_proposal&diff=438521GSoC2017 sonic anemometer proposal2017-03-30T06:27:45Z<p>Thrtransformerr: /* About Me */</p>
<hr />
<div>[[Category: BeagleBoard]]<br />
[[Category: GSoC]]<br />
[[Category: GSoCProposal]]<br />
== Proposal for Sonic Anemometer ==<br />
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.<br />
<br />
''Idea as Quoted from GSoC Ideas page:'' <br />
Working prototype sonic anemometer using BeagleBone, PRUDAQ, and ultrasonic sensors. Analyze methods for accuracy/sensitivity <br />
(eg, time-of-flight vs. phase difference) and implement "best" method. Use PRUs for independent real-time control of ultrasonics.<br />
<br />
''Student:'' Naveen Saini<br />
<br />
''Mentors'': Steve Arnold(nerdboy), Stephanie Lockwood-Childs<br />
<br />
''Code:'' N/A<br />
<br />
''Wiki'': http://elinux.org/GSoC2017_sonic_anemometer_proposal<br />
<br />
''GSoC'': N/A<br />
<br />
==Status==<br />
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.<br />
<br />
==Proposal==<br />
I have completed the task required as described on Ideas page, and created a pull request, as listed [https://github.com/thetransformerr/gsoc-application/tree/master/ExampleEntryJasonKridner here].<br />
===About Me===<br />
''GitHub:'' [https://github.com/thetransformerr @thetransformerr]<br />
<br />
''IRC:'' thetransformerr<br />
<br />
''Linkedin:'' [https://www.linkedin.com/in/5naveensaini/ Naveen Saini]<br />
<br />
''School:'' [http://jecrcuniversity.edu.in JECRC,Jaipur]<br />
<br />
''Country:'' India[The mystical wonderland ;)]<br />
<br />
''Primary language:'' English,Hindi<br />
<br />
''Typical work hours:'' 08AM-10AM , 09PM-01AM Indian Standard Time(+5:30)<br />
<br />
''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.<br />
<br />
''Skills(proficient):'' C,Ruby,Javascript<br />
<br />
''Experience'':Java,Python,Arduino,Node.js,Scala,Matlab,CAD.<br />
<br />
=== Sonic Anemometer===<br />
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.<br />
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.<br />
<br />
=== Principle of Sonic Anemometer:===<br />
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.<br />
This pair of transducers act alternately as transmitters and receivers, exchanging high-frequency ultrasound pulses between themselves. The times of flight in each direction t<sub>1</sub> and t<sub>2</sub>, 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:<br />
<br />
[[File:Time.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
By combining Eqns (1) and (2) and solving for ` v`, the following equation is obtained:<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
<br />
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. <br />
<br />
[[File:Twodim.png|400px|thumb|left|2D axis(to be aligned with compass to true north)]][[File:Threet.png|400px|thumb|center|3D axis(for reference)]]<br />
<br />
<br />
<br />
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)<br />
Now following Equations are involved here,<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:Angle.png|300px|thumb|center|Angle]]<br />
<br />
<br />
Now from above equations it is clear that speed of sound calculated this way is independent of factors such as temperatures.<br />
<br />
Now with this device we can calculate the wind speed as well as temperature as described below-<br />
[[File:Temp.jpg|300px|thumb|center|Temperature(virtual temperature)]]<br />
<br />
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. <br />
<br />
The sonic temperature, Tv (in Kelvin), may differ from the absolute temperature by an amount equal to the<br />
water vapor content in the air measured. This difference amounts to ±1°C at 20°C and decreases as the temperature decreases.<br />
<br />
===PRUDAQ===<br />
<br />
DAQ are the Data Acquisition devices which are used to acquire data from sensors and acts as a bridge between sensors and host computer.<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
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.<br />
We can probably use second one for '''calibration''' and other tasks.<br />
<br />
===Error Analysis===<br />
Following are the equations defined in thermodynamics for values calculated from the data:<br />
<br />
'''''c<sup>2</sup> =403T(1+0.32e/p)<br />
'''''<br />
where '''c''' is the velocity of sound ('''m s<sup>-1</sup>''') 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,<br />
<br />
'''''Ts [= T(1 + 0.32 e/p)]''''' <br />
<br />
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:<br />
<br />
'''''Tv =T(1+0.38e/p)<br />
'''''<br />
Clearly, '''Ts''' more closely approximates '''T<sub>v</sub>''' than it does '''T''', the error being on the order of '''±0.01°C''' in assuming '''T′ =T<sub>v</sub>′(virtual)''', compared to '''±0.05°C''' for '''T′ =T′(absolute)'''.<br />
Since virtual temperature is used sometimes in boundary layer calculations, we can safely assume sonic temperature as virtual temperature within safe experimental assumptions.<br />
<br />
'''Sampling rate required to measure the time of flight'''<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
for 0.1 meter per second error rate in the wind speed, some conservative estimates about distance and the combined pulse speed can be made<br />
<br />
[[File:Error.png]]<br />
<br />
The change in time of flight for a pulse speed difference, even when that speed is quite high, is on the order of hundreds of nanoseconds. A sample rate of at least 10Mhz will be required.<br />
<br />
===Timeline:===<br />
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<br />
<br />
This program is of 12 Weeks-With Evaluation phase on June 26 - 30, 2017 and July 24 - 28, 2017<br />
<br />
====First Week:====<br />
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.<br />
====Second Week:====<br />
Connect the Prudaq and take sample readings as described on their wiki example.<br />
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<br />
====Third Week:====<br />
Program the PRU to read the sample results from PRUDAQ and trigger successive generation of two axis sonic transducers.<br />
====Fourth Week:====<br />
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.<br />
'''Evaluation Goals 1:'''<br />
''The device is able to stream the results of successive measurements after every specified interval to<br />
the user space and it is stored into text file.Software Testing Units are created for possible errors.''<br />
<br />
====Fifth Week:====<br />
This week we will build the structure as portable, possibly as described in below pictures.<br />
<br />
[[File:Sonic.jpg|300px|thumb|center|PVC for easy and flexible implementation]][[File:Unknown.jpg|300px|thumbnail|center|Made of Copper and steel to heat during Cold]]<br />
<br />
====Sixth Week:====<br />
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.<br />
====Seventh Week:====<br />
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.<br />
====Eighth Week:====<br />
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.<br />
'''Evaluation Goals 2:'''<br />
''Apparatus is tested extensively for outdoors, and is able to perform functional tasks in various possible <br />
conditions and output reliable data with accuracy and have test units defined but other factors like azimuth angle <br />
or other correction algorithms would be applied in the next stage.''<br />
<br />
====Ninth Week:====<br />
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).<br />
====Tenth Week:====<br />
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).<br />
Other modifications like variable sampling frequency in case if required later by developers.<br />
====Eleventh Week:====<br />
Review all the test units created earlier during program and modify them or build new.<br />
====Final Week:====<br />
Create a REST API sort of thing that enables the reading and logging of results into remote machines and proof check all modules<br />
<br />
==Final Goals:==<br />
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.<br />
<br />
===Future/Additional Goals:===<br />
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.<br />
<br />
Other Goals that can be helped or created by us or other open source contributors<br />
<br />
1. Make A python script type to create the graph and other possible representations of the data processed.<br />
<br />
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.<br />
<br />
==Experience and Approach==<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Projects====<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
==== Participations ====<br />
* 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.<br />
* Participated on National level, in TopCoder Open Finals organised by TopCoder.<br />
<br />
==== Approach ====<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Contingency==<br />
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.<br />
<br />
==Benefit==<br />
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.<br />
<br />
'''What community members speak -'''<br />
<br />
''Great project for the Aspiring Weather Scientist.''<br />
Michael Welling('''m_w''') <br />
<br />
***'''''Mentors!!! please add your Quote here.'''''***<br />
<br />
==Suggestions==<br />
Nothing For Now...<br />
<br />
Thanks.</div>Thrtransformerrhttps://elinux.org/index.php?title=GSoC2017_sonic_anemometer_proposal&diff=438516GSoC2017 sonic anemometer proposal2017-03-30T06:26:58Z<p>Thrtransformerr: /* Proposal */</p>
<hr />
<div>[[Category: BeagleBoard]]<br />
[[Category: GSoC]]<br />
[[Category: GSoCProposal]]<br />
== Proposal for Sonic Anemometer ==<br />
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.<br />
<br />
''Idea as Quoted from GSoC Ideas page:'' <br />
Working prototype sonic anemometer using BeagleBone, PRUDAQ, and ultrasonic sensors. Analyze methods for accuracy/sensitivity <br />
(eg, time-of-flight vs. phase difference) and implement "best" method. Use PRUs for independent real-time control of ultrasonics.<br />
<br />
''Student:'' Naveen Saini<br />
<br />
''Mentors'': Steve Arnold(nerdboy), Stephanie Lockwood-Childs<br />
<br />
''Code:'' N/A<br />
<br />
''Wiki'': http://elinux.org/GSoC2017_sonic_anemometer_proposal<br />
<br />
''GSoC'': N/A<br />
<br />
==Status==<br />
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.<br />
<br />
==Proposal==<br />
I have completed the task required as described on Ideas page, and created a pull request, as listed [https://github.com/thetransformerr/gsoc-application/tree/master/ExampleEntryJasonKridner here].<br />
===About Me===<br />
''GitHub:'' [https://github.com/thetransformerr @thetransformerr]<br />
<br />
''IRC:'' thetransformerr<br />
<br />
''Linkedin:'' [https://www.linkedin.com/in/5naveensaini/ Naveen Saini]<br />
<br />
''School:'' [http://jecrcuniversity.edu.in JECRC,Jaipur]<br />
<br />
''Country:'' India[The mystical wonderland ;)]<br />
<br />
''Primary language:'' English,Hindi<br />
<br />
''Typical work hours:'' 08AM-10AM , 09PM-01AM Indian Standard Time(+5:30)<br />
<br />
''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.<br />
<br />
''Skills(proficient):'' C,Ruby, Node.js ,javascript<br />
<br />
''Experience'':Java,Python,Arduino,Scala,Matlab,CAD.<br />
<br />
=== Sonic Anemometer===<br />
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.<br />
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.<br />
<br />
=== Principle of Sonic Anemometer:===<br />
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.<br />
This pair of transducers act alternately as transmitters and receivers, exchanging high-frequency ultrasound pulses between themselves. The times of flight in each direction t<sub>1</sub> and t<sub>2</sub>, 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:<br />
<br />
[[File:Time.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
By combining Eqns (1) and (2) and solving for ` v`, the following equation is obtained:<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
<br />
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. <br />
<br />
[[File:Twodim.png|400px|thumb|left|2D axis(to be aligned with compass to true north)]][[File:Threet.png|400px|thumb|center|3D axis(for reference)]]<br />
<br />
<br />
<br />
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)<br />
Now following Equations are involved here,<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:Angle.png|300px|thumb|center|Angle]]<br />
<br />
<br />
Now from above equations it is clear that speed of sound calculated this way is independent of factors such as temperatures.<br />
<br />
Now with this device we can calculate the wind speed as well as temperature as described below-<br />
[[File:Temp.jpg|300px|thumb|center|Temperature(virtual temperature)]]<br />
<br />
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. <br />
<br />
The sonic temperature, Tv (in Kelvin), may differ from the absolute temperature by an amount equal to the<br />
water vapor content in the air measured. This difference amounts to ±1°C at 20°C and decreases as the temperature decreases.<br />
<br />
===PRUDAQ===<br />
<br />
DAQ are the Data Acquisition devices which are used to acquire data from sensors and acts as a bridge between sensors and host computer.<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
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.<br />
We can probably use second one for '''calibration''' and other tasks.<br />
<br />
===Error Analysis===<br />
Following are the equations defined in thermodynamics for values calculated from the data:<br />
<br />
'''''c<sup>2</sup> =403T(1+0.32e/p)<br />
'''''<br />
where '''c''' is the velocity of sound ('''m s<sup>-1</sup>''') 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,<br />
<br />
'''''Ts [= T(1 + 0.32 e/p)]''''' <br />
<br />
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:<br />
<br />
'''''Tv =T(1+0.38e/p)<br />
'''''<br />
Clearly, '''Ts''' more closely approximates '''T<sub>v</sub>''' than it does '''T''', the error being on the order of '''±0.01°C''' in assuming '''T′ =T<sub>v</sub>′(virtual)''', compared to '''±0.05°C''' for '''T′ =T′(absolute)'''.<br />
Since virtual temperature is used sometimes in boundary layer calculations, we can safely assume sonic temperature as virtual temperature within safe experimental assumptions.<br />
<br />
'''Sampling rate required to measure the time of flight'''<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
for 0.1 meter per second error rate in the wind speed, some conservative estimates about distance and the combined pulse speed can be made<br />
<br />
[[File:Error.png]]<br />
<br />
The change in time of flight for a pulse speed difference, even when that speed is quite high, is on the order of hundreds of nanoseconds. A sample rate of at least 10Mhz will be required.<br />
<br />
===Timeline:===<br />
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<br />
<br />
This program is of 12 Weeks-With Evaluation phase on June 26 - 30, 2017 and July 24 - 28, 2017<br />
<br />
====First Week:====<br />
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.<br />
====Second Week:====<br />
Connect the Prudaq and take sample readings as described on their wiki example.<br />
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<br />
====Third Week:====<br />
Program the PRU to read the sample results from PRUDAQ and trigger successive generation of two axis sonic transducers.<br />
====Fourth Week:====<br />
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.<br />
'''Evaluation Goals 1:'''<br />
''The device is able to stream the results of successive measurements after every specified interval to<br />
the user space and it is stored into text file.Software Testing Units are created for possible errors.''<br />
<br />
====Fifth Week:====<br />
This week we will build the structure as portable, possibly as described in below pictures.<br />
<br />
[[File:Sonic.jpg|300px|thumb|center|PVC for easy and flexible implementation]][[File:Unknown.jpg|300px|thumbnail|center|Made of Copper and steel to heat during Cold]]<br />
<br />
====Sixth Week:====<br />
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.<br />
====Seventh Week:====<br />
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.<br />
====Eighth Week:====<br />
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.<br />
'''Evaluation Goals 2:'''<br />
''Apparatus is tested extensively for outdoors, and is able to perform functional tasks in various possible <br />
conditions and output reliable data with accuracy and have test units defined but other factors like azimuth angle <br />
or other correction algorithms would be applied in the next stage.''<br />
<br />
====Ninth Week:====<br />
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).<br />
====Tenth Week:====<br />
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).<br />
Other modifications like variable sampling frequency in case if required later by developers.<br />
====Eleventh Week:====<br />
Review all the test units created earlier during program and modify them or build new.<br />
====Final Week:====<br />
Create a REST API sort of thing that enables the reading and logging of results into remote machines and proof check all modules<br />
<br />
==Final Goals:==<br />
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.<br />
<br />
===Future/Additional Goals:===<br />
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.<br />
<br />
Other Goals that can be helped or created by us or other open source contributors<br />
<br />
1. Make A python script type to create the graph and other possible representations of the data processed.<br />
<br />
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.<br />
<br />
==Experience and Approach==<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Projects====<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
==== Participations ====<br />
* 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.<br />
* Participated on National level, in TopCoder Open Finals organised by TopCoder.<br />
<br />
==== Approach ====<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Contingency==<br />
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.<br />
<br />
==Benefit==<br />
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.<br />
<br />
'''What community members speak -'''<br />
<br />
''Great project for the Aspiring Weather Scientist.''<br />
Michael Welling('''m_w''') <br />
<br />
***'''''Mentors!!! please add your Quote here.'''''***<br />
<br />
==Suggestions==<br />
Nothing For Now...<br />
<br />
Thanks.</div>Thrtransformerrhttps://elinux.org/index.php?title=GSoC2017_sonic_anemometer_proposal&diff=438511GSoC2017 sonic anemometer proposal2017-03-30T06:26:21Z<p>Thrtransformerr: /* About Me */</p>
<hr />
<div>[[Category: BeagleBoard]]<br />
[[Category: GSoC]]<br />
[[Category: GSoCProposal]]<br />
== Proposal for Sonic Anemometer ==<br />
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.<br />
<br />
''Idea as Quoted from GSoC Ideas page:'' <br />
Working prototype sonic anemometer using BeagleBone, PRUDAQ, and ultrasonic sensors. Analyze methods for accuracy/sensitivity <br />
(eg, time-of-flight vs. phase difference) and implement "best" method. Use PRUs for independent real-time control of ultrasonics.<br />
<br />
''Student:'' Naveen Saini<br />
<br />
''Mentors'': Steve Arnold(nerdboy), Stephanie Lockwood-Childs<br />
<br />
''Code:'' N/A<br />
<br />
''Wiki'': http://elinux.org/GSoC2017_sonic_anemometer_proposal<br />
<br />
''GSoC'': N/A<br />
<br />
==Status==<br />
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.<br />
<br />
==Proposal==<br />
I have completed the task required as described on Ideas page, and created a pull request, as listed [https://github.com/thetransformerr/gsoc-application/tree/master/ExampleEntryJasonKridner here].<br />
===About Me===<br />
''GitHub:'' [https://github.com/thetransformerr @thetransformerr]<br />
<br />
''IRC:'' thetransformerr<br />
<br />
''Linkedin:'' [https://www.linkedin.com/in/5naveensaini/ Naveen Saini]<br />
<br />
''School:'' [http://jecrcuniversity.edu.in JECRC,Jaipur]<br />
<br />
''Country:'' India[The mystical wonderland ;)]<br />
<br />
''Primary language:'' English,Hindi<br />
<br />
''Typical work hours:'' 08AM-10AM , 09PM-01AM Indian Standard Time(+5:30)<br />
<br />
''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.<br />
<br />
''Skills(proficient):'' C,Ruby, Node.js ,javascript<br />
<br />
"Experience":Java,Python,Arduino,Scala,Matlab,CAD.<br />
<br />
=== Sonic Anemometer===<br />
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.<br />
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.<br />
<br />
=== Principle of Sonic Anemometer:===<br />
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.<br />
This pair of transducers act alternately as transmitters and receivers, exchanging high-frequency ultrasound pulses between themselves. The times of flight in each direction t<sub>1</sub> and t<sub>2</sub>, 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:<br />
<br />
[[File:Time.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
By combining Eqns (1) and (2) and solving for ` v`, the following equation is obtained:<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
<br />
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. <br />
<br />
[[File:Twodim.png|400px|thumb|left|2D axis(to be aligned with compass to true north)]][[File:Threet.png|400px|thumb|center|3D axis(for reference)]]<br />
<br />
<br />
<br />
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)<br />
Now following Equations are involved here,<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:Angle.png|300px|thumb|center|Angle]]<br />
<br />
<br />
Now from above equations it is clear that speed of sound calculated this way is independent of factors such as temperatures.<br />
<br />
Now with this device we can calculate the wind speed as well as temperature as described below-<br />
[[File:Temp.jpg|300px|thumb|center|Temperature(virtual temperature)]]<br />
<br />
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. <br />
<br />
The sonic temperature, Tv (in Kelvin), may differ from the absolute temperature by an amount equal to the<br />
water vapor content in the air measured. This difference amounts to ±1°C at 20°C and decreases as the temperature decreases.<br />
<br />
===PRUDAQ===<br />
<br />
DAQ are the Data Acquisition devices which are used to acquire data from sensors and acts as a bridge between sensors and host computer.<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
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.<br />
We can probably use second one for '''calibration''' and other tasks.<br />
<br />
===Error Analysis===<br />
Following are the equations defined in thermodynamics for values calculated from the data:<br />
<br />
'''''c<sup>2</sup> =403T(1+0.32e/p)<br />
'''''<br />
where '''c''' is the velocity of sound ('''m s<sup>-1</sup>''') 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,<br />
<br />
'''''Ts [= T(1 + 0.32 e/p)]''''' <br />
<br />
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:<br />
<br />
'''''Tv =T(1+0.38e/p)<br />
'''''<br />
Clearly, '''Ts''' more closely approximates '''T<sub>v</sub>''' than it does '''T''', the error being on the order of '''±0.01°C''' in assuming '''T′ =T<sub>v</sub>′(virtual)''', compared to '''±0.05°C''' for '''T′ =T′(absolute)'''.<br />
Since virtual temperature is used sometimes in boundary layer calculations, we can safely assume sonic temperature as virtual temperature within safe experimental assumptions.<br />
<br />
'''Sampling rate required to measure the time of flight'''<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
for 0.1 meter per second error rate in the wind speed, some conservative estimates about distance and the combined pulse speed can be made<br />
<br />
[[File:Error.png]]<br />
<br />
The change in time of flight for a pulse speed difference, even when that speed is quite high, is on the order of hundreds of nanoseconds. A sample rate of at least 10Mhz will be required.<br />
<br />
===Timeline:===<br />
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<br />
<br />
This program is of 12 Weeks-With Evaluation phase on June 26 - 30, 2017 and July 24 - 28, 2017<br />
<br />
====First Week:====<br />
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.<br />
====Second Week:====<br />
Connect the Prudaq and take sample readings as described on their wiki example.<br />
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<br />
====Third Week:====<br />
Program the PRU to read the sample results from PRUDAQ and trigger successive generation of two axis sonic transducers.<br />
====Fourth Week:====<br />
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.<br />
'''Evaluation Goals 1:'''<br />
''The device is able to stream the results of successive measurements after every specified interval to<br />
the user space and it is stored into text file.Software Testing Units are created for possible errors.''<br />
<br />
====Fifth Week:====<br />
This week we will build the structure as portable, possibly as described in below pictures.<br />
<br />
[[File:Sonic.jpg|300px|thumb|center|PVC for easy and flexible implementation]][[File:Unknown.jpg|300px|thumbnail|center|Made of Copper and steel to heat during Cold]]<br />
<br />
====Sixth Week:====<br />
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.<br />
====Seventh Week:====<br />
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.<br />
====Eighth Week:====<br />
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.<br />
'''Evaluation Goals 2:'''<br />
''Apparatus is tested extensively for outdoors, and is able to perform functional tasks in various possible <br />
conditions and output reliable data with accuracy and have test units defined but other factors like azimuth angle <br />
or other correction algorithms would be applied in the next stage.''<br />
<br />
====Ninth Week:====<br />
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).<br />
====Tenth Week:====<br />
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).<br />
Other modifications like variable sampling frequency in case if required later by developers.<br />
====Eleventh Week:====<br />
Review all the test units created earlier during program and modify them or build new.<br />
====Final Week:====<br />
Create a REST API sort of thing that enables the reading and logging of results into remote machines and proof check all modules<br />
<br />
==Final Goals:==<br />
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.<br />
<br />
===Future/Additional Goals:===<br />
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.<br />
<br />
Other Goals that can be helped or created by us or other open source contributors<br />
<br />
1. Make A python script type to create the graph and other possible representations of the data processed.<br />
<br />
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.<br />
<br />
==Experience and Approach==<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Projects====<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
==== Participations ====<br />
* 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.<br />
* Participated on National level, in TopCoder Open Finals organised by TopCoder.<br />
<br />
==== Approach ====<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Contingency==<br />
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.<br />
<br />
==Benefit==<br />
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.<br />
<br />
'''What community members speak -'''<br />
<br />
''Great project for the Aspiring Weather Scientist.''<br />
Michael Welling('''m_w''') <br />
<br />
***'''''Mentors!!! please add your Quote here.'''''***<br />
<br />
==Suggestions==<br />
Nothing For Now...<br />
<br />
Thanks.</div>Thrtransformerrhttps://elinux.org/index.php?title=GSoC2017_sonic_anemometer_proposal&diff=438076GSoC2017 sonic anemometer proposal2017-03-25T16:43:12Z<p>Thrtransformerr: /* Proposal */</p>
<hr />
<div>[[Category: BeagleBoard]]<br />
[[Category: GSoC]]<br />
[[Category: GSoCProposal]]<br />
== Proposal for Sonic Anemometer ==<br />
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.<br />
<br />
''Idea as Quoted from GSoC Ideas page:'' <br />
Working prototype sonic anemometer using BeagleBone, PRUDAQ, and ultrasonic sensors. Analyze methods for accuracy/sensitivity <br />
(eg, time-of-flight vs. phase difference) and implement "best" method. Use PRUs for independent real-time control of ultrasonics.<br />
<br />
''Student:'' Naveen Saini<br />
<br />
''Mentors'': Steve Arnold(nerdboy), Stephanie Lockwood-Childs<br />
<br />
''Code:'' N/A<br />
<br />
''Wiki'': http://elinux.org/GSoC2017_sonic_anemometer_proposal<br />
<br />
''GSoC'': N/A<br />
<br />
==Status==<br />
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.<br />
<br />
==Proposal==<br />
I have completed the task required as described on Ideas page, and created a pull request, as listed [https://github.com/thetransformerr/gsoc-application/tree/master/ExampleEntryJasonKridner here].<br />
===About Me===<br />
''GitHub:'' [https://github.com/thetransformerr @thetransformerr]<br />
<br />
''IRC:'' thetransformerr<br />
<br />
''Linkedin:'' [https://www.linkedin.com/in/5naveensaini/ Naveen Saini]<br />
<br />
''School:'' [http://jecrcuniversity.edu.in JECRC,Jaipur]<br />
<br />
''Country:'' India[The mystical wonderland ;)]<br />
<br />
''Primary language:'' English,Hindi<br />
<br />
''Typical work hours:'' 08AM-10AM , 09PM-01AM Indian Standard Time(+5:30)<br />
<br />
''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.<br />
<br />
''Skills:'' C,Assembly language, Ruby, Python, Node.js<br />
<br />
=== Sonic Anemometer===<br />
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.<br />
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.<br />
<br />
=== Principle of Sonic Anemometer:===<br />
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.<br />
This pair of transducers act alternately as transmitters and receivers, exchanging high-frequency ultrasound pulses between themselves. The times of flight in each direction t<sub>1</sub> and t<sub>2</sub>, 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:<br />
<br />
[[File:Time.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
By combining Eqns (1) and (2) and solving for ` v`, the following equation is obtained:<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
<br />
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. <br />
<br />
[[File:Twodim.png|400px|thumb|left|2D axis(to be aligned with compass to true north)]][[File:Threet.png|400px|thumb|center|3D axis(for reference)]]<br />
<br />
<br />
<br />
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)<br />
Now following Equations are involved here,<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:Angle.png|300px|thumb|center|Angle]]<br />
<br />
<br />
Now from above equations it is clear that speed of sound calculated this way is independent of factors such as temperatures.<br />
<br />
Now with this device we can calculate the wind speed as well as temperature as described below-<br />
[[File:Temp.jpg|300px|thumb|center|Temperature(virtual temperature)]]<br />
<br />
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. <br />
<br />
The sonic temperature, Tv (in Kelvin), may differ from the absolute temperature by an amount equal to the<br />
water vapor content in the air measured. This difference amounts to ±1°C at 20°C and decreases as the temperature decreases.<br />
<br />
===PRUDAQ===<br />
<br />
DAQ are the Data Acquisition devices which are used to acquire data from sensors and acts as a bridge between sensors and host computer.<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
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.<br />
We can probably use second one for '''calibration''' and other tasks.<br />
<br />
===Error Analysis===<br />
Following are the equations defined in thermodynamics for values calculated from the data:<br />
<br />
'''''c<sup>2</sup> =403T(1+0.32e/p)<br />
'''''<br />
where '''c''' is the velocity of sound ('''m s<sup>-1</sup>''') 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,<br />
<br />
'''''Ts [= T(1 + 0.32 e/p)]''''' <br />
<br />
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:<br />
<br />
'''''Tv =T(1+0.38e/p)<br />
'''''<br />
Clearly, '''Ts''' more closely approximates '''T<sub>v</sub>''' than it does '''T''', the error being on the order of '''±0.01°C''' in assuming '''T′ =T<sub>v</sub>′(virtual)''', compared to '''±0.05°C''' for '''T′ =T′(absolute)'''.<br />
Since virtual temperature is used sometimes in boundary layer calculations, we can safely assume sonic temperature as virtual temperature within safe experimental assumptions.<br />
<br />
'''Sampling rate required to measure the time of flight'''<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
for 0.1 meter per second error rate in the wind speed, some conservative estimates about distance and the combined pulse speed can be made<br />
<br />
[[File:Error.png]]<br />
<br />
The change in time of flight for a pulse speed difference, even when that speed is quite high, is on the order of hundreds of nanoseconds. A sample rate of at least 10Mhz will be required.<br />
<br />
===Timeline:===<br />
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<br />
<br />
This program is of 12 Weeks-With Evaluation phase on June 26 - 30, 2017 and July 24 - 28, 2017<br />
<br />
====First Week:====<br />
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.<br />
====Second Week:====<br />
Connect the Prudaq and take sample readings as described on their wiki example.<br />
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<br />
====Third Week:====<br />
Program the PRU to read the sample results from PRUDAQ and trigger successive generation of two axis sonic transducers.<br />
====Fourth Week:====<br />
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.<br />
'''Evaluation Goals 1:'''<br />
''The device is able to stream the results of successive measurements after every specified interval to<br />
the user space and it is stored into text file.Software Testing Units are created for possible errors.''<br />
<br />
====Fifth Week:====<br />
This week we will build the structure as portable, possibly as described in below pictures.<br />
<br />
[[File:Sonic.jpg|300px|thumb|center|PVC for easy and flexible implementation]][[File:Unknown.jpg|300px|thumbnail|center|Made of Copper and steel to heat during Cold]]<br />
<br />
====Sixth Week:====<br />
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.<br />
====Seventh Week:====<br />
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.<br />
====Eighth Week:====<br />
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.<br />
'''Evaluation Goals 2:'''<br />
''Apparatus is tested extensively for outdoors, and is able to perform functional tasks in various possible <br />
conditions and output reliable data with accuracy and have test units defined but other factors like azimuth angle <br />
or other correction algorithms would be applied in the next stage.''<br />
<br />
====Ninth Week:====<br />
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).<br />
====Tenth Week:====<br />
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).<br />
Other modifications like variable sampling frequency in case if required later by developers.<br />
====Eleventh Week:====<br />
Review all the test units created earlier during program and modify them or build new.<br />
====Final Week:====<br />
Create a REST API sort of thing that enables the reading and logging of results into remote machines and proof check all modules<br />
<br />
==Final Goals:==<br />
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.<br />
<br />
===Future/Additional Goals:===<br />
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.<br />
<br />
Other Goals that can be helped or created by us or other open source contributors<br />
<br />
1. Make A python script type to create the graph and other possible representations of the data processed.<br />
<br />
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.<br />
<br />
==Experience and Approach==<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Projects====<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
==== Participations ====<br />
* 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.<br />
* Participated on National level, in TopCoder Open Finals organised by TopCoder.<br />
<br />
==== Approach ====<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Contingency==<br />
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.<br />
<br />
==Benefit==<br />
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.<br />
<br />
'''What community members speak -'''<br />
<br />
''Great project for the Aspiring Weather Scientist.''<br />
Michael Welling('''m_w''') <br />
<br />
***'''''Mentors!!! please add your Quote here.'''''***<br />
<br />
==Suggestions==<br />
Nothing For Now...<br />
<br />
Thanks.</div>Thrtransformerrhttps://elinux.org/index.php?title=GSoC2017_sonic_anemometer_proposal&diff=438071GSoC2017 sonic anemometer proposal2017-03-25T16:39:39Z<p>Thrtransformerr: /* Proposal for Sonic Anemometer */</p>
<hr />
<div>[[Category: BeagleBoard]]<br />
[[Category: GSoC]]<br />
[[Category: GSoCProposal]]<br />
== Proposal for Sonic Anemometer ==<br />
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.<br />
<br />
''Idea as Quoted from GSoC Ideas page:'' <br />
Working prototype sonic anemometer using BeagleBone, PRUDAQ, and ultrasonic sensors. Analyze methods for accuracy/sensitivity <br />
(eg, time-of-flight vs. phase difference) and implement "best" method. Use PRUs for independent real-time control of ultrasonics.<br />
<br />
''Student:'' Naveen Saini<br />
<br />
''Mentors'': Steve Arnold(nerdboy), Stephanie Lockwood-Childs<br />
<br />
''Code:'' N/A<br />
<br />
''Wiki'': http://elinux.org/GSoC2017_sonic_anemometer_proposal<br />
<br />
''GSoC'': N/A<br />
<br />
==Status==<br />
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.<br />
<br />
==Proposal==<br />
I have completed the task required as described on Ideas page, and created a pull request, as listed [https://github.com/thetransformerr/gsoc-application/tree/master/ExampleEntryJasonKridner here].<br />
===About Me===<br />
''GitHub:'' [https://github.com/thetransformerr @thetransformerr]<br />
<br />
''IRC:'' thetransformerr<br />
<br />
''Linkedin:'' [https://www.linkedin.com/in/5naveensaini/ Naveen Saini]<br />
<br />
''School:'' [http://jecrcuniversity.edu.in JECRC,Jaipur]<br />
<br />
''Country:'' India[The mystical wonderland ;)]<br />
<br />
''Primary language:'' English,Hindi<br />
<br />
''Typical work hours:'' 08AM-10AM , 09PM-01AM Indian Standard Time(+5:30)<br />
<br />
''GSoC participation:'' ''I haven't participated before.''The one of the most important reason is to create a project that I can be proud of and 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.<br />
<br />
''Skills:'' C,Assembly language, Ruby, Python, Node.js<br />
<br />
=== Sonic Anemometer===<br />
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.<br />
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.<br />
<br />
=== Principle of Sonic Anemometer:===<br />
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.<br />
This pair of transducers act alternately as transmitters and receivers, exchanging high-frequency ultrasound pulses between themselves. The times of flight in each direction t<sub>1</sub> and t<sub>2</sub>, 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:<br />
<br />
[[File:Time.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
By combining Eqns (1) and (2) and solving for ` v`, the following equation is obtained:<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
<br />
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. <br />
<br />
[[File:Twodim.png|400px|thumb|left|2D axis(to be aligned with compass to true north)]][[File:Threet.png|400px|thumb|center|3D axis(for reference)]]<br />
<br />
<br />
<br />
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)<br />
Now following Equations are involved here,<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:Angle.png|300px|thumb|center|Angle]]<br />
<br />
<br />
Now from above equations it is clear that speed of sound calculated this way is independent of factors such as temperatures.<br />
<br />
Now with this device we can calculate the wind speed as well as temperature as described below-<br />
[[File:Temp.jpg|300px|thumb|center|Temperature(virtual temperature)]]<br />
<br />
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. <br />
<br />
The sonic temperature, Tv (in Kelvin), may differ from the absolute temperature by an amount equal to the<br />
water vapor content in the air measured. This difference amounts to ±1°C at 20°C and decreases as the temperature decreases.<br />
<br />
===PRUDAQ===<br />
<br />
DAQ are the Data Acquisition devices which are used to acquire data from sensors and acts as a bridge between sensors and host computer.<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
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.<br />
We can probably use second one for '''calibration''' and other tasks.<br />
<br />
===Error Analysis===<br />
Following are the equations defined in thermodynamics for values calculated from the data:<br />
<br />
'''''c<sup>2</sup> =403T(1+0.32e/p)<br />
'''''<br />
where '''c''' is the velocity of sound ('''m s<sup>-1</sup>''') 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,<br />
<br />
'''''Ts [= T(1 + 0.32 e/p)]''''' <br />
<br />
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:<br />
<br />
'''''Tv =T(1+0.38e/p)<br />
'''''<br />
Clearly, '''Ts''' more closely approximates '''T<sub>v</sub>''' than it does '''T''', the error being on the order of '''±0.01°C''' in assuming '''T′ =T<sub>v</sub>′(virtual)''', compared to '''±0.05°C''' for '''T′ =T′(absolute)'''.<br />
Since virtual temperature is used sometimes in boundary layer calculations, we can safely assume sonic temperature as virtual temperature within safe experimental assumptions.<br />
<br />
'''Sampling rate required to measure the time of flight'''<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
for 0.1 meter per second error rate in the wind speed, some conservative estimates about distance and the combined pulse speed can be made<br />
<br />
[[File:Error.png]]<br />
<br />
The change in time of flight for a pulse speed difference, even when that speed is quite high, is on the order of hundreds of nanoseconds. A sample rate of at least 10Mhz will be required.<br />
<br />
===Timeline:===<br />
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<br />
<br />
This program is of 12 Weeks-With Evaluation phase on June 26 - 30, 2017 and July 24 - 28, 2017<br />
<br />
====First Week:====<br />
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.<br />
====Second Week:====<br />
Connect the Prudaq and take sample readings as described on their wiki example.<br />
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<br />
====Third Week:====<br />
Program the PRU to read the sample results from PRUDAQ and trigger successive generation of two axis sonic transducers.<br />
====Fourth Week:====<br />
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.<br />
'''Evaluation Goals 1:'''<br />
''The device is able to stream the results of successive measurements after every specified interval to<br />
the user space and it is stored into text file.Software Testing Units are created for possible errors.''<br />
<br />
====Fifth Week:====<br />
This week we will build the structure as portable, possibly as described in below pictures.<br />
<br />
[[File:Sonic.jpg|300px|thumb|center|PVC for easy and flexible implementation]][[File:Unknown.jpg|300px|thumbnail|center|Made of Copper and steel to heat during Cold]]<br />
<br />
====Sixth Week:====<br />
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.<br />
====Seventh Week:====<br />
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.<br />
====Eighth Week:====<br />
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.<br />
'''Evaluation Goals 2:'''<br />
''Apparatus is tested extensively for outdoors, and is able to perform functional tasks in various possible <br />
conditions and output reliable data with accuracy and have test units defined but other factors like azimuth angle <br />
or other correction algorithms would be applied in the next stage.''<br />
<br />
====Ninth Week:====<br />
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).<br />
====Tenth Week:====<br />
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).<br />
Other modifications like variable sampling frequency in case if required later by developers.<br />
====Eleventh Week:====<br />
Review all the test units created earlier during program and modify them or build new.<br />
====Final Week:====<br />
Create a REST API sort of thing that enables the reading and logging of results into remote machines and proof check all modules<br />
<br />
==Final Goals:==<br />
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.<br />
<br />
===Future/Additional Goals:===<br />
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.<br />
<br />
Other Goals that can be helped or created by us or other open source contributors<br />
<br />
1. Make A python script type to create the graph and other possible representations of the data processed.<br />
<br />
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.<br />
<br />
==Experience and Approach==<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Projects====<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
==== Participations ====<br />
* 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.<br />
* Participated on National level, in TopCoder Open Finals organised by TopCoder.<br />
<br />
==== Approach ====<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Contingency==<br />
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.<br />
<br />
==Benefit==<br />
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.<br />
<br />
'''What community members speak -'''<br />
<br />
''Great project for the Aspiring Weather Scientist.''<br />
Michael Welling('''m_w''') <br />
<br />
***'''''Mentors!!! please add your Quote here.'''''***<br />
<br />
==Suggestions==<br />
Nothing For Now...<br />
<br />
Thanks.</div>Thrtransformerrhttps://elinux.org/index.php?title=GSoC2017_sonic_anemometer_proposal&diff=438066GSoC2017 sonic anemometer proposal2017-03-25T15:54:09Z<p>Thrtransformerr: /* Projects */</p>
<hr />
<div>[[Category: BeagleBoard]]<br />
[[Category: GSoC]]<br />
[[Category: GSoCProposal]]<br />
== Proposal for Sonic Anemometer ==<br />
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.<br />
<br />
''Idea As Quoted from GSoC Ideas page:'' <br />
Working prototype sonic anemometer using BeagleBone, PRUDAQ, and ultrasonic sensors. Analyze methods for accuracy/sensitivity <br />
(eg, time-of-flight vs. phase difference) and implement "best" method. Use PRUs for independent real-time control of ultrasonics.<br />
<br />
''Student:'' Naveen Saini<br />
<br />
''Mentors'': Steve Arnold(nerdboy), Stephanie Lockwood-Childs<br />
<br />
''Code:'' N/A<br />
<br />
''Wiki'': http://elinux.org/GSoC2017_sonic_anemometer_proposal<br />
<br />
''GSoC'': N/A<br />
<br />
==Status==<br />
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.<br />
<br />
==Proposal==<br />
I have completed the task required as described on Ideas page, and created a pull request, as listed [https://github.com/thetransformerr/gsoc-application/tree/master/ExampleEntryJasonKridner here].<br />
===About Me===<br />
''GitHub:'' [https://github.com/thetransformerr @thetransformerr]<br />
<br />
''IRC:'' thetransformerr<br />
<br />
''Linkedin:'' [https://www.linkedin.com/in/5naveensaini/ Naveen Saini]<br />
<br />
''School:'' [http://jecrcuniversity.edu.in JECRC,Jaipur]<br />
<br />
''Country:'' India[The mystical wonderland ;)]<br />
<br />
''Primary language:'' English,Hindi<br />
<br />
''Typical work hours:'' 08AM-10AM , 09PM-01AM Indian Standard Time(+5:30)<br />
<br />
''GSoC participation:'' ''I haven't participated before.''The one of the most important reason is to create a project that I can be proud of and 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.<br />
<br />
''Skills:'' C,Assembly language, Ruby, Python, Node.js<br />
<br />
=== Sonic Anemometer===<br />
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.<br />
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.<br />
<br />
=== Principle of Sonic Anemometer:===<br />
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.<br />
This pair of transducers act alternately as transmitters and receivers, exchanging high-frequency ultrasound pulses between themselves. The times of flight in each direction t<sub>1</sub> and t<sub>2</sub>, 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:<br />
<br />
[[File:Time.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
By combining Eqns (1) and (2) and solving for ` v`, the following equation is obtained:<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
<br />
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. <br />
<br />
[[File:Twodim.png|400px|thumb|left|2D axis(to be aligned with compass to true north)]][[File:Threet.png|400px|thumb|center|3D axis(for reference)]]<br />
<br />
<br />
<br />
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)<br />
Now following Equations are involved here,<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:Angle.png|300px|thumb|center|Angle]]<br />
<br />
<br />
Now from above equations it is clear that speed of sound calculated this way is independent of factors such as temperatures.<br />
<br />
Now with this device we can calculate the wind speed as well as temperature as described below-<br />
[[File:Temp.jpg|300px|thumb|center|Temperature(virtual temperature)]]<br />
<br />
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. <br />
<br />
The sonic temperature, Tv (in Kelvin), may differ from the absolute temperature by an amount equal to the<br />
water vapor content in the air measured. This difference amounts to ±1°C at 20°C and decreases as the temperature decreases.<br />
<br />
===PRUDAQ===<br />
<br />
DAQ are the Data Acquisition devices which are used to acquire data from sensors and acts as a bridge between sensors and host computer.<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
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.<br />
We can probably use second one for '''calibration''' and other tasks.<br />
<br />
===Error Analysis===<br />
Following are the equations defined in thermodynamics for values calculated from the data:<br />
<br />
'''''c<sup>2</sup> =403T(1+0.32e/p)<br />
'''''<br />
where '''c''' is the velocity of sound ('''m s<sup>-1</sup>''') 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,<br />
<br />
'''''Ts [= T(1 + 0.32 e/p)]''''' <br />
<br />
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:<br />
<br />
'''''Tv =T(1+0.38e/p)<br />
'''''<br />
Clearly, '''Ts''' more closely approximates '''T<sub>v</sub>''' than it does '''T''', the error being on the order of '''±0.01°C''' in assuming '''T′ =T<sub>v</sub>′(virtual)''', compared to '''±0.05°C''' for '''T′ =T′(absolute)'''.<br />
Since virtual temperature is used sometimes in boundary layer calculations, we can safely assume sonic temperature as virtual temperature within safe experimental assumptions.<br />
<br />
'''Sampling rate required to measure the time of flight'''<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
for 0.1 meter per second error rate in the wind speed, some conservative estimates about distance and the combined pulse speed can be made<br />
<br />
[[File:Error.png]]<br />
<br />
The change in time of flight for a pulse speed difference, even when that speed is quite high, is on the order of hundreds of nanoseconds. A sample rate of at least 10Mhz will be required.<br />
<br />
===Timeline:===<br />
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<br />
<br />
This program is of 12 Weeks-With Evaluation phase on June 26 - 30, 2017 and July 24 - 28, 2017<br />
<br />
====First Week:====<br />
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.<br />
====Second Week:====<br />
Connect the Prudaq and take sample readings as described on their wiki example.<br />
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<br />
====Third Week:====<br />
Program the PRU to read the sample results from PRUDAQ and trigger successive generation of two axis sonic transducers.<br />
====Fourth Week:====<br />
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.<br />
'''Evaluation Goals 1:'''<br />
''The device is able to stream the results of successive measurements after every specified interval to<br />
the user space and it is stored into text file.Software Testing Units are created for possible errors.''<br />
<br />
====Fifth Week:====<br />
This week we will build the structure as portable, possibly as described in below pictures.<br />
<br />
[[File:Sonic.jpg|300px|thumb|center|PVC for easy and flexible implementation]][[File:Unknown.jpg|300px|thumbnail|center|Made of Copper and steel to heat during Cold]]<br />
<br />
====Sixth Week:====<br />
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.<br />
====Seventh Week:====<br />
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.<br />
====Eighth Week:====<br />
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.<br />
'''Evaluation Goals 2:'''<br />
''Apparatus is tested extensively for outdoors, and is able to perform functional tasks in various possible <br />
conditions and output reliable data with accuracy and have test units defined but other factors like azimuth angle <br />
or other correction algorithms would be applied in the next stage.''<br />
<br />
====Ninth Week:====<br />
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).<br />
====Tenth Week:====<br />
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).<br />
Other modifications like variable sampling frequency in case if required later by developers.<br />
====Eleventh Week:====<br />
Review all the test units created earlier during program and modify them or build new.<br />
====Final Week:====<br />
Create a REST API sort of thing that enables the reading and logging of results into remote machines and proof check all modules<br />
<br />
==Final Goals:==<br />
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.<br />
<br />
===Future/Additional Goals:===<br />
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.<br />
<br />
Other Goals that can be helped or created by us or other open source contributors<br />
<br />
1. Make A python script type to create the graph and other possible representations of the data processed.<br />
<br />
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.<br />
<br />
==Experience and Approach==<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Projects====<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
==== Participations ====<br />
* 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.<br />
* Participated on National level, in TopCoder Open Finals organised by TopCoder.<br />
<br />
==== Approach ====<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Contingency==<br />
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.<br />
<br />
==Benefit==<br />
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.<br />
<br />
'''What community members speak -'''<br />
<br />
''Great project for the Aspiring Weather Scientist.''<br />
Michael Welling('''m_w''') <br />
<br />
***'''''Mentors!!! please add your Quote here.'''''***<br />
<br />
==Suggestions==<br />
Nothing For Now...<br />
<br />
Thanks.</div>Thrtransformerrhttps://elinux.org/index.php?title=GSoC2017_sonic_anemometer_proposal&diff=438061GSoC2017 sonic anemometer proposal2017-03-25T15:53:02Z<p>Thrtransformerr: /* Experience and Approach */</p>
<hr />
<div>[[Category: BeagleBoard]]<br />
[[Category: GSoC]]<br />
[[Category: GSoCProposal]]<br />
== Proposal for Sonic Anemometer ==<br />
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.<br />
<br />
''Idea As Quoted from GSoC Ideas page:'' <br />
Working prototype sonic anemometer using BeagleBone, PRUDAQ, and ultrasonic sensors. Analyze methods for accuracy/sensitivity <br />
(eg, time-of-flight vs. phase difference) and implement "best" method. Use PRUs for independent real-time control of ultrasonics.<br />
<br />
''Student:'' Naveen Saini<br />
<br />
''Mentors'': Steve Arnold(nerdboy), Stephanie Lockwood-Childs<br />
<br />
''Code:'' N/A<br />
<br />
''Wiki'': http://elinux.org/GSoC2017_sonic_anemometer_proposal<br />
<br />
''GSoC'': N/A<br />
<br />
==Status==<br />
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.<br />
<br />
==Proposal==<br />
I have completed the task required as described on Ideas page, and created a pull request, as listed [https://github.com/thetransformerr/gsoc-application/tree/master/ExampleEntryJasonKridner here].<br />
===About Me===<br />
''GitHub:'' [https://github.com/thetransformerr @thetransformerr]<br />
<br />
''IRC:'' thetransformerr<br />
<br />
''Linkedin:'' [https://www.linkedin.com/in/5naveensaini/ Naveen Saini]<br />
<br />
''School:'' [http://jecrcuniversity.edu.in JECRC,Jaipur]<br />
<br />
''Country:'' India[The mystical wonderland ;)]<br />
<br />
''Primary language:'' English,Hindi<br />
<br />
''Typical work hours:'' 08AM-10AM , 09PM-01AM Indian Standard Time(+5:30)<br />
<br />
''GSoC participation:'' ''I haven't participated before.''The one of the most important reason is to create a project that I can be proud of and 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.<br />
<br />
''Skills:'' C,Assembly language, Ruby, Python, Node.js<br />
<br />
=== Sonic Anemometer===<br />
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.<br />
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.<br />
<br />
=== Principle of Sonic Anemometer:===<br />
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.<br />
This pair of transducers act alternately as transmitters and receivers, exchanging high-frequency ultrasound pulses between themselves. The times of flight in each direction t<sub>1</sub> and t<sub>2</sub>, 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:<br />
<br />
[[File:Time.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
By combining Eqns (1) and (2) and solving for ` v`, the following equation is obtained:<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
<br />
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. <br />
<br />
[[File:Twodim.png|400px|thumb|left|2D axis(to be aligned with compass to true north)]][[File:Threet.png|400px|thumb|center|3D axis(for reference)]]<br />
<br />
<br />
<br />
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)<br />
Now following Equations are involved here,<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:Angle.png|300px|thumb|center|Angle]]<br />
<br />
<br />
Now from above equations it is clear that speed of sound calculated this way is independent of factors such as temperatures.<br />
<br />
Now with this device we can calculate the wind speed as well as temperature as described below-<br />
[[File:Temp.jpg|300px|thumb|center|Temperature(virtual temperature)]]<br />
<br />
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. <br />
<br />
The sonic temperature, Tv (in Kelvin), may differ from the absolute temperature by an amount equal to the<br />
water vapor content in the air measured. This difference amounts to ±1°C at 20°C and decreases as the temperature decreases.<br />
<br />
===PRUDAQ===<br />
<br />
DAQ are the Data Acquisition devices which are used to acquire data from sensors and acts as a bridge between sensors and host computer.<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
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.<br />
We can probably use second one for '''calibration''' and other tasks.<br />
<br />
===Error Analysis===<br />
Following are the equations defined in thermodynamics for values calculated from the data:<br />
<br />
'''''c<sup>2</sup> =403T(1+0.32e/p)<br />
'''''<br />
where '''c''' is the velocity of sound ('''m s<sup>-1</sup>''') 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,<br />
<br />
'''''Ts [= T(1 + 0.32 e/p)]''''' <br />
<br />
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:<br />
<br />
'''''Tv =T(1+0.38e/p)<br />
'''''<br />
Clearly, '''Ts''' more closely approximates '''T<sub>v</sub>''' than it does '''T''', the error being on the order of '''±0.01°C''' in assuming '''T′ =T<sub>v</sub>′(virtual)''', compared to '''±0.05°C''' for '''T′ =T′(absolute)'''.<br />
Since virtual temperature is used sometimes in boundary layer calculations, we can safely assume sonic temperature as virtual temperature within safe experimental assumptions.<br />
<br />
'''Sampling rate required to measure the time of flight'''<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
for 0.1 meter per second error rate in the wind speed, some conservative estimates about distance and the combined pulse speed can be made<br />
<br />
[[File:Error.png]]<br />
<br />
The change in time of flight for a pulse speed difference, even when that speed is quite high, is on the order of hundreds of nanoseconds. A sample rate of at least 10Mhz will be required.<br />
<br />
===Timeline:===<br />
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<br />
<br />
This program is of 12 Weeks-With Evaluation phase on June 26 - 30, 2017 and July 24 - 28, 2017<br />
<br />
====First Week:====<br />
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.<br />
====Second Week:====<br />
Connect the Prudaq and take sample readings as described on their wiki example.<br />
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<br />
====Third Week:====<br />
Program the PRU to read the sample results from PRUDAQ and trigger successive generation of two axis sonic transducers.<br />
====Fourth Week:====<br />
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.<br />
'''Evaluation Goals 1:'''<br />
''The device is able to stream the results of successive measurements after every specified interval to<br />
the user space and it is stored into text file.Software Testing Units are created for possible errors.''<br />
<br />
====Fifth Week:====<br />
This week we will build the structure as portable, possibly as described in below pictures.<br />
<br />
[[File:Sonic.jpg|300px|thumb|center|PVC for easy and flexible implementation]][[File:Unknown.jpg|300px|thumbnail|center|Made of Copper and steel to heat during Cold]]<br />
<br />
====Sixth Week:====<br />
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.<br />
====Seventh Week:====<br />
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.<br />
====Eighth Week:====<br />
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.<br />
'''Evaluation Goals 2:'''<br />
''Apparatus is tested extensively for outdoors, and is able to perform functional tasks in various possible <br />
conditions and output reliable data with accuracy and have test units defined but other factors like azimuth angle <br />
or other correction algorithms would be applied in the next stage.''<br />
<br />
====Ninth Week:====<br />
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).<br />
====Tenth Week:====<br />
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).<br />
Other modifications like variable sampling frequency in case if required later by developers.<br />
====Eleventh Week:====<br />
Review all the test units created earlier during program and modify them or build new.<br />
====Final Week:====<br />
Create a REST API sort of thing that enables the reading and logging of results into remote machines and proof check all modules<br />
<br />
==Final Goals:==<br />
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.<br />
<br />
===Future/Additional Goals:===<br />
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.<br />
<br />
Other Goals that can be helped or created by us or other open source contributors<br />
<br />
1. Make A python script type to create the graph and other possible representations of the data processed.<br />
<br />
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.<br />
<br />
==Experience and Approach==<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Projects====<br />
* 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.<br />
* 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.<br />
* 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, Apache Spark et.<br />
<br />
==== Participations ====<br />
* 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.<br />
* Participated on National level, in TopCoder Open Finals organised by TopCoder.<br />
<br />
==== Approach ====<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Contingency==<br />
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.<br />
<br />
==Benefit==<br />
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.<br />
<br />
'''What community members speak -'''<br />
<br />
''Great project for the Aspiring Weather Scientist.''<br />
Michael Welling('''m_w''') <br />
<br />
***'''''Mentors!!! please add your Quote here.'''''***<br />
<br />
==Suggestions==<br />
Nothing For Now...<br />
<br />
Thanks.</div>Thrtransformerrhttps://elinux.org/index.php?title=GSoC2017_sonic_anemometer_proposal&diff=438041GSoC2017 sonic anemometer proposal2017-03-25T15:14:43Z<p>Thrtransformerr: /* Experience and Approach */</p>
<hr />
<div>[[Category: BeagleBoard]]<br />
[[Category: GSoC]]<br />
[[Category: GSoCProposal]]<br />
== Proposal for Sonic Anemometer ==<br />
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.<br />
<br />
''Idea As Quoted from GSoC Ideas page:'' <br />
Working prototype sonic anemometer using BeagleBone, PRUDAQ, and ultrasonic sensors. Analyze methods for accuracy/sensitivity <br />
(eg, time-of-flight vs. phase difference) and implement "best" method. Use PRUs for independent real-time control of ultrasonics.<br />
<br />
''Student:'' Naveen Saini<br />
<br />
''Mentors'': Steve Arnold(nerdboy), Stephanie Lockwood-Childs<br />
<br />
''Code:'' N/A<br />
<br />
''Wiki'': http://elinux.org/GSoC2017_sonic_anemometer_proposal<br />
<br />
''GSoC'': N/A<br />
<br />
==Status==<br />
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.<br />
<br />
==Proposal==<br />
I have completed the task required as described on Ideas page, and created a pull request, as listed [https://github.com/thetransformerr/gsoc-application/tree/master/ExampleEntryJasonKridner here].<br />
===About Me===<br />
''GitHub:'' [https://github.com/thetransformerr @thetransformerr]<br />
<br />
''IRC:'' thetransformerr<br />
<br />
''Linkedin:'' [https://www.linkedin.com/in/5naveensaini/ Naveen Saini]<br />
<br />
''School:'' [http://jecrcuniversity.edu.in JECRC,Jaipur]<br />
<br />
''Country:'' India[The mystical wonderland ;)]<br />
<br />
''Primary language:'' English,Hindi<br />
<br />
''Typical work hours:'' 08AM-10AM , 09PM-01AM Indian Standard Time(+5:30)<br />
<br />
''GSoC participation:'' ''I haven't participated before.''The one of the most important reason is to create a project that I can be proud of and 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.<br />
<br />
''Skills:'' C,Assembly language, Ruby, Python, Node.js<br />
<br />
=== Sonic Anemometer===<br />
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.<br />
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.<br />
<br />
=== Principle of Sonic Anemometer:===<br />
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.<br />
This pair of transducers act alternately as transmitters and receivers, exchanging high-frequency ultrasound pulses between themselves. The times of flight in each direction t<sub>1</sub> and t<sub>2</sub>, 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:<br />
<br />
[[File:Time.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
By combining Eqns (1) and (2) and solving for ` v`, the following equation is obtained:<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
<br />
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. <br />
<br />
[[File:Twodim.png|400px|thumb|left|2D axis(to be aligned with compass to true north)]][[File:Threet.png|400px|thumb|center|3D axis(for reference)]]<br />
<br />
<br />
<br />
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)<br />
Now following Equations are involved here,<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:Angle.png|300px|thumb|center|Angle]]<br />
<br />
<br />
Now from above equations it is clear that speed of sound calculated this way is independent of factors such as temperatures.<br />
<br />
Now with this device we can calculate the wind speed as well as temperature as described below-<br />
[[File:Temp.jpg|300px|thumb|center|Temperature(virtual temperature)]]<br />
<br />
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. <br />
<br />
The sonic temperature, Tv (in Kelvin), may differ from the absolute temperature by an amount equal to the<br />
water vapor content in the air measured. This difference amounts to ±1°C at 20°C and decreases as the temperature decreases.<br />
<br />
===PRUDAQ===<br />
<br />
DAQ are the Data Acquisition devices which are used to acquire data from sensors and acts as a bridge between sensors and host computer.<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
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.<br />
We can probably use second one for '''calibration''' and other tasks.<br />
<br />
===Error Analysis===<br />
Following are the equations defined in thermodynamics for values calculated from the data:<br />
<br />
'''''c<sup>2</sup> =403T(1+0.32e/p)<br />
'''''<br />
where '''c''' is the velocity of sound ('''m s<sup>-1</sup>''') 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,<br />
<br />
'''''Ts [= T(1 + 0.32 e/p)]''''' <br />
<br />
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:<br />
<br />
'''''Tv =T(1+0.38e/p)<br />
'''''<br />
Clearly, '''Ts''' more closely approximates '''T<sub>v</sub>''' than it does '''T''', the error being on the order of '''±0.01°C''' in assuming '''T′ =T<sub>v</sub>′(virtual)''', compared to '''±0.05°C''' for '''T′ =T′(absolute)'''.<br />
Since virtual temperature is used sometimes in boundary layer calculations, we can safely assume sonic temperature as virtual temperature within safe experimental assumptions.<br />
<br />
'''Sampling rate required to measure the time of flight'''<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
for 0.1 meter per second error rate in the wind speed, some conservative estimates about distance and the combined pulse speed can be made<br />
<br />
[[File:Error.png]]<br />
<br />
The change in time of flight for a pulse speed difference, even when that speed is quite high, is on the order of hundreds of nanoseconds. A sample rate of at least 10Mhz will be required.<br />
<br />
===Timeline:===<br />
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<br />
<br />
This program is of 12 Weeks-With Evaluation phase on June 26 - 30, 2017 and July 24 - 28, 2017<br />
<br />
====First Week:====<br />
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.<br />
====Second Week:====<br />
Connect the Prudaq and take sample readings as described on their wiki example.<br />
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<br />
====Third Week:====<br />
Program the PRU to read the sample results from PRUDAQ and trigger successive generation of two axis sonic transducers.<br />
====Fourth Week:====<br />
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.<br />
'''Evaluation Goals 1:'''<br />
''The device is able to stream the results of successive measurements after every specified interval to<br />
the user space and it is stored into text file.Software Testing Units are created for possible errors.''<br />
<br />
====Fifth Week:====<br />
This week we will build the structure as portable, possibly as described in below pictures.<br />
<br />
[[File:Sonic.jpg|300px|thumb|center|PVC for easy and flexible implementation]][[File:Unknown.jpg|300px|thumbnail|center|Made of Copper and steel to heat during Cold]]<br />
<br />
====Sixth Week:====<br />
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.<br />
====Seventh Week:====<br />
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.<br />
====Eighth Week:====<br />
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.<br />
'''Evaluation Goals 2:'''<br />
''Apparatus is tested extensively for outdoors, and is able to perform functional tasks in various possible <br />
conditions and output reliable data with accuracy and have test units defined but other factors like azimuth angle <br />
or other correction algorithms would be applied in the next stage.''<br />
<br />
====Ninth Week:====<br />
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).<br />
====Tenth Week:====<br />
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).<br />
Other modifications like variable sampling frequency in case if required later by developers.<br />
====Eleventh Week:====<br />
Review all the test units created earlier during program and modify them or build new.<br />
====Final Week:====<br />
Create a REST API sort of thing that enables the reading and logging of results into remote machines and proof check all modules<br />
<br />
==Final Goals:==<br />
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.<br />
<br />
===Future/Additional Goals:===<br />
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.<br />
<br />
Other Goals that can be helped or created by us or other open source contributors<br />
<br />
1. Make A python script type to create the graph and other possible representations of the data processed.<br />
<br />
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.<br />
<br />
==Experience and Approach==<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Contingency==<br />
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.<br />
<br />
==Benefit==<br />
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.<br />
<br />
'''What community members speak -'''<br />
<br />
''Great project for the Aspiring Weather Scientist.''<br />
Michael Welling('''m_w''') <br />
<br />
***'''''Mentors!!! please add your Quote here.'''''***<br />
<br />
==Suggestions==<br />
Nothing For Now...<br />
<br />
Thanks.</div>Thrtransformerrhttps://elinux.org/index.php?title=GSoC2017_sonic_anemometer_proposal&diff=438036GSoC2017 sonic anemometer proposal2017-03-25T15:10:09Z<p>Thrtransformerr: /* Experience and Approach */</p>
<hr />
<div>[[Category: BeagleBoard]]<br />
[[Category: GSoC]]<br />
[[Category: GSoCProposal]]<br />
== Proposal for Sonic Anemometer ==<br />
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.<br />
<br />
''Idea As Quoted from GSoC Ideas page:'' <br />
Working prototype sonic anemometer using BeagleBone, PRUDAQ, and ultrasonic sensors. Analyze methods for accuracy/sensitivity <br />
(eg, time-of-flight vs. phase difference) and implement "best" method. Use PRUs for independent real-time control of ultrasonics.<br />
<br />
''Student:'' Naveen Saini<br />
<br />
''Mentors'': Steve Arnold(nerdboy), Stephanie Lockwood-Childs<br />
<br />
''Code:'' N/A<br />
<br />
''Wiki'': http://elinux.org/GSoC2017_sonic_anemometer_proposal<br />
<br />
''GSoC'': N/A<br />
<br />
==Status==<br />
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.<br />
<br />
==Proposal==<br />
I have completed the task required as described on Ideas page, and created a pull request, as listed [https://github.com/thetransformerr/gsoc-application/tree/master/ExampleEntryJasonKridner here].<br />
===About Me===<br />
''GitHub:'' [https://github.com/thetransformerr @thetransformerr]<br />
<br />
''IRC:'' thetransformerr<br />
<br />
''Linkedin:'' [https://www.linkedin.com/in/5naveensaini/ Naveen Saini]<br />
<br />
''School:'' [http://jecrcuniversity.edu.in JECRC,Jaipur]<br />
<br />
''Country:'' India[The mystical wonderland ;)]<br />
<br />
''Primary language:'' English,Hindi<br />
<br />
''Typical work hours:'' 08AM-10AM , 09PM-01AM Indian Standard Time(+5:30)<br />
<br />
''GSoC participation:'' ''I haven't participated before.''The one of the most important reason is to create a project that I can be proud of and 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.<br />
<br />
''Skills:'' C,Assembly language, Ruby, Python, Node.js<br />
<br />
=== Sonic Anemometer===<br />
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.<br />
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.<br />
<br />
=== Principle of Sonic Anemometer:===<br />
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.<br />
This pair of transducers act alternately as transmitters and receivers, exchanging high-frequency ultrasound pulses between themselves. The times of flight in each direction t<sub>1</sub> and t<sub>2</sub>, 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:<br />
<br />
[[File:Time.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
By combining Eqns (1) and (2) and solving for ` v`, the following equation is obtained:<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
<br />
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. <br />
<br />
[[File:Twodim.png|400px|thumb|left|2D axis(to be aligned with compass to true north)]][[File:Threet.png|400px|thumb|center|3D axis(for reference)]]<br />
<br />
<br />
<br />
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)<br />
Now following Equations are involved here,<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:Angle.png|300px|thumb|center|Angle]]<br />
<br />
<br />
Now from above equations it is clear that speed of sound calculated this way is independent of factors such as temperatures.<br />
<br />
Now with this device we can calculate the wind speed as well as temperature as described below-<br />
[[File:Temp.jpg|300px|thumb|center|Temperature(virtual temperature)]]<br />
<br />
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. <br />
<br />
The sonic temperature, Tv (in Kelvin), may differ from the absolute temperature by an amount equal to the<br />
water vapor content in the air measured. This difference amounts to ±1°C at 20°C and decreases as the temperature decreases.<br />
<br />
===PRUDAQ===<br />
<br />
DAQ are the Data Acquisition devices which are used to acquire data from sensors and acts as a bridge between sensors and host computer.<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
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.<br />
We can probably use second one for '''calibration''' and other tasks.<br />
<br />
===Error Analysis===<br />
Following are the equations defined in thermodynamics for values calculated from the data:<br />
<br />
'''''c<sup>2</sup> =403T(1+0.32e/p)<br />
'''''<br />
where '''c''' is the velocity of sound ('''m s<sup>-1</sup>''') 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,<br />
<br />
'''''Ts [= T(1 + 0.32 e/p)]''''' <br />
<br />
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:<br />
<br />
'''''Tv =T(1+0.38e/p)<br />
'''''<br />
Clearly, '''Ts''' more closely approximates '''T<sub>v</sub>''' than it does '''T''', the error being on the order of '''±0.01°C''' in assuming '''T′ =T<sub>v</sub>′(virtual)''', compared to '''±0.05°C''' for '''T′ =T′(absolute)'''.<br />
Since virtual temperature is used sometimes in boundary layer calculations, we can safely assume sonic temperature as virtual temperature within safe experimental assumptions.<br />
<br />
'''Sampling rate required to measure the time of flight'''<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
for 0.1 meter per second error rate in the wind speed, some conservative estimates about distance and the combined pulse speed can be made<br />
<br />
[[File:Error.png]]<br />
<br />
The change in time of flight for a pulse speed difference, even when that speed is quite high, is on the order of hundreds of nanoseconds. A sample rate of at least 10Mhz will be required.<br />
<br />
===Timeline:===<br />
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<br />
<br />
This program is of 12 Weeks-With Evaluation phase on June 26 - 30, 2017 and July 24 - 28, 2017<br />
<br />
====First Week:====<br />
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.<br />
====Second Week:====<br />
Connect the Prudaq and take sample readings as described on their wiki example.<br />
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<br />
====Third Week:====<br />
Program the PRU to read the sample results from PRUDAQ and trigger successive generation of two axis sonic transducers.<br />
====Fourth Week:====<br />
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.<br />
'''Evaluation Goals 1:'''<br />
''The device is able to stream the results of successive measurements after every specified interval to<br />
the user space and it is stored into text file.Software Testing Units are created for possible errors.''<br />
<br />
====Fifth Week:====<br />
This week we will build the structure as portable, possibly as described in below pictures.<br />
<br />
[[File:Sonic.jpg|300px|thumb|center|PVC for easy and flexible implementation]][[File:Unknown.jpg|300px|thumbnail|center|Made of Copper and steel to heat during Cold]]<br />
<br />
====Sixth Week:====<br />
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.<br />
====Seventh Week:====<br />
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.<br />
====Eighth Week:====<br />
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.<br />
'''Evaluation Goals 2:'''<br />
''Apparatus is tested extensively for outdoors, and is able to perform functional tasks in various possible <br />
conditions and output reliable data with accuracy and have test units defined but other factors like azimuth angle <br />
or other correction algorithms would be applied in the next stage.''<br />
<br />
====Ninth Week:====<br />
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).<br />
====Tenth Week:====<br />
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).<br />
Other modifications like variable sampling frequency in case if required later by developers.<br />
====Eleventh Week:====<br />
Review all the test units created earlier during program and modify them or build new.<br />
====Final Week:====<br />
Create a REST API sort of thing that enables the reading and logging of results into remote machines and proof check all modules<br />
<br />
==Final Goals:==<br />
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.<br />
<br />
===Future/Additional Goals:===<br />
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.<br />
<br />
Other Goals that can be helped or created by us or other open source contributors<br />
<br />
1. Make A python script type to create the graph and other possible representations of the data processed.<br />
<br />
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.<br />
<br />
==Experience and Approach==<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Contingency==<br />
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.<br />
<br />
==Benefit==<br />
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.<br />
<br />
'''What community members speak -'''<br />
<br />
''Great project for the Aspiring Weather Scientist.''<br />
Michael Welling('''m_w''') <br />
<br />
***'''''Mentors!!! please add your Quote here.'''''***<br />
<br />
==Suggestions==<br />
Nothing For Now...<br />
<br />
Thanks.</div>Thrtransformerrhttps://elinux.org/index.php?title=GSoC2017_sonic_anemometer_proposal&diff=438016GSoC2017 sonic anemometer proposal2017-03-25T06:03:00Z<p>Thrtransformerr: /* Benefit */</p>
<hr />
<div>[[Category: BeagleBoard]]<br />
[[Category: GSoC]]<br />
[[Category: GSoCProposal]]<br />
== Proposal for Sonic Anemometer ==<br />
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.<br />
<br />
''Idea As Quoted from GSoC Ideas page:'' <br />
Working prototype sonic anemometer using BeagleBone, PRUDAQ, and ultrasonic sensors. Analyze methods for accuracy/sensitivity <br />
(eg, time-of-flight vs. phase difference) and implement "best" method. Use PRUs for independent real-time control of ultrasonics.<br />
<br />
''Student:'' Naveen Saini<br />
<br />
''Mentors'': Steve Arnold(nerdboy), Stephanie Lockwood-Childs<br />
<br />
''Code:'' N/A<br />
<br />
''Wiki'': http://elinux.org/GSoC2017_sonic_anemometer_proposal<br />
<br />
''GSoC'': N/A<br />
<br />
==Status==<br />
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.<br />
<br />
==Proposal==<br />
I have completed the task required as described on Ideas page, and created a pull request, as listed [https://github.com/thetransformerr/gsoc-application/tree/master/ExampleEntryJasonKridner here].<br />
===About Me===<br />
''GitHub:'' [https://github.com/thetransformerr @thetransformerr]<br />
<br />
''IRC:'' thetransformerr<br />
<br />
''Linkedin:'' [https://www.linkedin.com/in/5naveensaini/ Naveen Saini]<br />
<br />
''School:'' [http://jecrcuniversity.edu.in JECRC,Jaipur]<br />
<br />
''Country:'' India[The mystical wonderland ;)]<br />
<br />
''Primary language:'' English,Hindi<br />
<br />
''Typical work hours:'' 08AM-10AM , 09PM-01AM Indian Standard Time(+5:30)<br />
<br />
''GSoC participation:'' ''I haven't participated before.''The one of the most important reason is to create a project that I can be proud of and 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.<br />
<br />
''Skills:'' C,Assembly language, Ruby, Python, Node.js<br />
<br />
=== Sonic Anemometer===<br />
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.<br />
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.<br />
<br />
=== Principle of Sonic Anemometer:===<br />
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.<br />
This pair of transducers act alternately as transmitters and receivers, exchanging high-frequency ultrasound pulses between themselves. The times of flight in each direction t<sub>1</sub> and t<sub>2</sub>, 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:<br />
<br />
[[File:Time.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
By combining Eqns (1) and (2) and solving for ` v`, the following equation is obtained:<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
<br />
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. <br />
<br />
[[File:Twodim.png|400px|thumb|left|2D axis(to be aligned with compass to true north)]][[File:Threet.png|400px|thumb|center|3D axis(for reference)]]<br />
<br />
<br />
<br />
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)<br />
Now following Equations are involved here,<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:Angle.png|300px|thumb|center|Angle]]<br />
<br />
<br />
Now from above equations it is clear that speed of sound calculated this way is independent of factors such as temperatures.<br />
<br />
Now with this device we can calculate the wind speed as well as temperature as described below-<br />
[[File:Temp.jpg|300px|thumb|center|Temperature(virtual temperature)]]<br />
<br />
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. <br />
<br />
The sonic temperature, Tv (in Kelvin), may differ from the absolute temperature by an amount equal to the<br />
water vapor content in the air measured. This difference amounts to ±1°C at 20°C and decreases as the temperature decreases.<br />
<br />
===PRUDAQ===<br />
<br />
DAQ are the Data Acquisition devices which are used to acquire data from sensors and acts as a bridge between sensors and host computer.<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
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.<br />
We can probably use second one for '''calibration''' and other tasks.<br />
<br />
===Error Analysis===<br />
Following are the equations defined in thermodynamics for values calculated from the data:<br />
<br />
'''''c<sup>2</sup> =403T(1+0.32e/p)<br />
'''''<br />
where '''c''' is the velocity of sound ('''m s<sup>-1</sup>''') 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,<br />
<br />
'''''Ts [= T(1 + 0.32 e/p)]''''' <br />
<br />
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:<br />
<br />
'''''Tv =T(1+0.38e/p)<br />
'''''<br />
Clearly, '''Ts''' more closely approximates '''T<sub>v</sub>''' than it does '''T''', the error being on the order of '''±0.01°C''' in assuming '''T′ =T<sub>v</sub>′(virtual)''', compared to '''±0.05°C''' for '''T′ =T′(absolute)'''.<br />
Since virtual temperature is used sometimes in boundary layer calculations, we can safely assume sonic temperature as virtual temperature within safe experimental assumptions.<br />
<br />
'''Sampling rate required to measure the time of flight'''<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
for 0.1 meter per second error rate in the wind speed, some conservative estimates about distance and the combined pulse speed can be made<br />
<br />
[[File:Error.png]]<br />
<br />
The change in time of flight for a pulse speed difference, even when that speed is quite high, is on the order of hundreds of nanoseconds. A sample rate of at least 10Mhz will be required.<br />
<br />
===Timeline:===<br />
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<br />
<br />
This program is of 12 Weeks-With Evaluation phase on June 26 - 30, 2017 and July 24 - 28, 2017<br />
<br />
====First Week:====<br />
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.<br />
====Second Week:====<br />
Connect the Prudaq and take sample readings as described on their wiki example.<br />
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<br />
====Third Week:====<br />
Program the PRU to read the sample results from PRUDAQ and trigger successive generation of two axis sonic transducers.<br />
====Fourth Week:====<br />
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.<br />
'''Evaluation Goals 1:'''<br />
''The device is able to stream the results of successive measurements after every specified interval to<br />
the user space and it is stored into text file.Software Testing Units are created for possible errors.''<br />
<br />
====Fifth Week:====<br />
This week we will build the structure as portable, possibly as described in below pictures.<br />
<br />
[[File:Sonic.jpg|300px|thumb|center|PVC for easy and flexible implementation]][[File:Unknown.jpg|300px|thumbnail|center|Made of Copper and steel to heat during Cold]]<br />
<br />
====Sixth Week:====<br />
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.<br />
====Seventh Week:====<br />
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.<br />
====Eighth Week:====<br />
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.<br />
'''Evaluation Goals 2:'''<br />
''Apparatus is tested extensively for outdoors, and is able to perform functional tasks in various possible <br />
conditions and output reliable data with accuracy and have test units defined but other factors like azimuth angle <br />
or other correction algorithms would be applied in the next stage.''<br />
<br />
====Ninth Week:====<br />
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).<br />
====Tenth Week:====<br />
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).<br />
Other modifications like variable sampling frequency in case if required later by developers.<br />
====Eleventh Week:====<br />
Review all the test units created earlier during program and modify them or build new.<br />
====Final Week:====<br />
Create a REST API sort of thing that enables the reading and logging of results into remote machines and proof check all modules<br />
<br />
==Final Goals:==<br />
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.<br />
<br />
===Future/Additional Goals:===<br />
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.<br />
<br />
Other Goals that can be helped or created by us or other open source contributors<br />
<br />
1. Make A python script type to create the graph and other possible representations of the data processed.<br />
<br />
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.<br />
<br />
==Experience and Approach==<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Contingency==<br />
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.<br />
<br />
==Benefit==<br />
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.<br />
<br />
'''What community members speak -'''<br />
<br />
''Great project for the Aspiring Weather Scientist.''<br />
Michael Welling('''m_w''') <br />
<br />
***'''''Mentors!!! please add your Quote here.'''''***<br />
<br />
==Suggestions==<br />
Nothing For Now...<br />
<br />
Thanks.</div>Thrtransformerrhttps://elinux.org/index.php?title=GSoC2017_sonic_anemometer_proposal&diff=438001GSoC2017 sonic anemometer proposal2017-03-25T04:03:54Z<p>Thrtransformerr: /* Benefit */</p>
<hr />
<div>[[Category: BeagleBoard]]<br />
[[Category: GSoC]]<br />
[[Category: GSoCProposal]]<br />
== Proposal for Sonic Anemometer ==<br />
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.<br />
<br />
''Idea As Quoted from GSoC Ideas page:'' <br />
Working prototype sonic anemometer using BeagleBone, PRUDAQ, and ultrasonic sensors. Analyze methods for accuracy/sensitivity <br />
(eg, time-of-flight vs. phase difference) and implement "best" method. Use PRUs for independent real-time control of ultrasonics.<br />
<br />
''Student:'' Naveen Saini<br />
<br />
''Mentors'': Steve Arnold(nerdboy), Stephanie Lockwood-Childs<br />
<br />
''Code:'' N/A<br />
<br />
''Wiki'': http://elinux.org/GSoC2017_sonic_anemometer_proposal<br />
<br />
''GSoC'': N/A<br />
<br />
==Status==<br />
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.<br />
<br />
==Proposal==<br />
I have completed the task required as described on Ideas page, and created a pull request, as listed [https://github.com/thetransformerr/gsoc-application/tree/master/ExampleEntryJasonKridner here].<br />
===About Me===<br />
''GitHub:'' [https://github.com/thetransformerr @thetransformerr]<br />
<br />
''IRC:'' thetransformerr<br />
<br />
''Linkedin:'' [https://www.linkedin.com/in/5naveensaini/ Naveen Saini]<br />
<br />
''School:'' [http://jecrcuniversity.edu.in JECRC,Jaipur]<br />
<br />
''Country:'' India[The mystical wonderland ;)]<br />
<br />
''Primary language:'' English,Hindi<br />
<br />
''Typical work hours:'' 08AM-10AM , 09PM-01AM Indian Standard Time(+5:30)<br />
<br />
''GSoC participation:'' ''I haven't participated before.''The one of the most important reason is to create a project that I can be proud of and 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.<br />
<br />
''Skills:'' C,Assembly language, Ruby, Python, Node.js<br />
<br />
=== Sonic Anemometer===<br />
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.<br />
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.<br />
<br />
=== Principle of Sonic Anemometer:===<br />
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.<br />
This pair of transducers act alternately as transmitters and receivers, exchanging high-frequency ultrasound pulses between themselves. The times of flight in each direction t<sub>1</sub> and t<sub>2</sub>, 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:<br />
<br />
[[File:Time.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
By combining Eqns (1) and (2) and solving for ` v`, the following equation is obtained:<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
<br />
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. <br />
<br />
[[File:Twodim.png|400px|thumb|left|2D axis(to be aligned with compass to true north)]][[File:Threet.png|400px|thumb|center|3D axis(for reference)]]<br />
<br />
<br />
<br />
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)<br />
Now following Equations are involved here,<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:Angle.png|300px|thumb|center|Angle]]<br />
<br />
<br />
Now from above equations it is clear that speed of sound calculated this way is independent of factors such as temperatures.<br />
<br />
Now with this device we can calculate the wind speed as well as temperature as described below-<br />
[[File:Temp.jpg|300px|thumb|center|Temperature(virtual temperature)]]<br />
<br />
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. <br />
<br />
The sonic temperature, Tv (in Kelvin), may differ from the absolute temperature by an amount equal to the<br />
water vapor content in the air measured. This difference amounts to ±1°C at 20°C and decreases as the temperature decreases.<br />
<br />
===PRUDAQ===<br />
<br />
DAQ are the Data Acquisition devices which are used to acquire data from sensors and acts as a bridge between sensors and host computer.<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
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.<br />
We can probably use second one for '''calibration''' and other tasks.<br />
<br />
===Error Analysis===<br />
Following are the equations defined in thermodynamics for values calculated from the data:<br />
<br />
'''''c<sup>2</sup> =403T(1+0.32e/p)<br />
'''''<br />
where '''c''' is the velocity of sound ('''m s<sup>-1</sup>''') 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,<br />
<br />
'''''Ts [= T(1 + 0.32 e/p)]''''' <br />
<br />
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:<br />
<br />
'''''Tv =T(1+0.38e/p)<br />
'''''<br />
Clearly, '''Ts''' more closely approximates '''T<sub>v</sub>''' than it does '''T''', the error being on the order of '''±0.01°C''' in assuming '''T′ =T<sub>v</sub>′(virtual)''', compared to '''±0.05°C''' for '''T′ =T′(absolute)'''.<br />
Since virtual temperature is used sometimes in boundary layer calculations, we can safely assume sonic temperature as virtual temperature within safe experimental assumptions.<br />
<br />
'''Sampling rate required to measure the time of flight'''<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
for 0.1 meter per second error rate in the wind speed, some conservative estimates about distance and the combined pulse speed can be made<br />
<br />
[[File:Error.png]]<br />
<br />
The change in time of flight for a pulse speed difference, even when that speed is quite high, is on the order of hundreds of nanoseconds. A sample rate of at least 10Mhz will be required.<br />
<br />
===Timeline:===<br />
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<br />
<br />
This program is of 12 Weeks-With Evaluation phase on June 26 - 30, 2017 and July 24 - 28, 2017<br />
<br />
====First Week:====<br />
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.<br />
====Second Week:====<br />
Connect the Prudaq and take sample readings as described on their wiki example.<br />
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<br />
====Third Week:====<br />
Program the PRU to read the sample results from PRUDAQ and trigger successive generation of two axis sonic transducers.<br />
====Fourth Week:====<br />
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.<br />
'''Evaluation Goals 1:'''<br />
''The device is able to stream the results of successive measurements after every specified interval to<br />
the user space and it is stored into text file.Software Testing Units are created for possible errors.''<br />
<br />
====Fifth Week:====<br />
This week we will build the structure as portable, possibly as described in below pictures.<br />
<br />
[[File:Sonic.jpg|300px|thumb|center|PVC for easy and flexible implementation]][[File:Unknown.jpg|300px|thumbnail|center|Made of Copper and steel to heat during Cold]]<br />
<br />
====Sixth Week:====<br />
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.<br />
====Seventh Week:====<br />
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.<br />
====Eighth Week:====<br />
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.<br />
'''Evaluation Goals 2:'''<br />
''Apparatus is tested extensively for outdoors, and is able to perform functional tasks in various possible <br />
conditions and output reliable data with accuracy and have test units defined but other factors like azimuth angle <br />
or other correction algorithms would be applied in the next stage.''<br />
<br />
====Ninth Week:====<br />
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).<br />
====Tenth Week:====<br />
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).<br />
Other modifications like variable sampling frequency in case if required later by developers.<br />
====Eleventh Week:====<br />
Review all the test units created earlier during program and modify them or build new.<br />
====Final Week:====<br />
Create a REST API sort of thing that enables the reading and logging of results into remote machines and proof check all modules<br />
<br />
==Final Goals:==<br />
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.<br />
<br />
===Future/Additional Goals:===<br />
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.<br />
<br />
Other Goals that can be helped or created by us or other open source contributors<br />
<br />
1. Make A python script type to create the graph and other possible representations of the data processed.<br />
<br />
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.<br />
<br />
==Experience and Approach==<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Contingency==<br />
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.<br />
<br />
==Benefit==<br />
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.<br />
<br />
'''What community members speak -'''<br />
<br />
''Great project for the Aspiring Weather Scientist.''<br />
Michael Welling('''m_w''') <br />
<br />
<br />
'''''***Mentors!!! please add your Quote here.'''''<br />
<br />
==Suggestions==<br />
Nothing For Now...<br />
<br />
Thanks.</div>Thrtransformerrhttps://elinux.org/index.php?title=GSoC2017_sonic_anemometer_proposal&diff=437996GSoC2017 sonic anemometer proposal2017-03-25T03:44:33Z<p>Thrtransformerr: /* Error Analysis */</p>
<hr />
<div>[[Category: BeagleBoard]]<br />
[[Category: GSoC]]<br />
[[Category: GSoCProposal]]<br />
== Proposal for Sonic Anemometer ==<br />
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.<br />
<br />
''Idea As Quoted from GSoC Ideas page:'' <br />
Working prototype sonic anemometer using BeagleBone, PRUDAQ, and ultrasonic sensors. Analyze methods for accuracy/sensitivity <br />
(eg, time-of-flight vs. phase difference) and implement "best" method. Use PRUs for independent real-time control of ultrasonics.<br />
<br />
''Student:'' Naveen Saini<br />
<br />
''Mentors'': Steve Arnold(nerdboy), Stephanie Lockwood-Childs<br />
<br />
''Code:'' N/A<br />
<br />
''Wiki'': http://elinux.org/GSoC2017_sonic_anemometer_proposal<br />
<br />
''GSoC'': N/A<br />
<br />
==Status==<br />
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.<br />
<br />
==Proposal==<br />
I have completed the task required as described on Ideas page, and created a pull request, as listed [https://github.com/thetransformerr/gsoc-application/tree/master/ExampleEntryJasonKridner here].<br />
===About Me===<br />
''GitHub:'' [https://github.com/thetransformerr @thetransformerr]<br />
<br />
''IRC:'' thetransformerr<br />
<br />
''Linkedin:'' [https://www.linkedin.com/in/5naveensaini/ Naveen Saini]<br />
<br />
''School:'' [http://jecrcuniversity.edu.in JECRC,Jaipur]<br />
<br />
''Country:'' India[The mystical wonderland ;)]<br />
<br />
''Primary language:'' English,Hindi<br />
<br />
''Typical work hours:'' 08AM-10AM , 09PM-01AM Indian Standard Time(+5:30)<br />
<br />
''GSoC participation:'' ''I haven't participated before.''The one of the most important reason is to create a project that I can be proud of and 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.<br />
<br />
''Skills:'' C,Assembly language, Ruby, Python, Node.js<br />
<br />
=== Sonic Anemometer===<br />
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.<br />
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.<br />
<br />
=== Principle of Sonic Anemometer:===<br />
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.<br />
This pair of transducers act alternately as transmitters and receivers, exchanging high-frequency ultrasound pulses between themselves. The times of flight in each direction t<sub>1</sub> and t<sub>2</sub>, 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:<br />
<br />
[[File:Time.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
By combining Eqns (1) and (2) and solving for ` v`, the following equation is obtained:<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
<br />
<br />
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. <br />
<br />
[[File:Twodim.png|400px|thumb|left|2D axis(to be aligned with compass to true north)]][[File:Threet.png|400px|thumb|center|3D axis(for reference)]]<br />
<br />
<br />
<br />
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)<br />
Now following Equations are involved here,<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:Angle.png|300px|thumb|center|Angle]]<br />
<br />
<br />
Now from above equations it is clear that speed of sound calculated this way is independent of factors such as temperatures.<br />
<br />
Now with this device we can calculate the wind speed as well as temperature as described below-<br />
[[File:Temp.jpg|300px|thumb|center|Temperature(virtual temperature)]]<br />
<br />
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. <br />
<br />
The sonic temperature, Tv (in Kelvin), may differ from the absolute temperature by an amount equal to the<br />
water vapor content in the air measured. This difference amounts to ±1°C at 20°C and decreases as the temperature decreases.<br />
<br />
===PRUDAQ===<br />
<br />
DAQ are the Data Acquisition devices which are used to acquire data from sensors and acts as a bridge between sensors and host computer.<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
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.<br />
We can probably use second one for '''calibration''' and other tasks.<br />
<br />
===Error Analysis===<br />
Following are the equations defined in thermodynamics for values calculated from the data:<br />
<br />
'''''c<sup>2</sup> =403T(1+0.32e/p)<br />
'''''<br />
where '''c''' is the velocity of sound ('''m s<sup>-1</sup>''') 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,<br />
<br />
'''''Ts [= T(1 + 0.32 e/p)]''''' <br />
<br />
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:<br />
<br />
'''''Tv =T(1+0.38e/p)<br />
'''''<br />
Clearly, '''Ts''' more closely approximates '''T<sub>v</sub>''' than it does '''T''', the error being on the order of '''±0.01°C''' in assuming '''T′ =T<sub>v</sub>′(virtual)''', compared to '''±0.05°C''' for '''T′ =T′(absolute)'''.<br />
Since virtual temperature is used sometimes in boundary layer calculations, we can safely assume sonic temperature as virtual temperature within safe experimental assumptions.<br />
<br />
'''Sampling rate required to measure the time of flight'''<br />
[[File:Combined.png|300px|thumb|center|u calculation]]<br />
[[File:wind_vel.png|300px|thumb|center|t1 and t2 calculation]]<br />
for 0.1 meter per second error rate in the wind speed, some conservative estimates about distance and the combined pulse speed can be made<br />
<br />
[[File:Error.png]]<br />
<br />
The change in time of flight for a pulse speed difference, even when that speed is quite high, is on the order of hundreds of nanoseconds. A sample rate of at least 10Mhz will be required.<br />
<br />
===Timeline:===<br />
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<br />
<br />
This program is of 12 Weeks-With Evaluation phase on June 26 - 30, 2017 and July 24 - 28, 2017<br />
<br />
====First Week:====<br />
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.<br />
====Second Week:====<br />
Connect the Prudaq and take sample readings as described on their wiki example.<br />
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<br />
====Third Week:====<br />
Program the PRU to read the sample results from PRUDAQ and trigger successive generation of two axis sonic transducers.<br />
====Fourth Week:====<br />
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.<br />
'''Evaluation Goals 1:'''<br />
''The device is able to stream the results of successive measurements after every specified interval to<br />
the user space and it is stored into text file.Software Testing Units are created for possible errors.''<br />
<br />
====Fifth Week:====<br />
This week we will build the structure as portable, possibly as described in below pictures.<br />
<br />
[[File:Sonic.jpg|300px|thumb|center|PVC for easy and flexible implementation]][[File:Unknown.jpg|300px|thumbnail|center|Made of Copper and steel to heat during Cold]]<br />
<br />
====Sixth Week:====<br />
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.<br />
====Seventh Week:====<br />
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.<br />
====Eighth Week:====<br />
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.<br />
'''Evaluation Goals 2:'''<br />
''Apparatus is tested extensively for outdoors, and is able to perform functional tasks in various possible <br />
conditions and output reliable data with accuracy and have test units defined but other factors like azimuth angle <br />
or other correction algorithms would be applied in the next stage.''<br />
<br />
====Ninth Week:====<br />
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).<br />
====Tenth Week:====<br />
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).<br />
Other modifications like variable sampling frequency in case if required later by developers.<br />
====Eleventh Week:====<br />
Review all the test units created earlier during program and modify them or build new.<br />
====Final Week:====<br />
Create a REST API sort of thing that enables the reading and logging of results into remote machines and proof check all modules<br />
<br />
==Final Goals:==<br />
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.<br />
<br />
===Future/Additional Goals:===<br />
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.<br />
<br />
Other Goals that can be helped or created by us or other open source contributors<br />
<br />
1. Make A python script type to create the graph and other possible representations of the data processed.<br />
<br />
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.<br />
<br />
==Experience and Approach==<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Contingency==<br />
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.<br />
<br />
==Benefit==<br />
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.<br />
<br />
'''Quotes from community members'''<br />
''Please add your Quote here.''<br />
<br />
==Suggestions==<br />
Nothing For Now...<br />
<br />
Thanks.</div>Thrtransformerr