Hooray, the v1 Backcountry Logger boards have arrived from the PCB manufacturer! This time I used Dorkbot PDX, and the elapsed time from the ordering cutoff date to board delivery was only 12 calendar days. For $5 per square inch, with three copies of your board, and free shipping in the USA, I call that a pretty good deal.


The boards have dark purple soldermask, with gold plating. The quality looks good. When I received them, the boards originally had several small tabs around the edges from the panelization process. These were easily broken off with a pair of pliers, but you can still see some slight rough spots on the edges where the tabs were.

Before I even begin to stuff the board with components, let’s count all the mistakes I already see. You can’t learn without making mistakes, and I sure made a few here.

• silkscreen layers– I delivered an Eagle .brd file for manufacturing, and I thought the silkscreen would include only the contents of Eagle’s tPlace layer. Instead, both the tPlace and tNames layers appear on the silkscreen, which results in a lot of unintended and overlapping silkscreen labels. Next time I’ll deliver individual Gerber files instead of the .brd file, so I can be sure what it will look like.
• silkscreen on pads – You can’t just run silkscreen text right across the pads… what was I thinking? Wherever text overlaps a pad, the text disappears. This makes the text on the bottom side with my name and date very difficult to read..
• text proofreading – The date text says “May 21, 2111”. It’s from the future!
• no ground plane – I forgot to include a ground plane. Fortunately with this simple, low-speed design it’s probably OK without one, but its omission was not intentional.
• untented vias – I meant to tent the vias (cover them with soldermask), but I forgot. With tented vias, they wouldn’t stand out so much, and text running on top of vias would be much more legible.
• narrow pad holes – Some of the pads have what appear to be very narrow holes. It’s tough to see in the photo, but the holes for the ATmega and the capacitors are substantially narrower than all the others. Of course the hole sizes comes from the part footprints, which I just took from the Eagle library, but it’s my fault for not checking them. I did a quick test fit, and I think everything will still be OK with the narrow holes, but it’s tight.
• insufficient part clearance – I kind of assumed that parts would exactly match their outlines in the library, but a few are bigger. The battery holder in particular is a bit bigger than its outline, enough so that it partly blocks the power jumper (right-center), and bypass capacitor next to the ATmega.
• mounting holes too big – The four mounting holes in the corners are bigger and closer to the edges than I intended. The footprint for the hole is two concentric circles, and I’d thought the inner circle was the hole itself and the outer circle was the screw head for the matching screw. Instead, the outer circle is the hole itself, and I don’t know what the inner circle is.
• soldermask on pads – The two resistors both have soldermask covering their top-side pads. If you look closely, you can see that the 1K resistor at top-right, and 510 Ohm resistor at the bottom-middle don’t have visible pads. They’re there, but covered. Fortunately the bottom side of the pads aren’t covered, and that’s the solder side, so it’s OK. I checked Eagle, and this is how the Sparkfun axial PTH resistor footprint is designed, so it’s intentional. I can’t imagine why though– it seems like a bad idea.

Now it’s time to put this thing together. Soldering iron, here we go!

Shrinking a design as far as possible can be an addictive hobby. Even though PCBs for the first backcountry logger design aren’t yet back from the board house, I’ve been busy working on a revised version that’s just 1.9 x 1.1 inches (49 x 28 mm). That’s about the size of 3 AAA batteries laid side-by-side. It’s small!

If you’re just tuning in, the backcountry logger concept is a portable ATmega-powered device that collects temperature, air pressure, and altitude data, and shows graphs on a built-in LCD screen. It’s intended for hikers, climbers, and other outdoorsy folks who want to know if it was colder last night than three nights ago, whether the ridge they’re on is the 10200′ or 10600′ one from the map, or whether a storm is likely soon. Much attention has been giving to minimizing power consumption, so the battery should last many months.

Here’s the original logger design. It’s 2.75 x 1.8 inches, and uses all through-hole parts. The LCD is a Nokia 5110 on a breakout board, mounted onto the main board with an 8-pin 0.1 inch header, and covering the upper two-thirds of the main board. Similarly, the Bosch BMP085 temperature and pressure sensor is on a second breakout, mounted with a 6-pin 0.1 inch header and covering the lower-left corner of the main board. The battery is a CR2032 coin cell, and projected battery life is 8-12 months.

While the new design is functionally similar to the original, it replaces virtually every component with a smaller SMD version. It also drops the breakout boards, soldering the components directly to the main board instead. The LCD is replaced by a 128 x 64 OLED, which is physically smaller but has a higher resolution. To meet the higher power demands of the OLED, the coin cell is replaced by a single AAA cell and a 3.3V boost regulator. The addition of an external EEPROM provides space for higher resolution or longer-term data storage than is possible with the ATmega’s built-in EEPROM. And as a last-minute addition, the new design also adds a SignalQuest SQ-SEN-200 omnidirectional tilt and vibration sensor, which I hope to use to measure periods of movement to compile trip duration stats. Projected battery life is about 5 months.

The majority of the top layer is covered by the OLED itself, leaving precious little space for component placement. It’s just the three tactile switches, boost regulator IC, and a couple of capacitors. The tactile switches are the thinnest I could find (2.6 mm), so as not to add too much to the overall thickness of the logger. I would have dearly loved to use the user-friendly switches with the 12mm base, but there simply wasn’t enough room. Instead, the switches here are the 6mm base type with a 3mm round button. A single drill hole in the top-left corner provides an option to wear the logger on a lanyard or keychain.

The bottom layer is were most of the action is. The ribbon connector from the OLED wraps around the bottom of the board, and its 30 pins are soldered at bottom-center. The AAA battery spans the bottom third of the board, lying on top of the ribbon connector. Down the left side are the ISP header, external EEPROM, and BMP085 sensor. The right side is occupied by an inductor, diode, and capacitor required by the boost regulator. Squeezed into the center is the ATmega 328 in TQFP package, a tiny speaker, 32 kHz crystal, and the SQ-SEN-200 vibration sensor. The SQ-SEN-200 is the barrel-shaped component at top center, and its internal switch chatters open and closed whenever it’s bumped or moved.

Cramming all these components into the space available was an interesting challenge. The resulting board is almost as small as theoretically possible, since the width is already constrained by the size of the battery, and the height could only be a few mm less before it would be shorter than the OLED screen. I plan to wait a while before sending this board for manufacturing, at least until I’ve received the boards for the original design and confirmed that everything works. All this waiting for boards is maddening!

Sometimes it seems like there are a million different LCDs you might use with your microcontroller project, and deciding on one can be hard. Once you’re ready to move beyond a basic text display, you’ll find graphic displays have a dizzying number of options for technology, color depth, interface type, driver, and power. Recently I’ve been collecting info on display options for my own projects, and here I’m presenting three options that look promising.

The Nokia 5110 is a low-resolution monochrome LCD that’s cheap and extremely low-power. A family of small monochrome OLEDs provide crisp, bright displays with a bit more resolution, in a teeny-tiny package. A 1.8 inch color TFT provides even greater resolution and 18-bit color, while still limiting power to about 90 milliwatts.

Nokia 5110

Colors: monochrome
Resolution: 84 x 48
Active display area: 2.8 x 2 cm
Interface: SPI
Power: 3.3v
Current: 0.4 mA for logic, 1-10 mA for backlight
Cost: $10
Vendors: Sparkfun, Adafruit

This is the display I’m currently using for my Backcountry Logger project. It’s cheap, easy to use, and consumes very little power. You don’t really need the backlight for daytime visibility, and with backlight off, it consumes just 400 uA! Awesome for battery-powered projects. Just 1-2 mA worth of backlight current is plenty for night-time visibility too, although more would be nicer. This puts the display well within the capabilities of a single CR2032 coin cell.

Working with the display is simple, as long as you remeber it’s a 3.3v device and not 5v tolerant. There are lots of great tutorials and examples available for this display, including this nice one from Adafruit. Communication with the display controller uses SPI. Writing a single byte sets 8 pixels at a time, so pixels are not individually addressable. If you’re mostly displaying text or bitmaps this isn’t a problem, but if you need a more complex image consisting of many overlapping elements, you’ll need to composite them in software before sending the result to the display.

The weak points of the Nokia 5110 display are resolution and looks. The contrast and sharpness are pretty good for a display of this type, but there’s still no getting around the fact that this is a low-res, dark-gray on light-gray display. The 84 x 48 resolution allows for just 14 x 6 characters using a typical 5 x 7 font (allowing for space between letters). If you seek utility, low cost, and low power, it’s a great solution. If you want something with a bit more bling, look elsewhere.

SSD1306/SSD1308 OLED

Colors: monochrome
Resolution: 128 x 64
Active display area: 2.4 x 1.2 cm
Interface: SPI, I2C, or parallel
Power: 3.3v, and maybe 7-12v
Current: roughly 5-13 mA, depending on how many pixels are lit
Cost: $15-$20
Vendors: Sparkfun (bare LCD), Adafruit, eBay

This little OLED display comes in a few slightly different flavors, but all of them are tiny. It’s one thing to read the dimensions (0.96 inches horizontally), but another to see it in person. All three of the displays discussed here are small, but this particular OLED is smaller than a postage stamp. It’s about the size of the last joint on my thumb.

Despite its small size, the OLED display is very readable. It’s sharp and bright, and a pleasure to look at. Since it’s an OLED, there’s no backlight, and current draw varies between about 5 to 13 mA in my testing, depending on how many pixels are illuminated. The 128 x 64 resolution is a nice bump from the Nokia 5110 display, allowing for 21 x 8 characters. Communication choices are SPI, I2C, or parallel, selectable via configuration pins. Like the Nokia, each byte sets 8 pixels at a time. Adafruit has a tutorial and library.

The display controller chip runs at 3.3v, and the display itself needs 7-12v, although you might be able to get away with a single supply depending on which display variant you have.

Adafruit sells this display on a break-out board, with white pixels, with a SSD1306 controller. The SSD1306 has a built-in charge pump, and can optionally generate 7.5v for the display from a 3.3v supply, which is a very convenient option. Sparkfun sells the naked LCD, with white or blue pixels, and a SSD1308 controller that lacks the charge pump. You’ll need to mount the 0.5 mm pitch connector somehow, and provide a separate power supply for the logic and display. The most common eBay variant comes on a break-out board, with the SSD1306 controller, and yellow pixels in the top quarter and blue pixels in the bottom three quarters. Mine also came hard-wired to use the parallel interface, and switching to SPI required wicking away some solder jumpers and adding new ones.

This display meets a narrower range of needs, but is awesome for its target niche. I’m strongly considering doing a version 2.0 of the Backcountry Logger using this display, to gain the benefit of smaller size, higher resolution, and better looks. Unfortunately with the amount of current it needs, it’s probably outside of what a CR2032 can provide, and will require 2 x AAA or 1 x AAA with a DC boost converter.

Adafruit 1.8 inch TFT

Colors: 18-bit (262144 colors)
Resolution: 160 x 120
Active display area: 3.6 x 2.8 cm
Interface: SPI
Power: 5v or 3.3v
Current: 1 mA for logic, about 26 mA for backlight (can be dimmed)
Cost: $25
Vendors: Adafruit

This is the display I plan to use for Tiny CPU. Unlike the others, it’s a full color display with individually addressable pixels. It supports 18-bit color, but can also be configured for 16-bit color or monochrome (I think? Haven’t tried that yet). It’s a bit larger than the other two, but still quite small compared to most displays. It is natively a 3.3v device, but the Adafruit breakout board includes an LDO regulator and level-shifter chip, so it can be used with 5v microcontrollers as well. Current demands are the highest of the three displays, but not excessive at about 1 mA for logic and 26 mA for the backlight. The backlight can be dimmed using PWM to further reduce the current. This is still well within the capabilities of an AAA-based battery-powered project.

The TFT is very attractive, not quite on par with the OLED, but certainly nicer than the CSTN used in some other cheap color LCDs. The 160 x 120 resolution feels giant in comparison with the previous displays, allowing for 26 x 15 characters. The display controller allows for a few different protocols, but the break-out board hard-wires it for SPI.

With the larger resolution and greater bit depth, a screen’s worth of data requires many more bytes than the previous two displays. Depending on the speed of your microcontroller and SPI interface, this may result in noticeably slower refresh times. I tested it using hardware SPI on a 16 MHz Arduino, and found the refresh time to be acceptable.

Adafruit has a nice tutorial and library for working with this display (I’m sensing a theme here). Unexpectedly, the breakout board also has a micro-SD card reader on it. Ignore it, or use it as a bonus peripheral in your next project.

Hallelujah! After substituting an external 32768 Hz crystal as the timer clock source for my hiking data logger, I’ve reduced the sleep mode (LCD off) supply current to less than 0.01 mA! It’s actually below the resolution of my multimeter– the meter just reads zero. Previously I was using the microcontroller’s internal clock as the timer clock source, which required it to keep running during sleep mode, and resulted in a sleep supply current of 0.11 mA.

0.01 mA: that is one small number. 10 microamps! It’s hard to believe a real circuit can run on that little current. Gotta love these AVR microcontrollers.

When “on”, with the LCD enabled and the user pressing buttons, the supply current is 0.41 mA without the backlight, or 1.2 mA with the backlight. Every time a new pressure/temperature sample is taken (once a minute or so), there’s an additional short current spike of about 0.15 mA above the baseline. How short, I’m not sure, but probably less than 50 ms according to the datasheet.

Assuming the logger is fully powered with LCD and backlight for about 15 minutes a day, that’s about 1% of the day in high power 1.2 mA mode, and 99% in low power 0.01 mA mode. That’s an overall average current of about 0.02 mA or 20 microamps. At that rate, a CR2032 coin cell with typical 220 mAh capacity will have a battery life of more than a year.

In my last post, I described an idea for a hiking data analyzer based around an old cell phone LCD, a pressure/temperature chip, and an ATmega microcontroller. Since then, I’ve received the parts and built a simple demo that exercises everything. It’s not very exciting yet, but it demonstates that all the parts are working as expected, so now the real work can begin.

In the photo, clockwise from the upper-left, you can see the ATmega, LED used for debugging, Nokia 5110 LCD, Bosch BMP085 pressure/temperature sensor, and the ISP programming cable. The BMP085 is mounted upside-down, since direct light on the sensor can skew its measurements. A small 3.3v power supply is to the left of the board, not visible.


The demo circuit polls the sensor once per second, and displays the results on the LCD. The photo shows a current report of 70.8 degrees Farenheit, a station pressure (actual pressure reading) of 999.02 millibars, and an equivalent pressure at sea level of 29.84 inches of mercury. The equivalent sea level pressure matches almost exactly with local weather reports, but the temperature is about 2 degrees higher than what’s reported by three other thermometers in the room. Suspecting that the power supply or other nearby components might be slightly warm and affecting the reading, I tried insulating the sensor by putting a cup over it, but the results were the same with and without the cup.

I wrote the demo software last week, before the parts arrived. Fortunately it only had a few small bugs, and it was just a couple of hours from when I opened the parts box to when I had everything working, although I did have to resort to logic analyzer debugging to resolve a problem with my I2C code.

Some thoughts, before I move on to the software design:

LCD resolution – I think I didn’t fully appreciate just how low-res 84×48 is. I can forget about drawing complex graphs with labeled reference lines. Small graphs should still be possible, but I’ll probably need to move a cursor over the graph to see times and values, which is a little clunky. The 5×7 font with one pixel of space to the right and below will allow for 6 lines of 14 characters each. A 5×5 font would allow 8 lines, but would also complicate the LCD display update, since the display must be written in units of 8-pixel tall columns.

program size – The demo program is 8294 bytes, which is already 25% of the capacity of the ATmega 328. Much of that is the floating point math library and the LCD font, which are one-time memory costs. Still, after more interesting program logic is added along with a few more bitmap images, I’m concerned it may not fit in 32K of program space.

temperature offset – Why does the sensor report a temperature 2 degrees higher than the room’s air temperature? Is it being warmed from a nearby component? Does the sensor itself generate a small amount of heat during its operation, biasing the result? Should I subract 2 degrees from the sensor reading to get the “true” air temperature?

supply current – The demo circuit draws about 1.35 mA. That’s not much, but it’s a lot more than it should, according to the datasheets. Even allowing for the busy loop in the microcontroller that keeps it constantly active, the circuit should only be drawing about 0.3 mA for the microcontroller, 0.24 mA for the display, and 0.005 mA average for the sensor. I measured the microcontroller drawing a bit less than 1 mA, and the LCD drawing 0.47 mA. I’m unsure why those measurements are so much higher than the datasheet values.

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.