DIY Solder Paste Stencil - Etched soda can

Sparkfun have a great tutorial on how to use a solder stencil to make placing SMD components easier prior to using the skillet reflow method. It is awesome just how well this works. However, getting a stencil made and shipped takes time, and it is not cheap for one off prototypes. This post describes what worked very well for me. If I was going to do hundreds of boards I might use steel, but this is cheap and easy. The soda can aluminium can thickness is also about perfect to put just the right amount of paste on. Read the following like a tutorial. I assume you can do toner transfer and you know how to handle chemicals safely.

You will need: A soda can (full helps), scotchbrite scourer, toner transfer stuff (see above), Phosphoric Acid (sold as rust or aluminium cleaner from a hardware store), Hydrochloric Acid.

Step 1: Make sure you select an un-dented soda can, scour off the paint on the outside of the can until it is smooth aluminium and clean with water. This is easier when the can is full. Empty out the soda (don't drink it - that stuff will kill you!)

Step 2: Carefully cut the can to get a sheet of aluminium. Try really hard not to bend it. You want a smooth sheet. Flatten it by pulling across the edge of a table, or under a ruler smoothly. Cut out a bit about 2cm larger all around than the PCB. Use the scotchbrite again to remove the coating from the inside of the can to get to bare aluminium. You might be tempted to leave the inside on as a resist, but it will probably have micro holes in it by the time you etch. Also it is more difficult to remove after etching.

Step 3: Prepare the artwork. Ensure you come in from the edge of your pads by 4 mil all around. The etched area will be larger than your artwork, especially in fine areas. In eagle you can use the design rule setting Cream|Masks to change the tCream layer to be smaller than the pads. Export the artwork, make it negative (using MS Paint), and mirrored. The last part is important. You might think you can just flip the stencil over, but the etched hole walls are at an angle and smoothing on the paste works best if the holes are larger on the top than the bottom.

Step 4. Transfer toner like you are used to.

Step 5. To prepare for the etch mask the bottom side of the board and around the edges of the toner with clear tape. It needs to be clear so you can judge the end of the etch properly.

Step 6. Prepare the enchant. I use a 50:50 mix of Phosphoric Acid (mine is about 600g/L) and HCl (30%). The exact proportions do not matter. This etch works because the Phosphoric acid removes the oxidation, while the HCl attacks the bare metal. I dilute the etch mix with water to about half strength to slow the etch. I think diluting with methylated sprits is probably a better idea. That would help to reduce the foaming I think.

Step 7. Etch. It will start really slow, then gradually speed up as the Phosphoric Acid removes the oxide layer. Soon you will see bubbles forming and it will start to foam. Constant agitation is your friend. For me it takes about 10 minutes to etch through the thickness of the soda can. As it progresses make sure to regularly check for the end point (like every 30 seconds or so). If you etch for too long the undercut will make your paste stencil holes to big and join up. For most pads you will see that they etch faster near the edges. The trick is to stop as soon as the edge of each pad is 'cut' by the etch. Check by dunking in water and looking at the bottom with light from behind. Do not worry about the middle of each pad, the bottom tape will pull that away when it is removed.

Step 8. Remove all of the tape carefully then remove the toner with toluene or xylene.

Step 9. Dry and check. Follow the Sparkfun tutorial to do the pasting. I smooth the paste on with a razor blade. I got my paste from DealExtreme, it seems to work with fine pitch SMD components.

Below is a picture of one of my stencils. Note the fine pitch SSOP components.

Playing with PCB's

For most of the last few months of messing around with the development of the BlueFlyVario I have been playing with prototyping PCB's. Before I go on I have some important advice:

DON'T DO THIS! At one point I figured it would be a good idea to be able to produce PCB's myself for a run of about 10 to 50 prototypes. After a few months of fiddling around, trying all kinds of different methods, I have one PCB that I am happy with. Just one. I think it has cost me quite a bit to produce it. I am about 50% confident I could produce another in about two hours, but I might screw it up. In this post I am going to describe what worked for me and what didn't. The bottom line is that I recommend getting PCB's produced in a fab house. I have just ordered a batch from SeeedStudio to check them out.

Artwork

I used Eagle. It is pretty common amongst hobbyists. After a few hours I got used to the interface. Sparkfun has some good tutorials.

Substrate and Etching

I started with standard double sided 1.6mm FR4, the 1 oz copper kind. After screwing up quite a few times I now understand how important it is to prepare the surface very carefully. The method that works best for me involves using wet 400 grit sandpaper in a random fashion. This works best with a small sanding block to ensure the surface is completely flat.

I tried all kinds of methods for etch resist. Drawing using a sharpie is useful only in patching up areas where fine detail is not important. I spent some time messing with dry film negative acting photo resist (the DuPont stuff you can get in small quantities on ebay). This is used in professional fab houses and I thought would be a great idea. It comes with the promise of being able to get 6mil traces in optimised production environments. In practice I was able to get 16 mil traces, but with most boards there were always errors. The obstacles to overcome include:

• Getting the film to stick with no bubbles. This is tricker than trying to get a screen protector on with no bubbles. Just one small bubble with screw things up as the etch gets under the resist in the wrong places. Being very careful and using a pouch laminator helps a lot.
• Producing artwork thick enough. Toner on clear film worked best.
• Getting exposure right. I used a BugZapper lamp (40W I think) at 30cm for three minutes. That worked well.

I have ended up relying on toner transfer. I can now get 10mil traces and spaces with no problem. There are tutorials all over the net on how to do this. Some pointers that worked for me:

• I use a cheap HP mono laser printer. The toner seems to be heavy enough, even on ground plane pours, and it melts at the right temperature.
• I tried lots of different paper. In the end paper from an Australian Who magazine works best. The idea is to get the glossiest possible paper that is very thin and breaks down well in water. Glossiness prevents the toner getting too intertwined with the paper fibres, thinness ensures the heat and pressure gets through the paper to remelt the toner, and being easily dissolvable in water helps the paper come away.
• I used a cheap A4 pouch laminator. It takes 4 to 12 passes to get the board hot enough to melt the toner. It is all about the right temperature, not the number of passes. If you do one pass, then wait until the board cools down, you need to start again. It is also important to ensure the paper does not move around. The best method I found was to ensure the paper was a little smaller than the board (so it does not hang over the side and get stretched in funny ways, attaching only one side with a piece of tape (the side fed into the laminator first).
• To release the magazine paper it just needs a few minutes soaking in warm water, then very carefully pealing off the paper. Some will stick to the toner which is stuck to the board. I used light rubbing with my thumb under water to carefully remove the paper from between fine SSOP pads. If any toner comes off the fine bits you will need to start again. If the board is too dirty or too smooth the toner will not stick. This is tricky to get right.

This bit is dangerous if you do not know what you are doing. I use an etch consisting of one part HCl at 30% strength (Mutaric acid or Hydrochloric Acid from the hardware store) and two parts 3% H2O2 (Hydrogen Peroxide from the chemist). Constant agitation should see the exposed copper come off in a few minutes.
 

To remove the toner I use toluene/xylene based paint thinners. Any strong non-polar aprotic solvent will work better than acetone, which for some strange reason seems to be the standard.

Holes and vias

I thought it might be a good idea to have a crack at through hole plating the vias. This in theory involves drilling holes prior to etching, and some electrochemistry. I failed at the hole wall activation stage, mostly because I could not source a fine enough graphite powder without forking out a wad of cash and waiting weeks for delivery. I figured a really good hole wall activation mix would be toluene, graphite powder, and polystyrene. Polystyrene dissolves in toluene well, the resulting mix is not very viscous and flows well into the holes, it also allows a fine suspension of graphite powder to be maintained. Once dry, a very thin film of polystyrene holds the graphite in place. It further smooths if heated and forms a thin film of very conductive polymer, provided the graphite powder is thin enough. I gave up once I worked out that wire is good enough.

Quality fine PCB drill bits can be got on ebay for about $1 each. My solution for working diy vias involves drilling with a 20mil bit (after etching). I make the via pads 70mil in diameter which helps to ensure that even the two copper sides are not perfectly aligned, then it might still be ok. I then put a small copper wire through the hole (I use single core wire from stripped down CAT 5 cable - it is just about the perfect size). I make the wire flush on top, but with about 0.2 to 0.4 mm of protrusion on the bottom side which is stamped flat with a modified hole punch prior to a small flat dab of solder on the bottom side only. After SMD components are in place I then put a dab of solder on top.

BlueFlyVario Android App

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.

Latency and Timing

My experience with latency and timing is worth a blog post. I have now have a working Android app with acceptable timing issues, but not without some pain. The alpha Android app will be described in my next blog post. A few days ago a friend asked me about the project (alight - I offered an explanation). Her immediate question surrounded the latency and what issues I was having. Was the latency acceptable?

Latency

I am going to start by describing the complex pipeline that starts with air pressure, and ends with the Android device displaying something on the screen and going beep.

1. The air pressure and temperature exists at a point in time around the device. Below is a very close up picture of the MS5611 without the protective cap. This is one that I broke. On the left is the actual sensor, the right is the microprocessor circuitry that is part of the sensor. A particular air pressure does something funky to micro diaphragms in the MS5611. I am not quite sure what micro devices bend, or change resistance or capacitance or whatever, but what does happen is that the sensor part of the MS5611 is virtually instantaneously put into a particular state. (I am guessing in pico or nano seconds). 

2. The PIC Micro-controller (operating at 8 MHz) goes through the loop of:

• 2a. Triggering a temperature sample on the MS5611.
• 2b. Waiting up to about 9ms for the temperature to be measured internally in the MS5611's microprocessor 4096 times and averaged (at least I think it is averaged and not some other algorithm). It is possible to select a lower oversampling rate and hence be quicker, but the trade off is accuracy. I think it makes more sense to allow that math to be done in the MS5611 microprocessor rather than do it on the PIC.
• 2c. Then reading the temperature (negligible)
• 2d. Then triggering a pressure sample (negligible)
• 2e. Waiting about 9ms again for the MS5611 to do a 4096 oversample of pressure reading for reading.
• 2f. Then reading the pressure (negligible)
• 2g. Then triggering a temperature sample (negligible)
• 2h. Then calculating the pressure from the read temperature and pressure. To do this also takes bunch of  calibration constants which are read from the MS5611 at startup (negligible on the 8Mhz PIC)
• 2i. Then formatting and sending the pressure characters to the RN42 bluetooth module over UART. I thought that this process would not take much time, but for some time I was using the microchip c++ function sprintf. This is really expensive on the PIC and took heaps of time so I changed to just pushing a sequence of chars to the UART (for those like 'P', 'R' and 'S') and doing a custom int (32 byte unsigned) to char sequence conversion for the pressure (representing the Hex value of the right five nibbles of the 4 byte calculated pressure). This was much quicker, but it still takes time as the PIC to RN42 bluetooth module connection is working at 58k. I guess that this whole print characters thing happens in a few ms. What is important is that I am pretty sure it happens in less than time it takes for the temp measurement on the MS5611. So when we loop back to reading the temperature from the device we will not be waiting for much of the rest of the 9ms.
• 2j. Then looping back to 2b (I already trigged the temperature at 2g).

In total this takes just less then 20ms. I was able to get it to less than 19 ms (or about 52 Hz) with some tweeking. For reasons described below I slowed this loop down to exactly 20ms. Note that it is about 13 ms from the time of the pressure measurement 2f, to the time it is sent to the RN42 (2i).

3. The RN42 (when established in a bluetooth SPP connection with the Android device), does its thing in some mysterious way. There is this 'bluetooth stack' thing that each character needs to go through, then over the air via the 2.4GHz bluetooth signal, then back through the bluetooth stack on Android. I am not sure how long that takes. From others tests I am guessing about 20 ms. I might do some more tests on this in the future. [probably not – it seems to work ok]

4. The characters then pop out of the bluetooth stack on Android and are read by the Java application code. Here is where things get really unpredictable. I measured the interval between pressure measurements on Android (using System.nanotime(), which I don't really trust but there is nothing better). I found the time intervals to be very erratic. Overall the average time interval is 20ms after I changed it to 50Hz. All pressure measurements are getting through. What I am pretty sure is going on is that the Android threading means that other things, like all that stuff you have going on the background of your PC right now, takes up processor time. At GHz clock speeds the Android device eventually gets around to measuring the data from the bluetooth input stream, sometimes reading a few measurements in a row with less than 1ms in between. My guess is that the average latency here is about 10ms.

5. The vario averaging then adds quite a lot of latency depending on the degree of averaging (damping). With a damping factor of 0.05 at 50Hz it takes about 860ms to reflect 90% of a change. But that is not the latency I am really concerned about. I am more concerned about the latency in 1, 2, 3 and 4.

In total, my guess was that pressure change to pressure available to Java on android latency is about 13 + 20 + 10 ms. So less than 50ms. This should be barely perceptible providing the App can display visually and using audio quickly enough (that story is for the next post).

Timing

Initially I tried spitting out the pressure as quickly as possible from Bluetooth device. I planned to measure the time of the ‘read’ and use this time for the integration of a window of a bunch of pressure measurements. The inconsistency of timing of ‘reads’ of this measurement from Android meant that I was getting screwy results. I tried averaging the pressure time reads, but this was confounded by the few initial measurements that happened at startup. Initialising the vario values worked, but as I tweaked the code on the microchip the pressure intervals would change slightly, screwing up the initialisation.  At the same time I was coding up the display on the android device and it was tricky to relate windows of time to the number of measurements.

The solution to all my timing problems was simple. I implemented a timing loop on the PIC using an interrupt to execute a pressure read and send every 20 ms exactly (50 Hz). The android device just needs to make the same assumption that the pressure measurements are 50 Hz apart, which I now do. Everything with timing is mostly good.

I assume that the internal clock is running exactly at 8MHz. In practice the FRC clock on the PIC is up to 1% or 2% inaccurate. At a particular temperature and operating voltage the clock should be pretty much constant. At 3.0V and 25 degrees Celsius it is most accurate. In practice I do not think that this error is going to matter much. If the vario says 5m/s up when it is really 4.9 m/s I am not sure anyone will care. At some point in the future I could add a crystal to the device to fix this up. Or alternately implement some code on Android to properly measure pressure intervals and add a correction factor. At this stage I am going to do neither.

The MS5611 - a resounding success

I got a few MS5611 samples through a friend in Europe to integrate onto the BlueFlyVario prototype just before I went away a year ago. My initial attempts at soldering on some legs and making dodgy breakout boards failed. I ruined at least one of the samples by melting the protective plastic case. During my time away more people started to use the sensor and I managed to get a few breakout boards from ebay.

To solder the MS5611 onto the PCB breakout board I first put a few very small dabs of solder on the PCB SMD pads. This is easily achieved by first using liquid flux on the pads, then loading up the tip of a standard soldering iron with a lump of molten solder, then just finely touching the molten lump to the pad. The idea is to get a small bit of solder on each pad (with the same amount on each pad!) Next I cleaned the contacts on the MS5611 with flux and wiped it all off - the idea is to remove the oxidation layer. Then I took the PCB and put in on an electric frying pan (skillet). As soon as the pan warmed enough to see the solder melt I put the MS5611 into place with a pair of tweezers. The surface tension from the molten solder held the component in place with a little wiggle of the board. As soon as it was cool I found that I had a perfect SMD solder joint.

I put the associated other components on the breakout board, really only a capacitor and headers, then tested them with the prototype. I had to remove the BMP085 and all of the associated circuitry, then put the breakout board in place. I used the SPI interface functionality rather than I2C as the datasheet said I could expect better noise performance (hence, lower error). It took me a few hours to get everything up and working again. I had to remember how to properly configure the PIC programmer and desktop prototype app. Modifying the PIC 24F code to do SPI ended up being pretty easy, there were a few examples on the net. The first time I properly compiled the program and ran it I got a huge shock, it was working with good, not too noisy, pressure data coming out. I lifted up the prototype vario and my computer went beep.

Some fiddling with the desktop app allowed me to see the altitude graphically and I added in a RMS error to debug the noise. Initially I was getting about 25cm RMS noise with about 50 samples per second. The 50 samples per second actually measures the both the pressure and temperature 50 times a second, then outputs the pressure only. It should be possible to measure the temperature only about 10 times per second, using each temp measurement for about 9 pressure measurements. That would give us about 90Hz for the pressure measurements. I am not sure we need that much...

The prototype was pretty sensitive and it was defiantly an improvement over the BMP085, but I was not happy yet. I added a RF Choke on the V IN line of the MS5611 and the noise went down to about 15cm, although sometimes it floats up if I touch the wrong component on the prototype. I am not sure what the value of the RF Choke is, it was just one that I grabbed from the workbench. The source of the noise could be the linear voltage regulator, the Bluetooth transmitter, or the switching of the PIC microcontroller. It does not really matter, what does matter is that the the noise suppression works really well. I have ordered some ferrite beads for the next prototype. I should get even better noise performance if I filter out noise from the ground plane as well. I don't have an oscilloscope so I can't actually measure what frequencies I am trying to filter and perfectly match the ferrite bead to it. If only I was rich.

Below is a short video of the vario in hand with the prototype desktop app overlayed on it. Note the white altitude display with the vario data (damped) on top of it.

The settings are:
altDamp=0.05 (i.e. 5% of each new measurement is added to the 'current' measurement - see the previous post about the IIR filter to understand what this means)
varioDamp=0.3
varioWindow=50 (about 1 second at the 50 Hz I am measuring at)
vario2Damp=0.05
vario2Window=100 (about 2 seconds)

Next steps:
- Order components for the next round of prototypes (done). I am going to make a couple, with pretty much all SMD components.
- Order PCB prototyping stuff.
- Prepare Eagle circuit diagram and PCB artwork.
- Develop prototype Android app.

Stay tuned, I am back on track. I aim to have a few working SMD prototypes and the prototype Android app by the end of July. Circuit diagrams and code are coming.

A year of developments

After returning home from almost a year away on a work assignment I now have a little time to continue with my BlueFlyVario project. I have had a lot of success, but that is for the next post. In this post I will provide an update of what has changed over the past year. The bottom line is that the concept I first had some years ago, then started developing in earnest about 18 months ago, remains a worthwhile pursuit.

There has been a little movement in the availability and price of some of my chosen components. The RN42 Bluetooth module has come down in price a little, it is still the cheapest one available and now appears to be more widely used. Microchip has recently bought Roving Networks so I expect that their marketing might will make it even more available in a few months time. The Microchip PIC's are cheaper, as are the batteries and most of the passive components.

The MS5611, the key pressure sensor module I selected, has been used by a range of hobbyists. The Arduino microcopter folks have successfully integrated it. The module is now available in hobby quantities on at least a few specialist websites (http://www.drotek.fr/shop/en/43-ms5611-pressure-barometric-sensor.html for example). You can also get the sensors on breakout boards on ebay occasionally. I got my hands on a few samples from a friend, and ordered got some breakout boards from ebay while I was away. Moreover, there is at least one commercial vario using the MS5611, the Flytepark microvario (http://flytepark.com/Store/Microvario). This is the culmination of Hari Nair's work and I once more congratulate him, not only for this vario, but his ongoing commitment to share his work with an open design.

I am not the only one looking at a bluetooth vario and over the past year others have got similar products to market and further discussed them on forums. The FlyNet vario is one example of something very similar to what I want to build (https://www.asinstrument.ch/pages/home). It is more expensive than I am targeting (over $200) and it seems like the application and design are not open. However, the interface protocol is. I am considering using the same interface protocol as it is very similar to what I am currently using. For me to change will only take a few lines of code. I would add semi regular (once every few seconds) temperature updates, but I am less keen to allow users to change the device name.

Android, the target platform, has continued to get stronger and there are now a wider range of much more capable devices. Importantly, it is easy to pick up a cheap second hand 'old' android phone that should work really well as a front end for the vario. A few recent Android devices now have integrated pressure sensors, but I am unsure if it is possible right now to use these sensors as the basis of a sensitive vario. I think not from my initial research. The sensors are either not sensitive enough (like 30 cm RMS at best) and in many cases the operating system will not return measurements faster than a few Hz. I am aiming for 10cm RMS measurements at 50Hz. There is a discussion about this on pgforum.

Based on all of that I recommenced the hardware prototype development with the aim of integrating the MS5611...

Development on Hold

I have to go away for a few months for work. Development will be on hold until 2012...