It’s new project time, and I’ve decided to try my hand at building a data logger/grapher/analyzer for long-distance hikers. In August I’ll be hiking the John Muir Trail, a 211 mile wilderness trail through remote parts of California’s Sierra Nevada mountains. My goal is to build a small battery-powered device that measures altitude, temperature, and other data, and take it with me on the trip. Sure, I could probably buy a commercial unit that does all this and more, but where’s the fun in that?


This project will be a first for me in several ways. It will be my first project intended for practical use instead of simply being an interesting gizmo, so design considerations like size, weight, and reliability will be important. It will also be my first portable battery-based project, and first 3.3v project. Most importantly, it will be my first low-power project, where designing for the lowest possible current draw will be of central importance.

Overview – The plan is to collect periodic pressure and temperature samples, and use them to calculate useful data displayed on an LCD, like a beefed-up version of an altimeter wristwatch. When calibrated, the current air pressure can be used to determine elevation above sea level. Combining pressure, elevation, temperature, time of day, and possibly other data like moving time and distance traveled will provide endless options for graphing and analyzing the data for hiking geeks.

Some of the features I imagine are:

• current temperature display
• high/low daily temperature
• graph of temperature over time
• current altitude display
• graph of altitude over time
• rate of ascent/descent display
• estimated time remaining to reach a specified goal elevation
• total ascent/descent distance
• current air pressure at sea level display
• weather forecast
• storm warning alarm (rapidly dropping air pressure)
• clock/stopwatch/timer/alarm
• battery voltage display, estimated remaining battery life
• day trip/movement timer*
• total accumulated trip/movement timer*
• graph of moving vs stopped periods over time*
• step counter/pedometer**
• estimated distance traveled display**
• estimated current speed display**
• day trip average speed display**
• graph of distance traveled over time**
• estimated time remaining to reach a specified goal trip distance**
• graph of speed over time**
• inclinometer**

* requires a shake/motion sensor to detect when you’re walking vs standing still
** requires an accelerometer and some questionable software methods

The core of the hike logger design is a graphical LCD display, air temperature/pressure sensor, and a microcontroller. To ease construction, I’ll be using break-out boards for all the SMD parts, and mounting the break-outs onto a main board containing the microcontroller and miscellaneous hardware.

84×48 monochrome graphical LCD – SparkFun sells these inexspensive Nokia 5110 displays. The break-out board is 4.5 cm square. These displays operate on a 2.7 to 3.3v supply, use an SPI interface for communication with the microcontroller, and draw about 240 microamps when active and 1.5 microamps when powered-down.


Bosch BMP085 digital pressure sensor – These micro sensors measure both air pressure and temperature. The SparkFun break-out board is a paltry 1.5 cm square. The sensors operate on a 1.8 to 3.6v supply, use I2C for communication with the microcontroller, and draw about 5 microamps when sampling at 1 Hz or 0.1 microamps when on standby. Temperature accuracy is +/- 0.5 degree C, and pressure accuracy is +/- 1 hPa, which translates to an altitude accuracy of about 30 feet.


ATmega328 microcontroller – This 8-bit microcontroller is the same one used in the Arduino. It features SPI and I2C interfaces, 32K program memory, 2K RAM, 1K EEPROM, and operates on a 1.8 to 5.5v supply. At 1 MHz, it draws 300 microamps when active, 40 microamps when idle, and 0.9 microamps in power-save mode.

CR2032 3V coin cell – These tiny batteries hold 220 mAh of juice, and have a maximum discharge current of about 3 mA. 3 mA! That’s not even enough to light a single LED. It’s possible to exceed 3 mA (these batteries are popular in LED throwies), but battery life will be severely degraded.


Power Budget – My goal is for the hike logger to run for at least 4 weeks on a single CR2032. That’s 672 hours of run time, with a 220 mAh battery, so the average current draw can’t exceed about 330 microamps. That looks achievable, assuming the display powers off after a minute of activity, the sample rate is low, and the microcontroller sleeps between samples. In fact, the logger should only draw about 3 microamps when sleeping! Even when it’s active and busy, the current draw should still be less than 1 mA. So the battery life goal looks within reach, as long as I’m careful to avoid parasitic currents in pull-up resistors and similar locations, and I avoid the temptation to add more power-hungry goodies to the design.

Data Retention – The simplest logging mechanism requires 3 bytes per sample – 1 for temperature and 2 for altitude. Using the 1K EEPROM on the microcontroller, that’s space for 341 samples. If I also used the 2K RAM for additional sample storage, that would provide a total space for 1024 samples. That’s 17 hours of data with a 1-minute sampling interval, which is more than enough for this application. With a 5-minute sampling interval, it would provide space for 85 hours or 3.5 days of sample data. Run-length compression or other techniques could probably squeeze more samples into memory. To fit the entire 3 week trip, a small I2C EEPROM could be added.

Physical Design – The whole package will be about 4.5 x 6 x 1 cm, and weigh a few ounces. Designing the device for real-world use presents some challenges. Carrying a naked PCB on a lanyard or inside my backpack doesn’t seem like a good plan. It could get wet, it could short against another object, it could get crushed. A case must protect it from the environment, while not enclosing it so completely that temperature or pressure measurements are affected. The case must also be small and lightweight. I haven’t yet had any great case design ideas, so I may just hang the naked PCB off my backpack and hope for the best.

Jiggle Sensor – One feature-extension idea I may explore is using some kind of jiggle sensor to detect when the device is in motion, and when it’s stationary. This would enable automated recording of the start and end times for each day’s hike, as well as the length of any rest stops along the way. It might be interesting to know that I’d spent only 5 hours actually hiking one day, although it took 8 hours from one camp site to the next. Just how long are those lunch breaks? Graphing this data for a period of several days might be interesting as well. And knowing the distance of each day’s hike from the map, the average speed could be calculated from the travel time. Of course a sensor isn’t really needed for this– I could manually note the start and stop times of the hike, or press a button to mark them, but doing it automatically is much nicer.

I considered a few different ways to detect walking-jiggle motion, but there may be better ones. Any suggestions? One approach would be to use a pair of mechanical tilt switches, mounted at right angles to each other. When at rest, both switches remain in fixed states, open or closed. When moving, the walking motion would probably provide enough vibration to make one of both switches bounce open and closed. This could be detected by the microcontroller and interpreted as a walking signal. The drawback is that tilt sensors aren’t really intended for this, and depending on the orientation of the device in my pocket or bag, the switches might not vibrate reliably open/closed during walking.

An alternative jiggle detector idea is to use a piezo element with a mass on it. These are typically used to detect knocking or tapping motions on a device. This might work, but they seem geared towards detecting hard, high-frequency vibrations, not the slow 1 Hz or so oscillations of walking. Especially if the device is inside a backpack, the motion of walking might not create enough vibration to be detected.

The most promising jiggle detector looks like the SQ-SEN-200 omnidirectional tilt/vibration sensor. It’s a normally closed switch, regardless of its orientation, but when moved the switch chatters open and closed. The drawback with these is that they’re only available directly from the manufacturer, with a $100 minimum order.

Accelerometer – A second feature-extension idea is the addition of an accelerometer. This would immediately solve the jiggle sensor problem, and open up a range of new possibilities. By holding the device to my eye and sighting along the edge to the top of a ridge or peak, it could be used as an inclinometer to calculate the slope angle. With some software analysis of the accelerometer data, it might be possible to detect individual steps when walking, enabling step-counting and stride rate features. I’m not sure it would be possible to extract steps from the acceleration data reliably, but if it is, an Analog Devices accelerometer tech note describes how it can be used to make fairly good estimates of stide length, distance traveled, and movement speed. This opens up all kinds of interesting new feature possibilities.

I’ve been looking at the Analog Devices ADXL345 accelerometer. It has a digital I2C interface, low power requirements (40 to 140 microamps, depending on sample rate), and a sample FIFO that lets the microcontroller read samples less often than the actual sampling rate. Another popular option is the ADXL335, which has an analog interface and draws about 350 microamps. Unfortunately all the accelerometer options are tiny little SMD devices that would be difficult to hand-solder, and break-out boards add more bulk and expense. SparkFun sells a 2.1 x 1.6 cm break-out for the ADXL345 for $28.

Let’s Go! – The basic parts needed are in the mail, and I’m beginning the circuit and software design now. I hope to have a breadboard prototype of the basic features ready for demo in about a week. The results will determine where this project goes next.