The first batch of prototypes for beta testers is almost ready to ship. The pretty picture below shows how I turned all of those circuit boards and components to working, programmed, and tested prototype BlueFlyVarios. The only components missing from this picture are the case (which is a small TicTac box) and the battery. Unfortunately, my shipment of batteries from China went missing. A replacement shipment is supposedly on the way. Perhaps they will be here when I get back from vacation in a few weeks. If they are here, I expect to start shipping these prototypes around 11 Oct.
Prototype Assembly
With a bit of practice I reckon I could assemble, program and test a batch of ten of these prototypes in about two hours in my home setup. This batch probably took me three times as long as that, on average about 35 minutes for each one. It is a bit finicky to get the right amount of solder paste around the SSOP pins of the PIC micro and for most of the prototypes there was a bit of touch up work. Programming the micro and configuring the settings on the RN-42 also takes a bit of work.
Cost
The cost of these prototypes works out to A$60 (plus shipping), which is how much the components cost me and a little more to cover consumables. Shipping will be A$10 within Australia or A$15 internationally (if you want tracked postage this will cost more). As I write this blog there are still a few of the prototypes that have not been promised to beta testers. If you want one contact me via http://www.alistairdickie.com/home/index.php?option=com_contact&task=view&contact_id=1&Itemid=29
How to use the hardware
If you get one of these prototypes some important stuff you need to know:
Turn it on and you should see the blue light flashing. Pair it with your Android device using the code 1234. Open the BlueFlyVario app and press Menu|Connect device.
Ignore the flashing green light, it is left over from some hardware debugging.
A full battery lasts 17 hours. Plug in a mini-USB connector to charge it. The red light goes on. When it goes off the BlueFlyVario battery is fully charged.
The USB connector does nothing other than charge the battery. The data pins are not connected to anything.
Next Steps
Once these prototypes are in the wild I will consider if I go down the path of making more of the same or redesigning the board and getting a different case.
Most of my last month or so of BlueFlyVario development has been focused on getting the Android app to be usable and customisable. The BlueFlyVario android app is ready for technologically courageous testers to have a play with. You can install it as a non-market app from http://alistairdickie.com/blueflyvario/. [EDIT - Get it from Google Play now]. There are a few features left in from testing...
App Design
I have tried hard to design an app that allows for significant user customisation in the front end, and in the back end code allows developers to add new features. I would like to think that the app as you see it today is just the beginning.
Screenshots
The screenshots below shows what the current default layout looks like.
The first page shows some basic information and displays three of the component types. The icons in the top right change color based on the status. From right to left; BFV hardware connection, GPS location upated, vario audio, and flight started. All blue is all good.
The component in the top right is the 'location' component. There are heaps of settings for it. It essentially shows a trace of your track over the last 120 seconds. The color of the track is the same as the color of the vario trace. Green bits of the track are where lift was.
The 'vario trace' component shows the sensitive vario on the left and a trace of the averaged vario trailing out to the right. The grey underneath is the alititude over the same period.
Swipe the screen right to left to fling to the next page.
This page shows all fields currently available. A few of them were on the previous page. Like all other components these fields can be customised in position, size and colors for text, labels and lines. Additionally most fields can have different units and number of decimal places (in fact, full DecimalFormat pattern support).
Also at the top of the page is a 'label' component.
On the next page you can see another example of the location component. Pages can be added or removed, and you can add any components you want to any page, make them any size, background color, etc. Here we see the location component with the 'lineColor' set to be transparent. Tap in the middle of the component for its settings. If you are not sure where to tap there is a preference that can show you where the tap point are. This location component has 'rotate' set to false which means it always has North up.
On this last page you see a location component again and some fields, but also the wind trace component. I really developed this for testing the algorithm I outlined in the last post. The data you see drawn above is from a development feature that simulates a flight track. You need to run it for at least three minutes to see the data picture above. Note that the location track points are 'drifted' based on the wind speed and direction that was associated with that point. Combined with vario data, and selectively only showing those points on the location trace that are in lift, this essentially maps out pockets of lift in the sky.
What you don't see
There are many features you don't see in the screenshots above:
The very many preferences for making the app do what you want.
How you can press and drag on components to move them around or resize them.
The way you can customise almost everything about what you see, then export and share layouts with others.
The flight functionality, which is only simple at this stage, but works. A flight is recorded as a simple csv file in the Android/com.bfv/files directory.
Further App Development
I have hundreds of ideas. Here are a few:
More component types (a map component is next I think).
Comp features like waypoints, tasks, etc.
IGC and KML flight saving.
Live tracking options.
Auto flight start (I meant to put this in, I just realized I forgot)
Airspace
Flight events which automatically switch screens
Fix bugs...
Next Steps
As soon as the app is in the hands of testers (with some hardware) I hope to get it working on GitHub and use that for bug tracking and development discussion.
Coding the android app is progressing well and I have most hardware parts for the first ten prototypes. In coding the Android app I got a little fixated on developing an algorithm for estimating wind speed and direction from the gps location flight path. I think what I have done is new. [EDIT: See the comments below from Edgar, I guess what I did was not new]. If it is not new, then as far as I can tell from pretty extensive Google and literature searches, it is undocumented in the public arena. This post gets pretty technical, so first..
The bottom line
Using information from only the GPS, this algorithm provides a pretty good estimate of windspeed, wind direction, and airspeed. The algorithm does not rely on turning circles or airspeed measurements. It does assume that the aircraft is flying at a reasonably constant airspeed over a time period, or at least that the airspeed is not overlay biased towards any heading. It also assumes that the wind speed is pretty constant over the same time period. It does rely on some changes in heading over the time period. If the aircraft heading is distributed over a 60 to 90 degree arc then the windspeed, direction and airspeed will be calculated pretty accurately. By pretty well, I mean less than about 20% error, which is kind of like the variation of windspeed and wind direction caused by gusts in any case.
For a typical paraglider boating around in thermal or on a ridge the assumptions above hold true. Even with a little speed bar our airspeed range is reasonably confined, and most people do not use it while thermalling. A time period of 90 seconds works well from my testing so far. I think that this algorithm would work less well for hang glider and sailplane pilots as they vary airspeed much more often. It will be interesting to get some practical feedback.
My main motivation for working out the windspeed and wind direction is to ensure I can predict where a packet of lift that you have just flown through will have moved to later in time. That magic is for a later post. Now the technical stuff.
What the GPS gives us
Most GPS spit out position information every second. In addition to position we get heading and ground speed. The GPS is not merely taking two location points and calculating the vector between them. Rather, it measures the Doppler shift in the signal from each satellite and converts that to a heading and speed. This is quite nifty and I imagine particularly more accurate than just taking the difference between two points.
The wind triangle
The picture below tells a thousand words. On the left is a 2D flight path in pink. I have marked three points on the path (p1, p2 and p3). The green arrows represent the ground speed and heading vectors at each point. You can also see the blue arrow representing the windspeed and wind direction. Notice that groundspeed at point p2 and p3 is much greater (longer arrow) when the wind is from the side at point p1. On the right side are these three groundspeed vectors plotted on the XY velocity plane, and the windspeed plotted. Note that each of the red airspeed vectors have the same magnitude |a| (our assumption of constant airspeed), and the the windspeed vector is assumed to be the same at each point. The greyed out triangle is the 'wind triangle' for a particular point in time. The most important thing in this picture is the circle. For any three points drawn on a plane (not on a straight line), there is only one circle that fits them all. To work that circle out we only need our three groundspeeds. The centre of the circle gives us the windspeed vector, and its radius is the airspeed.
Practical data
In theory, with just three gps heading and speed readings, provided we were not travelling in a straight line, we could determine windspeed and direction. In practice there are all kinds of errors, our assumptions do not hold exactly, and so on. But with more data we can find the circle that best fits our points. The image below is a graph of all speed and headings from a ~35 min scratchy paragliding flight on a ridge. The units are in m/s. When I first saw this I was amazed at how consistent both my airspeed and the windspeed was over the 30 minutes. In flight I experienced the range of gusts and direction changes that we are used to when flying a ridge. Yet, it is still easy to see where the circle fits if you were to draw it by hand.
Below is 90 seconds of data from the middle of the flight. This time I have hand drawn a circle on it. The errors of the points are much less.
Circular Regression
To fit a circle to a bunch of points requires the use of advanced math. It is called circular regression. Nikolai Chernov from the University of Alabama had an excellent summary of his work presented here. He has provided a bunch of algorithms. I chose the Taubin-based Newton method for a number of reasons: Speed (it runs fast enough on Android), I am not worried about numerical stability for the kind of data we will get, it does not need matrix functions, and it is characterised as 'perhaps the best algebraic fit'. The Kasa fit worked well enough but the Taubin was much better at small arcs. In addition to the 'fit' produced I then calculate the mean squared error of the predicted centre and radius of the circle. Some of the methods in JBone code provided inspiration. I will share the actual Java code from the Android app with the initial release in a few weeks time.
Below is an animation of successive circle fits over time. The red dot is the origin. The fits start at 90s. The center pink dot size represents the mean squared error of the circle location. The two circles represent the mean squared error associated with radius.
The graph below is the calculated windspeed and direction over time associated with the above flight. It matches what I experienced.
I have added a simple IIR filter on the windspeed (the yellow line). This smooths out second to second fluctuations and is what will be implemented in code.
Further work
This can be better. The circular regression algorithm tries to minimize the sum of the square errors from all of the points. If it could be altered to weight the points over time, with the most recent having the highest weight, then it might be possible to get a more time sensitive fit. In addition, the current algorithm calculates a full fit with each new point. It might be possible to alter it to reduce the computational intensity by saving some of the computed data for older points, and by using the previous fit as a starting point for the next fit.
