Anemometer Final Report

[vis...@gmail.com]

Original Intentions:
Initially the project focused on creating an anemometer using time of flight of ultrasonic pulses with the use of a THS1206 ADC. This included gathering and utilizing other information such as temperature, humidity, and pressure in order to calculate the expected speed of sound. The difference between expected and actual time of flight would be used to find the wind speed.

Findings and Changes:
The THS1206 probably isn't the best fit for the Beaglebone. Some of the design decisions for the ADC don't mesh so well with the design of the Beaglebone. Specifically, the THS1206 uses I/O lines to both accept configuration commands as well as produce output. It uses a short sequence of inputs on dedicated input lines in order to control the I/O direction. Several of the lines used in this sequence don't fit into the available pins without splitting control or data lines across both PRUs, but fortunately can be tied to an active state. Timing requirements dictate PRUs are used to communicate with the THS1206, but the PRUs do not have control of the Beaglebone pinmux. This dictates that there must be some additional synchronization between the PRUs and ARM in order to control the pinmux. The ARM also must alter the pinmux while running the program, which doesn't seem to be precisely the intended mode of operation although it is certainly possible. It also seems like it can't be effectively powered from the Beaglebone, and requires a separate 3.3V and 5V power source.

Recently, PRUDAQ was announced. It offers a high speed ADC on a cape, with firmware and software support. This is clearly the best way forward for this project.

Completed Work:

• THS1206 Firmware and Userspace Driver [1][2]
• All three processors are involved in controlling the THS1206.
• PRU0 is used for generating the clock, with some synchronization with PRU1 to account for variable transfer times (and also controls transmitters)
• The PRUs can't store enough data for all readings from transmission to pulse detection (and actually don't know when the pulse is detected anyway) so it delays for some time before running the clock (even this basic method allows for wind speeds of up to about 70 m/s, at which point you have bigger problems than your anemometer not catching the pulse)
• PRU1 is used to configure the ADC, read and store ADC output, signal PRU0 when it is ready to accept more data, signal the ARM to make pinmux changes, and transfer stored output to the ARM using RPMsg
• The userspace driver works with PRU1 to control the pinmux and accepts ADC output transfers

• Convert ADC output to time of flight [2][3]
• There is some very basic code for this (grabs the max value). It is untested, but pulse detection does seem to be done as simply as this
• Calculate speed of sound from sensor readings [4]
• Estimates the speed of sound using temperature, humidity, and pressure
• Sensors report relative humidity while the speed of sound depends on absolute humidity, so pressure and temperature are also used to estimate absolute humidity from temperature, pressure, and relative humidity
• With a time of flight and distance, and above estimation, can calculate the wind speed
• PRUDAQ
• Modified PRU0 (acting as a clock) firmware to control transmitters as well [5]
• Also uses a delay system similar to that for the THS1206 to reduce processing load
• Hooked their userspace data capture into my time of flight and wind speed processing [6]

Unfinished Work:

• So far it actually only works in a single axis. The modifications required to account for both axes is pretty minor though. The firmware controlling the transmitters just needs to cycle between two pins. The time of flight processing can store one result and ship pairs off instead of one value at a time. A touch of trig can be used to combine the two vectors.
• The magnetometer never got added. It's only relevant with both axes, and again is pretty trivial. There is code for it out and about and would only be used to orient the combined wind vector.
• The big thing is testing. Unfortunately I managed to burn out my THS1206. I'm still not sure what the issue was, but the best guess seems to be some pin contention. However the ADC pins don't seem to come up driven, so it's a bit of mystery still. I didn't dig into this too much because of PRUDAQ. My PRUDAQ cape is due to arrive sometime in the next few hours... which is about the time this all wraps up.

Future Work:

• The unfinished stuff, obviously. Testing in particular.
• More frequent wind speed updates. The time of flight results come in way faster than things like temperature and humidity. Right now I just do one batch of everything but there's no need to wait so long.
• Get the PRUDAQ device tree overlay working. I wasn't able to get it to actually control the pinmux so I fell back to a universal overlay and config-pin.
• Look at using the BeagleLogic drivers for PRUDAQ. If it works out it could mean a significant boost to the sample rate. Depending on the accuracy of the other sensors this could be significant.
• With PRUDAQ things are somewhat more configurable than I originally intended for the THS1206. Many things are still hardcoded for that, when they could be grabbed from the PRUDAQ configuration. This spans between programs though, so it would require (more) IPC.
•  Maybe some people would like a lower sample rate to reduce processor strain if they are doing other things on the board as well, etc.
• Some basic QoL stuff like adding a zeroing method. Automatically detect distance assuming no wind.
• Look doing things in a more relative way (take a zero time of flight and record environmentals, and then calculate expected relative differences given environmentals for a measurement). May not be better than just adding a zero.
• Add absolute humidity estimations below 0C. That's what the basic THS1206 was rated down to anyway, and such estimations were somewhat harder to come by.
• Add better ways to get the wind speed. Right now it's just a print out. Figure out how people actually want to get weather data.
• Clean things up a bit. PRUDAQ organization is a bit different from what I had, and for ease and speed I didn't put the effort into moving things around and making it match up.

Lessons Learned:
I didn't have the smoothest... studentship(?) ever, as some of you know. There were a number of lessons I learned the hard way (or perhaps am still learning, to some degree). The first major one is that I should take advantage of the resources available to me. I'm reluctant to bother people (particularly experts) with basic questions. Normally this isn't such a problem and to some degree is perhaps even a good thing, but in project with such time constraints and an ecosystem that has so much churn, I really ought to take advantage of the experts that signed up to field even the stupid questions. I spent far too much time digging around trying to find answers on my own that a mentor could have answered in no time. I also took the weekly self-assigned tasks too seriously. Every week I put down what looked at the time like a reasonably small amount of things to do and just about every week multiple things took way more time than I expected - often due to or at least exacerbated by my reluctance to ask about basic things. Although I don't know that anybody else expected me to get all of those tasks done each week, I sure did. It was rather discouraging and turned into a problem of it's own. A few weeks ago I ended up going dark just to get out from under it. It sort of worked, but also meant I was MIA and out of contact with the mentors during some of the most critical times of the project. So I guess overall... ask stupid questions of people that volunteered to field them, don't be too hard on yourself, and talk to people.


Links:
Project: https://github.com/Visaoni/beagle-sonic-anemometer
Proposal: https://docs.google.com/document/d/1MEx5eXVJNEdANsgICRpYv12qtIIKDZ-8NK3cDtr5EL4/pub

[1] https://github.com/Visaoni/beagle-sonic-anemometer/tree/ths1206/src/firmware/ths1206
[2] https://github.com/Visaoni/beagle-sonic-anemometer/blob/ths1206/src/software/adc-controller/main.c
[3] https://github.com/Visaoni/beagle-sonic-anemometer/blob/prudaq/src/firmware/prudaq/tof_analysis.c
[4] https://github.com/Visaoni/beagle-sonic-anemometer/blob/master/src/software/sensor-fusion/fusion.py
[5] https://github.com/Visaoni/beagle-sonic-anemometer/blob/prudaq/src/firmware/prudaq/pru0.p
[6] https://github.com/Visaoni/beagle-sonic-anemometer/blob/prudaq/src/firmware/prudaq/tof_analysis.c