Pressure and Temperature Demo
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.
Read 10 comments and join the conversation10 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
Have you verified that the microcontroller is running at the clock rate you think it is? Looks like the active mode at 3.3 V is around 1 mA at 2 MHz; to get to 0.3 mA you would need to drop the clock to around 0.5 MHz (just eyeballing the graphs, so these numbers are approximate). Turing on the various peripherals in the microcontroller will also increase the current consumption, but it doesn’t look like it would account for such a dramatic discrepancy.
Do you really need the floating point library? Couldn’t you store the values as X * 100 – that way you can do mults and whatnot without needing FP. I wrote a very simple temperature reader for the DS18B20-series that way, worked very nicely.
Hi Erik! It should be running at 1MHz (8MHz internal oscillator with /8 divider), but I haven’t actually confirmed that with the scope. Might unconnected, unused inputs be drawing some power? I think I remember reading that the input buffer circuitry may draw power if the inputs are floating.
Christian, yes most of the math could be done in fixed point. I need the floating point library for the pressure to altitude conversion, though. It involves exponentiation with fractional exponents, for which I’m using pow(). If I get desperate for space, maybe I can replace the formula with a look-up table for the expected input range.
Looks to me like the ATmega328 core would use between 0.5 and 0.6 mA at 1 MHz at 3.3 V, depending on which graph we are looking at. Perhaps the 0.3 mA figure you are looking at is specified at a lower voltage? Turning on all the peripherals would increase the current consumption by about 18.3%
The BMP085 breakout board has 4.7 k pull-ups on the SDA and SCL lines. Driving against these one of these pull-ups would take about 0.7 mA, so there would be a jump in current whenever you are using the I2C interface. Hopefully you are using a slow sampling rate.
Unconnected inputs in general can increase power consumption because if the voltage floats to an undefined logic level above Vil but below Vih you can end up with complementary pairs of transistors both partially on giving a path from power to ground. In this particular case though, the ATmega uses Schmitt trigger inputs (logic levels are well defined for all voltages between VCC & GND) so I think leaving them unconnected would be less likely to cause this problem (but I certainly could be wrong; I’ve never tried minimizing power consumption with these).
What setting are you using for PUD (Internal pull up disable) on the ATMega? Floating pins will affect current consumption.
OK, I think I’m in business. After some work, I’ve reduced the supply current to 0.44 mA with the LCD on, and 0.11 mA with the LCD off! That’s putting the ‘328P into power-save mode between updates, and using a TIMER2 interrupt to wake it up periodically.
I explicitly enabled the internal pull-ups for all unused inputs, but it made no noticeable difference in the supply current.
0.11 mA – that’s 110 microamps! That’s small. That should theoretically be enough for 84 days of use, assuming the LCD is mostly off. Still, by the datasheets, the supply current in power-save mode should be a single digit number of microamps. I suspect the oscillator needed for TIMER2 is using substantial current. I plan to try an external 32768 Hz crystal instead of the internal osciallator for TIMER2, and see if I can lower the supply current further.
That’s the same crystal as you’d need for an RTC module! given that you’re using the TIMER2 to wake up the 328P you can keep track of wall clock time there as well and still enjoy sleep modes. 🙂
See this post for more info on an ultra-low-power hookup of the BMP085: http://jeelabs.org/2010/06/30/going-for-gold-with-the-bmp085/ – there’s more if you search for “BMP085”.
[…] and temperature sensor demo – [Link] Tags: ATMega, BMP085, LCD, pressure, temperature Filed in Test/Measurements | 1 views No […]
Thanks Jean-Claude, there’s some great info on your site. I’m currently sitting in a busy loop while waiting for the BMP085 results, so there’s some more power savings that could be found by sleeping during that time. But since I’m only reading the sensor once per minute, it’s not essential. In a later post I said I’d lowered the average current to below what can be measured with my multimeter (10 uA), but I was measuring incorrectly. The average current is actually about 20 uA right now.