Saturday, 23 July 2011
Development on Hold
I have to go away for a few months for work. Development will be on hold until 2012...
Monday, 23 May 2011
Testing the alpha prototype
To test the prototype I had to write and tweak a small Java desktop application. I used the bluecove library so I could use JSR-082 bluetooth calls for the desktop. This is much more reliable than connecting via a virtual COM port, an much more like I will do for the Android app.
The desktop application simply reads the stream of pressure data and displays it as text fields with an added graphical interface for the vario. The purpose of the test app is to work out what parameters are best for smoothing the incoming pressure stream for the vario while minimising lag, what damping factor to use for the altitude. The app you see in the youtube video below is set up with one altimeter with a damping factor of 0.01, and two variometers.
As it turned out I not only performed a linear regression on a window of the pressure data, but also then subsequently smoothed the result with an IIR filter. The parameters for the two varios shown in the app are:
Var 1: Window (50 measurements - about 2.5s), damping factor 0.3
Var 2: Window (60 measurements), damping factor 0.05
Note that both 'varios' use the same incoming pressure data stream. They just analyse it differently.
The graphical display of the vario data was an accident. I just wanted to be able to visualise the response lag. Having stumbled upon this display I reckon I will use it in the Android app. I will tweak it a bit to include Var 1 and Var 2 bars on the left and will probably add an altitude graph below it and allow the user to vary the timescale. At the end of the video you can see how the auto range scaling works.
In this test I managed to determine there is a bit more lag than I would like in the vario, but it should still be usable. With the MS5611, I should be able to get more resolution and less lag.
Sunday, 22 May 2011
Processing and filtering the data
A raw stream of pressure data is noisy. If it was displayed directly to the user as altitude it would not mean much as it jumps around and causes more confusion than good. For a useful altimeter we need to convert the pressure to altitude and smooth the data out. For the vario we need to determine the rate of change of altitude.
Pressure to altitude conversion
The BMP085 tutorial on Sparkfun provides a handy reference to the pressure to altitude conversion. The altitude equation near the bottom of the tutorial is the one to use. Read more about QNH here to understand all about the relationship between pressure and altitude.
Filtering the altitude data
The raw stream of pressure data converted to altitude is shown in the image below. To get this data the alpha prototype was kept at constant altitude for about 20s, then lifted up about 2m and kept there for 20s, then down 1m and constant for 10s, then back to the original height for 10s.
To turn the noisy data into a smooth line we need to filter the data. The trick is to balance the degree of filtering, which is really just different ways to sum up and balance historical data, with the degree of lag you are willing to accept. For the altimeter we can accept seconds of lag and there is no real issue, up to about 10 seconds is fine. This means that we can use a well damped filter.
There are a bunch of choices. A simple average is perhaps what most people might instinctively use. Just by averaging the last 20 or 40 measurements (representing one or two seconds) you will get a much smoother line. The problem with doing the maths is a little more complex than needed as you require to save each of the last x measurements then do the averaging math each time you need to display the altitude. This is not an issue on a PC or Android device, but is a pain on a micro controller.
A more simple approach is to use an IIR filter. This wikipedia article will confuse the hell out of most people. It is actually really easy when explained in words. You measure the altitude the first time. This becomes the 'current' altitude. With each subsequent measurement you sum X% of the new measurement with (100 - X)% of the previous 'current' altitude for the new 'current' altitude. This ends up being an exponential filter, where the most recent measurements have more weight than older measurements. The X% is the damping factor. Around 5 or 10 is about right, the lower the number the more damping. More damping equals more smoothness but more lag.
A more complex approach is to use a one dimensional Kalman filter. After playing with this I managed to work out that it is pretty much equivalent to the IIR filter, once it has been tweaked. I am going to use an IIR filter for altitude.
Linear regression for vertical speed
To turn the altitude data to vertical speed we need to determine the slope of the graph. The easiest way to do this is to take a linear regression over a time window. Again, the greater the window the more smoothing, but the greater the lag. In the bottom image I show how 1, 2 and 3 seconds regression windows work. 1s is too noisy. You can see that in the first 20s there are many spurious vario blips over 0.1 m/s. 2s and 3s are much better (and about the same). You can see at the 20s mark when the vario was lifted the vertical speed up around 0.5 m/s. There is a little more lag on the 3s data window compared to the 2s window as expected.
You don't need to the the entire linear regression, just calculate the slope. I have a working vario!
Pressure to altitude conversion
The BMP085 tutorial on Sparkfun provides a handy reference to the pressure to altitude conversion. The altitude equation near the bottom of the tutorial is the one to use. Read more about QNH here to understand all about the relationship between pressure and altitude.
Filtering the altitude data
The raw stream of pressure data converted to altitude is shown in the image below. To get this data the alpha prototype was kept at constant altitude for about 20s, then lifted up about 2m and kept there for 20s, then down 1m and constant for 10s, then back to the original height for 10s.
To turn the noisy data into a smooth line we need to filter the data. The trick is to balance the degree of filtering, which is really just different ways to sum up and balance historical data, with the degree of lag you are willing to accept. For the altimeter we can accept seconds of lag and there is no real issue, up to about 10 seconds is fine. This means that we can use a well damped filter.
There are a bunch of choices. A simple average is perhaps what most people might instinctively use. Just by averaging the last 20 or 40 measurements (representing one or two seconds) you will get a much smoother line. The problem with doing the maths is a little more complex than needed as you require to save each of the last x measurements then do the averaging math each time you need to display the altitude. This is not an issue on a PC or Android device, but is a pain on a micro controller.
A more simple approach is to use an IIR filter. This wikipedia article will confuse the hell out of most people. It is actually really easy when explained in words. You measure the altitude the first time. This becomes the 'current' altitude. With each subsequent measurement you sum X% of the new measurement with (100 - X)% of the previous 'current' altitude for the new 'current' altitude. This ends up being an exponential filter, where the most recent measurements have more weight than older measurements. The X% is the damping factor. Around 5 or 10 is about right, the lower the number the more damping. More damping equals more smoothness but more lag.
A more complex approach is to use a one dimensional Kalman filter. After playing with this I managed to work out that it is pretty much equivalent to the IIR filter, once it has been tweaked. I am going to use an IIR filter for altitude.
Linear regression for vertical speed
To turn the altitude data to vertical speed we need to determine the slope of the graph. The easiest way to do this is to take a linear regression over a time window. Again, the greater the window the more smoothing, but the greater the lag. In the bottom image I show how 1, 2 and 3 seconds regression windows work. 1s is too noisy. You can see that in the first 20s there are many spurious vario blips over 0.1 m/s. 2s and 3s are much better (and about the same). You can see at the 20s mark when the vario was lifted the vertical speed up around 0.5 m/s. There is a little more lag on the 3s data window compared to the 2s window as expected.
You don't need to the the entire linear regression, just calculate the slope. I have a working vario!
 |
| Raw pressure data converted to altitude (blue) with IIR filter (red - damping factor 5%) |
 |
| Linear regression of pressure data over various time periods |
Building the Alpha Prototype
Moving from the breadboard to the alpha prototype was again much harder than I thought. The most challenging thing was trying to work out where solder had jumped tracks under the board. As part of 'debugging' the circuit I had to take the BMP085 breakout off the protoboard, and in doing so screwed up the breakout. This gave me an opportunity to use my skillet desoldering techniques for recovering an SMD component. With the BMP085 off I put pins on it like the RN-42. This allowed separate access to VDDD and VDDA so I could use a few inductors to isolate the analogue voltage input.
Below are some pics.
Below are some pics.
 |
| The working alpha prototype. The button does nothing - I turn it on an off using the jumper in the top right. |
 |
| The BMP085. Notice the dodgy free wiring, including a SMD cap that has little pins to get it as close as possible. |
 |
| It was difficult to avoid jumping tracks on the protoboard. Note the battery wires soldered underneath. |
Thursday, 19 May 2011
Testing Components
From a blank breadboard to working components took over a month of occasional tinkering. The 'easy' things ended up being a pain in the ass.
Step 1 - Getting the RN-42 working. This was much easier than I thought, once I had soldered the required pins. I just used the circuit in the data sheet, applied power, searched for the bluetooth device from the desktop then connected. I used TeraTerm as the terminal emulator program to access the device using $$$ to enter command mode and play with the settings. A few tips:
Step 2 - Getting the Microcontroller working with the RN-42. This was much harder than I thought. I eventually worked out how to hook everything up and program using ICSP via the PICKIT. The tutorial here plus Hari Nair's PIC24F code helped. The most difficult thing was working out baud rate on both the RN-42 (which is set via command mode) and the PIC24F (which is dependant on the clock rate). Eventually I got it all working and was able to print 'Hello BlueFlyVario' via bluetooth to the terminal emulator.
The most painful thing with the PIC24F was when I wanted to use U2 rather than U1 as the UART port. The U2RX is on pin 5, which also happens to be used for AN3. A very poorly documented feature of the PIC24F is that if you are going to use a pin that can be used as an analogue input as a digital input (which the UART needs) then you have to set the corresponding ADxPCFG register, as by default it is set as an analogue input. In this case the call '_PCFG3=1;' was all that was required - after eight hours of pain.
Step 3 - Interfacing with the BMP 085. This was pretty easy. Hari Nair's code was very helpful for the interfacing. Instead of doing all of the calculations on the PIC I just dumping the pressure every measurement cycle to the uart.
Another thing that is kind of important is that all of the ancillary characters that I was tempted to 'print' to the uart costs a lot of micro controller processing time. In the end I am only dumping a very short string with the pressure as an int in pascals.
At this point I thought I had cracked it, I would soon have a working vario...
 |
| The 'kind of working' integrated components |
Step 1 - Getting the RN-42 working. This was much easier than I thought, once I had soldered the required pins. I just used the circuit in the data sheet, applied power, searched for the bluetooth device from the desktop then connected. I used TeraTerm as the terminal emulator program to access the device using $$$ to enter command mode and play with the settings. A few tips:
- Soldering pins onto the surface mount device was not too hard. I tinned up some copper wire with solder, put a tiny dab of solder onto the surface mount pad, then soldered the two together with a minimium of head. This is a pretty easy and quick method for prototyping with SMD components.
- The bluetooth stack on a PC is a pain in the ass. Connecting to a SPP device via a virtual COM port via a terminal emulator is far from reliable. I ended up having to restart my system way too often to reconnect to the RN-42 in between power cycles. If you can write some code to connect via bluetooth without the virtual COM port it will be much more reliable. I have used Java desktop JSR-82 based code to do that now.
Step 2 - Getting the Microcontroller working with the RN-42. This was much harder than I thought. I eventually worked out how to hook everything up and program using ICSP via the PICKIT. The tutorial here plus Hari Nair's PIC24F code helped. The most difficult thing was working out baud rate on both the RN-42 (which is set via command mode) and the PIC24F (which is dependant on the clock rate). Eventually I got it all working and was able to print 'Hello BlueFlyVario' via bluetooth to the terminal emulator.
The most painful thing with the PIC24F was when I wanted to use U2 rather than U1 as the UART port. The U2RX is on pin 5, which also happens to be used for AN3. A very poorly documented feature of the PIC24F is that if you are going to use a pin that can be used as an analogue input as a digital input (which the UART needs) then you have to set the corresponding ADxPCFG register, as by default it is set as an analogue input. In this case the call '_PCFG3=1;' was all that was required - after eight hours of pain.
Step 3 - Interfacing with the BMP 085. This was pretty easy. Hari Nair's code was very helpful for the interfacing. Instead of doing all of the calculations on the PIC I just dumping the pressure every measurement cycle to the uart.
- You might be able to see from the image that I picked up the status pin of the RN 42 (pin 21 - PIO5) via an I/O on the PIC. I programmed it so the PIC code only runs when the bluetooth is connected.
- Rather than pause for the pressure conversion I am picking up End Of Conversion from the BMP085 to measure the subsequent pressure measurement as fast as possible.
- The BMP085 breakout does not allow access to VDD Digital and VDD Analogue as separate power inputs. This means that it is not possible to shield the analogue power input from the digital switching using inductors. This meant that the RMS error of the pressure measurements was about 30% higher than the datasheet said was possible.
Another thing that is kind of important is that all of the ancillary characters that I was tempted to 'print' to the uart costs a lot of micro controller processing time. In the end I am only dumping a very short string with the pressure as an int in pascals.
At this point I thought I had cracked it, I would soon have a working vario...
Tuesday, 17 May 2011
Initial Production Concepts
My aim is to be able to produce the BlueFlyVario in low rate production for sale to other pilots at a cost of around $50 to $100 per unit (with free software). These are the steps I envisaged:
Already Complete (as of May 2011):
Already Complete (as of May 2011):
- Alpha Hardware Prototype 0.1a - Breadboad testing of core components, software development tools, interfaces, etc. (although still not with the MS5611, still using the BMP 085).
- Check SPP interfaces through a terminal emulator
- Alpha Hardware Prototype 0.2a - Integration of the 0.1a prototype components onto a prototype board.
- Java desktop software for testing the data stream.
- Java desktop vario software for in-hand waving experiments.
- Android software for field (and in flight) testing.
- Alpha Hardware Prototype 0.3a - Integration of the MS5611 onto the 0.2a prototype.
- Beta Hardware Prototype 0.4b - Designing a circuit board and case for a complete SMD solution.
- Beta Hardware Prototype 0.5b - Make around 5 to 10 prototypes for use by geeky paragliding friends for testing and feedback. These are my production prototypes I want to cost less than $50 in components (including shipping of components to me).
- Initial beta Android software release
- Low Rate Initial Production - I intend to be able to do this at home for up to around 100 devices for wider community use. I want this to cost $50 to $100 including production (less labor) and shipping to users.
- Android software release with source code etc.
 |
| BlueFlyVario logo mockup |
Component Selection - The rest
Bloody Blogger! I just spent a few hours summarising how I spent a few weeks selecting components for the prototype BlueFlyVario, describing in detail why I choose what I did, etc. The ultra nasty autosave thing in Blogger saved over everything when I accidentally selected all of the text and deleted it. I really dislike trying to replicate my thoughts so this post is now going to be only a quick summary.
Microcontroller – I chose the PIC24F16KA101. It does everything I need (UART, I2C, Digital IO, Analogue input, etc), comes in DIP and SSOP packages and is programmable in C with free compilers. I got this (less than $3) along with a PICKIT2 programmer from MicrochipDirect. Awesome speedy shipping.
BluetoothModule – I choose the Roving Networks RN42. This is going to be the most expensive component ($20) but provides a bunch of features that I like (adjustable baud rate, Bluetooth name etc, LED status output). It is well documented. If I choose to expand to making these varios for iStuff then there is an apple friendly version.
Voltage Regulator – Not sorted yet. I just used an old component I had lying around for the prototype. I will choose a SMD component in the next few weeks, probably a Microchip one (like the MCP 1702 – less than $1).
LiPo Battery – Also not sorted yet. I will get a 3.7V LiPo or LiIon battery, probably one I can get in quantity from DealExtreme (about $5 or so). About 1000 mAh should give a life of over 20 hours (the Bluetooth Module is the most power hungry component, about 40mA while transmitting). For the prototype I just used an old smart phone LiIon battery I had lying around.
Recharge Circuitry – I used the breakout from Sparkfun for the MCP73831T for the prototype. I can get this IC from MicrochipDirect for less than $1 for production prototypes.
SMD Resistors and Capacitors – I got one of those packets of 5000 resistors and 2000 capacitors in a wide range of values from ebay for less than $20. For the prototypes in the breadboard I used old components I had lying around. For low rate production prototypes the cost of the SMD components is negligible.
Circuit Board – I have not done anything on this yet. BatchPCB seems to be the standard for these kinds of projects. In volume production a double sided board with vias, etc. is likely to cost less than $1, but in the prototypes I expect it to be about $5 or so.
Case – Not chosen yet, but I know I need to prior to designing the circuit board. I reckon about $4 is about right.
LEDs , switch, usb connector, etc – I have just used old components to date. These should all be less than $3 in the production prototype.
In general I have chosen everything to be 3.3V compatible (same as the pressure sensor, meaning less power switching about.
Adding all of the above production prototype costs up (including the pressure sensor on the previous page - $15 for the MS5611) gives a total cost estimate of $55 for the production prototypes. 10% cost growth already!
Microcontroller – I chose the PIC24F16KA101. It does everything I need (UART, I2C, Digital IO, Analogue input, etc), comes in DIP and SSOP packages and is programmable in C with free compilers. I got this (less than $3) along with a PICKIT2 programmer from MicrochipDirect. Awesome speedy shipping.
BluetoothModule – I choose the Roving Networks RN42. This is going to be the most expensive component ($20) but provides a bunch of features that I like (adjustable baud rate, Bluetooth name etc, LED status output). It is well documented. If I choose to expand to making these varios for iStuff then there is an apple friendly version.
Voltage Regulator – Not sorted yet. I just used an old component I had lying around for the prototype. I will choose a SMD component in the next few weeks, probably a Microchip one (like the MCP 1702 – less than $1).
LiPo Battery – Also not sorted yet. I will get a 3.7V LiPo or LiIon battery, probably one I can get in quantity from DealExtreme (about $5 or so). About 1000 mAh should give a life of over 20 hours (the Bluetooth Module is the most power hungry component, about 40mA while transmitting). For the prototype I just used an old smart phone LiIon battery I had lying around.
Recharge Circuitry – I used the breakout from Sparkfun for the MCP73831T for the prototype. I can get this IC from MicrochipDirect for less than $1 for production prototypes.
SMD Resistors and Capacitors – I got one of those packets of 5000 resistors and 2000 capacitors in a wide range of values from ebay for less than $20. For the prototypes in the breadboard I used old components I had lying around. For low rate production prototypes the cost of the SMD components is negligible.
Circuit Board – I have not done anything on this yet. BatchPCB seems to be the standard for these kinds of projects. In volume production a double sided board with vias, etc. is likely to cost less than $1, but in the prototypes I expect it to be about $5 or so.
Case – Not chosen yet, but I know I need to prior to designing the circuit board. I reckon about $4 is about right.
LEDs , switch, usb connector, etc – I have just used old components to date. These should all be less than $3 in the production prototype.
In general I have chosen everything to be 3.3V compatible (same as the pressure sensor, meaning less power switching about.
Adding all of the above production prototype costs up (including the pressure sensor on the previous page - $15 for the MS5611) gives a total cost estimate of $55 for the production prototypes. 10% cost growth already!
 |
| Some of the components |
 |
| Shipping Detritus |
Monday, 16 May 2011
Component Selection - The pressure sensor
The key to any good vario is a ultra accurate and responsive pressure sensor. Pressure sensors come in many flavors. We want one that is designed to measure barometric air pressure. The integrated digital pressure sensors I am interested in incorporate an analogue sensor, a A/D converter, some kind of digital filter, and a digital interface. These integrated sensor modules greatly simplify measuring pressure. The procedure is pretty simple from an electronics point of view:
After a bit of googling I reckon the best pressure sensor modules to use are those from MEAS-SA (they used to be called Intersema). Other sensors from MEAS are used in leading commercial varios. In some cases I think leading vario manufactures do not use integrated modules, preferring to optimise pressure measurement rate and accuracy with their own A/D conversion and filtering. Here are some of the integrated modules: http://www.meas-spec.com/pressure-sensors/board-level-pressure-sensors/altimeter-pressure-sensor-modules.aspx. Of these, the MS5611 looks to be the perfect sensor for vario's. It is marketed by MEAS as a 'Variometer Module', although I am unsure if any paragliding varios are using it yet. It only came out in 2010. The MS5801 also looks good, but it is more expensive and it does not look to offer better performance (but it is weather proof'ish). The MS5611 is probably around $5 at 1000's quantities. Samples should be around $15 each.
The MS5611 should be able to read at about 50 to 100 times a second (depending on the other stuff done by the microcontroller) at a resolution of about 0.012 mBar (which is equivalent to about 10cm change in altitude). If I spit out pressure at 5Hz this will allow me to do some averaging and get even better resolutions. The only problem with this sensor is its availability. As far as I can determine the only way to get it is to order samples through MEAS or from their distributors. This initially posed some challenges for me, but now a few months later I have a source that should work (thanks Rob and Soph!).
When I first looked the only sensor that was easy to get with decent performance was the Bosch BMP085. This is 'widely' available, meaning a number of hobby electronics stores stock it. I got the one with a breakout board from Sparkfun (http://www.sparkfun.com/products/9694). The raw module is about $8.95, I paid a bit more for the breakout one as I knew I would be experimenting on the breadboad.
The BMP085 specs are not as good as the MS5611. I can only measure about 20 times a second, and at this rate the resolution is 0.03 mBar (equivalent to about 25 cm altitude change). Hari Nair has used it in his machines that go ping successfully so I was convinced that it would be good enough.
I looked at other sensors but both of these are in the right cost band and should have good enough performance (their is no better than the MS5611). My approach is to get the BMP 085 for my initial prototypes because it is easy to source, then try to get the MS5611 for my production prototypes and integrate it into the design later. The classic balance of risk, cost and schedule; all in my little project...
Below is a graph comparing the resolution (in meters of altitude equivalent) vs. the time it takes between pressure measurements (in pascals) of the two pressure sensors discussed. With each sensor you can select what level of oversampling you want to trade off between resolution and time. The information comes from each of the datasheets and has not been verified by me.
- Provide the sensor power.
- Interface with the sensor using I2C or SPI from a microcontroller (they all have a few pins for this)
- Get some config parameters from the sensor.
- Send commands to do a pressure conversion then read the pressure.
After a bit of googling I reckon the best pressure sensor modules to use are those from MEAS-SA (they used to be called Intersema). Other sensors from MEAS are used in leading commercial varios. In some cases I think leading vario manufactures do not use integrated modules, preferring to optimise pressure measurement rate and accuracy with their own A/D conversion and filtering. Here are some of the integrated modules: http://www.meas-spec.com/pressure-sensors/board-level-pressure-sensors/altimeter-pressure-sensor-modules.aspx. Of these, the MS5611 looks to be the perfect sensor for vario's. It is marketed by MEAS as a 'Variometer Module', although I am unsure if any paragliding varios are using it yet. It only came out in 2010. The MS5801 also looks good, but it is more expensive and it does not look to offer better performance (but it is weather proof'ish). The MS5611 is probably around $5 at 1000's quantities. Samples should be around $15 each.
The MS5611 should be able to read at about 50 to 100 times a second (depending on the other stuff done by the microcontroller) at a resolution of about 0.012 mBar (which is equivalent to about 10cm change in altitude). If I spit out pressure at 5Hz this will allow me to do some averaging and get even better resolutions. The only problem with this sensor is its availability. As far as I can determine the only way to get it is to order samples through MEAS or from their distributors. This initially posed some challenges for me, but now a few months later I have a source that should work (thanks Rob and Soph!).
When I first looked the only sensor that was easy to get with decent performance was the Bosch BMP085. This is 'widely' available, meaning a number of hobby electronics stores stock it. I got the one with a breakout board from Sparkfun (http://www.sparkfun.com/products/9694). The raw module is about $8.95, I paid a bit more for the breakout one as I knew I would be experimenting on the breadboad.
The BMP085 specs are not as good as the MS5611. I can only measure about 20 times a second, and at this rate the resolution is 0.03 mBar (equivalent to about 25 cm altitude change). Hari Nair has used it in his machines that go ping successfully so I was convinced that it would be good enough.
I looked at other sensors but both of these are in the right cost band and should have good enough performance (their is no better than the MS5611). My approach is to get the BMP 085 for my initial prototypes because it is easy to source, then try to get the MS5611 for my production prototypes and integrate it into the design later. The classic balance of risk, cost and schedule; all in my little project...
Below is a graph comparing the resolution (in meters of altitude equivalent) vs. the time it takes between pressure measurements (in pascals) of the two pressure sensors discussed. With each sensor you can select what level of oversampling you want to trade off between resolution and time. The information comes from each of the datasheets and has not been verified by me.
Friday, 13 May 2011
The BlueFlyVario concept
In order to control myself, and stop heading off on a tangent, I gave myself a limited goal. Make a working bluetooth pressure sensor prototype device that can be used with an Android app to provide basic vario functionally.
The features of the device would be:
I wanted this device and app not just for me, but for the broader flying community. This means that I planned to do the following:
The features of the device would be:
- Low cost, ideally less than $US50 in components per device for the production of ten prototypes.
- Simple electronics with the bare minimum of components:
- A digital pressure sensor module - easy to interface with a micro controller with I2C or SPI interface.
- A micro controller IC - cheap, must have free C compiler available and offer lots of ports.
- A bluetooth transmitter module that uses the Simple Port Protocol for easy access on the target device.
- Voltage regulator IC - something efficient and not electrically noisy.
- LiPo battery, ideally one from a mobile phone so it is easy to source. I want to be able to use the device for at least 20 hours without recharging.
- Recharge circuitry that allows recharge from a USB port.
- Surface mount resistors and capacitors.
- Small circuit board.
- Case, ideally starting with an existing case design
- A few LED's for indicating connection status
- One button (on/off)
- It should spit out pressure data often enough to enable an Android vario app at least as capable as commercial varios.
I wanted this device and app not just for me, but for the broader flying community. This means that I planned to do the following:
- Provide this blog, so other pilots could get their geek on.
- Make the vario software open source with something like the LGPL licence, so anyone could copy it and use it for anything. I do not intend to sell the app, it will be free.
- Make the bluetooth data stream format open so that other developers can make apps, either using my basic vario app as a reference or make their own app.
- Provide enough info so others could replicate the hardware development. However, I intend to produce the bluetooth devices in limited quantities and sell them for less than $100 each, enough to cover costs of components and production.
Tuesday, 3 May 2011
The Beginnings - Taking an idea off the shelf.
I have been flying paragliders since 1995. About a year after I started I had my first flight with a vario. The little beeps indicating lift added to all the visual indicators I had learnt to use in the year I did not have a vario. I realised the advantage of being prompted by the minute changes in pressure and purchased my Renschler SOL 3, a vario I still use today.
In 2006 I reckoned that a simple vario could be put together with a pressure sensor, bluetooth transmitter, power supply and microcontroller. I imagined that the device would transmit pressure data to a target like a PDA or Nokia mobile phone. See my post about halfway down the page on pgforum.com here: http://www.paraglidingforum.com/viewtopic.php?t=5363 (the one by Alistair Dickie - that's me). I did not do anything about it, other than lots of googling, the occasional chat with other pilots on the way up to launch, or more often that not in the bombout.
Fast forward to 2011. There was another post on pgforum about a homebuilt vario design (http://www.paraglidingforum.com/viewtopic.php?t=36799) and then another about barometric pressure sensors in Android tablets (http://www.paraglidingforum.com/viewtopic.php?t=36347). One of my too many hobbies is java programming (see alistairdickie.com for some of my older stuff). Android programming is in Java. I got my wife a new Android phone the beginning of this year so I could check it out - well, she actually needed a new phone - checking out Android was a side benefit. I discoverd that there are a few paragliding apps for Android phones. Gaggle seems to be one of the most widely used (http://www.paraglidingforum.com/viewtopic.php?t=30548), but it is missing accurate vario functionality. My interest in a bluetooth vario was rekindled.
I started googling again in earnest. Were there any other bluetooth varios available? What was the state of bluetooth transmitter modules? How about microcontrollers? Most importantly, pressure sensors? What had other experimenters done? It all looked good. I worked out that in the five years since the initial concept there had been a number of advances:
In 2006 I reckoned that a simple vario could be put together with a pressure sensor, bluetooth transmitter, power supply and microcontroller. I imagined that the device would transmit pressure data to a target like a PDA or Nokia mobile phone. See my post about halfway down the page on pgforum.com here: http://www.paraglidingforum.com/viewtopic.php?t=5363 (the one by Alistair Dickie - that's me). I did not do anything about it, other than lots of googling, the occasional chat with other pilots on the way up to launch, or more often that not in the bombout.
Fast forward to 2011. There was another post on pgforum about a homebuilt vario design (http://www.paraglidingforum.com/viewtopic.php?t=36799) and then another about barometric pressure sensors in Android tablets (http://www.paraglidingforum.com/viewtopic.php?t=36347). One of my too many hobbies is java programming (see alistairdickie.com for some of my older stuff). Android programming is in Java. I got my wife a new Android phone the beginning of this year so I could check it out - well, she actually needed a new phone - checking out Android was a side benefit. I discoverd that there are a few paragliding apps for Android phones. Gaggle seems to be one of the most widely used (http://www.paraglidingforum.com/viewtopic.php?t=30548), but it is missing accurate vario functionality. My interest in a bluetooth vario was rekindled.
I started googling again in earnest. Were there any other bluetooth varios available? What was the state of bluetooth transmitter modules? How about microcontrollers? Most importantly, pressure sensors? What had other experimenters done? It all looked good. I worked out that in the five years since the initial concept there had been a number of advances:
- A few bluetooth varios had been built. The Flymaster F1 module (working only with their PDA software), and a few home built devices from kit components were examples. However, there was nothing quite like I had envisaged.
- Bluetooth transmitter modules had come a long way, in simplicity and price. Sparkfun has a bunch.
- Microcontrollers had become easier to program (C with free tools is now the standard, I would not have to frack around with Assembly), and much cheaper (like less than $5).
- Pressure sensors suitable for varios had become much cheaper. The BMP085 available from Sparkfun had a reasonable following, but there were new ones coming out from MEAS as well. Importantly, these new sensors were cheap (less than $10 to $20) and easy to interface with from microcontroller code.
- Other experimenters had built and posted code for simple varios. I found Hari Nair's site http://pixelproc.net/ to be the most amazing resource.
Subscribe to:
Posts (Atom)