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.
