Saturday, 22 August 2015

More BlueFly and XCSoar Integration

XCSoar has been a big part of the BlueFly experience for many pilots. It was about two and a half years ago when I first announced integration with XCSoar. Since that time we have seen XCSoar on the Kobo and almost 3000 BlueFly varios of different types shipped around the world. The recent release of XCSoar version 6.8 adds some features which allow for further integration with the BlueFly. I have added some experimental features to the BlueFly firmware to make this work.

[Edit: I updated the firmware the the following day to fix a bug and add one more command - see below for edits]

[Edit: These features can also be used with LK8000 - See here]

[Edit: Despite my original blog post, it now looks like version 6.8 of xcsoar does not actually include the gce event triggers in response to Airspace events]

Firmware changes

Three new commands were added in experimental firmware 10.m0810.m07. They all play some part in controlling what sounds are made by the BlueFly speaker. After upgrading the firmware don't forget to send the command $RSX* to reset to default settings.
  • The new command $BSD FFF DDD* plays a tone of frequency FFF Hz for a duration of DDD ms. 
    • FFF can be any frequency from about 150 Hz to about 8000 Hz. Outside of this range the BlueFly speaker does not work well. Note that different volume settings will alter the apparent pitch of the sound. If you send a frequency of 0 then the BlueFly will be silent for the specified duration. 
    • DDD is the duration in ms. You can send any integer up to about 32000 (i.e. 32 seconds). The duration will be rounded up to the nearest 10 ms. 
    • While the tone is playing other sounds from the BlueFly will be silenced.
    • You can send the command while another sound is playing and it will be added to a queue. 
    • For example, the command $BSD 400 100* will play a tone at 400Hz for 100 ms. 
  • The BSD command will play a sequence of sounds the one command if you use the following format: $BSD FF1 DD1 FF2 DD2 ... ... FFN DDN* 
    • The full length of the command including $ and * is limited to 82 characters, so you can fit about 7 to 10 sounds in depending on duration and frequency. 
    • Note that freq/ms pairs sent (in one command, or in a series of commands) will be put onto the queue and played in the order they were put in. The queue length is 30 10  [Edit: I updated this in 10.m08] so you can play some short tunes. 
    • For example, the command $BSD 400 100 0 150 1000 50* will play a tone of 400 Hz for 100ms, followed by silence for 150 ms, followed by a tone of 1000 Hz for 50 ms. 
  • A new command $BVU* will double the current volume (clamped to the maximum of 1000). You get a short beep each time you send the command to indicate the new volume. 
  • A new command $BVD* will halve the current volume (clamped to the minimum of 1). You get a short beep each time you send the command to indicate the new volume.
Edit: In 10.m08 I made the following additional changes:
  • Added command $BTN* in 10.m08 which simulates pressing the hardware button on the vario.
  • Fixed a bug which stopped the hardware button from silencing the vario. 
In forums I mentioned that I might implement a BAL command to play some set tunes. However, I did not want to hard code particular sequences in the firmware and I am comfortable that the BSD command will meet most needs. 

Custom XCSoar events

For some time XCSoar has had a feature to customize the interface and response to events using the custom .xci files in the XCSoarData directory. To test some of my new commands I created a bluefly.xci file. A full description of .xci files is not available; you need to dig into the XCSoar source code to understand how they work, and even then it is tricky to understand. I will try to describe the features of the .xci file format I have used. 

I have only tested basic functionality on Windows, Android and Kobo. I have not comprehensively tested in in flight and you should consider it experimental. 

First, to use the file you need to:
  • Upgrade to XCSoar 6.8 by following the directions for your device. 
  • Put the bluefly.xci file in your XCSoarData directory on your device. Depending on your device this directory will be in different locations. 
  • Restart XCSoar then Menu|Config|System|Look|Language,Input(Ensure Expert is checked)|Events then select the bluefly.xci file. Restart XCSoar again. 
The video below shows how the new firmware and bluefly.xci file works with XCSoar on the Kobo. 

The first part of the .xci file creates a new BlueFly menu item in the main menu in XCSoar:

event=Mode BlueFly

The next parts of the file create the five menu items in the new BlueFly menu:

event=SendNMEAPort1 BVU
label=Vol Up

event=SendNMEAPort1 BVD
label=Vol Down

event=SendNMEAPort1 RST

#event=SendNMEAPort1 BSD 392 100 784 100 392 100 784 100
#event=SendNMEAPort1 BSD 262 400 0 50 262 400 0 50 392 200
event=SendNMEAPort1 BSD 392 20 0 10 392 20 0 10 392 20 0 10 392 20 0 10 392 20 0 10 

event=Mode default

The first four commands make use of the command SendNMEAPort1 event. The command will be wrapped in $ and * to make the full command sent to the BlueFly. 
  • The first two menu items adjust the volume using the new commands.
  • The next simply restarts the BlueFly. You might like to change RST to RSX to restart the BlueFly and reset all of the settings. 
  • The next menu item uses the new BSD command to send a tone sequence. I tried with XCSoar to execute two "event=SendNMEAPort1" in response to the one input, but I think that XCSoar is sending them too quickly for the BlueFly harware to parse them. That is why I ended up with the one command where a series of notes can be sent. I have used menu item to test various sounds. Note that the lines beginning with # are ignored. Note also that if your BlueFly is set up as the second device you will need to adjust the events to SendNMEAPort2. 
  • The last menu item cancels the menu and sends XCSoar back to default mode. 
The next events in the file are "Glide Computer Events", which occur when things happen in XCSoar. I am not sure if there is a comprehensive listing of gce events, but I know these two were added in version 6.8 (thanks to Peter for this great addition to XCSoar). I have not actually tested them in flight yet so I am not sure how they work with my new firmware.  [Edit: It seems we are still waiting for these events to make it into the code: In the meantime see the modified bluefly.xci below]

[Edit: I am really sorry, but now I think that all of the airspace related GCE event stuff in XCSoar is not working in version 6.8 of xcsoar. The AIRSPACE_ENTER event seems to be not firing, and I dug down into the code. Although it appears on the list of events in, it looks like whatever code used to fire that event does not exist any more. The good news is that the BlueFly firmware is ready to go. So, now we just need an xcsoar developer who can commit the appropriate code.]

event=SendNMEAPort1 BSD 392 100 784 100 392 100 784 100

event=SendNMEAPort1 BSD 392 20 0 10 392 20 0 10 392 20 0 10 392 20 0 10 392 20 0 10

event=SendNMEAPort1 BSD 1000 500 800 500 600 500 400 2000 1000 500 800 500 600 500 400 2000


event=SendNMEAPort1 BSD 392 100 784 100 392 100 784 100

I am super interested to hear your suggestions for changing the bluefly.xci file and incorporating some more events. 

XCSoar Manage options

Another new feature in version 6.8 are some menu items to adjust a few of the hardware settings on the BlueFly from within the Devices menu. Below is a screenshot of the new Manage menu available when you have a connected device selected with the BlueFly driver. 

Only two of the hardware settings are adjustable in this release; the volume and Output Mode. Note that if you change the Output Mode to something other than BlueFlyVario you will need to also adjust the XCSoar driver. Thanks to Ben for this awesome new addition to XCSoar. 

More work

These new features of XCSoar come from our community of pilots. We are all very lucky a few guys spend some time working out how to make things happen they way they want. It is great when it all comes together. 

Sunday, 9 August 2015

BlueFly Firmware Update 10.M06

Busy lives means that sometimes the simplest things take forever, like making some minor changes to the firmware. However, when I change the firmware with a new feature I want to make sure it works then document it correctly.

Version 10.M06 of the firmware released today has the following changes:

  • I fixed the bug associated with not being able to set the hardware setting heightSeconds above about 650. This was an integer overflow thing that was easy to fix. 
  • A new hardware setting speedMultiplier (default = 1.0) allows you to adjust the way that the cadence adjusts with increasing vertical speed. By default the cadence increases pretty rapidly according to the graph in the Hardware Settings Manual (see the section on Beep Cadence), and by about 3m/s of vertical speed the cadence is down to about 0.1s. Some pilots who fly regularly in stronger lift wanted this to not be so sensitive. Adjusting the speedMultiplier to 2.0 means that this tops out at 6m/s instead. 

See the support page for the new firmware, an updated Hardware Settings Manual, and an update to the BFVDesktop app.

After updating the firmware make sure to send the command $RSX* via the BFVDesktop app to the BlueFly. This will reset your settings and ensure that the new settings can be used. 

If you have further suggestions for changes to the BlueFly which you think can be made in the firmware please contact me. Both of these changes came from feedback from users. 

Sunday, 7 June 2015

TTL_GPS Support Tips

The TTL_GPS model of the BlueFlyVario and a Kobo eReader can be the basis of a great vario in the hands of a reasonably experienced electronics tinkerer. Some people find it a little difficult to install successfully. This post provides a few tips.

Easy Install Method

There are many ways to install the BlueFlyVario_TTL_GPS to a Kobo. My current favorite install method involves using the included connector so that the vario is removable from the Kobo for easily adjusting Hardware Settings or doing firmware upgrades. If you are just experimenting with using a Kobo as a vario, or you are a little unsure what you are doing, then I recommend using this simple install (see the release blog post for more information). Advanced users can always install in a more robust way by de-soldering and re-soldering later. A few tips:
  • Install the right angled pins flush with the board. This makes the BlueFly sit flush to the front of the Kobo. The image below shows the sequence of pushing the plastic on the pins, cutting the pins, soldering, then removing the plastic from the pins.
  • Use the neoprene (essential) and heatshrink (not shown in the image below) to enclose the BlueFly, then fix to the front of the Kobo with double sided tape. Leave the covering on the sticky side of the neoprene and use the black squishy side to cover the pressure sensor (the sticky glue would block the holes). 

Using a USB to TTL Serial converter

A USB to TTL Serial converter makes it much easier to adjust hardware settings and is essential if you want to do firmware upgrades for the TTL_GPS model. You can adjust hardware settings when the BlueFly is connected to the Kobo with Putty and Telnet (see this blog post), but is is much easier with a USB to TTL Serial converter and the BFV Desktop application. The converter I use is shown in the image below. These can be purchased from eBay for a few dollars. Search eBay for "usb ttl serial". I only use the FTDI based converters as I am super confident that the drivers are kept up to date for most platforms.

Once the converter is plugged in to a Windows computer it should install as a serial port automatically. Have a look at the website of the converter chip manufacturer for appropriate drivers if it did not install. Take a note of what the serial port is. Depending on your version of Windows you might need to look in your device settings.

The connection between the converter and the BlueFlyVario_TTL_GPS is shown below. This converter is set to provide 5V of power. Note that the TTL levels on Rx and Tx are therefore 5V which is out of spec for the BlueFlyVario's 3.3V micro-controller, but I have not found it to be an issue with the 2.2k resistors in series. If the converter is set to provide 3.3V the BlueFly draws enough current on start-up to reset the converter, which is annoying. The most important thing to remember when connecting the BlueFly to the Converter is to ensure connections as follows; 
  • GND (BlueFly) to GND (Converter)
  • Tx (BlueFly) to Rx (Converter) 
  • Rx (BlueFly) to Tx (Converter)
  • V+ (BlueFly) to V+ (Converter)

With the converter plugged in with a USB cable run the BFV Desktop app (get the latest version from the support page). Next, connect to the relevant converter serial port at 57600 baud. Turn on the BlueFly by pressing the button and you should see data from the BlueFly streaming in. Using the BFV Desktop application you can then easily adjust all hardware settings. See the hardware settings manual (also on the support page) for information on the range of hardware settings.

If you want to update the firmware then I suggest ensuring communication with the BlueFly via the BFV Desktop app first. That ensures you have an working serial port connection. See the support page for information about updating firmware and how to use the DS30loader application. Note that you can only connect the BlueFly to one application at a time.

Debugging GPS Performance

The performance of the PA6H GPS is different the GPS in your Smartphone. It has no connection to the internet and often takes longer to receive satellites. Also, the antenna is generally not as good. Nevertheless, when it is working well most uses find it more than good enough to support flying. The most common questions I get about GPS performance ranges from the message "GPS Not Connected" to poor altitude performance.

The first step is to check if GPS messages are being sent to xcsoar. Check this in xcsoar by looking at the data stream coming in the Monitor (Menu|Config|Config2/3|Devices|Monitor). Check if the GPS messages are being sent to the vario. If the GPS LED flashing (it is either blue or red), then messages beginning with $GP... should be sent to xcsoar (GPS Data). A few are sent every second. If you can't see any messages then the BlueFly might not be connected properly, the xcsoar device settings might not be correct, the BlueFly hardware settings might be wrong, or there could be a hardware problem.

If you have GPS messages and are still having problems then check the HDOP and VDOP values in the $GPGSA messages. See this page for a description of these sentences. To enable detailed analysis set up the NMEA logger (Menu|Config|Config2/3|System|Setup|Logger|NMEA logger = On), record a track, then download the log to the PC using the Kobo in Nickel mode. If the HDOP and VDOP look good then the GPS should be giving a good fix.

For some earlier versions of the BlueFlyVario_TTL_GPS firmware it is possible $GPGGA sentences were clipped when you get a DGPS fix. If the messages are clipped (one character in the checksum instead of two) then update to the latest BlueFly firmware.

Lastly, note that the GPS vs Vario altitude in xcsoar is sometimes messed up. This article by Neil Page describes the various altitude settings. Use barometric altitude in preference to GPS altitude.

If these tips did not help then the best way to ask for support is to email me using the contact section of the website

Friday, 15 May 2015

Updated BlueFlyVario_Bluetooth_v10 Assembly

I released the BlueFlyVario_Bluetooth_v10 about six months ago (see this post). Most pilots have had no trouble with assembly, but there have been a few issues for some and there is always room to improve. This post describes a slightly different mix of parts you will receive and a simplified assembly procedure. Also, I have made a video of the assembly in response to quite a few requests.

What has changed and why?

  • The PCB is now shipped with the heatshrink and neoprene on. This part of the assembly was tricky for some pilots, the heatshrink would get all messed up, or the neoprene would be stuck the wrong way. I previously suggested putting the battery under the heatshink, now I am advocating to put it outside the heatshrink on the underside of the PCB. This idea came from a Red Bull x-alps competition pilot who wanted to be able to change batteries more easily. 
  • The screws and standoffs are now black plastic instead of metal. There are many good things (5g less mass, greater bluetooth antenna range), but I think it just looks cooler. 
  • The hole for the button on the blue translucent prototype case is now laser cut when the sides are made. This is neater and easier than having to drill every one. 

What is in the bag?

The components in the package are:
  • A BlueFlyVario_Bluetooth_v10 module with heatshrink and neoprene on. This has been bench tested.
  • A translucent blue acrylic prototype case. The acrylic is covered in brown paper.
  • Black nylon screws and standoffs for the case; four each of 12mm screws, 6mm screws, 5mm standoffs, and 6mm standoffs. You will need to shorten the 6mm screws by about 0.5mm using a sharp knife.
  • A 600mAh battery with 1.25mm 2 pin molex connector. The battery has some double sided tape on one side.

Follow the instructions in the video. The testing procedure is described in more detail in the post about the initial release (I did not follow it closely in the video). Please contact me if you have any questions or suggestions.


Sunday, 3 May 2015

Using an external speaker

On the version 10 models of the Bluefly there is a header to connect an external speaker. I have not used it much but have received a few questions. Unless you a really into electronics hacking I would not recommend using a different speaker.

Standard layout

The standard speaker on board the version 10 models is one of the following:

These are all 15 ohm to 20 ohm electromagnetic speakers. On the Bluefly the speaker is driven by a square wave switching a transistor. The circuit diagram and pcb layout on each of the model release blog posts shows how it works. 
The Bluefly runs on 3.0V (TTL_GPS) or 3.3V(Bluetooth and USB). When the transistor is 'on' the speaker would consume up to 150 to 220 mA, however when sounding it is driven by a square wave and making a continuous sound only consumes up to 70 mA. The regulator can provide 100 mA so we are near the limit of its performance. 

Using a different speaker

If you want to use a different speaker a 16 ohm (or greater) device rated for 3V should be used. You could connect it directly to the output, but a connection with a potentiometer is probably more appropriate so you can do some manual volume control (let Google be your friend to see how to wire a pot to provide volume control - search "potentiometer speaker volume control"). I can't recommend a particular speaker, other than advising that larger size generally equals greater sound volume. 

It is prudent to disconnect the current speaker or else it will be in parallel to the new one, and therefore decrease the overall resistance of the speakers. It is tricky to remove the surface mount speaker. The simplest thing to do to disconnect it is to cut the trace to the negative speaker terminal. Only two of the four pads are connected. The positive pad is connected directly to Vdd. The negative pad has a trace (either on the top or bottom) which can be cut. See the board layouts on the links above. Cutting the trace is obviously a one way thing, which is why it is only for serious electronics hackers.

[Edit: The image below shows the speaker pin holes on the BlueFlyVario_TTL_GPS_v10(rev2) board, and the location of the track on the underside of the board which leads to the negative terminal that you would need to cut to isolate the existing SMD speaker.]

Sunday, 22 March 2015

BlueFlyVario_TTL_GPS_v10 improvements

It has been a long time in between blog posts (almost 11 weeks)! This little hobby continues to keep me too busy. It has been one of the worst flying seasons in Canberra for many years which has given me time to continue production, build weather stations (the freeflightwx), and work on the BlueFlyVario.

I have been working on some new devices. In a future post I will describe plans for a BlueFly model that includes Blutooth, GPS, an SDCard for recording tracks, and USB computer interface. However, this post is all about improvements to the TTL_GPS model to make the GPS work better.

The issues

A few pilots reported that the BlueFlyVario_TTL_GPS with Kobo/xcSoar combination occasionally dropped portions of the track or had difficulty maintaining a satellite fix. With the help of our community of pilots I have determined that there are two distinct issues, both of which have now been addressed.

The first issues is a simple firmware error. In the firmware version M01 to M04 the GPS sentences being sent from the PA6H GPS were being clipped if the sentence length was longer than 79 characters. A NMEA sentence can be up to 80 visible characters long. Unfortunately, the bug clipped the sentence when it was longer than 79 characters, meaning the GPS data was not being transferred through to the Kobo. There are only some very particular circumstances when the PA6H would use the full 80 characters. The PA6H needs a DGPS fix (which we do not get in Australia) and needed to fix 10 or more satellites. In strong signal areas of Europe this can happen, and was causing dropouts which were very difficult to understand. The fix was super simple and has been rolled into the M05 firmware release (which will be on the support page of the website shortly). Unless you are having issues with a bad GPS track, and the NMEA log shows you are getting dropouts, then I would not worry about upgrading the firmware.

The second issue is associated with power supply noise and the ability of the GPS to get a good fix. I postulated that there are a few causes of the GPS power supply noise:
  • Broadband power supply noise from the 3.3v UART power from the Kobo. I measure that as around 70 to 100 mV pp (measured on an oscilloscope with AC coupling, 1x probe)
  • Broadband power supply EM emissions from the Kobo which are picked up by wires or the BlueFly/GPS circuitry. 
  • EM emissions from the Kobo which are at GPS frequencies (or appropriate multiples) and increase the baseline a real GPS signal must overcome. 
1 and 2 combine to affect GPS power supply noise on the BlueFly module. In the rev2 board on the first realease of the v10 the noise was filtered with only a 0.1uf cap at the input to the GPS, but further upstream the TC1015 regulator has 1uf on both the supply and output. This gets the Vpp down to less than the PA6H spec requirements of 50mV pp.

Improving power supply noise on the rev 2

If you have a BlueFlyVario_TTL_GPS_v10 with a rev2 board then you can adopt the following strategies to reduce power supply noise:
  • Make sure the wires which connect the BlueFly module to the Kobo are as short as possible, less than 5cm if possible. 
  • If the wires are longer, include a twist in the VCC/GND pair and the Tx/Rx pair.
  • Make sure that the wires are not routed across the middle of the Kobo PCB. 
  • Make sure that all solder joints are clean of flux. A little acetone on a small cotton swab will help clean any connections you have made. 
  • While the VBACKUP can improve time to first fix when you first turn it on, the long wire can also pick up electrical noise so you should consider if it is really needed. 
Further improvements - The rev 3 pcb

To further reduce power supply noise we needed a new pcb layout and some extra filtering components. The latest batch of BlueFlyVario_TTL_GPS_v10 pcbs are a new rev3 layout. I will be shipping rev3 pcb with all BlueFlyVario_TTL_GPS_v10 orders from now on. 

The rev 3 pcb incorporates the following changes:
  • Improvements to the ground plane under the GPS. This means that I removed the external pads for hacking to communicate with the GPS. If you want to get super serious about customizing your GPS you will have to solder to the PA6H pads instead. I am pretty sure that will only affect less than 1% of users.
  • Added Tx/Rx resistors for communication between the micro-controller and the GPS. This reduces noise on those lines.
  • Added an extra cap and ferrite to the power supply to make an LCC filter (600 ohm ferrite, 1uf, 0.01uf)
  • Moved the pressure sensor a little to make the neoprene fit over it better.
  • Moved the blue (or red) LED away from the pressure sensor.
All of these changes reduce the power supply noise, which in turn should improve the GPS performance. I remain confident that the rev2 board works well, but this new board should be just a little better. I have attached a schematic and layout below.

Wednesday, 31 December 2014

BlueFlyVario_USB_v10 released

Almost a year ago I started planning for an audio only vario to complement the original BlueFlyVario. I got a little distracted keeping up with orders of the Bluetooth version and the TTL_GPS (because of Kobo vario revolution). I started planning an audio vario again about six months ago. After settling on features, testing and producing an initial batch I am now very happy to announce a limited release the BlueFlyVario_USB_v10.

Design Philosophy

When designing this new vario I wanted to achieve a few things:

  • Build on the work of the successful Bluetooth model by providing a simple device designed for audio output. The firmware is pretty much the same as the Bluetooth and TTL_GPS models. 
  • Make it smaller. I wanted it to be easily able to fit in a helmet. I think this is the smallest vario available for purchase - it is about the size of a AA battery. 
  • Power with a rechargeable battery. Replacing batteries is a pain, but recharging is something we are really used to with our phone. The vario has a micro-USB connector which is the same as most phones. 
  • Provide a simple interface to alter the hardware settings. I considered having a separate USB-to-TTLSerial converter, but settled on incorporating a FTDI FT230X chip to provide an onboard emulated serial port. This only costs a few extra dollars, and does not take up too much board space (especially since I have now moved to using 4 layer PCB's). 
  • Expose the spare UART and audio interface for hacking. 
Because of all of this it ended up being more than just another audio only vario. The USB interface to change hardware settings and hack-able features makes it much more useful. 

Key Specifications

The BlueFlyVario_USB_v10 key features are:

  • Sensitive MS5611 pressure sensor with 10 cm resolution. 
  • Pleasant sounding audio tones, similar to fully featured varios. 
  • Onboard electromagnetic micro speaker (loudness 95dB). 
  • 250mAh rechargeable LiPo battery with 1.25mm Molex connector. Lasts about 10 to 20 hours depending on audio settings. Fully charge in about an hour. 
  • Onboard FTDI FT230X USB Serial chip. The device appears as a serial port with default drivers on most operating systems.  
  • Mass of about 9g. 
What is in the bag?

You need to do the final assembly yourself. You get the following bits in the bag:
  • The main module. This is 50mm x 12mm. 
  • A small piece of neoprene. This is really important. It must be placed over the pressure sensor if the sensor is exposed to any light. The neoprene allows the air pressure through, but stops the light. Light makes the pressure sensor go crazy.
  • A small 250 mAh battery. This is a single cell LiPo with a 1.25mm Molex connector. 
  • A small piece of blue PVC heatshrink. The simplest of cases is all you need. 


    Assembly should only take about five minutes:
    • Step 1 - Attach the battery. Remove the cover of the double sided tape and stick it to the bottom of the circuit board. See the placement in the image below.
    Battery placement
    • Step 2 - Do a quick test. At this point press the button to turn it on. You should hear a few beeps. The number of lower pitch beeps between the high pitch 2 second beep and short 0.5s beep indicate the battery voltage (6 = full, 1 = almost empty). Press and hold the button for 3s to turn it off.
    • Step 3 - Cover. Place the small piece of neoprene over the pressure sensor then encase the whole device in heatshirk. You will need to open up the heatshink to fit it over the button. Make sure the neoprene is covering every part of the sensor. 
    Neoprene placement
    Heatshrink placement
    • Step 4 - Shrink. Use a hairdryer on hot or a heat gun on very low to shrink the heat shrink. The switch might turn on. After shrinking, carefully slice the heatshink from the top of the switch, then shrink a little again. Test again to make sure the switch is working. 
    After shrinking
    Slice heatshink from top of switch
    A neat little circle
    After shinking again around the switch
    • Step 5 - Charge the battery. Plug in to a phone charger to charge the battery. The red LED will come on, then turn off when fully charged. [Note that as soon as you apply power to the micro-usb port that the device will turn on. This is because of stray current from the FTDI chip into the uart on the micro. Every ten minutes when on charge it will power down (based on the auto off feature), then power back on. The auto-on with recharge was an 'unintended feature' of this design. I might change it in the future with a couple of extra resistors in the design.
    • Step 6 - Alter the hardware settings. Most people will probably want to change the sink alarm from the default -0.2 m/s to something like -2.0 m/s (this stops the annoying sink alarm and reduces power consumption). Visit the support page of the website to download the BFV desktop app and the hardware settings manual to understand how to do it. 
    Advanced Use

    There should be a whole bunch of other things that this vario will do for advanced users. The pressure stream coming from the vario means that if you want to use it with an external application like XCSoar then it should be possible, provided the FTDI device enumerates properly on the device. This is only possible on Android/Kobo with some software hacking which I have not done yet. I have not tested this yet on anything other than the desktop version of XCSoar

    At some point I will update the BlueFlyVario Android app to allow the device to be used with a USB OTG connector.


    Like always; I share the design. Intrepid hackers might attach a GPS to the exposed U1 UART port or an external speaker. SJ1 and SJ2 provide for different power options. See the images below.