Maximum Altitude

12 views
Skip to first unread message

Derek

unread,
Nov 29, 2011, 7:38:24 AM11/29/11
to Backwoods Logger development discussion
Hello,

I do high altitude mountain climbing and will be ascending to 5895
meters (19,340 ft) in December. I'd love to log this climb, but the
homepage states that the maximum altitude is 4500 meters. I looked up
the sensor and its rated to 9000 meters. Is this a software issue or
does it actually work to the higher altitude?

From http://code.google.com/p/backwoods-logger/
"Altitude (calculated from air pressure) measurements in 2 ft steps,
from -1384 ft to 14999 ft (-300 to 4500 meters)"

From http://www.bosch-sensortec.com/content/language1/downloads/BST-BMP085-DS000-05.pdf
"Pressure range: 300...1100hPa (+9000m ... -500m above sea level)"

Many thanks!
Derek

Steve Chamberlin

unread,
Nov 29, 2011, 10:18:20 AM11/29/11
to backwoods-lo...@googlegroups.com
Hi Derek,

Good question. That's a software issue-- 14999 feet was chosen because it covers all the mountains in the continental United States. There's a total of 4 bytes (32 bits) for each sample, which are allocated 13 bits to altitude, 11 to pressure, 8 to temperature. You could double the altitude range with a small code change, but you'd have to decrease the resolution (4 ft steps instead of 2 ft steps), or steal a resolution bit from the temperature or pressure scales.

Does that make sense?

Steve

Derek Kozel

unread,
Nov 29, 2011, 11:13:39 AM11/29/11
to backwoods-lo...@googlegroups.com
Thanks Steve,

I'll take a look at the code tonight and see if it can be altered to
work for me. Altitude is a derived quantity from temperature and
pressure right? So if the limiting factor is storing the data it could
be recalculated on demand and use the free'd space to store greater
resolution data on the other two fields. For now though I think
decreasing the resolution is a reasonable fast fix for my problem.

Derek

Steve Chamberlin

unread,
Nov 29, 2011, 12:33:18 PM11/29/11
to backwoods-lo...@googlegroups.com
Recalculating altitude on demand is an interesting idea! The current altitude calculation is done using a 32-bit pressure value and 16-bit temperature value, before any of the data is quantized for storage. If you later recalculated altitude from the quantized pressure and temperature data, you'd have a less accurate altitude result, but it might still be good enough. Especially since, as you mentioned, you could use the 13 bits currently devoted to altitude to store more accurate pressure and temperature data instead. This might require some substantial rework of the code, but the results could be worth it.

One possible hurdle is that the formula for calculating altitude from pressure and temperature is fairly complex, and involves the exp() function. It's not a big deal when you're only doing it once a minute when a sample is taken, but if it had to be calculated on the fly 128 times in order to draw a graph, it might be noticeably slow and make the user interface chug. Or it might be fine.

I'd say it's definitely worth investigating further.

Steve

Steve Chamberlin

unread,
Nov 29, 2011, 1:49:11 PM11/29/11
to backwoods-lo...@googlegroups.com
I just had a brief look at this, and it looks like it should work. The "32 bit" pressure value returned from the sensor is actually only 19 bits, so there are just 35 total bits of raw data needed to store full-resolution pressure+temperature measurements. Truncating that, or lopping off parts of the high and low range, should make it possible to fit into 32 bits with better resolution than the current method. This would mean you'd not only get altitude readings to the summit of Everest, but the pressure and temperature graphs would be higher resolution than they are now, all without increasing the storage requirements.

Steve

EBo

unread,
Nov 29, 2011, 11:46:01 PM11/29/11
to backwoods-lo...@googlegroups.com
I started a reply earlier today going through a quick
back-of-the-envelope calculation on this. At 2 ft resolution over the
full range of the instrument you only need 15 bits, so you can scale and
play a few games and pack it in better as Steve suggests.

If we are seriously discussing reworking that section of the code is it
possible to have options to either get maximum precision of the devices
(which I could actually use with the work I want to play with) and a
full range option? Derek's original problem really only uses 1/2 of the
device range, while someone else might want to put the logger in an
areal UAV and fly it 25,00+ ft. Do I hear 100,000 ft weather baloon
launches anyone???

EBo --

Reply all
Reply to author
Forward
0 new messages