The EDU build we released in 2020 provides remarkable flexibility for courses in environmental monitoring. However an instructor still needs to invest about five days ordering parts, testing components, and preparing kits for a 15-20 seat course being run remotely. (only 1/2 that is needed for in-person courses where the students pin & test the parts themselves). While that’s not unusual for university-level lab based subjects it is something of a stretch for high school teachers. And thanks to COVID chip shortages, modules that were only 99¢ at the beginning of this project could now set you back $5 each. So with all that in mind, we’ve continued development of a ‘lite’ version of our logger with the lowest possible prep time. That new baby is now ready for release with data download & control managed through the IDE’s serial monitor window.

In addition, it’s not unusual to see a 50mv delta at the battery terminals for every 5°C change in ambient so a standard lithium coin cell will not power the logger below 0°C. But if theres one thing I’ve learned on this project it’s that datasheets only tell you so much about system behavior in the real world – especially with stuff constructed from cheap modules carrying half a dozen unspecified bits. So let’s just build one and see how it goes…

Modifying the RTC module:

I’ve no doubt the UART connected time is shortening the batteries lifespan slightly, in fact Panasonic specifies: “the total charging amount of the battery during it’s usage period must be kept within 3% of the nominal capacity of the battery”, so it’s a good idea to remove the battery if you are spending an extended time with the units connected to the serial line to keep the total reverse current time to a minimum. But given our tight operational margin I don’t think we can afford to lose two hundred millivolts over a Schottky protection diode. A typical solution would address this by ORing the two supplies with an ideal diode circuit but that’s not a option here as ideals usually waste some 10-20 µA. On a practical level it’s easier to just to pop in a fresh battery before every long deployment. Drift on these DS3231 RTCs is usually a loss of ~4-5 seconds per month, but could be up to twice that for -M variants of the chip.

Modify the Pro Mini board:

Join the two components:

But you always have the default 2.7v BOD on while the processor is operating so you probably want to stop logging when the rail starts falling below ~2785mv. Also keep in mind that there is range on that brownout threshold, from min. 2.5v to max. 2.9v. So one 328p may be more tolerant to running at low voltages than another.

This two module combination usually sleeps around 1µA and most of that is the RTC’s (IBATT) timekeeping current as the 328p should only draw ~150nA in powerdown mode [with BOD off]. If we assume four readings per hour at 5mA for 10msec, the battery life calculator at Oregon Embedded estimates a 220mAh battery will last more than 10 years…which is ridiculous. We know from the datasheet that 575µA temperature conversions bring the RTC average up to 3µA – which isn’t showing up on this direct measurement. And there’s the battery self discharge of 1-3% per year. Perhaps most important there’s the complex relationship between pulsed loads and CR2032 internal resistance, which means we’ll be lucky to get half the rated capacity before hitting brown-out at 2.7v A more realistic estimate would start with the assumption that the battery only delivers about 110mAh with our logger consuming whatever we measure + 3µA (RTC datasheet) + 0.3µA (coincell self-discharge). We can round that up to 5µA continuous, with four 5mA*10millisecond sensor readings per hour, and we still get an estimated lifespan of about two years. So our most significant limitation is the amount of EEprom memory rather than battery power.

The Code: [posted on Github]

The most important difference between a coin cell powered logger and our AA powered units is that the battery has a high probability of being depleted to the point of a BOD restart loop. (which causes rapid flashing of the D13 LED) So we use a multi-step serial exchange in Setup() to prevent data already present in the EEprom from being accidentally overwritten.

Addendum 2023-10-25: Code revisions are *currently underway* to support the use of these loggers in enviro-sci course curriculum & some elements of the old logger code may disappear from Github for a while until our students have progressed further through the lab sequence. Those elements will then be restored to the base code on Github. This may cause discrepancies between the text in this post and the options in that code.

In Setup()

A UART connection is required at start-up so those menu-driven responses can occur through the serial monitor in the IDE. These have timeouts to avoid running the CPU during unintentional restarts. The menu sequence can be re-entered at any time simply by closing & re-opening the serial monitor window:

The first menu option asks if you want to download the contents of the logger memory to the serial monitor window. This can take 1-2 minutes with large EEproms at 500000 baud, which is the fastest rate an 8MHz ProMini can reliably sustain. Then copy/paste (Ctrl-A & Ctrl-V) everything from the IDE window into an Excel sheet and then, below the data tab, select Text to Columns to separate the data at commas. Or you can paste into a text editor and save as a .txt file for import to other programs. While that process is clunky because the IDE’s interface doesn’t export, everyone already has the required cable and data retrieval is driven by the logger itself. ( And yes, the exchange could be done with any other serial terminal app.)

After the start menu sequence the first sample time is written to the internal EEprom so the timestamp for sensor readings can be reconstructed during data retrieval later by adding offsets added to the first reading time. This technique saves a significant amount of our limited EEprom memory and all it takes is =(Unixtime/86400) + DATE(1970,1,1) to convert those Unix timestamps human readable in Excel. It is important that you download the old data before changing the sampling interval via the menu options because that interval (stored in eeprom) is used to reconstruct the timestamps during download. Valid intervals must divide evenly into 60 and be less than 60. Second-intervals can be used for rapid testing if you first enter (0) for the minutes during setup.

No sensor data is lost from the EEprom when you replace a dead coin cell and you can do the entire data retrieval process on UART alone with no battery in the logger. But RTC time reset should only be done after installing a new battery or the time will not be retained. If the time in the serial menu after a complete power loss reads 2165/165/165 165:165:85 instead of 2000/01/01 then there’s a good chance the RTC’s registers have been corrupted & the clock may need to be replaced. I’ve managed to do this to a few units by accidentally shorting the voltage to zero when the logger was running from a capacitor instead of a battery.

After setting the RTC time, the sampling interval, and other operating parameters, the logger requires the user to enter the ‘start’ command again. Only when that last ‘start’ confirmation is received are the EEprom(s) erased by pre-loading every location with ‘0’ values which also serve as End-Of-File markers during the next download. The red D13 led then blinks at 1second while the logger waits for the first sampling alarm to align with the current time before beginning the run.

Main LOOP()

To save power, slow functions like digitalWrite() and pinMode() can be replaced with much faster port commands. Careful attention is paid to pin states, peripheral shutdowns (power_all_disable(); saves ~0.3mA) and 15msec sleeps are used throughout for battery recovery. Waking the 328p from powerdown sleep takes 16,000 clock cycles (~2milliseconds @8MHz +60µS if BOD_OFF) and the ProMini draws ~250µA while waiting for the oscillator to stabilize. Care must be taken when using CLKPR to reduce system speed because the startup-time also gets multiplied by the divider.

( Note: For the following images a Current Ranger was used to convert µA to mV during a reading of the RTC’s temperature register at 1MHz. So 1mV on the oscilloscope means 1µA is being drawn from the Cr2032 )

[ 2023-05-31 UPDATE: I came across several cheap eBay EEproms that would freeze the system when I lowered the system clock to 1MHz to save power during EEprom saves. So I have removed that technique from the code on GITHUB to make that codebase more generic. This problem did not affect the chips I bought from DigiKey]

CR2032 voltage is checked during the EEprom data save because an unloaded coin cell voltage does not change – even when the battery is nearly dead. This assures that the voltage droop is captured though the exact timing of that minimum varies from one memory chip to the next. Logger shutdown gets triggered when the EEprom write brings the rail voltage below the 2795mv systemShutdownVoltage, which happens when the internal resistance of the coincell rises at end of life.

Adding Sensors:

An RTC temperature only configuration for this logger records a 0.25°C temperature record from the DS3231, index-encoded to use only one byte per reading. This allows ~4000 readings to be stored in the 4k EEprom on the RTC module. This works out to a little more than 40 days at a 15 minute sampling interval, but you can set SampleIntervalMinutes to any even divisor of 60.

That little AT24c32 doesn’t last very long with sensors that generate 2 or 4 byte integers. The solution is to combine them with larger 32k (AT24c256), or 64k (AT24c512) chips so the sensors arrive with the extra storage space they require. These EEprom modules can usually be found on eBay for ~$1 each and (after you change the bus address & bytesofstorage defs) they work with the same page-write & addressing code as the 4k EEprom.

You must use low power sensors with a supply range from 3.6v down to our 2.7v EEprom/BOD cutoff. A good sensor to pair with this logger should sleep around 1µA and take readings below 1mA. Sometimes you can pin-power sensors that lack low current sleep modes although if you do that be sure to check for unexpected current leaks in other places such as bus pullup resistors and the I2C bus may go into an illegal state (the idle condition is with both lines high) requiring a full reset of all sensors after power is restored. Choose libraries which allow non-blocking reads so you can sleep the ProMini while the sensor is gathering data and check that those libraries do not contain any delay() statements. In that regard my favorite sensor combination for this logger is an NTC thermistor & CDS cell which adds nothing to the sleep current. We explained how to read resistive sensors with Arduino’s Input Capture Unit in some detail back in 2019; so here I will simply show the hardware connections. Add these passives to the Pro Mini BEFORE joining it to the RTC module, taking care not to hold the iron so long that you cook the components:

Don’t expect the NTC you have in your hands to match exactly the values provided by its manufacturer. Fortunately there are several online calculators to choose from when determining your NTC thermistor constants. For calibration data, I use a food dehydrator to heat the loggers to around 45-50°C, then then it cool to room temp. for the midpoint, and then put them in the refrigerator overnight for a cold point at ~5°C. I add this NTC/LDR combination to all loggers (even if they will eventually drive I2C sensors) because a good test-run for newly built units is to read these sensors at an ultra short five second interval until the EEprom is full. After passing that test you can be sure the core of the logger is ok before adding new sensors.

Other useful modifications to the basic 2-module logger include:

Leakage scales linearly with capacitance so use the Falstad simulator to see what size you actually need. Capacitors rated 10x higher than the applied voltage reduce leakage current by a factor of 50. So your rail buffering caps should be rated between 10 to 30v if you can find them. While they are a bit bulky, electrolytics also work fine. The 220µF/25v 227E caps I tested only add ~5nA to the loggers sleep current and these can be obtained on eBay for <50¢ each. High voltage ratings get you closer to the low leakage values you’d see with Polypropylene, Polystyrene or Teflon film and moves you farther away from de-rating problems.

Note that as the buffering cap gets larger, you need to add more ‘recovery time’ before the rail voltage is restored after each load. A large rail capacitor also protects the unit from impacts which might briefly disconnect the spring contact under the coin cell. This is a such common problem in our other loggers that we use a drop of hot glue to lock the RTC coin-cell in place before deployment.

Discussion:

CLKPR brings the ProMini down to 1MHz and a current of ~1.3 mA however the energy cost per logging event actually increases when the system clock gets divided. But with our slim operating margin the growing internal resistance of the coin cell means we have to stay above 2.775v even if it means using less efficient code. Running from the internal oscillator might help but is avoided because our ICU timing method needs the thermal stability of an external oscillator and, the internal oscillator makes UART coms flakey. FRAM has much lower saving currents than standard EEproms but those expensive chips sleep around 30µA so they aren’t a viable option for low-power systems. (…unless you pin-power them so you can cut their power during sleep.)

In the next three images, a Current Ranger converts every 1µA drawn by the logger to 1mV for display on the scope. The last two spikes are transfers of buffer-array data into the 4K EEprom on the RTC module while the CPU takes ADC readings of the rail voltage. Note that our code staggers EEprom save events so they don’t occur in the same pass like this, but I forced them together for this testing to illustrate the effect of repeated pulse-loads:

The basic RTC-only sensor configuration reached a very brief battery current peak of ~2.7mA with no buffering cap, 1.5mA with 220µF and less than 1mA with 1000µF. The amount of voltage drop these currents create depend on the coin cells internal resistance but a typical unbuffered unit usually sees 15-30mV drops when the battery is new and this grows to ~200mV on old coin cells pulled from loggers that have been in service since 2018. The actual drop also depends on time, with subsequent current spikes having more effect than the first as the internal reserve gets depleted. The following images display the voltage droop on a very old coin cell pulled from a logger that’s been in service since 2016 (@3µA average RTC backup)

After many tests like those above, our optimal solution is to run the processor at 8MHz most of the time while breaking up the execution time with multiple 15 millisecond POWER_DOWN sleeps before the CR2032 voltage has time to fall very far. (This is especially necessary if you start doing a lot of long integer calculations) This has the added benefit that successive sensor readings start from similar initial voltages. The processor is brought down to 1MHz only during the EEprom save event where the block can not be divided (and that only happens when the data buffering arrays are full….)

Even with fierce memory limitations we only use the 328’s internal 1k for a couple of index variables that get written while still tethered to the UART for power. EEprom.put starts blocking the CPU from the second 3.3msec / byte, and internal EEprom writing adds an additional 8mA to the ProMini’s normal 5mA operating current. This exceeds the recommended pulse current for a garden variety CR2032. And multi-byte page writes aren’t possible so data saved into the 328p costs far more power than storage in an external EEprom. However it is worth noting that reading from the internal EEprom takes the same four ticks as an external with no current penalty, while PROGMEM takes three and RAM takes two clock cycles. So it doesn’t really matter to your runtime power budget where you put constants or even large lookup tables.

A simple optimization we haven’t done with the code posted on GitHub is to increase the I2C buffer. All AT-series EEproms are capable of 32-byte page-writes but the default wire library limits you to only 30 bytes per exchange because you lose two for the register location. So we used 16-byte buffer arrays in the starter code but you could increase those array/transfers to 32 bytes by increasing the wire library buffers to 34 bytes:

In wire.h (@ \Arduino\hardware\arduino\avr\libraries\Wire\src)
#define BUFFER_LENGTH 34
AND in twi.h (@ \Arduino\hardware\arduino\avr\libraries\Wire\src\utility)
#define TWI_BUFFER_LENGTH 34

With larger EEproms you could raise those buffers to 66 bytes for 64 data-byte transfers. That buffer gets replicated in five places so the wire library would then require an extra 138 bytes of ram over the 32-byte default. 128k EEproms often refresh entire 128-byte blocks no matter how many bytes are sent, so increasing the buffer reduces wear considerably for those chips, while 64k & below may perform partial page-writes more gracefully. It’s also worth mentioning that there are alternate I2C libraries out there (like the one from DSS) that don’t suffer from the default library’s limitations.

An average sleep current of ~5µA*86400 sec/d burns ~432 milliAmpseconds/day. With a page-write that draws 4mA*6msec, the usual 12x buffer-array transfers of data to EEprom per day will consume about 288mAs. Cutting that in half by doubling the size of the array is going to save you ~144mAs per day, so it will take four days to save enough power for one more day of operation. That return is better with older 10 millisecond/write EEproms, and reducing the number of pulse-load events may extend battery life in ways other than the power being saved. I always do the 34-byte I2C buffer & 32-byte data array increases for long deployment loggers because the cheap EEproms on eBay are always older revs, so they take twice as long for both read & write operations compared to newer AT series chips from DigiKey.

No matter what optimizations you make, battery life in the real world can also be shortened by temperature cycling, corrosion from moisture ingress, being chewed on by an angry dog, etc. And you still want the occasional high drain event to knock the passivation layer off the battery.

An important topic for a later post is data compression. Squashing low-rez sensor readings into only one byte (like we do with the RTC temperature & battery voltage) is easy; especially if you can subtract a fixed offset from the data first. But doing that trick with high resolution thermistor or lux readings is more of a challenge. Do you use ‘Frame of Reference’ deltas, or XOR’d mini-floats? We can’t afford much of an energy tradeoff for heavy calculations on our little 328p so I’m still looking for an elegant solution.

Hopefully this new member of the Cave Pearl family goes some way toward answering people asking why we haven’t moved to a custom PCB: Using off-the-shelf parts is critical to helping other instructors base their courses on our work, and when you can build a logger in about 15 minutes, from the cheapest parts on eBay – that still runs for a year on the coin cell… why bother? We do water sampling dives all the time with those 50mL centrifuge tubes and I’ve yet to see the Nunc’s from Thermo leak at depths far beyond IP68. And again, you are only talking about $1 each for those tubes.

We’ve also been having fun embedding these ‘ProMini-llennium Falcons’ into rain gauges and other equipment that predates the digital era. There’s a ton of old field kit like that collecting dust in the corner these days that’s still functional, but lacks any logging capability.

Addendum

If you deploying in an area exposed to direct sun you can prevent the logger from getting too hot by adding a layer of PTFE thread tape around the tube:

Adding a small amount of silicone grease to the rim of the tube before closing improves the seal with the lid considerably. We’ve done pressure tests to 45psi so these tubes can be deployed to at least 20m depth. Avoid old stock as the caps get brittle & crack long before the clear tubes age. Use small 0.5-1 gram desiccant packs with this housing.

Addendum: 2022-07-01

Since we covered adding sensors, here’s a couple of burn-down curves for the two configurations described above. Both were saving 4 bytes of data per record every 30 minutes giving a runtime storage capacity of about 150 days. Battery was logged each time the 16-byte buffer-arrays were written to eeprom. Both loggers have a measured sleep current of ~1.5µA and they will be downloaded periodically. Although the curve spikes up after each download, these are runs on the same coin cell battery:

I’m running these tests without help from a rail buffering cap, to see the ‘worst case’ lifespan. A pulse loaded Cr2032 has an internal resistance of ~20Ω for about 100 mAh of its operational life, so our 5mA eeprom writing event should only drop the rail 100mv with no rail buffer cap. But once the cell IR approaches 40Ω we will see drops reaching 200mv for those events. The CR2032’s shown above have plateaued near their nominal 3.0v, so we should see the rail droop to ~2800mv when the batteries age. Again, with the 220 µF rail capacitor those drops are reduced to less than 1/2 that size and with 1000µF they are virtually eliminated.

Note that the download process briefly restores the voltage because the 3.3v UART adapter drives a small reverse current through the cell. I think this removes some of the passivation layer, but the effect is short lived. I have reloaded these two loggers with a new code build that tracks both high (immediately after wake) & low (during EEwrite) battery levels to see if the delta in the logs matches the 50mv drops I usually see with a scope.

According to Maxell’s 1Meg-ohm (3.3µA continuous) discharge test, coin cells should stay at their 3v plateau until they deliver about 140mAh [~500,000 mAs] So buffering caps aren’t really needed until batteries pass that point. In testing, 200uF rail caps extended runtime by about 35%. Of course, if you reach a year without the rail buffer, then you’ve probably filled the EEprom. So that capacitor may only be necessary with high-drain sensors or in low temperature deployments where the battery will struggle with larger IR drops. According to Nordic Semi: “A short pulse of peak current, say 7mA (typical of a Bluetooth Low Energy radio) for 2 milliseconds followed by an idle period of 25ms is well within the limit of a CR2032 battery to get the best possible use of its capacity.” Our EEprom save events are typically around 6-8 mA for 5ms which causes <50mv drop with a 200µF. Even with very old batteries the typical EEsave event doesn’t usually drop the rail more than 150mv, however the recovery time grows from less than 25msec to more than 150msec, so logging events look more like ‘blocks’ on the oscilloscope trace rather than a series of short spikes.

And here we compare our typical logging events to the current draw during the RTC’s internal temperature conversion (with a 220µF/25v cap buffering the rail). On all three the horizontal division is 50 milliseconds, and vertical is 200µA via translation with a current ranger:

The datasheet spec for the DS3231 temp conversion is 125-200ms at up to 600µA, but the units I tested drew half that at 3.3v. The rail cap can’t protect the coin cell from these long duration events so RTC temp conversions overlapping the EEprom save will likely be the trigger for most low voltage shutdowns. The best we can do to avoid these collisions is to check the DS3231 Status Register (0Fh) BSY bit2 and delay the save till the register clears. But even with that check, sooner or later, a temp conversion will start in the middle of an EEprom save.

Another thing to watch out for is that with sleep currents in the 1-2µA range, it takes a minute to run down the little 4.7µF cap on the ProMini board. If you have a 220µF buffering the rail the logger can sleep for more than 10 minutes with no battery. So if you are trying to reset the RTC you may need to briefly short Vcc to GND (at the UART headers) after removing the coin cell. Note that on several of the RTC modules the alarms continue to be asserted even after you disable them in the control register and this draws 6-700uA continuously through the pullup on the module. The only way to be absolutely sure the RTC alarm(s) will not fire after a shut-down is to turn off the RTC’s main oscillator. It’s also worth noting that the datasheet says: “If low power consumption during reset is important, it is recommended to use an external pull-up or pull-down.” If your code hangs, the processor will draw 5mA continuously until the battery drains and the logger goes into a BOD restart loop with the D13 red led flashing quickly. The logger will stay in that BOD loop from 4-12 hours until the battery falls below 2.7v without recovering. This has happened many times in development with no damage to the logger or to any data in the EEprom.

In all cases, your first suspect when you see weird behavior out of the logger is that the coin cell needs to be replaced. It’s worth noting that name brand CR2032s (Panasonic, MuRata, Duracell, Energizer, etc.) can last significantly longer than no-name ‘bulk’ coin cells from eBay/Amazon. They also plateau at 3.05v, while cheaper cells tend to level out at 2.95v. Most of the units I’ve tested trigger their BOD just below 2.775 volts. And 10 to 20 millivolts before the BOD triggers the internal voltage ref goes a bit squirrely, reporting higher voltages than actual if you are using the 1.1vref trick to read the rail. The spring contact in the RTC module can be pretty bad and that can give you random quits from large voltage drops so I usually slide a piece of heat-shrink behind it to strengthen contact with the flat surface of the coin cell. Normal operation will see 40-50mv drops during EEprom saves up to 3msec with 200µF rail buffers ( with a 1000µF rail cap those events are under 20mv) If those events look unusually large or recovery starts stretching to 100’s of milliseconds on the scope you probably have bad battery contact. In all cases, a long duration load can deplete the rail buffering cap – a 200µF reaches the same v-drop as a ‘naked’ battery after ~3msec, and 1000µF after ~10msec.

Addendum: 2023-04-23

We finally released the full build tutorial on YouTube – including how to upgrade the default 4k EEprom with two stacked 64k chips:

Make at least two machines at a time. I usually build in batches of six, and of those, one usually ends up with either a faulty RTC module or a ProMini with one of those fake 328p chips that wont sleep below 150µA. Test each ProMini with ‘blink’ before assembly because you occasionally get one that shipped without a bootloader. Having more than one logger makes it easy to identify when you’ve got a hardware problem rather than an error in your code. Even then, no unit is worth more than an hour of troubleshooting when you can build another one from scratch in about 30 minutes – your time is worth far more than these components. That said, taking time to clean all the parts before & after assembly is always worth your time, because with sleep currents below 5µA any leakage paths between PCB traces from flux residue, fingerprint smudges, etc. become important.

And all the other quid-pro-quos about dodgy eBay vendors still apply: Split your part orders over multiple suppliers with different quantities, ordered on different days, so you can isolate the source of a bad shipment. Don’t be surprised if that batch of boards somehow turns into a random delivery of baby shoes to your doorstep. Amazon is often cheaper than eBay and AliExpress is 1/4 the price of both.

Addendum: 2023-06-05

Ran a series of Cr2032 battery tests with these little loggers and was pleasantly surprised to find that even with the default BOD limiting us to the upper plateau of those lithium cells; we can still expect about two years of run time from most name brand batteries (with a 200uF rail cap). And with a series of different resistors on the digital pins, this logger might be the cheapest way to simulate complex duty cycles for other devices. Also keep in mind that all the units in the battery test had BOD’s below 2.8v – about 1 in 50 of these Promini’s will have a high BOD at the maximum 2.9v value in the datasheet. It’s worth doing a quick burn test with the Hdao cells to spot these high cutoff units to exclude them from deployment.

Addendum: 2023-10-25

Macintosh users have been running into a very specific problem with this logger: their USB-c to USB-a adapter cables are smart devices with chips inside that will auto shut-down if you unplug them from the computer while they are connected to a battery powered logger. The VCC & GND header pins on the logger feed enough power/voltage back through the wires to make the chip in the dongle go into some kind of error state – after which it does not re-establish connection to the Mac properly until it is completely de-powered. So you must unplug your loggers at the UART module to logger connection and NOT by simply pulling the whole string of still-attached devices out of the USBc port.

Addendum: 2023-12-01

Released the classroom version of this 2-module logger, with substantial code improvements to make it easier to add new sensors. This new build has two breadboards supported on 3D printed rails so that sensor connections can easily be changed from one lab activity to the next. The default code reads temperature via the RTC, and NTC thermistor, Light via an LDR and the Bh1750, and Pressure via a Bmp280.

Addendum: 2024-04-20

We have a separate post describing how to calibrate the NTC thermistors on these two module loggers using a DIY warm water bath made from insulated lunch boxes:

References:

Heliosoph: Arduino powered by a capacitor
Nick Gammon: Power Saving techniques for microprocessors
Jack Ganssle: Hardware & Firmware Issues Using Ultra-Low Power MCUs
Using a $1 DS3231 Real-time Clock Module with Arduino
Waterproofing your Electronics Project
An Arduino-Based Platform for Monitoring Harsh Environments
Oregon Embedded Battery Life Calculator
WormFood’s AVR Baud Rate Calculator
ATmega328P Datasheet