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 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. 

17 comments:

  1. This is excellent !!!
    Exactly what was missing for a full integration !!
    Very nice work al !

    ReplyDelete
  2. BTW, would the sound ajustment feature work with the older TTL v9 version ?

    ReplyDelete
    Replies
    1. Patrick, Yes. See the paragliding forum post for an example of what some guys have done with the .xci file.

      Delete
  3. I did all the steps described here, but I dont hear any sound, if I press the test button. Whar can I do to fix the bug (XCSOAR 6.8.1, BFV FW 08)?

    ReplyDelete
    Replies
    1. Matt, It is really hard to debug from afar. I would first confirm that the BlueFly is actually firmware version "BlueFlyVario_TTL_GPS_10.208". Look at the monitor in xcsoar and start the BlueFly and you will get version information on the first line. Next, check the format of the xci file to make sure it has no spaces in the wrong place, and a new line at the end of the file. If that all looks good the serious debugging with a TTL-Serial converter might be needed.

      Delete
    2. Al, thank you for your hints. I fixed it. It was a cold solder joint. Now it works great!

      Delete
  4. Would I be able to use the GPS enabled version of the vario with an Android tablet?

    ReplyDelete
    Replies
    1. To do this with the V10 you will need some electronics skills, either to hack an interface onto the TTL_GPS model, or to hack a GPS into the Bluetooth model. The next version of the BlueFlyVario may include a model with GPS and Bluetooth.

      Delete
    2. To do this with the V10 you will need some electronics skills, either to hack an interface onto the TTL_GPS model, or to hack a GPS into the Bluetooth model. The next version of the BlueFlyVario may include a model with GPS and Bluetooth.

      Delete
    3. Darn. I'm afraid beyond basic sodering I'm pretty lost, with the integration of the v10 to the kobo all that is necessary is the connection of some wires. Is there a way to adapt that system to an android device? I'm not afraid of opening her up.

      Delete
    4. If you want to connect to an Android device just use the Bluetooth model and the internal GPS of the Android device. That is what most people are doing with the Bluetooth model.

      Delete
  5. Always something new to find and know! (in my case the new volume setting)
    Thank you for this page

    ReplyDelete
  6. This comment has been removed by the author.

    ReplyDelete
  7. This comment has been removed by the author.

    ReplyDelete
  8. Do you think it's possible to send some setting commands to the BFV adding them in .xci files?
    Something like:

    mode=BlueFly
    type=key
    event=SendNMEAPort1 BZZ 1
    label=Buzzer ON
    location=5

    Thanks.

    ReplyDelete
    Replies
    1. I'll Answer myself: It's possible.
      BTW i mistyped the command. It's BBZ not BZZ.
      I'm planning to create some menu to configure the BFV through .xci file, like setting different values for sink and lift threshold.

      Delete
    2. It is great you worked it out. Some guys are discussing using xci files with the BlueFly in this thread on paraglidingforum.com: http://www.paraglidingforum.com/viewtopic.php?p=p496376#p496376

      Delete