GPS and Airspeed Shields

I was really happy to release the BlueFlyVario_Bluetooth_v11 a few weeks ago. Since then I have found some time to get the GPS and Airspeed shields ready to go. In this post I will describe how the shields work and what you need to do to integrate one to the BlueFlyVario_Bluetooth_v11. A word of warning - the shields are for experienced tinkerers who are good at soldering and want to experiment.

The Shield Concept

I have developed quite a few different BlueFly models over the past few years. It all started with a simple device that just sent pressure data via Bluetooth. In v6 I added audio, a TTL version came later, then with Kobo mods becoming popular we got the TTL_GPS model. Firmware update-able versions started with v10.

If I just kept on adding sensors and other components to the BlueFly we would end up with a device that has a lot of stuff that many people would not use. That would be a waste of time for me, and a waste of money for users. However, there were some key things I wanted to be able to offer experienced users. The micro-controller on the v11 has enough spare pins to allow extra things to be added. Instead of adding sensors on the main BlueFly board I decided to offer extra capacity with an add on shield. The 'shield' is just a small daughter-board the same size as the BlueFly board. This is sandwiched with the BlueFly and connected with headers to make a more powerful device.

The images below shows the circuit diagram and PCB layout of the shield. Note that the components which can be attached to RB10 and RB11 can either be configured as buttons or LED's depending on what is populated.

BlueFly_v11_Shield_GPS

Description: The B_v11_Shield_GPS adds a PA6H GPS on UART1 (U1) of the microcontroller. The GPS shield has a few extra components to smooth the power supply to the GPS and provide the PA6H LED output. Note that the BlueFly button protrudes through the hole in the shield. The GPS works in exactly the same way as the GPS on the TTL_GPS models of the BlueFly:

• Any sentences coming from the GPS which begin with $ and ending with new line (\n) are echoed out on U2 by multiplexing the with the standard BlueFly output. 
• The BlueFly does nothing with the GPS information other than pass it through. 
• At this stage XCSoar is the only application which reads both the BlueFly output (in a few different modes) and the standard GPS sentences from the same data stream. 

Target Users: I expect that most people that want the v11 Bluefly and this add on v11 GPS shield will be wanting to connect it to a Kobo which as been modified to accept Bluetooth connections. Anyone who intends to use the BlueFly with a device that already has a GPS (like and Android or iOS devices) should not bother with this module.

Released Version: The BlueFly_v11_Shield_GPS is provided in kit form. The kit includes the items pictured below:

• The BlueFly_v11_Shield_GPS board.
• Some pins for connection to the BlueFlyVario_Bluetooth_v11 (these will need soldering). 

BlueFly_v11_Shield_Airspeed

Description: I have been tinkering with Airspeed for some time. It was not until I started experimenting with the MS4525DO differential pressure sensor that I found something I was happy with. This is the same sensor which is used in the PX4 airspeed sensor and is connected via I2C.

The MS4525DO upper port (the one near the top of the picture) is connected to the pitot pressure and the lower port is connected to the static pressure. The included pitot tube and clear tubing is a cheaply available RC model tube and will need modification at the nose to make it work properly as when it is machined the pitot hole gets a little closed. You will have to tinker with the physical layout of the tube to get it accurate, although note that there is no way to get accurate airspeed below about 10 to 15 km/hr.

Some additional notes (I will update the hardware settings manual at some stage):

• The BlueFly needs a special hardware setting adjusted. To adjust usePitot send $BUP 1* to the BlueFly via the normal manner (or tick the box in the BFVDesktop application). This makes the BlueFly read this pitot sensor each cycle via I2C and adjust the sent data appropriately. This will be described fully in the manual update; but in the interim note that the LX mode sends the indicated airspeed (IAS) when usePitot is set.
• When the BlueFly starts up with usePitot enabled it immediately begins a pitot calibration. This lights the red LED on the shield, then takes about five seconds of pitot data. The differential pressure measured is averaged and taken to be zero airspeed. 
• You can trigger another calibration at any time by pressing the red button on the shield next to where the normal BlueFly button protrudes. It is important that the pitot tube is in no wind when the calibration is underway. 
• If you set usePitot, but the shield is not connected, the BlueFly will send an error message. 

Target Users: I expect that most people that want the v11 Bluefly and this add on v11 Airspeed shield will be experimenting with different configurations. I am yet to be convinced that there is some logical place to put a pitot tube anywhere on a paraglider which has clean enough air; it is easier on a hangglider. At some stage I will probably design a 3D case to mount the pitot tube and vario components.


Released Version: The BlueFly_v11_Shield_Airspeed is provided in kit form. The kit includes the items pictured below:

• The BlueFly_v11_Shield_Airspeed board. 
• A basic pitot tube and clear tubing. 
• Some pins for connection to the BlueFlyVario_Bluetooth_v11 (these will need soldering). 

BlueFly_v11_Shield_GPS+Airspeed

Description: This provides the capabilities of both modules in one. See the image below:

Assembly

To assemble the shield onto the BlueFly requires some skill or a friend who knows what they are doing with a soldering iron. There are many ways it could be assembled together, and in the end you will need some kind of case which houses everything. At some point I will probably design a 3d printable case but so far I have only tested it with a Frankenstein mix of tape and heatshink which will be unacceptable for most people.

Some assembly tips:

• You will need to disassemble the BlueFly and disconnect the battery. 
• Start by soldering the pins on to the BlueFly, short ends in the pcb from the component side, then solder from the bottom. You should use all 11 pins (4 on one side, 7 on the other). 
• Use the 5mm standoffs from the BlueFly to position the shield above the main board. Note the button protruding through the hole at just the right height. 
• Solder the pins to the shield from the top. 
• Plug the battery back in (protect it from the pins with some tape), connect to the BFVDesktop application, then start testing. 

See the image below for an indication of what a shield looks like when connected to the base BlueFly.

Next Steps

There is quite a lot more to do:

• Design a 3d printable case for use with the airspeed sensor.
• Much more testing with the airspeed sensor. 
• Integration of GPS and airspeed information with other apps
• Update the hardware settings manual. 

The shields are available for purchase now. Note that I am only producing them in low volumes and will hand assemble and test each one based on the number of orders received.  

BlueFlyVario_Bluetooth_v11 released

I love releasing new models of the BlueFly. Every new model is a little milestone where I have tried to make the vario better and be more suited to a wider range of pilots. Almost a year ago to the day I released the BlueFlyVario_Bluetooth_v10. With the v11 you will get iOS support and the ability to add an air speed sensor and GPS with a separately available shield. Despite the Australian dollar exchange rate falling I have managed to keep the price the same by optimising production and selection of components. This blog post talks in detail about the new stuff following the announcement a few weeks ago. It will still take me a few weeks to catch up on orders.

What is in the bag

Back in May a new method of shipping and assembly was described. The v11 keeps this same procedure and you should watch the video before assembling the vario. The little things like trimming the screws and getting the battery lead properly placed with make the vario much neater. In the bag you will find:

• The vario covered in heatshrink with neoprene protecting the pressure sensor. This has been bench tested. 
• A 600 mAh battery with connector. 
• The two sides of the prototype case, covered in protective paper you will need to remove. 
• A pack of plastic screws and standoffs. 
• [Edit: From 26 Apr the BlueFlyVario_Bluetooth_v11 now ships with the Sky Blue Enclosed Case]

See the image below:

Hardware Changes

Below is a close up picture of the new circuit board. 

Some of the important changes include:

• The RN4677 bluetooth module replaces the RN42. This module is a dual mode module that supports Bluetooth Low Energy connections to iOS and also supports Bluetooth SPP connections on Android devices and on Windows. This is a new module and I had a little trouble with it initially but have managed to get it working reliably with over two months of testing. The benefits of the new module are:
• iOS support, however it will still be a little while until some iOS apps support the vario. We are working on FlySkyHy integration. There are a few BLE testing apps which enable you to see the data stream and even send commands to the vario which have given me confidence that integration with other iOS apps will be easy. 
• It is smaller. This means I have been able to fit more stuff on the PCB while keeping the size the same. 
• The range is better. Earlier today a mate put the vario in his RC plane (with the air speed sensor still in development) and flew it around. The BlueFly was paired with xcsoar running on my OnePlus One and we were able to see the data streaming in from about 100m away. 
• It is a little cheaper. 
• I have changed to the microprocessor to the PIC24F32KA302 and am now using the QFN package instead of SSOP. Even though it is smaller it is actually easier to solder without jumping leads, and most importantly, I have a bunch of extra IO lines to add new features. 
• The TC1015 regulator has been upgraded to the TC2185. This provides a higher max current to allow for the add-ons and has slightly better power supply noise performance. 
• Some of the IO lines are exposed in a new way (see the image below of the bottom of the PCB):
• U1 is used for connecting the GPS to V+, Tx, Rx and Gnd. The shield uses these for connecting a PA6H GPS. 
• The serial Tx and Rx between the microprocessor and the RN4677 are adjacent to U1. 
• The I2C lines V+, SCL, SDA and Gnd are used by the shield for connecting the MS4525DO pressure sensor. 
• RA7, RB10 and RB11 are used by the shield for extra buttons and LED. 

If you are a super keen hacker and want the circuit diagram or PCB layout please contact me. 

Firmware Changes

New features of the v11 firmware include:

• Boot up shorts for entering the bootloader and resetting all of the hardware settings:
• Previously to enter bootloader mode you shorted programming pads 2 and 5. Now you short SDA to ground (see the picture above). 
• Previously to reset all the default hardware settings you shorted programming pads 2 and 4. Now you short SCL to ground. 
• An updated ds30bootloader. This was required for the new microprocessor and to support the new boot up short mechanisms. 
• A new hardware setting for supporting the airspeed sensor. I will post more about that in a later blog. 
• The default baud rate setting for U2 has changed. The microprocessor now communicates with the bluetooth module at 115.2k instead of 57.6k. 

The GPS/Airspeed shield

A GPS/Airspeed sensor shield will be available separately, I think from around mid December. I am still testing and want to be confident all of the features are reliable. The shield will be available as a kit with the PA6H GPS only, with the MS4525DO airspeed sensor only, or with both. The image below shows the shield next to the new vario. I will post comprehensive information when it is released.

BlueFly_Bluetooth_v11 announced

Despite the paucity of posts, I have been feverishly working on the next version of the Bluetooth version of the BlueFly in every second of my diminishing spare time. It is almost a year since the v10 was released and it is time for an update. In this post I will preview some new features prior to the release, which I expect will occur in late November.

I am currently out-of-stock of the BlueFlyVario_Bluetooth_v10. Any orders between now and the release of the v11 will be filled with the new model. Please be patient as I get everything together.

What stays the same?

• Pretty much every firmware feature of the v10 is available in the v11. All of the hardware settings and commands will be available in the v11. 
• The PCB size, speaker, button location and LED colors are all the same. 
• The prototype case and battery will not change. 
• The price, at least for now. Some component prices have reduced, but the Australian dollar has also fallen. 

What is new?

• The first big news is a new bluetooth module which will work with iOS. I have replaced the RN42 with Microchip's new RN4677. This is a dual mode module with both Bluetooth SPP and Bluetooth Low Energy (BLE). Most devices will continue to use Bluetooth SPP, but BLE means that iOS devices can be supported. This should mean that FlySkyHy will support the new BlueFly if I can get a prototype to Rene and he can find time to alter his code. 
• The new PCB layout also supports an add on shield for more features. The shield, which will be available separately, can be configured with either or both of a PA6H GPS or a MS5425DO differential pressure sensor. Much of my experimentation over the last few months has been to finally get reliable airspeed measurement with easy calibration and stable performance. I will post a lot more about that when I release the shield (which will be some weeks after the new v11 is released). 
• I have updated the micro-controller and some other components. There will be more information about these on release of the v11. 
• Also, there will be some new firmware features. Again, more on release. 

See the image below of the prototype being tested on the workbench; the headers help with development but they are not part of the final version. 

What needs to be done before release of the BlueFlyVario_Bluetooth_v11?

• Manufacture the first production batch of hardware - I am waiting on some components. 
• Finalise the updated boot-loader. The new bluetooth module and micro-controller meant I have had to make many updates to to. Now I need to finish testing. 
• Finalise the updated firmware. Again, more testing. 
• Update the BFVDesktop pc application with new hardware settings. 
• Update the BlueFlyVario android application. 
• Write another blog post. 

What about the TTL_GPS and USB models?

At some stage I think I will update the TTL_GPS model from v10 to v11 so it can support the new micro-controller, but probably not for many months and I am not sure if it will support the airspeed measurement. The update to the USB model will have to wait for the v12...

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. 

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. 

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.

Assembly

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.

  

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:

• http://www.newark.com/pdfs/datasheets/Multicomp/SMT-8540B-K4083.pdf
• http://www.mouser.com/ds/2/334/SMT-0827-S-2-R-36461.pdf
• http://www.kingstate.com.tw/index.php/en/products-magnetic-buzzer/products-magnetic-transducer/products-smd/item/114

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. 

• TTL_GPS model: http://blueflyvario.blogspot.com.au/2014/11/blueflyvariottlgpsv10-released.html Also see the rev3 if that is your layout: http://blueflyvario.blogspot.com.au/2015/03/blueflyvariottlgpsv10-improvements.html
• Bluetooth model: http://blueflyvario.blogspot.com.au/2014/11/blueflyvariobluetoothv10-released.html
• USB model: http://blueflyvario.blogspot.com.au/2014/12/blueflyvariousbv10-released.html

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

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.