This is a short account of our first attempt at building a lightweight variometer that could transmit a reliable real-time climb/sink feedback signal to aid in RC thermal soaring.

The variometer described is based on the VTI SCP1000 D01 pressure sensor (now discontinued) and the "Pro Mini" Arduino board (8MHz, 3.3V), both sold by Sparkfun.

The prototype version relies on a piezo transducer to produce the audio signals in situ (pictured below). The beeps are then simply picked up by the microphone of an onboard PMR unit (446 MHz walkie-talkie) and monitored from a corresponding unit carried by the pilot on the ground.

A later and lighter version uses a regular radio link to digitally transmit the signal values, and the audible beeps only then generated after reception on the ground.

---

Hardware layout

In order to make the finished vario as physically compact as possible a custom "shield" was crafted. This sits between the Pro Mini board and the SCP1000 breakout board. In the picture below the Pro Mini's engaged pins are designated by blue letters while the pinout of the sensor's BOB are shown in red.

 The empty shield is tested for size. Mounted like this (with the soldering side up) the components fit exactly in between the headers! No space wasted here!

I generally like to house my projects in old-school cigar boxes, rather than bland plastic or tin cabinets. This little gadget measures only 34x19x14mm, though, so a box for very small cigars was called for!

---

The software

Our variometer specific algorithm involves a couple of smoothing steps to filter out most of the signal noise, combined with an anti-hysteresis routine intended to provide a reasonable responsiveness and minimise output "stiction". The latest sketch version can be dowloaded here: Vario_SCP1000_mx07.pde.

---

Pressure chamber testing

In order to develop the software and also for testing the hardware in the lab, a simple pressure chamber was assembled from "household" parts: 

• A robust plastic food container (1.6 litre) with a very airtight snap-on lid.
• A plastic 5 ml syringe (without the steel needle) mounted in a rubber grommet through the lid.
• Cables (USB and serial) also passing though hermetical seals.

    

With the µC connected to the breadboard and the sensor placed in the chamber it was easy to simulate quick changes in local air-pressure by manipulating the syringe plunger, while monitoring the response characteristics revealed by the streaming output to the serial computer connection. Unfortunately, the sensor element is sensitive to light (as well as air pressure). This easily introduces confusing errors, so it is essential to keep the sensor in darkness, or at least in a very steady light, while measuring. My black cycling shorts did good service...

Below is a graphical analysis of a typical test run, lasting about six seconds. The graph corresponding to the vario signal's magnitude (i.e. the climb-rate) is coloured red, while the smoothed altitude (taken as the inverted air-pressure) is indicated by the green graph. The vario signal values are scaled up by a factor of 30 to exagerate the fluctuations and the Y-axis markings does not apply to this curve. (Click picture to enlarge.)

---

Pseudo field testing

After much laborious testing and tweaking (basically waiving the sensor up and down all night until exhausting both biceps and enthusiasm), we were eager to observe the vario's response under more challenging conditions by taking it for a ride in the fastest elevator to be found in the vicinity. The 32-story office building "Kista Tower" has elevators with a velocity that approaches 6 meters per second, reaching the top floor in about the same time an ordinary  elevator climbs  just five stairs.

Despite the surging accelerations and retardations, enough to make you seasick soon, the recorded vario-graph from this test session -- first going down 28 stories, then up again in spirts of 2 to 5 stories -- looks "clean" enough, with moderate lag, none-to-minimal overshoot and no discernable oscillations as such. And the beeper sang its staccato tune in falsetto all the while!

As in the previous graph the legend is: Blue line = "Cropped Raw Pressure Measurement", Green line =  Ditto smoothed, Red line = Vario output signal.

Even more interesting, perhaps, is to compare the above with a similar graph recorded in the significantly slower type of elevator of a local 16-story condominium estate. This elevator has a nominal speed of 1.1 m/s, and the session involved two consequtive "roundtrips" between stories 7 and 16, the second time around ascending in three "steps". 

Even at a cursory glance, this graph reveals a response pattern with certain undesired traits, emphasizing output quirks already detected in previous "desktop" testing. 

More precisely, the very effective smoothing of the signal, which is visible whenever the sensor is sitting still (more or less) at a stable altitude, and which is achieved in code mostly through an input signal constrainment routine, is all but lost as soon as there is a significant transition to a new elevation, i.e. the rate of pressure change is large enough. This immediately results in ungainly fluctuations, as shown by the jagged curve in the graph. The beeper tone then becomes noticeably wobbly too, of course.

This certainly won't do! Back to the old keyboard...

It appeared that the problem basically lay with the "anti-stiction" routine and the naive on/off way this was implemented. A new variable ("trendSet") for the purpose of tracking the apparent trend, that is the "long term" vertical velocity and its direction/sign, was introduced. This is then factored in to set a trend-following value (the "fleeting_state" variable) which is an approximation of the anticipated next mean value (assuming a smooth pressure curve). This value, in turn, becomes the new centre or "neutral value" of the constrainment span determined by the constant "slack". The end result, presumably, should be a more consistent suppression of sensor noise in all the expected variometric states (rising, sinking or keeping elevation).

And it worked! Examining the last graph below, which shows the output from a repeat of the session above, but using the revised code (version mx07), it is clear to see that the excessive noise exhibited earlier when climbing or sinking is indeed gone.

Comments

Resources