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