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.