Blue BlueFlyVarios

Blue Boards

A few weeks ago I got a big batch of blue PCB's. The first few version 6 prototypes were green, but I have been shipping blue ones for a few weeks now and will continue to do so. This is not really a huge deal. There is absolutely no difference in terms of function, but it does look just a little cooler.

Version 6 Prototype Update

The version 6 prototypes are pretty popular. I am shipping about five a week since I announced it just over a month ago. I have enough stock of all major components to continue at this rate for a few months. Although, it will be at least a few days until I get more prototype cases (I have been out of stock for a week). This is the third time I have underestimated the demand and have been caught a little short. 

I predicted that many people would just want to use the version 6 BlueFlyVario in audio mode. This is indeed the case. Some friends have just put the board in its heatshrink in the lining of their helmet. Below is a picture of a batch of the prototypes made up and ready to ship as soon as the prototype cases arrive. 

Blue Cases

Continuing my blue theme, I have ordered a batch of custom translucent blue prototype cases. These will take at least a month or so to arrive. In the mean time I will continue shipping with the transparent case.

Some answers

Over the last few months I have responded to many emails, forum posts and some blog comments about the BlueFlyVario. Much of this discussion has similar themes. In this post I hope to address some issues so I can point future queries towards this page. This is kind of like a FAQ.

"It would be great to see the BlueFlyVario with a wired connection to my device"

I have spent way too many hours thinking how the BlueFlyVario could connect in a wired way. There are very many options such as;

• a 3.3V serial (UART) connection via the micro USB pin
• add a chip like the FT232RL that provides a USB device that acts as a virtual COM port.
• change the PIC microprocessor to one that supports USB OTG 
• output the data using some kind of analog encoding for input via a device microphone port. 

All of these options have issues. The main problem that I have faced is that each of these solutions would be specific to a small range of devices. Choosing Bluetooth SPP means that pretty much every device with bluetooth (except iOS stuff) can be interfaced with the BlueFlyVario. Perhaps I am influenced by the fact that every device I own or have access to that I might want to use as a flight instrument can interface to via bluetooth; however, among the six android devices (four phones, two tablets) I would struggle to create one type of wired connection that would be successful with all of them. 

"I have a pressure sensor built into my Android device. I would like to use your software with it"

I have not implemented this in the BlueFlyVario Android software as it is pretty device/Android version specific. The BlueFlyVario Android software is open and you are free to modify it to meet your needs. 

Additionally, I am not aware of an Android device with a high resolution pressure sensor. Some pilots have been happy with a vario based on BMP085 based sensor (30cm resolution at less than 50Hz), which is the kind of sensor built into those phones that have one, but most pilots feel it is a step back from their current vario. If Android devices get high resolution sensors (10cm at 50Hz), and this information can be accessed from the OS, then there will be no need for the BlueFlyVario. 

"I would like to see other sensors on board the BlueFlyVario, like GPS or multiple pressure sensors "

I have focused on just a pressure sensor because it is the key thing missing to turn an Android device into a vario. 

The GPS on Android devices is good enough for 95% of pilots. My software uses it for windspeed calculations. 

Some pilots, particularly glider pilots, want multiple pressure sensors arranged in such a way that pitot and static pressures can be measured. This would allow for better wind speed calculations and provide the ability for total energy compensated vario measurements. 

The Experimenters Version of the BlueFlyVario will allow those with serious tinkering skill to incorporate other sensors. I will be working on releasing that over the next few months. 

"The BlueFlyVario should cost less"

I agree. The component costs for me at batch volumes of around 50 represent about half of the device cost. The remaining 50% comes from consumables used in production, apportioned overheads used in keeping my little workshop going, packing and shipping costs, and paypal fees. At this stage it would really only be possible to get the costs down if production increased to volumes of many hundreds. I am not trying to profit from this hobby.

"Can you get the BlueFlyVario to work with other software?"

Yes. It is already integrated into XCSoar. Work is underway to integrate it in XCTrack. If you are a software developer and can access a Bluetooth SPP stream then I encourage you to look at the Android BlueFlyVario app software on GitHub for some inspiration. If you need a BlueFlyVario device for testing contact me and I will help you out. 

"How does the BlueFlyVario perform compared to other varios?" 

Performance is a complex question. To address some of the issues that affect responsiveness, accuracy, precision and latency I will summarize what I have experienced in BlueFlyVario development. My aim has been to get the best performance possible out of the best sensor available. 

Performance starts with the sensor. I am using the MS5611 for the reasons I describe here. Essentially, there is a relationship between the number of readings possible per second, and the RMS error in each reading. The MS5611 can theoretically provide an RMS error of around 10cm (in pressure altitude terms) at a rate of 50 samples per second (at an oversampling rate of 4096). In practice, to get this good, requires very careful circuit design to filter the power supply. I have been able to get to an RMS error of 12cm at a rate of 50 samples per second. 

Next, we need a filter on the sequence of noisy pressure measurements to turn it in to a precise estimate of the rate of change of altitude. There are many approaches to this. I started with a linear regression and IIR filter. I have tested many approaches, including an AB filter, but in the end I have settled on a Kalman filter for its performance and theoretical underpinnings. I have found that the filter choice does not matter anywhere near as much as the sensor selection and power supply design. 

The time between the filtered lift rate being above the threshold and the commencement of the beep matters quite a bit. This depends on the way code is designed on the vario and supporting software. For my new hardware audio, it is less than 5ms until the beep commences. Transmission of the pressure data over bluetooth adds around 150ms. Based on feedback from other pilots it sounds like this delay does not matter much. 

The type of audio also matters, perhaps subconsciously based on what most pilots are used to. Variable frequency and cadence based on lift rate is anecdotally important. 

The most important thing from the above list is pressure sensor selection and the power filtering on the pressure sensor supply. I have managed to get the BlueFlyVario to the point where I can lift it from chest to head height and get ultra responsive beeping. I know most pilots don't need a vario that is this sensitive, but it is a kind of addictive obsession to pursue performance. 

Most pilots who have used it say the BlueFlyVario is as good as the best varios on the market. 

Purchase page back online

The cases have arrived. That means I now continue to have a small handful of the new prototype version 6 'in stock'.

I have updated the online purchase website to buy one with PayPal

http://www.alistairdickie.com/blueflyvario/index.php/buy.

Hardware prototype version 6 ready

After a few months of messing about with the hardware design I have settled on the final design for prototype version 6. There are a few new features, the look is more polished, and the usability has been improved.

The image above shows the final assembled prototype (on the right). I plan to ship the prototypes in a package that includes the circuit board in heat shrink (as shown on the left) and the case in component form. For version six the final assembly will be left to you. This saves me time, the postage cost is less to many destinations, and it will fill in five minutes on a quiet evening. This video shows the process for final assembly and testing.

Upgrades from earlier versions

There are a lot of little tweaks. Here are the highlights:

• Integrated Hardware Audio. I spoke about this in an earlier blog post. I pretty much did what I said in that post. When I started the BlueFlyVario journey I was initially resistant to do anything on the device except send pressure data to a phone. However, after tinkering with the hardware audio I realised it was a feature that everyone had to have. Integrated audio makes the vario much more versatile, for the addition of only about $3 of additional components. At some point I might write a blog post that describes all of the audio settings that you can adjust on the hardware via the connected app. 
• Heatshrink. The effect of a small piece of 43mm clear PVC heatshink makes the device feel much more robust. The heatshrink protects the components and helps hold the battery in place. The device is about 11mm thick in the heatshrink. I suspect that some users will just leave the BlueFlyVario like this, and will not bother putting it in the perspex prototype case. Especially if they are going to put it under the padding in their helmet. The PCB mounting holes can be used as tie down points. 
• Pressure Sensor cover. The pressure sensor is really sensitive to sunlight. This meant that users of earlier versions had to hide the device away in flightdecks and pockets. A small piece of 3mm neoprene allows air pressure through but blocks sunlight completely. This is very effective and even dampens wind noise a little. I left the white cover on the neoprene to make it easier to put the heat shrink over it. Beware that pressing on the neoprene does affect the pressure so you should mount the device in a spot where it is not going to be pushed in and out often. 
• New PCB layout. The PCB layout needed to be pushed around to incorporate the audio circuitry. Also all LED's, resistors and capacitors were changed to 0603 size, and some values were altered to optimise the design. The circuit schematic and PCB layout below shows the new design. Despite R8 being listed as a 10 ohm resistor, I am actually using a 0 ohm resistor in the final design. It makes the audio louder and does not increase current consumption much. 

So now I am planning to start churning these out at cost for collaborative hardware developers. I have made a small batch and have the parts for the next batch on order. I have put the plans for prototype version 6a (the experimenters version) on hold until I see what the initial interest is like. 

Android App Updated (version 0.6b)

I have just completed a major update of the Android app. It should be in the play store in the next 24 hours. This has been prompted by the next version of the prototype hardware, which has been shipped to a few people and will be ready for general release in the coming weeks. The key updates to the Android app are:

Kalman Filtered Pressure Stream. The hardware device sends raw pressure measurements 50 times a second. I was previously getting altitude and vario information from a complex set of IIR filtering and linear regression. That has now all changed. A kalman filter is used to keep a running estimate of position (altitude) and velocity (vario). There is only one parameter to set, the position noise (there are some other paramters that are hard coded, but these will not affect users). This turns the steam of pressure data into a stream of Alt and Vario 1 data based on the position noise parameter. The Alt and Vario 2 data is further damped using IIR filters. This makes a much simpler mix of settings and is much more computationally efficient.

Audio. The audio in the Android app was updated to make it more computationally efficient and responsive. I got rid of the "sink, sink" sound and replace it with a more familiar tone. I have also changed the default lift base frequency to 1000Hz. This is much louder on most phones speakers. The new bunch of settings should be fairly self explanatory if you read the description in the menu. Just make sure the cutoff for lift is less than or equal to the threshold, and the cutoff for sink is greater than or equal to the threshold.

Hardware Settings. In the settings menu is a sub menu that allows you to set the settings on a connected hardware device. From hardware prototype version 6 you should get a dialog similar to the one shown below. Earlier hardware versions can not access this menu. The audio settings are similar to the settings in the Android app, but are completely independent. Audio on the hardware can be enabled either when the hardware is connected to an Android device, or not, or both, or neither. The secondsBluetoohWait parameter controls how long the hardware will be available for a bluetooth connection when first turned on. The rateMultipler parameter controls how fast the lift beeps beep. 0.5 is twice as fast as 1.0. The volume parameter is a rudimentary way to set the hardware audio volume. 1.000 is default, 0.100 is about half, 0.010 is pretty quiet.

I suspect that some users of the new BlueFlyVario will only ever use the Android App to affect the hardware settings on the device.

Flight Altitude. This is a new field that shows the difference between the alt at the start of the flight, and the current alt.

In addition there are many more bug fixes, and I suspect a few new bugs. Contact me if something does not seem to work as you expect.

Hardware Audio Integration

The last few weeks have been dominated by continuing recovery from my accident at the end of last year. While that has been going on I have sent out the last few version 5 prototypes, and have been tinkering with the initial version 6a prototypes to finalise the hardware and firmware design for version 6. The most important outcome of this is my new plan to add hardware audio from version 6. The good news is that the vario will beep when not connected via Bluetooth (providing you are going up). The less good news is that all of this will delay the release of version six to some time in May.

So, how will it work. Essentially, when you turn on the vario it will start in hardware audio mode. If you go up above the lift threshold it will start beeping, if you go down below the sink threshold it will sound the sink alarm. Like other advanced varios, the audio frequency changes dependent on the lift/sink rate. For example, for the lift settings, by default the audio frequency is 700 Hz at 0.0 m/s, then increases by 10 Hz for each 0.1 m/s. The cadence also decreases from 0.5s to about 0.25s as lift increases from 0.0 m/s to 3.0 m/s. When (if) the Bluetooth connection is made the hardware audio turns off and the connected device provides the audio. If no Bluetooth connection is made within about 5 minutes then the Bluetooth is turned off to save power.

Like most of what I do, I want the audio settings, and things like the Bluetooth scan period, to be configurable. I will do this by adding a few features to the Android app that sets features on the BlueFlyVario hardware audio mode.

I spent quite some time testing a range of buzzers. I started with piezo buzzers like everyone else. I 'drove' a few using the PWM (Output Compare) from the PIC. To do this I have had to alter my planned 6a layout to swap a few pins around. The main problem with piezo buzzers in my design is twofold. First, piezo buzzers are generally driven by a higher voltage than 3V in order for them to be loud. Adding a charge pump circuit is quite a big change that I am not going to make. Second, the resonant frequency is around 4000 Hz. They are not so loud at 700 Hz.

For those reasons I chose to consider electromagnetic buzzers. They have the advantage of being smaller, having good SMD options, having better frequency response in the range I am interested in, and able to be run at 3V effectively. The main disadvantage is the need for additional components including a switching transistor and a back EMF protection diode. Overall the additional component cost is less than $2. The buzzer I am probably going to use is listed here http://au.element14.com/jsp/search/productdetail.jsp?SKU=2135919. The one I have in the test bed at home appears as loud or louder than other audio only varios. See the picture below where I have hacked in a 8mm x 8 mm buzzer. I will need to tweak the PCB layout to make it all fit...

Power consumption changes a bit. I intend to ensure there is sufficient resistance in place for the buzzer so that power consumption is less than when connected via bluetooth, without negatively effecting the loudness. This should mean that battery life will still be well over 12 hours.

As part of this tinkering I have conducted a few tests of the latency associated with the transmission of data from the BlueFlyVario and time taken by Android to respond by beeping. My test setup, with a custom app and a test firmware on the vario, essentially beeped on the hardware, then sent a signal to the Android device saying beep as soon as you can. I recorded the output in Audacity to roughly measure the delay. It varied a little depending on the code order on both devices, but by far the biggest delay is the responsiveness of the audio subsystem on the Android device. I am using older Andriod code which adds over 100 ms of latency. Newer Andriod versions (4.1) and devices are targeting 10ms or less of latency. (http://createdigitalmusic.com/2012/07/android-high-performance-audio-in-4-1-and-what-it-means-plus-libpd-goodness-today/) But for the moment for most devices the total latency averages to 150ms, which is noticeable but probably not really significant for most pilots. However, it will be for some. This means that I think that some pilots will prefer the audio to be from the hardware rather than the Android device, even when connected via Bluetooth. More custom settings...

Oh, and finally, to support the hardware audio, I have implemented a Kalman filter on the PIC micro-controller  This is going to be in the Android app as well to replace the relatively clumsy linear regression + IIR filter. 

Experimenters Version

I am toying with an experimenters version of the BlueFlyVario. I got a batch of circuit boards made, but have only populated one for my own use. The idea is to expose all of the spare micro-controller pins so daughter boards can be designed to provide additionally functionality. Additionally, the In Circuit Serial Programming (ICSP) pins have been exposed to allow easy reprogramming of the micro-controller using a PICKIT 2 or equivalent programmer. A picture of the board design is shown below. The pins are exposed in a 0.1" series of through holes to allow standard headers. It is possible to still put the board in the DP5031 case I used for prototype version 5 (and intend to use in version 6).

Up until now I have used software SPI (bit banging) for the interface between the PIC24F16KA101 and the MS5611 pressure sensor. In this experimenters version I have moved the interface to the hardware SPI pins on the micro-controller. This has meant a pretty significant change to the firmware. It also means that adding additional devices to the SPI bus becomes less of a hassle.

The exposed pins will allow additional (spare) PIC24F hardware features to be used; including an AD channel, UART, I2C, and general IO pins. I will be using the experimenters version to get the code right for prototype version 6 (which is just the same as version 5 to look at, but will be easier to make and is electronically much more similar to this experimenters version). I have lots of ideas for daughter boards and altered firmware. These are all independent ideas, I am not thinking of doing them all in the one device!:

• Two additional pressure sensors configured in such a way that allows connection of pitot and static tubes.
• An LCD screen display (I have pretty much got a Nokia 84 x 48 LCD screen working already on a breadboard)
• A small ePaper display (something like this  http://www.seeedstudio.com/depot/eink-display-shield-p-1374.html?cPath=132_134; or without the arduino integration overhead http://www.aliexpress.com/store/product/E-ink-e-paper/600281_563811171.html)
• Integrating two high resolution 1D accelerometers. These would be physically connected to each riser. The idea is to see if I can measure the 'feeling' of wing feedback we get to improve the flight instrument. 
• Integrating an ISM RF transceiver to transmit the vario data over ranges up to a few km. 
• Integrating a GPS receiver to get better data than what a phone spits out.
• Integrating a speaker to develop the code for audio output.

I still expect that the standard version 6 hardware will be what most people will want. I am intending to get quite a few of them made. The experimenters version 6a will be available in much more limited quantities for those that fell they have the electronic design skills to make use of it. My aim is to release both by the end of April with firmware code and updated schematics.