You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to BeagleBoard GSoC
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.