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.

Prototype Version 0.5b

As I recover from my accident I have been doing a little work progressing the prototype hardware to the next version. This version incorporates a few user suggestions, improves the look, and is slightly easier for me to make.

A summary of key changes from version 0.4b:

• A new case based on the Dangerous Prototypes Sick of Beige DP5031. This is slightly smaller than a tic-tac box in length and width, but it is a little thicker. The extra $1.50 compared to a box of tic-tacs is worth it, considering that final assembly is easier, it is noticeably smaller, and it looks way cooler. A few people have mentioned that they are concerned that the sides are exposed. I am not. If you are, just put the whole thing in a small ziploc bag or 40mm heatshrink. 
• I have switched from mini USB to micro USB for the charging point. This is the same as pretty much every Android device and it should be easier for most people. The connector is a little more flimsy, but I have been generous with the amount of solder I use to keep it on. 
• I have changed the battery type to a 35x30x6mm 600mAh LiPo. This smaller capacity is a compromise based on what was available (I could not get more of the old one) and what would fix in the new case. The battery life is now around 12 hours, which is still way more than is really needed. 
• The new PCB layout is a little neater. All of the LED's are lined up on the side. The RN42 antenna does not hang over the edge of PCB. Apart from looking cooler, this results in the device being easier to make.
• I have changed a few of the tantalum capacitors to ceramics. This has reduced the electrical noise by about 10%.

I have only made a small run of prototype version 0.5b. There are a few available through the order site. See the image below:

Prototype version 0.6b is in the works. It will be very similar to version 0.5b, but with a few more PCB layout tweaks to make it even easier to manufacture. I intend to release the complete design files for that version under some sort of permissive free licence (including PCB gerbers, schematic, and PIC24F code).

XCSoar Integration

Great news! Thanks to the XCSoar dev team (particularly Tjeerd), the BlueFlyVario is now integrated with XCSoar. For the moment the integration is in the XCSoar testing app available on Google Play here https://play.google.com/store/apps/details?id=org.xcsoar.testing&hl=en. I understand that features in the testing app will migrate to the stable version over time. Because of my injury I have not flown with this yet so my comments are based on testing on the desktop.

The BlueFlyVario pressure data sent via bluetooth is used by XCSoar in a similar manner that would be used to process pressure data from an internal pressure sensor or a serially connected device. The current implementation uses a Kalman filter to smooth the data. (http://git.xcsoar.org/cgit/master/xcsoar.git/tree/src/Device/Driver/BlueFlyVario.cpp). It provides XCSoar with barometric altitude and vario data (see line 90 and 92 of the driver).

A few tips to getting it working:

• Make sure you have paired the BlueFlyVario with your device prior to starting up XCSoar. You should only ever need to do this once (not every time you use it). 
• Ensure that your device's bluetooth radio is turned on prior to starting XCSoar. 
• Ensure that the BlueFlyVario is turned on prior to starting XCSoar. 
• Click Menu|Config|Config 2/3|Devices (You can also do the same thing through Menu|Config|Config 2/3|System|Setup|Devices - this is what the screenshot below is from). Select a disabled device and click Edit (probably "B: Disabled" if the only other device you have connected is the internal GPS). Set the "Port" to the particular BlueFlyVario device (you will only see the BlueFlyVario device here if the bluetooth radio is turned on). Set the Driver to "BlueFly Vario". At this point you might need to close and restart, perhaps reboot the device, maybe use the reconnect feature. It was a bit fiddly for me the first time around. For me now, the BlueFlyVario connection to XCSoar seems pretty robust and happens automatically. 
• You might like to switch a few of the info boxes around. The Vario Trace one is handy to get good feedback from testing. Don't forget that to get the Barometric Altitude working you need to set QNH.
• You might like to turn on the Audio Vario gauge.
• You might like to change the "Look" by setting the InfoBox geometry to one that includes the  word Vario in it. 

An example of what the setup should look like.

How you could configure the screen to included extra data from the BlueFlyVario.

A todo in the XCSoar code is to do something with the BlueFlyVario battery status that is sent every ten seconds. I am not sure if that will end up being used. 

This does not mean I am going to give up on developing my BlueFlyVario android app. There are many things I still want to do with my app that I could not do easily in XCSoar. Additionally, my understanding of C magic is quite poor. I will stick with developing my stuff for Android in Java.