Saturday, 5 April 2014

BlueFlyVario_TTL version 8 released

I have spent many months working on the BlueFlyVario_TTL. This post announces a limited release. Anyone can purchase one, but it is ‘limited’ because you will need some electronics skill to make it work the way you want. I will release another version of this in the next few months with extra components, but I am still not sure what is the best configuration.

I made a deliberate decision to produce a simpler version of the BlueFlyVario, rather than pursue the standard approach taken by many developers to make something more complex. This is a lot harder than it sounds.

I initially decided to pursue something like the TTL in an effort to produce an audio only vario module with the same awesome audio which the standard BlueFlyVario provides. Wide interest in modifying the Kobo eReader pushed me towards exposing a TTL serial interface, but with only one port available on the simple eReaders I had to multiplex GPS information using the second serial port on the micro controller. Development of this lead to the change in the BlueFlyVario version 8 which I released in the previous blog post.


Compared to the standard BlueFlyVario with Bluetooth, the baseline BlueFlyVario_TTL is simply just a populated PCB which is programmed with the BlueFlyVario firmware. There is no Bluetooth module, battery or case. The key specifications are summarized in the image below:

  • 1: Second serial interface. A serial port of the PIC microcontroller (UART1) is exposed with V+, Rx, Tx and GND (3.3v). By default it is configured at 9600 Baud to accept NMEA sentences from widely available GPS modules. Sentences starting with $ and ending with /n (carriage return character) are stored then immediately multiplexed with the information being sent out the primary TTL Interface. XCSoar is smart enough to interpret the multiplexed stream via a single device.
  • 2: Pressure sensor. The MS5611 pressure sensor is a super accurate little temperature compensated module with a digital interface. The surrounding components filter the power supply. When shipped this component is covered with neoprene to avoid light sensitivity (but do not press on it when active to avoid touch sensitivity). 
  • 3: Microcontroller. The PIC24F16KA301 is running at 8MHz. This is fast enough to provide advanced Kalman filtering of the pressure measurements (which is reads from the pressure sensor at 50 times a second). At this speed the micro controller can also handle reading and sending data over the two serial ports. 
  • 4: Speaker interface. Super keen experimental users might want to integrate the audio signal into a headset. 
  • 5: Solder jumper. If you want to disable the integrated transducer clear this solder jumper.
  • 6: Status LED. This lights up with every beep. 
  • 7: TTL Interface. The primary interface (which is actually UART 2 on the microcontroller) is used to provide power to the device and send and receive data via Tx and Rx (at 57600 kps). See the hardware settings manual for detailed information about the interface.
  • 8: Programming Pads. I program the firmware using a PICKIT 3 and this pads. Short pads 2 and 4 when turning on to reset the hardware settings (see the Hardware Settings Manual). 
  • 9: Voltage Regulator.  A Microchip TC1015 LDO voltage regulator outputs 3.0V to run the micro controller and pressure sensor. It works with input power between 3.3V and 6V. Below about 3.2 V it fails to provide a stable voltage to the pressure sensor. Standard 3.3V in from other low voltage TTL devices (such as the Kobo) work well. 
  • 10: Audio. An integrated small electromagnetic transducer provides the kind of pleasant sounding vario that is normally reserved for bigger devices. 


To make the TTL work you will need to do the following:

  • Provide power. I have deliberately not included a battery and switch. There are so many options and everyone has a slightly different need. You might choose to power it with a 1S LiPo, 3 x AAA alkaline batteries, power from USB, or power it from a Kobo. Whatever you choose you need to do ensure you meet the following specs.
    • Voltage: The TTL needs between 3.3V and 6V at the V+ pin on the main TTL interface end (do not provide power to the other end).
    • Current: The device consumes 10mA when not making noise, and around 50-60mA when sounding. Assuming a duty cycle of silence:noise of about 4:1 the average current consumption is about 20mA.
  • Provide a programming interface. A USB to Serial connector provides the ideal programming interface. This is used to configure the hardware settings if you want to change the defaults. You can get cheap USB to TTL serial converters on ebay, at hobby king or electronics shops like Sparkfun. I am considering including one in future releases of the TTL. 
  • Provide a data interface for external applications. If you want the vario data to be sent to an external application you can use the aforementioned USB to Serial convertor (for devices that support such a converter). Other devices (such as the Kobo) can be wired directly to the Tx and Rx pins. 

I envisage that the TTL can be used in many ways once it has been configured via the programming interface. Some examples:

  • Audio only mode. In this mode you only need to provide power and it will work. Something like a 3 x AAA case with integrated switch should meet the needs of most people. I am considering including one of these in future releases with the baseline configuration.
  • Integrated Helmet vario. The board is small enough to be integrated into a helmet. In this configuration a small RC 1s LiPo of around 600mA provides heaps of juice. A switch in series allows it to be turned on and off in flight. 
  • Integration via USB to a Linux device. Some users in sailplanes might want to integrate the vario directly into a Linux device via a USB to serial interface. I understand a few people are going to try to encase the vario and connect it to the TE probe. I am keen to get feedback. 
  • Integration with a Kobo. The picture below shows how I have integrated it with the Kobo on my workbench. In this configuration the Kobo is providing power to both the BlueFlyVario_TTL and the attached GPS module. This type of GPS module, based on the NEO-6M chip, is widely available and the default settings should work for most users. 


The images below show the schematic and PCB layout for the BlueFlyVario_TTL version 8 prototype.

Monday, 31 March 2014

BlueFlyVario version 8 released

I am super happy to release the BlueFlyVario version 8 prototype together with the BlueFlyVario_TTL. This next iteration of the Bluetooth design does not change much for most users, but under the hood I have changed the processor, updated the firmware extensively and provided a great base for ongoing improvements. The TTL version replaces the Bluetooth module with a TTL (3.3v) interface and will be covered in detail in a separate post.

BlueFlyVario Version 8 prototype

The key changes are:
  • A serial port of the PIC micro controller (UART1) is exposed with V+, Rx, Tx and Gnd (3.3v TTL interface). By default this port is configured at 9600 Baud to accept NMEA sentences from widely available GPS modules. All sentences starting with $ and ending with /n (carriage return character) are stored then immediately multiplexed with the information being sent out the Bluetooth serial port. XCSoar is smart enough to interpret the multiplexed stream via a single device.
  • I upgraded the voltage regulator from 3.0V to 3.3V. This provides slightly more power for any external device on UART1. It also provides a slightly more stable power supply which improves the performance of the pressure sensor a little. 
  • The micro controller was changed to the PIC24F32KA301. This has twice the memory of the previous micro controller which allows much more flexibility for growth. The current v8 firmware was updated to use the XC16 compiler. It takes about half of the program space. 
The image below shows the new layout. Note that this shipped device has the same pretty blue acrylic case, LiPo battery, neoprene cover (for the pressure sensor) and heatshrink. 


I have already shipped more than 50 of the version 8 prototypes. Europe is waking up from winter and the demand this spring is once again a little more than I predicted. I should be able to meet demand over the next few weeks but please understand if it takes a few weeks for me to get your order ready to ship.

Other new stuff

In conjunction with the release of the version 8 prototype:
  • See the Support page for a new Hardware Settings Manual and BFVDesktop App. 
    • The Hardware Settings Manual is a comprehensive description of all of the settings for the version 8 prototype. It expands on a previous blog post and provides information for users and developers. 
    • The BFV Desktop App is used for testing the BlueFlyVario and altering the hardware settings. It is a Java desktop application and it theoretically compatible with any platform that can run Java 6. 
  • I have updated the pricing policy. This has not changed the price, but does reflect the current reality. Essentially, the price for the BlueFlyVario includes components, production time, shipping and PayPal fees. You don’t pay for development costs, warranty, dealer mark-up, profit, website costs, taxes or profit 

The images below show the schematic and PCB layout for the version 8 prototype.

Friday, 24 January 2014

BlueFlyVario_TTL and other news

Despite the paucity of posts there is still a lot going on in my BlueFlyVario development world. I have recently return home after spending time away with family and have only just got on top of the back orders. I discovered it is possible to make and ship over 30 varios in one day! That brings the total number of version 7 prototypes shipped to over 125 since release just over two months ago.


In addition to the dual sensor version I mentioned in my last post (which I am still working on) I am in the final stages of testing a much simpler little device. I am calling this the BlueFlyVario_TTL. It is essentially just a BlueFlyVairo without the expensive RN42 Bluetooth module and battery management. I expose the TTL serial Rx and Tx which would normally go to the RN42. This allows the same hardware settings to be altered. Essentially this will provide a tiny super sensitive audio only vario which can be integrated into stuff. The current BlueFlyVario_TTL prototype is pictured next to the version 7 prototype below. It is about 35mm x 12 mm x 6 mm.

In the configuration above the BlueFlyVario_TTL does not have a case, battery, switch or battery charger. I will ship it encased in heat shrink. If power (3V) is applied to the outer pins it turns on. I envisage that the BlueFlyVario_TTL will be integrated into helmets with users providing an appropriate wiring, switch and power supply. I think that the widely available and cheap 18650 battery with a holder and switch is probably a good choice. Also, with the header pins shown above the BlueFlyVario_TTL can be plugged into a USB to serial converter for programming via a PC (or even to integrate with XCSoar or other programs via a cable). I have included a couple of holes for connection to helmet speaker systems if users want to disable the on-board speaker (by clearing the solder jumper).

I have not quite settled on the final configuration for this device. I might include a little serial programmer, or a switch, or a battery, etc. I am not quite sure. In the configuration shown above it will cost between $50 and $60, but if I start adding additional bits it would cost more. If you are interested in the BlueFlyVario_TTL please contact me and let me know your preferred configuration. Before release I will also need to write a PC app for setting hardware parameters via serial ports and document the serial protocol.

Speaker Changes

My supplier for the on board speaker discontinued the black colored speaker I used on the first version 7 prototypes. I spent some time testing a wide range of other speakers and finally settled on the white Kingsgate one pictured above. It is just as loud as the previous one and only a few cents more expensive per device. I hope this one stays available for longer.

App Update

I have recently fixed a bug with the Android app. This fixes a problem that European users had with altering hardware settings containing decimal points. 

Sunday, 22 December 2013

Airspeed Experiments

Over the last few months I have continued my experiments with airspeed measurements using two MS5611 pressure sensors. I built on some of the work described in this earlier post. I was initially really confident, but there are a few issues which are difficult to overcome. So now I have a new plan with a differential pressure sensor. Through this journey I learnt a lot more about how our pressure sensors work. In this blog post I will describe what I have learnt and the way ahead.

A new prototype

My main motivation in continuing with the twin MS5611 setup was to make a vario that had both super accurate static pressure changes (like the current BlueFlyVario), and could very accurately measure airspeed. I built on the design and theory outlined in this earlier post. The BlueFlyVario_Twin was designed for sailplane pilots. Bluetooth transmission of vario information from the total energy probes near the tail fin will overcome some of the accuracy issues associated with the volume of air in the tubes which normally run to the cockpit. I imagined that it would also be useful for hang glider pilots, but I am still not really confident that there is a way to mount a pitot tube for practical paraglider use.

The BlueFlyVario_Twin prototype design (see the images below) built on the basic BlueFlyVario and added some extra features:
  • The extra MS5611 pressure sensor.
  • Some more power configuration options which allow for 12V in (instead of the LiPo battery).
  • I exposed the second UART on the mirocontroller. This will allow for custom firmware to add a GPS or export the data vial TTL serial. 
  • I planned to use the more capable PIC 24F32KA301. I was running out of space on the current micro-controller. 

An assembled prototype is shown below. This was the test setup.

What went wrong?

In short, zero drift. Each MS5611 has a bunch of calibration coefficients. On start up these coefficients are read and then used to calculate the temperature compensated pressure. There are some remaining errors. The error from one measurement to the next is small (less than 10cm in pressure altitude terms) which means an individual sensor is perfect for use as a vario. However, the error in the absolute pressure is up to 100 times the relative pressure (about 10m in pressure altitude terms).

I thought that the error in absolute pressure could be compensated for by taking an initial measurement from each sensor at start up (when both sensors were subject to the same pressure), then applying that difference as a calibration coefficient. However, the difference drifts over time, not quickly, but over ten minutes or more it can drift far enough to mean that relative pressure measurements between the two sensors start to become inaccurate. The image below shows how the difference drifts over about two hours. The x axis is in seconds, and the y axis is the difference in pressure in pascals. To get good airspeed accuracy requires measuring differential pressure at accuracies of less than 5 pa. A drift of over 40pa would screw that up.

There is still some hope with this setup as we care more about the rate of change of differential pressure rather than the absolute differential pressure. In the data above we can see the base rate of change of differential pressure is no more than +/-0.01 pa/s. In a typical sailplane scenario on entering a thermal you might slow from 70 kts to 50 kts in 30s. The pitot pressure change would be about 300 pa (depending on air density), a differential pressure rate of about 10 Pa/s. This is a thousand fold difference from the rate of change from zero drift. This would allow for a roundabout way to calculate a total energy compensated vario measurement without the calculation of airspeed. However, I want airspeed as well so I needed another plan.

What is causing the zero drift?

I spent some time understanding how piezo resistive pressure sensors work. This document provides a wealth of great information that I will not repeat here. In summary, I suspect that each sensor is drifting based on subtle temperature dependent characteristics of each sensor. As each sensor is subject to different resistive heating the absolute pressure drifts, which is magnified for two sensors.

The way ahead

I will continue with the BlueFlyVario_Twin in a different configuration. I now plan to use a differential pressure sensor instead of the second MS5611. The first MS5611 will still be there to give accurate static vario, but the differential pressure sensor will be used for airspeed measurements. I am going to test the MEAS MS4525HRD in 0-1psi /differential configuration ( It is designed for airspeed measurement so I suspect the zero drift will be low enough (the datasheet does not quote zero drift) . With a busy summer and some time waiting for components it will probably not be until March until I know if my new design will be good enough to progress to a prototype I will be happy for others to use. I am optimistic once again!

Sunday, 24 November 2013

Android App Updated (version 0.7b)

I just uploaded an updated version of the BlueFlyVario app to Google Play. The update will take a few hours to propagate.

New Hardware Settings

The main new feature is the addition of new hardware settings to work with the new version 7 prototype hardware. You should read this previous blog post to understand how hardware settings work. The new hardware settings for version 7 allow the BlueFlyVario to output pressure and vario data in new ways. This means it is compatible with a wider range of applications via the bluetooth SPP connection. The new settings are:

  • outputMode (default = 0) - Sets the output mode. The available output modes are:
    • 0 - The standard BlueFlyVario output mode. This sends raw pressure measurements in the form: 
      • "PRS XXXXX\n": XXXXX is the raw (unfiltered)pressure measurement in hexadecimal pascals.
    • 1 - The LK8EX1 output mode for use with LK8000. This sends pressure and vario data in the form: 
      • "$LK8EX1,pressure,altitude,vario,temperature,battery,*checksum\r\n": pressure is sent as a decimal integer number of pascals, altitude is not sent (99999 is sent instead), vario is the decimal integer vertical climb rate in cm/s, temperature is in degrees Celsius (1 decimal place), and battery is the battery voltage of the on-board battery (2 decimal places). 
    • 2 - The LXWP0 output mode for use with a range of apps: 
      • "$LXWP0,loger_stored (Y/N), IAS (kph), baroaltitude (m), vario (m/s),,,,,,heading of plane,windcourse (deg),windspeed (kph)*CS": The BlueFlyVario only has a partial implementation of this sentence. It only outputs the baroaltitude and vario (all other fields are blank). Note that baroaltidude is determined from filtered pressure using the outputQNH setting.
    • 3 - The FlyNet protocol:
      • "_PRS XXXXX\n": In this case XXXXX is output as the filtered pressure stream. The filtering parameters used are those from the other hardware settings.  
  • outputFrequency (default = 1). Sets the frequency of output sentences from the BlueFlyVario. The BlueFlyVario hardware runs on a 20ms cycle (50 cycles per second). If outputFrequency is set to 1 then the hardware will send a sentence on each cycle. If set to 2 it will send a sentance every second cycle and so on (if set to 50 is will send a sentence every 50th cycle, i.e. once per second). You might use this with the LK8EX1 output mode to send a sentence five times per second (set to 10). 
  • outputQNH (default = 101325). See outputMode = 2 above. 

You will only see the new hardware settings if you have the new version 7 prototype hardware or have upgraded the firmware on version 6 hardware. Firmware upgrade requires a microchip programmer and the hex file. If you think you can do this yourself contact me and I will send you the hex file (or you can send me your version 6 prototype and I will do it for you).

Other changes

Most other changes to the app are minor such as bug fixes associated with some European locals that use ',' as a decimal separator.

I have added rudimentary support for the new BlueFlyVario_Twin, which has two pressure sensors and can be used to calculate pitot speed and total energy compensated vertical speed. More on that in a future blog post when the new device is ready for release...

Wednesday, 20 November 2013

Audio Demonstration Video

A few people have asked me to describe how the audio on the BlueFlyVario sounds. The video below shows this in three parts. It begins with a basic audio demonstration. This is followed by a short demonstration of the sensitivity of the MS5611 and how I use neoprene to protect it from light. It concludes with a bunch of varios beeping in unison.

What collective noun should we use for a bunch of varios? Perhaps a 'bleep' of varios.

Friday, 15 November 2013

Prototype version 7 released

Prototype version 7 is ready to order! In fact, I have already shipped about 30 to those that decided to pre-order one in the last three weeks. When I released prototype version 6 almost six months ago I thought I might only make about 50. However, there are now over 200 out in the wild, and each month the number of orders continues to increase. This post will talk about the improved user and design features in the latest release.

User Features

The new BlueFlyVario prototype version 7 is pictured above. The look and feel of the design is very similar to version 6. I have kept the same case and PCB size. The LED locations have moved around a little but I do not think that most users really look at them. You will still need to complete final assembly into the prototype case yourself. See this video:

Other new features include:

  • I have added support in the firmware for outputting different sentences other than the standard BlueFlyVario unfiltered pressure measurements as "PRS XXXXX" 50 times a second. The new output sentences will be enabled with new hardware settings. I will need to update the Android BlueFlyVario app then blog again to describe these new features in detail. As a teaser, the new formats are: 
    • LK8EX1 for compatibility with LK8000 devices which have bluetooth support.
    • A partial implementation of the $LXWP0 sentence (only the baroaltitude and vario fields). You might want to use this to minimize the processor power in XCSoar if you are using the audio on the BlueFlyVario instead of XCSoar. 
    • The FlyNet "_PRS XXXXX" protocol.
  • The audio frequency has been constrained so it can not be set below 130 Hz. In the last prototype the default hardware settings would mean that if you were in strong sink (below about -2.5 m/s), then the audio frequency output would be at about this level or below. The electromagnetic transducer has funky harmonics at about 125 Hz and below, and would start to sound at double or quadruple the set frequency.
  • An updated electromagnetic transducer. It is slightly louder and the one I have chosen has a footprint which is cross compatible with a range of other transducers, which means it is more likely I will be able to continue to source it. I now melt a small hole in the heat shrink so the sound comes out better.
  • I have added a solder jumper near the micro-USB port (which is open by default). If you wanted to remove the battery and power the device directly from the micro-USB port (for advanced users), then you would close this jumper. Essentially, it bypasses all of the charge circuitry. Beware: closing this jumper with the battery connected and then connecting power would destroy the battery (dangerously). 

Design Features

One of my main motivations for prototype version 7 was to design it so it was easier to assemble and test. It took around 30 minutes to assemble and test a version 6 prototype by hand. I have now got that down to 25 minutes for version 7. That might not sound like much, but when I am making them in batches of ten I save around an hour. These efficiency improvements include:

  • An updated PCB layout to make components easier to place by hand. This include aligning 0603 components in the same direction.
  • I have added more copper around the switch pads. This should make the switch more secure. 
  • The battery leads are now connected via 0.1" spaced through hole components. This makes the battery leads neater. Advanced users might also choose to remove the battery and power directly via a two pin header soldered here instead.
  • I got a commercial solder stencil with my last PCB order from This is easier to use than my previous approach of using a DIY stencil etched from a soda can.  
The schematic and PCB layout are shown below. The gerbers or microcontroller code are available for personal use on request, please email me.