BlueFlyVario version 8 released

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

BlueFlyVario Version 8 prototype

The key changes are:

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

The image below shows the new layout. Note that this shipped device has the same pretty blue acrylic case, LiPo battery, neoprene cover (for the pressure sensor) and heatshrink. 

Availability

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

Other new stuff

In conjunction with the release of the version 8 prototype:

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

Schematics

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

BlueFlyVario_TTL and other news

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

BlueFlyVario_TTL

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

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

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

Speaker Changes

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

App Update

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

Airspeed Experiments

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

A new prototype

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

The BlueFlyVario_Twin prototype design (see the images below) built on the basic BlueFlyVario and added some extra features:

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

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

What went wrong?

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

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



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

What is causing the zero drift?

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

The way ahead

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

Android App Updated (version 0.7b)

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

New Hardware Settings

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

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

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

Other changes

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

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

Audio Demonstration Video

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

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

Prototype version 7 released

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



User Features

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

Other new features include:

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

Design Features

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

• An updated PCB layout to make components easier to place by hand. This include aligning 0603 components in the same direction.
• I have added more copper around the switch pads. This should make the switch more secure. 
• The battery leads are now connected via 0.1" spaced through hole components. This makes the battery leads neater. Advanced users might also choose to remove the battery and power directly via a two pin header soldered here instead.
• I got a commercial solder stencil with my last PCB order from http://smart-prototyping.com/. This is easier to use than my previous approach of using a DIY stencil etched from a soda can.  

The schematic and PCB layout are shown below. The gerbers or microcontroller code are available for personal use on request, please email me. 

BlueFlyVario found

This is a cool story. It is about the BlueFlyVario, but it shows that people are awesome, and that random events can be great.

Stephan was one of the first people who supported the BlueFlyVario vario project by purchasing a version 6 prototype. It was one of the first ten which means he had one with a green pcb. About a month ago he ordered another via the website. I figured he really liked it and was purchasing one for a friend. After I shipped it I forgot to ask him more about it as I got consumed in preparing version 7 (another blog post about that soon).

In the middle of last week I got an email via the website from Balazas in Hungry:

I found a Blue Fly Vario V6 device in Austria near a paragliding area in the bush last Friday while I was there for rock climbing. It was wet, and one of the plastic case is broken, but it works as I tried it. If you can help, I would send back to the owner, probably someone lost it.

It was awesome for Balazas to get in contact with me. In a later email he mentioned that he was motivated by a desire for those that do sports in the mountains to help each other as our sports can be dangerous sometimes. There was more awesomeness to come from him.

I have kept a reasonable record of who I have sent BlueFlyVario's to. I record the last four digits of the MAC address which forms part of the bluetooth name. So I asked Balazas and after his prompt response quickly worked out the vario was the first one I shipped to Stephan back in May. When he found out:

This is amazing, I lost this variometer approx 100m above ground and heard it crashing into the woods. I would not have given a penny that it is still working. I lost it about two weeks ago, so it must have been laying there in the heavy rains of last weeks, unbelievable!

I put these guys in touch with each other and Balazas quickly sent the vario back to Stephan:

A big thank you guys for finding out and sending it back to me. This is really great and a little sensation for me! First of all that someone found it second that it survived the fall from over 100 meters with very little damage and third that it found the way back home via Australia to Austria... 

You can see above the perspex protocase got cracked in the fall. A new one is on the way to Stephan right now. 

I don't recommend dropping your vario from 100m and leaving it for a few weeks in the rain. Even so, it is great to see that even with this punishment the vario still works.  In fact Balazas said when he first picked it up in the forest he turned out on and it beeped, then he paired it. Some people are awesome.