Barometric altitude measuring problems

Measuring altitude by the air pressure, especially the total amount of cumulative ascent and descent, is not as straight forward as it might seem. There are basically three types of problems involved:

1. Maters of principle

2. Problems with pressure to altitude conversion

3. Technological problems.

1. Maters of principle

This is sometimes called “The shoreline problem”. How long is a shoreline (e.g. of California)? First it may seem a simple question. But how small details you count? If you ignore all the details smaller than 10 feet you get reasonable figure. But is it really the real length? Maybe 1 inch would do (by that you get already ten times longer measure. But on what grounds would you stop there. In the end shouldn't you go to atomic level to get the real length, or even subatomic particles (then the length gets millions of times longer)?

This is pretty much what we are dealing with here. What is counted as ascent and descent? On every step you go a bit up and bit down. Should that be counted? Hardly not. In a forest path you step over humps and stones. Is that ascending and descending? How high (or long) a hump should be that you count it in? Where do you put the limit? There is no absolute answer. Yet on this decision radically depends the amount of total cumulative ascent and descent.

2. Problems with pressure to altitude conversion

The local pressure to altitude conversion is based on theoretical model of the atmosphere. A quite simple version is used in the air traffic. Pressure is directly (linearly) converted to altitude. That is not a real altitude, but it does not matter because all the airplanes of the world use the same method, so their relative altitude differences are always kept (actually in aviation language it is not called altitude but flight level: e.g. flight level 240 means 24000 feet in ideal stable standard atmosphere; incidentally FL 0 is not the current real sea level.). When landing (or departing), altimeter is calibrated so the 0 altitude corresponds to the current pressure on the ground at the airport. When flying over the mountains the margin is large enough to counter any expected atmospheric situation.

How ever that is not acceptable for mountaineering. You need to know the real altitude, and with much smaller granularity than an airplane. Here a different atmospheric model is used. It is not a stable model, it includes the current temperature. It assumes a standard vertical temperature gradient, i.e. temperature changes in a standard way by altitude. Thus the current pressure and temperature is used to calculate the altitude. Also we need to calibrate at some point the current pressure and temperature to a real altitude.

But in real world the pressure and temperature do not behave so neatly. The temperature change by altitude can be very irregular leading calculations based on only one temperature measurement giving wrong altitude. In fact in the real world the pressure by altitude does not behave that simply either. This is particularly true at a whether front. A whether front is never vertical but strongly tilted. When you are on a mountain when whether front is passing (and knowing the right altitude is more critical than ever) and above the front you will most likely get seriously off readings. And from to point of view of the ascent or descent even a small change in real altitude can be big change in the local pressure making you device to record a big change in the altitude. Also even if you move laterally the pressure is not necessarily the same. E.g. when you are by a wall (building or mountain) toward which a strong wind blows the pressure is higher than around it. If a strong wind passes your device the pressure is significantly lower than the atmospheric pressure caused by Bernoulli effect (you blow between two papers and they stick together). Sun is heating pavement or wall causing higher pressure than nearby. Etc. So your lateral movement causes your device register ascents and descents that really didn't happen.

And that's not all. Atmosphere is of course very dynamic. By the change of the whether the overall pressure changes (sometimes very rapidly especially when a front passes by). This would require recalibration. Thus the periodic automatic calibration based on the GPS altitude causing altitude measurement change and a false ascent or descent (in theory this error could be eliminated if the file format would include information that this change was due a recalibration; I don't know if this is the case). Local pressure can change very rapidly for many reasons (wind gust, passing truck etc.) even when you don't move at all. And your device will register false ascent or descent. Even your breathing or yelling changes the local pressure near your mouth and nose.

Fancy algorithms can be developed to try to filter out such disturbances but in most cases there is practically no way to separate actual change of altitude from those disturbances (and too clever algorithms would not fit into the device memory or would be far too slow anyway). Again much depends on the chosen theoretical detail granularity (see 1. above) and smoothing algorithms (more about them below).

3. Technological problems.

Anyone who has been dealing with sensors of any kind knows that their performance is far from perfect. This also true with electrical pressure sensors. The raw analogical signal coming from them looks usually more like a fence than a clean line. And for digital devices you need an AD converter, that changes the electric voltage to digital form (ones and zeros), does not perform perfectly either (especially the small and cheap ones that can be used in devices like Fenix or Ambit). Just adding together all the up changes and down changes from such data would not give any meaningful information. You definitely need some smoothing algorithm (discarding clearly false values, sliding average, wavelets, Kalman, Sp-line fitting, fourier etc.). There are actually different algorithms for real time analysis for getting accurately the current and the current cumulative situation with a minimal delay on your display while you are moving, and different ones for post analysis (where you have all the data and there is no such hurry). Post analysis is in principle (for the mathematics involved) much more accurate. Again very fancy algorithms will not fit into a small device. The PC software also for post analysis is most likely much better than the one in the device. It could well be that the device has no separate post analysis algorithm for totals but just uses the on the run accumulated data gotten by the real time algorithm. Also the algorithms might be for current data too aggressive loosing real changes, or too conservative leaving too much erroneous jumping up and down and thus giving far too small or far too big ascent and descent values. Much depends on the desired detail granularity (as described in section 1.). That can vary from device to device and from program to program. And you can easily see how the measurement time granularity effects this all. For ideal result time granularity must be in right ratio to (smoothed) individual measurement accuracy. Lower time granularity can act as an (unintended) filter (poor one though) giving (seemingly) better results. But as demonstrated that also depends on the nature of the current data (and the answer to the principle question in section 1.).

Also the very motion of your arm can cause problems. Try it: you put your arm down (start recording), put your arm up (let it be for few second) and then down again (and stop). Most likely you get total ascent and descent of about 3 feet even though you actually didn't go anywhere. Then do it ten times and you'll get 30 feet totals. How to eliminate the effect of the motion of the sensor in relation to your body. It is a semi technological problem, and very difficult one to solve (that is, if you keep the watch in your wrist as intended; now think of e.g. scratching your head while moving, avoiding branches in forest or, good heavens, rock climbing.)

Summary

It is clear that what is meant by raw (unfiltered) data is far from being well defined. What already at different stages has been done to this 'raw' data can drastically vary. And especially how the totals are calculated from this data is not necessarily at all the same in different devices or programs. And it is very very difficult to objectively define what would actually be the correct values (remember the shoreline problem). Of course if the totals are significantly smaller than the known difference between the lowest and highest point of the track then something is seriously wrong. Biking on a smooth paved road the watch in the bag should give better comparison values. It would actually be interesting to compare values with going the same route by bike (slow) and running.

All in all one must note that the cumulative ascent and descent total values are at best indicative rather than exact data. Of course there could be bugs in the devices and programs, but separating bugs and features by the actual real life measurements is not at all easy, even when the values seem to be way off or inconsistent between different devices and programs.