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 http://www.postfrontal.com/forum/topic.asp?TOPIC_ID=7932&whichpage=2)]

[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:

mode=Menu

type=key

event=Mode BlueFly

label=BlueFly

location=5

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

mode=BlueFly

type=key

event=SendNMEAPort1 BVU

label=Vol Up

location=1

mode=BlueFly

type=key

event=SendNMEAPort1 BVD

label=Vol Down

location=2

mode=BlueFly

type=key

event=SendNMEAPort1 RST

label=Reset

location=3

mode=BlueFly

type=key

#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 

label=TestBeep

location=4

mode=BlueFly

type=key

event=Mode default

label=Cancel

location=9

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: http://git.xcsoar.org/cgit/master/xcsoar.git/tree/src/Input/InputQueue.hpp?h=v6.8. 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 http://git.xcsoar.org/cgit/apf/xcsoar.git/plain/src/Input/InputQueue.hpp, 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.]

mode=default

type=gce

data=AIRSPACE_NEAR

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

mode=default

type=gce

data=AIRSPACE_INSIDE

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

mode=default
type=gce
data=AIRSPACE_ENTER
event=SendNMEAPort1 BSD 1000 500 800 500 600 500 400 2000 1000 500 800 500 600 500 400 2000

mode=default
type=gce
data=STARTUP_REAL

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. 

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.