Translucent Blue Cases

If you have been following the blog for a while you will know that I have been shipping the BlueFlyVario with the DP5031 prototype cases from SeeedStudio since prototype version 5. It is a great case that very adequately does the job of protecting the components on the board from knocks. Since prototype version 6 the PCB also has clear pvc heatshrink on it to help keep the battery and neoprene in place, and protect the components from dust and sticky fingers. Together the heatshink and prototype case make the device look a little polished, but it still retains the prototype look and feel.

I figured I was ordering quite a few of these cases from Seeed so approached them about getting a large custom order. With the help of Dangerous Prototypes I was able to organise for the cases to be made from translucent blue acrylic. After a few minor challenges the cases arrived earlier this week and I have already shipped a bunch with the current prototype version 6 to fulfill orders from the last week and a half.

A nice thing about the way this custom order was shipped to me from Seeed is that each prototype case came in a robust bag. When combined with a BlueFlyVario this is how it looks when I ship the components.

Not everyone is super comfortable with the prototype case. In a blog post coming up soon I will outline what others have done to design an enclosed case which can be 3D printed. 

App updated to improve performance

A rainy day gave me the opportunity to improve a few things in the BlueFlyVario app. A new version (0.61b) has been uploaded to Google Play and should push out in the next day.

Performance Improvements

• A more efficient way to read the incoming bluetooth stream has been implemented.
• Some code has been added to throttle the frame rate. Previously the app just tried to redraw itself as quickly as possible, and as a consequence sucked up all available cpu cycles. The frame rate is now limited to 20 fps, although you can change this through Menu|Settings|Layout and Display|FPS. If you have a slow old device you might like to slow it to 10 fps or even 5 fps. If you set it too high it will just go as quickly as possible.
• Some memory optimizations and tuning to reduce the need for garbage collection and improve execution speed.

Stability Improvements

• Some new code has been added to change the way that Bluetooth connections are made. If you are having problems with a stable Bluetooth connection, or being able to reliably connect, try the following:
• Start the BlueFlyVario app. Go to the app's Menu|Settings|Bluetooth area. Ensure the normal connection method is set and ensure connect on start is not checked. 
• Exit the app (fully, by either restarting your phone or force stopping the app)
• Unpair the BlueFlyVario from within the Settings area of your phone, then restart your phone. At this point you should have no BlueFlyVario record in the bluetooth connections, and when you start the app it should not try to make a connection. 
• Next, turn on the BlueFlyVario hardware and pair it with the phone from the phone's Settings area. Note that you will not need a pin on newer Android devices.
• Now, start the BlueFlyVario app and use the Menu|Connect Device to connect. It should connect to the hardware via the 'normal' method and using the pair record from the phones Settings area. 
• If that does not work (it might not on android 2.3.x devices), change to the 'reflection' connect method.
• Some bug fixes to avoid very irregular application crashes. 

The best news from all of this is that the performance improvements should increase the phone's battery life while the app is running, perhaps by as much as 30% due to avoiding wasted cpu cycles. 

Hardware Settings

I this post I am going to try to be pretty comprehensive all of the settings that control the BlueFlyVario prototype version 6 hardware. These settings are altered from the Android app using Menu|Settings|Hardware Settings. This menu item can only be accessed when the hardware is connected to the Android app. Although many of the settings are similar to those that control the audio on the Android device, they are completely independent. Both the app and the hardware work on the raw pressure stream, and none of the hardware settings alter how that raw stream is sent out. When you change a hardware setting through the app it is altered immediately and is stored in the memory on the hardware.

Edit: This post describes hardware settings in the version 6 prototype. There are some new hardware settings for the version 7 prototype. You can read about them here.

General Settings

The first few settings are pretty self explanatory:

• useAudioWhenConnected (default = false) - If true the hardware audio will sound when the device is connected via Bluetooth. 
• useAudioWhenDisconnected (default = true) - If true the hardware audio will sound when the device is not connected via Bluetooth. 

Next:

• positionNoise (default 0.1) - This setting controls one of the parameters for the KalmanFilter that is built into the hardware. A higher value gives less sensitivity by smoothing out the noisy pressure measurements. Try 1.0 to see the difference.

And near the bottom:

• secondsBluetoothWait (default 180) - This setting controls how many seconds the hardware will keep its bluetooth radio on while waiting for a connection. 

Audio Thresholds

The audio switches on and off based on the measured vertical speed. The settings liftThreshold, liftOffThreshold, sinkThreshold and sinkOffThreshold control when the sound comes on and off. The graph below describes how this works and what the defaults are. It is fine to set the on and off thresholds to the same value, but you will get funny results if the off threshold is higher than the on threshold. 

Essentially what happens as you enter lift is that the vario senses a decreasing pressure. Note that there is a slight delay between the movement and the sensed lift due to the way the filtering works. An updated value of filtered lift gets calculated from each pressure measurement, 50 times a second (or every 20 ms). The first time the lift goes above the liftThreshold a beep is scheduled for a duration controlled by the beep cadence formula (see below). That beep will last for as long as the beep cadence, then a period of silence will be scheduled, this time based on the most recently measured lift duration. Only at that time 'beeping' could end, but if the lift continues to be above liftOffThreshold, then another sequence of beep followed by silence will be played.

Beep Cadence

When beeping commences a beep is initiated for a duration based on the measured vertical speed. As soon as the beep stops a silent pause will then be initiated, again for a duration based on the measured vertical speed. The graph below shows the formula used to control the beep duration based on the measured lift. Essentially, it means the faster you are going up, the faster the beeps will occur. Note the rateMultiplier settings can make it go faster as shown below. A rateMultiplier setting of 0.5 will make it beep twice as fast. 

Audio Tone

In addition to the thresholds and cadence, the audio tone is adjusted based on the measured speed by the four settings liftFreqBase, liftFreqIncrement, sinkFreqBase and sinkFreqIncrement. The graph below shows how the frequency changes based on these settings, and also shows what the defaults are. The frequency of the sound is constantly being updated to control the tone as the filtered vario value changes. This is occurring with every measurement (every 20 ms) whether or not the audio is on. This will result in changes of pitch in beeps as they are playing based on updated filtered vario values, and on occasion the sink tone will sound at the end of a beep if the filtered vario value changed to below 0 during a beep being played.

Volume

The BlueFlyVario uses an electromagnetic transducer. You can see the datasheet here . (Edit: I am now using this one ) These devices are driven by a square wave from a microcontroller pin (using the inbuilt PWM ). Using the trick described in the graph below the volume is controlled without needing a variable resistor. Think of the transducer diaphragm being 'kicked' by a high pulse. The more gentle the 'kick' the quieter the sound. The volume setting is not linear.

Reset Hardware Defaults

If you really screw this up, and for some reason you can not fix it through the app, then it is possible to reset the hardware settings to their default values using the procedure shown below. You might have to do this if the bluetoothWaitTime gets set to less than the amount of time required to establish a connection. 

Some Notes

• The settings I picked as defaults are not the best. Please provide feedback by commenting on this post with what settings work for you and why.
• The trick to a well performing vario is to get a combination of 'positionNoise' and 'liftThreshold' that works best. If you have almost no filtering (i.e. a low position noise of 0.01) then the calculated vario value will be very noisy. In this circumstance the audio threshold would need to be set at 0.4m/s or higher to avoid errant beeping. These settings would be good if we wanted the vario to be ultra responsive to really jerky movements. However, for flying we bounce around a bit more gently. A position noise of 0.1 with a audio threshold of 0.2 seemed to work pretty well for me. 
• Most people will probably want to adjust the sinkThreshold setting to less than their glider sink rate, so it is not on all the time.
• Battery Life will be affected by what settings you choose. The largest consumers of battery life are the bluetooth radio and the electromagnetic transducer. Having both on full time would reduce battery life to less around 8 hours. Most people want the vario to beep when they are in real lift, and the sink tone to only come on when they are in significant sink (-2.0 or so). This will mean that the audio will only be sounding for less than 50% of most flights, which would give you over well over 10 hours battery life when not connected via bluetooth. I will post a more detailed description of battery consumption in a separate post.
• This could be a chapter of a user manual...

Air speed from two MS5611

Some time ago on this blog I promised an experimenters version of the BlueFlyVario. Earlier today I posted details of it on the blog. My first project with this version was to add an additional two MS5611 pressure sensors so I could rig up a custom airspeed sensor. It seems to be working ok, even though I have not tested it in flight. 

The setup

I got some little boards made up that use that pick up the VDD and GND on the bottom, link to the SPI MOSI, MISO and SCLK lines, and just use two additional IO pins for cable select. The headers are designed to line up with the headers on the experimenters board.

The picture below shows a spare board in the middle, and the made up one slightly lower left. Over the top of the MS5611 I put some neoprene like my standard v6. The small pcb tangs that contain the sensors are designed so that 7mm inner diameter vinyl tubing fits over the top. The header ends of these tubes are sealed with a bit of hot melt glue. I was quite amazed how well hot melt sticks to vinyl tubing. I had thought it would just peal off, but no; it's really sticky. 

The 7mm id vinyl tubing then has some 5mm id vinyl tubing to extend to the custom pitot tube. I made this up from some brass tubing from a hobby shop, with a few holes drilled in the right place and some hot melt to seal stuff up. There is actually a thin brass tube through the middle of the main one, with appropriate connectors to pitot and static sensors. Wikipedia shows a little theory of pitot-static tube design.

Determining the air speed

The micro controller code was altered to measure the pressure from each of the three sensors. It outputs PRS N1 N2 N3, where N1 to N3 is the pressure in pascals in hexidecimal of the form XXXXX. N2 and N3 are connected to the pressure sensors on the tangs. This gives us a dynamic and static pressure measurement, 50 times a second. To translate this to m/s is as simple as

Velocity (m/s) = sqrt(2 * (N2- N3) / airdensity).

I just used the standard air density in kg/m3 in my simple testing. This gives Indicated Air Speed. The conversion to True Air Speed should be easy enough given our slow speeds and some simple assumptions about atmospheric density based on pressure. Also, it will be important to put the pitot tube in really clear airflow.

I did a few calculations on the theoretical error. If we assume the error in the differential pressure is about the same as double the error in the sensors (RMS of 20 pascals), then the error in airspeed is very low (less than 1%) for speeds over 3 km/hr. In practice there are many other errors, but a quick 'blow on pitot' test seems to be able to produce reliable results given a 'constant' amount of blowing.

My next steps will involve more extensive testing and calibration. Then maybe a total energy compensated vario.

Experimenters version ready

I promised some time ago that I would produce an experimenters version of the version 6 prototype. I have recently got a batch of these boards and done some tinkering. The pads are the same as the version 6 prototype so this is easy to make using the same solder stencil. The main difference is the line of headers along the right. These headers expose various pins from the microcontroller for additional IO options. Below is a diagram of the pcb and schematic.

If you want one of these instead of a normal version 6 prototype please contact me. I will make you up a custom version and share the code.

 

Blue BlueFlyVarios

Blue Boards

A few weeks ago I got a big batch of blue PCB's. The first few version 6 prototypes were green, but I have been shipping blue ones for a few weeks now and will continue to do so. This is not really a huge deal. There is absolutely no difference in terms of function, but it does look just a little cooler.

Version 6 Prototype Update

The version 6 prototypes are pretty popular. I am shipping about five a week since I announced it just over a month ago. I have enough stock of all major components to continue at this rate for a few months. Although, it will be at least a few days until I get more prototype cases (I have been out of stock for a week). This is the third time I have underestimated the demand and have been caught a little short. 

I predicted that many people would just want to use the version 6 BlueFlyVario in audio mode. This is indeed the case. Some friends have just put the board in its heatshrink in the lining of their helmet. Below is a picture of a batch of the prototypes made up and ready to ship as soon as the prototype cases arrive. 

Blue Cases

Continuing my blue theme, I have ordered a batch of custom translucent blue prototype cases. These will take at least a month or so to arrive. In the mean time I will continue shipping with the transparent case.

Some answers

Over the last few months I have responded to many emails, forum posts and some blog comments about the BlueFlyVario. Much of this discussion has similar themes. In this post I hope to address some issues so I can point future queries towards this page. This is kind of like a FAQ.

"It would be great to see the BlueFlyVario with a wired connection to my device"

I have spent way too many hours thinking how the BlueFlyVario could connect in a wired way. There are very many options such as;

• a 3.3V serial (UART) connection via the micro USB pin
• add a chip like the FT232RL that provides a USB device that acts as a virtual COM port.
• change the PIC microprocessor to one that supports USB OTG 
• output the data using some kind of analog encoding for input via a device microphone port. 

All of these options have issues. The main problem that I have faced is that each of these solutions would be specific to a small range of devices. Choosing Bluetooth SPP means that pretty much every device with bluetooth (except iOS stuff) can be interfaced with the BlueFlyVario. Perhaps I am influenced by the fact that every device I own or have access to that I might want to use as a flight instrument can interface to via bluetooth; however, among the six android devices (four phones, two tablets) I would struggle to create one type of wired connection that would be successful with all of them. 

"I have a pressure sensor built into my Android device. I would like to use your software with it"

I have not implemented this in the BlueFlyVario Android software as it is pretty device/Android version specific. The BlueFlyVario Android software is open and you are free to modify it to meet your needs. 

Additionally, I am not aware of an Android device with a high resolution pressure sensor. Some pilots have been happy with a vario based on BMP085 based sensor (30cm resolution at less than 50Hz), which is the kind of sensor built into those phones that have one, but most pilots feel it is a step back from their current vario. If Android devices get high resolution sensors (10cm at 50Hz), and this information can be accessed from the OS, then there will be no need for the BlueFlyVario. 

"I would like to see other sensors on board the BlueFlyVario, like GPS or multiple pressure sensors "

I have focused on just a pressure sensor because it is the key thing missing to turn an Android device into a vario. 

The GPS on Android devices is good enough for 95% of pilots. My software uses it for windspeed calculations. 

Some pilots, particularly glider pilots, want multiple pressure sensors arranged in such a way that pitot and static pressures can be measured. This would allow for better wind speed calculations and provide the ability for total energy compensated vario measurements. 

The Experimenters Version of the BlueFlyVario will allow those with serious tinkering skill to incorporate other sensors. I will be working on releasing that over the next few months. 

"The BlueFlyVario should cost less"

I agree. The component costs for me at batch volumes of around 50 represent about half of the device cost. The remaining 50% comes from consumables used in production, apportioned overheads used in keeping my little workshop going, packing and shipping costs, and paypal fees. At this stage it would really only be possible to get the costs down if production increased to volumes of many hundreds. I am not trying to profit from this hobby.

"Can you get the BlueFlyVario to work with other software?"

Yes. It is already integrated into XCSoar. Work is underway to integrate it in XCTrack. If you are a software developer and can access a Bluetooth SPP stream then I encourage you to look at the Android BlueFlyVario app software on GitHub for some inspiration. If you need a BlueFlyVario device for testing contact me and I will help you out. 

"How does the BlueFlyVario perform compared to other varios?" 

Performance is a complex question. To address some of the issues that affect responsiveness, accuracy, precision and latency I will summarize what I have experienced in BlueFlyVario development. My aim has been to get the best performance possible out of the best sensor available. 

Performance starts with the sensor. I am using the MS5611 for the reasons I describe here. Essentially, there is a relationship between the number of readings possible per second, and the RMS error in each reading. The MS5611 can theoretically provide an RMS error of around 10cm (in pressure altitude terms) at a rate of 50 samples per second (at an oversampling rate of 4096). In practice, to get this good, requires very careful circuit design to filter the power supply. I have been able to get to an RMS error of 12cm at a rate of 50 samples per second. 

Next, we need a filter on the sequence of noisy pressure measurements to turn it in to a precise estimate of the rate of change of altitude. There are many approaches to this. I started with a linear regression and IIR filter. I have tested many approaches, including an AB filter, but in the end I have settled on a Kalman filter for its performance and theoretical underpinnings. I have found that the filter choice does not matter anywhere near as much as the sensor selection and power supply design. 

The time between the filtered lift rate being above the threshold and the commencement of the beep matters quite a bit. This depends on the way code is designed on the vario and supporting software. For my new hardware audio, it is less than 5ms until the beep commences. Transmission of the pressure data over bluetooth adds around 150ms. Based on feedback from other pilots it sounds like this delay does not matter much. 

The type of audio also matters, perhaps subconsciously based on what most pilots are used to. Variable frequency and cadence based on lift rate is anecdotally important. 

The most important thing from the above list is pressure sensor selection and the power filtering on the pressure sensor supply. I have managed to get the BlueFlyVario to the point where I can lift it from chest to head height and get ultra responsive beeping. I know most pilots don't need a vario that is this sensitive, but it is a kind of addictive obsession to pursue performance. 

Most pilots who have used it say the BlueFlyVario is as good as the best varios on the market.