Android has many quirks but I have a better than expected working app. Together with the prototype bluetooth module it functions better than my first vario from 15 years ago, and I think as well as my current vario. The video at the bottom of this post shows how far I have got. Adding vario functions is just a matter of writing code. Below I mostly describe challenges, but overall I found my first foray into Android Java an easy transition from the J2SE Java desktop environment.
Android version
The latest version of android is ‘Ice Cream Sandwich’. I needed to make some choices what ‘legacy’ devices I will support. Here is a summary of the distribution of devices by Android version. I have three android devices at home, a Froyo (2.2) HTC Aria, a Gingerbread (2.3.3) Samsung Galaxy S, and a ICS (4.0.3) ASUS tablet. Based on what I have, and the distribution of devices, I plan to see if I can choose API level 8. If that does not work then API level 10 is a must.
Android Bluetooth
I started with the Bluetooth Chat sample distributed with the Android SDK. After hacking away for a few hours I was able modify this to get the stream of pressure data arriving just fine. There were a few challenges. The principle challenge was about using BluetoothDevice.createRfcommSocketToServiceRecord(MY_UUID). Unfortunatly this method is a little buggy and causes an error on API level 8 devices. I used the reflection based work around described here and it worked fine.
The Bluetooth connection is still not perfect. I often get a ‘Connection Refused’ on my first attempt, and occasionally on the second attempt. It might be some combination of settings on the RN42. I will need to code in some sort of failsafe.
Graphics
Custom graphics were going to be required to get the look and feel I wanted for the vario. After a little reading I decided to go down the 2D graphics path using a SurfaceView object. Having spent way to many hours in the Java2D libraries this proved pretty easy, in fact, I think it is easier than Java 2D. Even without code optimisation it has ended up being plenty fast enough.
In the video below you can almost see how the desktop vario/alt trace has translated onto Android. I am really happy with this. The drawing is super quick on the ‘old’ HTC Aria. You can see how the trace colour changes depending on the vario value. I have added a little blue dot for the highest vario value in the trace.
What I am aiming for in my reference app is a super thermal hunting machine. I plan to add to the vario/alt trace with a similar trace for location, not on a map, but just graphically. I plan to scribble the same coloured trace (with the blue dot) on a location graph. The idea is to map out the last x seconds of lift/sink to assist with coring thermals. This will need me to read the location (every second or so) and work out wind drift of the trace (based on assuming constant speed). I plan to include this feature in the reference app.
Sound
Making Android go beep was tricky. Android devices have a nasty lag playing sounds. This can be overcome somewhat by using the SoundPool class, but still playing a sound is tricky. I have ended up with a nifty workaround that is acceptable.
To begin with all of the sound stuff needs to happen in a separate thread. This required some synchronization tricks to ensure data being used for the sound (the vario) was not being updated at the same time by the pressure reading / vario calculating thread. I ended up generating a 1s long .ogg file of a 1000 Hz sine wave tone (using Audacity). When beeping is turned on this file just plays in an infinite loop. To adjust the tone the file is sped up or slowed down. This will give tones of 500 Hz to 2000 Hz. If I need tones outside of this I can use other files if needed, but for the moment this range sounds fine.
To adjust the beep I use Thread.pause(ms) for some timing. In each loop I adjust the volume of the tone from 0 to maxVolume to turn the tone on and off. This does not alter the overall device music volume, just the volume of the playing tone. There is negligible delay from setting the volume to maxVolume until the time the tone is heard, compared to ‘play’ which has a slightly noticeable lag. This trick allows the beeping on and off to be quick. The cadence (delays inserted in the Thread.pause(ms)) varies between about 450ms (for 0.2 m/s up) and about 150 ms (for 4.5+ m/s up).
Overall I now have an acceptable beep, although not optimized quite yet. I am not sure if the constantly playing tone is expensive from a battery perspective. I think this will be device dependant, but I don’t think it will be an issue compared to bluetooth and screen use.
In the future I need to add a sink alarm. I think I might also add in some surprise easter egg sounds for lift above 3m/s!
Battery Life
I have done nothing to preserve battery life yet. I think I can do some things, but overall this app is going to be pretty heavy on the Android device’s battery. If it can last a typical day worth of flying with a few phone calls etc then I will be happy.
Way Ahead
The next steps in app development are:
- Add the location thing.
- Clean up the Bluetooth connection, reconnection, etc.
- Add in ‘start flight’ and flight time recording functionality.
- Add in the user preferences functionality for vario damping, displayed components, units (ft/m), etc.
- Add a few extra altitude displays (height above launch, custom alt based on QNH or a particular reference height.
- Cleaning up code and documenting (comments).
I am aiming for replicating the functions of a basic GPS/vario, adding in my super thermal hunting trace tools. Comp features such as waypoints, routes, etc can wait until future versions. I am aiming to open source this code as soon as I can get the first 10 or so hardware prototypes out. If you are a paraglider pilot and can code Android let me know if you are interested in testing by responding to this thread on paragliding forum.
I am deliberately putting the app coding on hold until I have the next prototype of the BlueFlyVario hardware. That is what will take some time. Components ordered over the internet are starting to arrive…
The video below is a little shaky. Wait until the end of it for some screenshots. The Android devices are an ASUS Transformer tablet and a HTC Aria phone.
Android version
The latest version of android is ‘Ice Cream Sandwich’. I needed to make some choices what ‘legacy’ devices I will support. Here is a summary of the distribution of devices by Android version. I have three android devices at home, a Froyo (2.2) HTC Aria, a Gingerbread (2.3.3) Samsung Galaxy S, and a ICS (4.0.3) ASUS tablet. Based on what I have, and the distribution of devices, I plan to see if I can choose API level 8. If that does not work then API level 10 is a must.
Android Bluetooth
I started with the Bluetooth Chat sample distributed with the Android SDK. After hacking away for a few hours I was able modify this to get the stream of pressure data arriving just fine. There were a few challenges. The principle challenge was about using BluetoothDevice.createRfcommSocketToServiceRecord(MY_UUID). Unfortunatly this method is a little buggy and causes an error on API level 8 devices. I used the reflection based work around described here and it worked fine.
The Bluetooth connection is still not perfect. I often get a ‘Connection Refused’ on my first attempt, and occasionally on the second attempt. It might be some combination of settings on the RN42. I will need to code in some sort of failsafe.
Graphics
Custom graphics were going to be required to get the look and feel I wanted for the vario. After a little reading I decided to go down the 2D graphics path using a SurfaceView object. Having spent way to many hours in the Java2D libraries this proved pretty easy, in fact, I think it is easier than Java 2D. Even without code optimisation it has ended up being plenty fast enough.
In the video below you can almost see how the desktop vario/alt trace has translated onto Android. I am really happy with this. The drawing is super quick on the ‘old’ HTC Aria. You can see how the trace colour changes depending on the vario value. I have added a little blue dot for the highest vario value in the trace.
What I am aiming for in my reference app is a super thermal hunting machine. I plan to add to the vario/alt trace with a similar trace for location, not on a map, but just graphically. I plan to scribble the same coloured trace (with the blue dot) on a location graph. The idea is to map out the last x seconds of lift/sink to assist with coring thermals. This will need me to read the location (every second or so) and work out wind drift of the trace (based on assuming constant speed). I plan to include this feature in the reference app.
Sound
Making Android go beep was tricky. Android devices have a nasty lag playing sounds. This can be overcome somewhat by using the SoundPool class, but still playing a sound is tricky. I have ended up with a nifty workaround that is acceptable.
To begin with all of the sound stuff needs to happen in a separate thread. This required some synchronization tricks to ensure data being used for the sound (the vario) was not being updated at the same time by the pressure reading / vario calculating thread. I ended up generating a 1s long .ogg file of a 1000 Hz sine wave tone (using Audacity). When beeping is turned on this file just plays in an infinite loop. To adjust the tone the file is sped up or slowed down. This will give tones of 500 Hz to 2000 Hz. If I need tones outside of this I can use other files if needed, but for the moment this range sounds fine.
To adjust the beep I use Thread.pause(ms) for some timing. In each loop I adjust the volume of the tone from 0 to maxVolume to turn the tone on and off. This does not alter the overall device music volume, just the volume of the playing tone. There is negligible delay from setting the volume to maxVolume until the time the tone is heard, compared to ‘play’ which has a slightly noticeable lag. This trick allows the beeping on and off to be quick. The cadence (delays inserted in the Thread.pause(ms)) varies between about 450ms (for 0.2 m/s up) and about 150 ms (for 4.5+ m/s up).
Overall I now have an acceptable beep, although not optimized quite yet. I am not sure if the constantly playing tone is expensive from a battery perspective. I think this will be device dependant, but I don’t think it will be an issue compared to bluetooth and screen use.
In the future I need to add a sink alarm. I think I might also add in some surprise easter egg sounds for lift above 3m/s!
Battery Life
I have done nothing to preserve battery life yet. I think I can do some things, but overall this app is going to be pretty heavy on the Android device’s battery. If it can last a typical day worth of flying with a few phone calls etc then I will be happy.
Way Ahead
The next steps in app development are:
- Add the location thing.
- Clean up the Bluetooth connection, reconnection, etc.
- Add in ‘start flight’ and flight time recording functionality.
- Add in the user preferences functionality for vario damping, displayed components, units (ft/m), etc.
- Add a few extra altitude displays (height above launch, custom alt based on QNH or a particular reference height.
- Cleaning up code and documenting (comments).
I am aiming for replicating the functions of a basic GPS/vario, adding in my super thermal hunting trace tools. Comp features such as waypoints, routes, etc can wait until future versions. I am aiming to open source this code as soon as I can get the first 10 or so hardware prototypes out. If you are a paraglider pilot and can code Android let me know if you are interested in testing by responding to this thread on paragliding forum.
I am deliberately putting the app coding on hold until I have the next prototype of the BlueFlyVario hardware. That is what will take some time. Components ordered over the internet are starting to arrive…
The video below is a little shaky. Wait until the end of it for some screenshots. The Android devices are an ASUS Transformer tablet and a HTC Aria phone.
