Tag Archives: arduino

Testing Cr2032 Coin Cell Batteries with our 2-Part ProMini logger

A DIY Pressure Chamber to Test Underwater Housings

Addendum: 2023-05-30

Although the units sleep current was the same as before the pressure testing, the battery in the 30mL tube barely made another twelve hours on the bookshelf before the voltage dropped again – well before the expected remaining run time. So it’s a safe bet that any deployment which exposes coin cells to pressure at depth is a one-shot run. Given how cheap these batteries are, that’s pretty much a given when deploying these little loggers even if they remain dry.

“Too Ugly to Steal & Too Heavy to Carry” : Insights from a decade of rain gauge deployment

2 Replies

A typical climate station from our project with other sensors protected from the direct sun under the bricks. Those loggers get checked carefully because scorpions are particularly fond of these brick stacks.

Most experiments require weather information to put environmental trends into context. So even though the majority of our sensor network is under ground, or under water, each study area includes a climate station on the surface. Our field sites are rarely close enough to government stations for their data to reflect local conditions because the official stations are spatially biased toward population centers and coastlines. As a result, we operate about ten weather stations and of the sensors they contain, tipping bucket rain gauges (TRGs) can be challenging to maintain at stations that only get serviced once or twice a year.

Where to spend your money

A fieldwork photo from early in the project when we were trying many different rain gauge designs. The aluminum funnels at the back are field repairs after the originals became brittle & cracked. Over time, this happens to all of our plastic funnel gauges. It’s worth noting that those aluminum funnels also corrode with organic acids from debris, but that takes 3-4 years instead of just months.

EVERYTHING exposed to full sunlight must be made of metal if you want it to last more than a year. I know there are plenty of tempting rain gauge designs at Thingiverse, but we’ve yet to see even hardened 3Dprints stand up to tropical conditions. This is also true for Stevenson screens, where I’d recommend a stack of metal bowls on stainless threaded rods (like that used by the Freestation project) over most of the pre-made ones on the market. Local varmints love using climate stations as chew toys.

A typical station ready to deploy: Left: Hobo/Onset RG2 and right is the older 6″ Texas Electronics gauge it was based on. The separate loggers recording each TRG also record pressure & temp. The central logger records RH%, but RH sensors are so prone to failure that we no longer combine them with anything else. During installation, washers can be added for leveling where the gauges are bolted to the brick.

If you need one, then you actually need two. So long as you follow that first rule, it’s better to install two medium quality gauges rather than a single new one that eats your budget. When you’re replacing four to six gauges per year, lighter six inch diameter units are much easier to transport. Be sure to have a receipt ready for import duty and even if you only paid $100 for that used gauge on eBay you can should expect an additional $100 getting it into another country. (and significantly more for some shiny new gauge that doesn’t have any scratches or dents on it yet) Another reason to double up is that you can pack them into different suitcases. When the airline loses a bag – which happens more often than you’d expect – you still have at least one to deploy. Finally, if you install dual TRG’s from the start of your project, you then have the option of temporarily re-allocating to singles if a bad weather event destroys half your installations.

A low budget hack that you can maintain is better than an expensive commercial solution that you can’t. Avoid any system with special unobtainium batteries or connectors that you can’t buy/repair at your fieldwork destination. That sweet looking ultrasonic combo you were drooling over at AGU was probably engineered for the US agricultural market, and may not work at all in Costa Rica. If you do start testing acoustic or optical rain sensors, then have a second low tech backup on the station beside it. Most methods have some sort of ‘blind spot’ where they generate inaccurate data and the only way to spot that is to have data from a different device to compare. Reed switches also have the advantage that they require no power to operate.

A new gauge with a funnel full of standing water after only six months.

The debris snorkel plugged because it was designed for fine mid-west field dust, rather than the soggy leaf debris blowing around in a tropical storm. Pine needles cause similar headaches for researchers in northern climates.

Watch out for siphon mechanisms at the bottom of funnels designed to improve accuracy.

Anything that makes the flow path more convoluted will eventually clog – so I cut them out.

Location, Location, Location

Installation guidelines for weather stations usually make assumptions that only apply only in wealthy first world countries. This is hardly surprising given that even mid-range kit will set you back $1,000 and pro-level equipment can top $10,000 when you include the wireless transmitters & tripod mounting system. But our research almost never happens under such genteel conditions, so here’s my take on some of those serving suggestions:

A brick stack used to raise the funnels above the roof edge walls. These are bound with construction adhesive and industrial zip ties. Rooftop stations are still affected by high winds and falling branches, but just as often the disturbance is from maintenance people working on the water tanks, etc.

Place the weather station in an open area, free from obstructions such as trees or buildings, to ensure proper air flow and accurate wind measurements.
So what do you do if those open areas only exist at all because someone cut down trees to build? And anemometer measurements are only possible if your kit can stand being hit by several tropical storms per year. Not to mention the amount of unwanted attention they draw. Wind data is one of the few things we rely on government & airport stations for.
Choose a location with a stable and reliable power supply, or consider alternative power sources such as solar panels or batteries.
The expectation of reliable electricity / internet / cell phone reception is as humorous to a field scientist as the expectation of getting a hot shower every day. For more giggles, why not pop over to the next geo-sci conference in your area and ask them how long their solar powered station in Michigan ran before it was riddled with buckshot. Batteries are your only option, and the system should be able to run at least twice as long as your expected servicing schedule because things never go according to plan.
Locate the weather station in an area that is easily accessible for maintenance and repairs.
Even in areas that regularly get pummeled by hurricanes, vandalism/theft is our biggest cause of data loss. Any equipment within reach of passers-by will be broken or missing within a couple of months – especially if it looks like a scientific instrument. So it’s worth a good hike through dense jungle to protect your data, even if that makes the station harder to access.
Choose a location away from any artificial sources of heat, such as buildings or parking lots.
Rooftops are the only locations where we’ve managed to maintain long term stations because they are persistent, hidden from view, and the surrounding trees have been cleared. And in an urban environment…isn’t that, you know, the environment? Yes the thermal data is off because those rooftops go well over 45°C, but temperature is the easiest data to get from tiny little loggers that are more easily hidden at ground level.
Consult with local authorities and meteorological agencies to ensure that the location meets any necessary standards or regulations.
A solid long-term relationship with the land owner, and your other local collaborators is vital for any research project, but don’t expect local authorities to make time for a friendly chat about your climate station. NGO’s are usually run by volunteers on shoe-string budgets so they’ll be grateful for any hard data you can provide. However, those same groups are often a thorn in the paw of the previously mentioned authorities. Threading that needle is even more complicated when some NGO’s are simply place-holders for large landowners. In addition to significant amounts of paperwork, public lands suffer from the problem that legislation & staff at the state/territory level can change dramatically between election cycles, sometimes to the point of banning research until the political wind starts blowing in a different direction.

Maintenance

The best maintenance advice is to have separate loggers dedicated to each sensor rather than accumulating your data on one ‘point of failure’ machine, especially when DIY loggers cost less than the sensors. We try to bring enough replacement parts that any site visit can turn into a full station rebuild if needed.

After six years in service I’m surprised this unit hasn’t been zapped by lightning.

Even with zip-tie bird spikes this gauge still accumulates significant poop each year. This passes through the main filter screen which stops only sticks, seeds & leaves. Chicken wire is another common solution to the bird roosting problem that’s easy to obtain locally.

Funnel & screen after the annual cleaning. This stainless steel kitchen sink strainer works far better than the commercial solutions we’ve tried because it has a large surface area that rises above most of the debris. It is installed at a slight angle and held in place by wads of plumbers epoxy putty. **This has become a standard addition to ALL of our rain gauges.**

You’d think name brand gauge makers would use stainless steel parts – and you’d be wrong. Sand & coat those internal screw terminals with grease, conformal, nail polish, or even clear acrylic spray paint if that’s all you can find locally. This also applies to pipe clamp screws which will rust within one year even if the band itself is stainless.

Like bird spikes and debris snorkels, there are several commercial solutions for calibrating your gauge, but my usual procedure is to poke a tiny pin-hole in a plastic milk jug or coke bottle, and adding 1 litre of water from a graduated cylinder. Placing this on the funnel of a rain gauge gives a slow drip that generally takes about 30 minutes to feed through. The slower you run that annual calibration test the better, and ideally you want an average from 3-5 runs. Of the many gauges we’ve picked up over the years, I have yet to find even new ones that aren’t under-reporting by 5-10% and it’s not unusual for an old gauge to under-report by 20-25%, relative to its original rating. Leveling your installation is always critical, but this can be difficult with pole mounted gauges. In those cases you must do your calibration after the TRG is affixed. I rarely move the adjustment stops on a gauge that’s been in place for a couple of years even if the count is off, because that’s less of a problem to deal with than accidentally shearing those old bolts with a wrench.

The Data

Rain gauges have large nonlinear underestimation errors that usually decrease with gauge resolution and increase with rainfall rate – especially the kind of quick cloud-burst events you see in the tropics. Working back from the maximum ranges, you’ll note that few manufacturers spec accuracy above two tips per second. So that’s a reasonable ‘rule of thumb’ limit for small gauges with plastic tippers that will plateau long before larger gauges with heavier metal tipping mechanisms. Gauge size is always a tradeoff between undercounting foggy drizzles at the low end (where smaller tippers are better) or undercounting high volume events (where larger gauges generally perform better). Even if you hit the sweet spot for your local climate, storms can be so variable that a perfectly sized & maintained gauge still won’t give you data with less than 15% error for reasons that have little to do with the gauge itself.

This adds 5-10 ms hardware de-bounce to the reed switch. Most gauges have switch closure times of under 100ms with 1-2ms of bounce either side. After the FALLING trigger, sleep for ~120msec before re-enabling the interrupt. You can eliminate the 5k puller using the 25k internal pullup @ D3, but your rise time changes from 10ms to 25ms and the resulting divider only drops to 15% Vcc.

All that’s to say your analysis should never depend on rainfall the way you might rely on temperature or barometric data. More records, from more locations, always gives you a better understanding of site conditions than ‘accurate’ data from a single location. Of course, that gives you the “man with two watches” problem when one of the gauges is in the process of failing. The most difficult situation to parse is where something slowly plugs one of the funnels but both gauges are still delivering plausible data. A signature of this kind of fail is that one gauge of a pair starts delivering consistent tip rates per hour during events while the other gauge shows larger variation. An alarm bell should go off in your head whenever you see flattened areas on a graph of environmental data:

Wasps & termites are particularly fond of rain gauges because they naturally seek shelter underneath them – where the drain holes are.

Daily Rainfall (mm) record from the gold funnel TRG at the top of this post showing before (green) & after (red) the storm that clogged the filter. Failure is indicated by prolonged curving descents followed by a long tail of low counts as the trapped water slowly seeps through the blockage. Normal rainfall data looks spikey because it can vary dramatically in as little as 15 minutes with long strings of zeros after each rain event.

Did I mention snakes? Yep, they love our climate stations. My guess is they go in after residual water left in the tipper mechanism.

These problems are much easier to sort out if both of the gauges at a given station are calibrated to the same amount of rainfall per tip (usually 0.01inches or 0.2mm) and disappear entirely if you have three records to compare.

While I’ve been critical of the cheap plastic tippers you find in home weather station kits they still have a place for budget EDU labs, and I’ve more than a few in my back garden feeding data into prototypes for code development. A new crop of metal & plastic hybrid gauges have started appearing on Amazon/eBay for about $150. The build quality seems a bit dubious, but we are going to give them a try this year anyway to see if they can serve as backups to the backups. As they say in the army: “Quantity has a quality all it’s own”. I wonder if any citizen science projects out there could adopt that motto?

Addendum: 2023-04-17

As luck would have it, that cheep Chinese gauge arrived from Amazon the day after I made this post. I wasn’t expecting much from a $150 rain gauge, but this one turned out be such an odd duck that I’ll include it here as a warning to others. On the right you see a photo from the listing, which made me think both the body and the funnel were made from brushed metal. What actually arrived made it clear the whole listing was carefully crafted to hide some pretty serious designs flaws.

Another dented delivery though, to be fair, the metal is tissue paper thin. At least this one didn’t get stolen from the front porch. Aluminum spray paint was used to disguise the crappy plastic funnel in the listing photos.

You could snap any part of this mechanism with finger pressure. And I wouldn’t take bets on how waterproof that junction box is either. There were no photos of this mechanism in the listing, which should have stopped me right there.

The thing that makes this such a good example of bad engineering is that they first optimized production cost with cheap brittle plastic that will likely fail with a year. As a result, the tipper ended up so light that they had to add a second funnel & tipping mechanism to deal with the momentum of drops falling from the main funnel. That second mechanism is so small it’s guaranteed to plug up with the slightest amount of debris – causing the unit to stop working even before the plastic starts to crack. If they had simply added that extra material to a larger, heavier bottom tipper the upper mechanism wouldn’t have been necessary.

What takes this from merely bad to actually funny was the inclusion of an “Intelligent rainfall monitoring system for data upload via Ethernet, GPRS and RS485”. I presume that was intended to connect with ‘industry standard’ meteorological stations but who’d tack a cheap sensor like this onto one of those $1000+ loggers? Even stranger to me is the idea you’d waste that much power on a simple reed switch. Fortunately there is a terminal block where you can bypass that all that baggage, though that’s also fragile to the point of single-use.

In the current political environment, the last thing I’d do is put something like this on my ethernet.

Bottom line is that you are better off buying a used unit from a quality manufacturer than you are getting a new one from a company that doesn’t have a clue what they are doing. For comparison, here’s how the mechanisms inside decent gauges look:

While the tipper inside a Texas/Onset gauge is made of plastic it is extremely tough. The needle point pivots are hardened and we’ve yet to see one fail. The magnets however do rust, but like the reed switch they are easily replaced with a bit of CA glue. Magnets have fallen from tippers on gauges from several different companies because differential expansion in tropical heat cracks the epoxy.

This High Sierra was built like a Russian tank and you see similarly rugged components inside older gauges from brands like Vaisala. After retiring the gauge itself, we repurpose these indestructible innards for drip monitoring projects inside caves.

Waterproofing your Electronics Project

Sealants

No matter what coating you use, everything must be scrupulously clean before it’s applied. Corrosion inducing flux is hydroscopic and there’s always some left hiding underneath those SMD parts – especially on cheap eBay modules. That means scrubbing those boards with alcohol and an old toothbrush, drying them with hot air & cotton swabs, and then handling by the edges afterward. Boards with only solid-state parts (like the ProMini) can be cleaned using an ultrasonic cleaner and 90% isopropyl but NEVER subject MEMS sensors or RTC chips to those vibrations. Polymer based RH sensors like the BME280, or MS5803 pressure sensors with those delicate gel-caps, also get careful treatment. After cleaning, let components to dry overnight in a warm place before you coat them with conformal. I clean new modules as soon as they arrive, and store them in sealed containers with desiccant.

This $25 jewelry cleaner gets warm during the 5 -10min it takes to get the worst parts clean so I run this outside to avoid the vapours.

MG Chemicals 422-B Silicone Modified Conformal Coating is the one we’ve used most over the years. Even with a clean board, adhesion to raised ICs can be tricky as surface tension pulls it away from sharp edges. Like most conformals, 422-B fluoresces under UV-A so a hand-held blacklight lets you check if it’s thin at some corner, or if you simply missed a spot. The RC/Drone crowd regularly report on many of the other options on the market like Corrosion-X, Neverwet, KotKing, etc. I’ve never seen a head-to-head test of how well the different conformals stand up over time, but the loggers we’ve retired after 5-6 years in service look pretty clean. I like the flow characteristics of 422 for our small scale application, though the vapours are nasty enough to make you wonder how much brain damage your project is really worth. You can also just burn the stuff off with a soldering iron if you need to go back for quick modification after its been applied. Conformals can be made from other compounds like acrylic or urethane, and at the top of the market you have vacuum-deposited coatings like Parylene.

Nail polish gets mentioned frequently in the forums and it’s usually a type of nitrocellulose lacquer. While it’s non-conductive and non-corrosive, acetate chemistry is not far off acetone which solvates a lot of stuff. So nail polish may soften some plastics and/or the varnish protecting your PCBs. It might also wipe the lettering off some boards. So the trick is to start with the thinnest layer possible and let that harden completely before applying further coats. Nail polish softens somewhat when heated above 200°C with a hot air gun enabling you to scrape it away if you need to rework something after covering. Overall it’s a good low-budget option that’s less complicated to apply than a UV cured solder mask solution.

One of our many early failures before we decided to **use only transparent epoxies**. The outer surface of this epoxy was intact; giving no hint of what was happening below.

Some epoxies permit slow water vapour migration leading to corrosion at points with leftover flux. Like the white example above, this potting was still OK at the surface. Both of these two failures pre-date our use of conformal on *everything*.

You never get 100% coverage so the areas underneath components usually remain unprotected. But coatings really shine as a second line of defence that keeps your logger going when the primary housing suffers minor condensation or makes the unit recoverable after a battery leak. Even when we intend to pot a circuit completely, I still give it a thin coat of conformal to protect it during the week long burn-in test before encapsulation. (If you are using cheap sensors from eBay, expect ~20% infant mortality) Be careful not to let coatings wick onto metal contacts like those inside an SD card module or USB connector and remember to seal the cut edges of that PCB so water can’t creep between the layers.

The delicacy of application required when working with IC sensors means that spray-on coatings are usually a bad idea, but there are exceptions. Paul over at Hackaday reports success using clear acrylic spray paint as a kind of poor man’s Parylene after “comparing the MSDS sheets for ‘real’ acrylic conformal spray coatings, and acrylic paint. All that’s missing is the UV indicator, and the price tag.” He uses this technique in outdoor electrical boxes but the first thing that comes to my mind is coating the screw terminals inside most rain gauges (see photo at end of post), and the exposed bus-bars you see in some climate stations.

Potting / Encapsulation

Hot glue is a quick way to seal one side of pass-through so you can pour liquid epoxy on the other.

Hot-melt Glue: Glue sticks come in a variety of different compounds. But it’s hard to know what’s in the stuff at your local hardware store so my rule of thumb is to just buy the one with a higher melting point. If you are gluing to something with a high thermal mass or a surface that can transfer heat (like copper PC board) the glue will freeze before it bonds. So preheating the item you are working on with a hot air gun before gluing is usually a good idea. I’ve used glue sticks for rough prototypes more times than I can remember, sometimes getting several months out of them before failure in outdoor locations. Cheaper no-name sticks tend to absorb a lot of water(?) and have more trouble sticking to PCB surface coatings. So it’s a temporary solution at best unless you combine it with something more resistant like heat shrink tubing. Add glue to what you’re sleeving, and it will melt and flow when you shrink – effectively a DIY adhesive lined heatshrink:

Here I used leather gloves to squeeze the hot-melt glue inside adhesive lined heat-shrink until it covered the circuit without bubbles. This one lasted ~8 months and then we **switched to epoxy fills**.

Hot glue is also quite handy for internal stand-offs or just holding parts together if they are too irregularly shaped for double-sided mounting tape to do the job. Isopropyl alcohol helps remove the glue if you need to start over.

Superglue & Baking Soda: These dollar-store items are perfect for sealing & repairing the polymer materials that most waterproof kit is made from. Adam Savage has a great demo of this on YouTube. That gusseting build-up technique is so fast it now accomplishes many of the things I used to do with hot glue. You can also use the accelerant trick to improve the strength of 3D prints made from PLA, as demonstrated by the ever-mirthful Robert Murray-Smith.

At this scale the viscosity of your encapsulating material is as important as any vapours it might give off. To avoid wicking problems, a ring of ‘dry’ plumbers putty can secure a filter cap over the sensor after the liquid potting compound sets.

Silicone Rubber comes in two basic types: ‘Acid cure’ which smells like vinegar and ‘Neutral cure’ which gives off alcohol while it hardens (often used in fish-tank sealants). Never use acid curing silicone on your projects. Hackaday highlighted a method using Tegderm patches to give silicone encapsulations a professional appearance although you can usually smooth things well enough with a finger dipped in dish detergent. In another Hackaday post on the subject, a commenter recommends avoiding tin-cured RTV silicones in favor of platinum cured which has longer lifespan and less shrinkage. Really thick silicone can take several days to cure but accelerants like corn-starch or reptile calcium powder can cut that to a few hours. It’s also worth knowing that silicones expand/contract significantly with temperature because this can mess with builds using pressure or strain sensors.

The $5 3440 Plano Box housings we use on **the classroom loggers** stand up to the elements well enough in summer months, but rarely have an adequate seal for the temperature swings in fall or winter. Judging by this post over at AVRfreaks, this is a common issue with most of the premade IP68 rated housings on Ebay/Amazon.

While silicone is waterproof enough for the duration of a dive it is NOT water-vapor proof. I often use GE Silicone II (or kafuter K-705) to seal around the M12 cable glands we use on student projects. However, water vapor eventually gets in when the housings “cool down & suck in moist air” causing condensation on the upper surface. Any container sealed with SR will eventually have an internal relative humidity comparable to the outside air unless your desiccants prevent that from happening. Always use desiccants with color indicator beads so you can see when they need to be replaced. Old desiccant pouches can be ‘recharged’ overnight in a food dehydrator and used ones can usually be found for ~$10 at your local thrift shop. Dehydrators are also great for reviving old filament if you have a 3d printer.

Liquid Epoxy: If money is no object, then there are industrial options like Scotchcast but many come in packaging that dispenses volumes far too large for a small batch of loggers. The best solution we could find at the start of this project was Loctite’s line of 50mL 2-part epoxies designed for a hand-operated applicator gun. Used guns can be found on eBay and there are plenty of bulk suppliers for the 21-baffle mixing nozzles at 50￠each or less. Loctite E-30CL has performed well over years of salt-water exposure on our PVC housings though it does fog & yellow significantly after about six months. Check the expiry date before buying any epoxy because they harden inside the tube when they get old. I’ve often received epoxies from Amazon that are only a month or two from expiring, so don’t buy too much at one time. And they don’t last long once you crack the seal, so I usually line up several builds to use the entire tube in one session.

A background layer of black EA E-60NC potting compound was used to improve the visual contrast. Once that set a clear acrylic disk was locked into place over the OLED with E-30CL epoxy – taking care to avoid bubbles. The acrylic does not yellow like the epoxy and can be thick enough to protect relatively delicate screens from pressures at depth.

My favorite use of liquid epoxy combines it with heat shrink tubing to make long strings of waterproof sensors:

A short piece of adhesive lined heat shrink seals one end of the clear tube to the cable. Epoxy is added to fill about 1/3 the volume. Then gentle heating shrinks the clear tube from the bottom up until the epoxy just reaches the top. Another adhesive lined ring seals the epoxy at the top of the tube. Then *gentle* heating of the clear heatshrink contracts it into a smooth cylinder. Extra rings are added to strengthen the ends.

We’ve deployed up to 24 DS18b20 sensors on a single logger running underwater for years – failing eventually when the wires broke inside intact cable jackets because of the bending they received over several deployments. This mounting takes a bit of practice, so have a roll of paper towels nearby before you start pouring and I usually do this over a large garbage can to catch any accidental overflow.

This image shows the typical appearance of E30CL after several months in seawater. The brown dot is a marine organism that bored into the epoxy, but they have never tried to drill through the housing itself… which says something about the toxicity of polyvinyl chloride.

The 2-Part fiberglass resins used for boat repair are another good potting option though they are often opaque with unusual coloration. Low viscosity mixes can be applied with precision using disposable syringes. It’s important that you transfer the stirred resin into a second container before pulling it into the syringe because there’s often a poorly mixed layer stuck to the sides of the first mixing cup. 3D printed shells are often used as casting molds but if all you just need is a rectangular shape then I’d use a LEGO frame lined with plastic food wrap. You can make single-use molds that conform to unusual shaped objects with sheets of modeling clay. When encapsulating large volumes you can make that expensive epoxy go farther with ‘micro-balloon’ fillers made from tiny phenolic or glass spheres. I’ve used old desiccant beads for this many times. Other inert fillers like talc power are sometimes used the lower peak temps during the curing process because fast setting epoxies get quite hot – sometimes too hot to touch. And speaking of heat, all encapsulation methods open the possibility that high power components could cook themselves. So avoid covering any heat sinks when you pot your boards.

Filler / Paste Epoxies: J-B weld is good low-budget option for exposed sensor boards. This two part urethane adhesive bonds well to most plastic surfaces and the filler it carries gives a working consistency somewhere between peanut-butter and thick honey. This is helpful in situations where you want to mount something onto a relatively flat surface like the falcon tubes we use with our 2-part Mini Loggers:

This BMP280 module already has a coating of conformal.

Shift the epoxy to the edges of the sensor with a toothpick

Although the original grey formulation gets it’s color from metal filings it is an electrical insulator. The older style JB weld that comes in two separate tubes is slightly thicker than that sold with an applicator syringe. It’s also worth noting that the stuff really needs at least 24 hours to set – not the 6 hours they claim on the package. There is also a clear version that can be used to protect light sensors, but I’ve yet to field test that in harsh enough conditions to see how it ages:

JB can also be used to secure delicate solder connections.

PTFE tape is a good diffuser if light levels get to high.

Unlike E30CL, clear JB-weld retains all those tiny bubbles.

A JB-weld coated DS18b20 after 6 months in the ocean. Specks of iron-particle rust can be seen, but when I broke away the coating the can underneath was still clean & shiny.

Wax: I haven’t tried this yet but it sounds like it could be fun: Refined paraffin can be purchased in food grade blocks for sealing jars, etc. at most grocery stores and it flows well into small component gaps. It’s also removeable, however the 45°C melting point which makes this possible is too low for outside deployments where I’ve seen loggers reach 65°C under tropical sun. A tougher machinable-wax can be made at home by mixing LDPE (plastic grocery bags) or HDPE (food containers) into an old deep fryer full of paraffin wax. The general recipe is a 4:1 ratio of paraffin to LDPE/HDPE and this raises the melting point enough to withstand summertime heat. Or you could try Carnauba wax which has a melting point above 80°C. You probably want to do partial pours with any wax based approach as shrinkage can be significant. If I had to make something even more heat resistant I’d consider an asphalt-based roofing cement. That’s a one-way trip, but it should last quite a while outside.

If you’re spending company money, it’s worth noting that many professional potting compounds like those from 3M are sold in hot-melt glue stick formats [usually 5/8″(16mm) diameter rather than the more common hobby market 1/2″]. This dramatically reduces waste & mess compared to working with liquid epoxies. Of course, it’s unlikely a DIYer will be able to use them as the applicators alone can set you back $300 to $600 USD.

Housings & Connectors

Although 3D printers are now affordable, we still use plumbing for our underwater housings so that others can replicate them with parts from their local hardware store. The design has changed significantly over time but this tutorial video from 2017 still stands as the best overall description of the ‘potting wells’ method we use to mount sensors on those PVC housings. It also shows how to make robust underwater connectors using PEX swivel adapters:

Smooth surfaces on the inside of those wells are scored with a wire brush or rough grit sandpaper before pouring the epoxy. After solvent welding, leave the shells to set overnight before adding epoxy because bad things happen when you mix chemistries. In fact, that’s a good rule for all of things listed in this post. Otherwise that expensive potting compound could turn into a useless rubbery mess. Another important thing to note is that we break the incoming wires with a solder joint that gets encapsulated before the housing penetration. This is more reliable than cable glands because water can’t wick along the wires if the jacket gets compromised. The shell shown in that video uses a Fernco Qwik-Cap as the bottom half of the housing and quite a few Qwik-cap housings have survived years under water although the flexing of that soft polymer limits them to shallower deployments. So these wide-body units get used primarily for drip loggers & surface climate stations. It’s worth noting that water vapour slowly migrates through the plastic knockout cap on the upper surface of our drip counters. So they require fresh desiccants once a year even though the logger could run much longer than that. A reminder that over the time scales needed for environmental monitoring, many materials one thinks of as ‘waterproof’ are not necessarily vapour proof.

For underwater deployments we developed a more compact screw-terminal build that would fit vertically into a 2″ cylindrical body. After many struggles with salt water corrosion we gave up on ‘marine grade’ stainless steel and started using nylon bolts to compress the O-ring. But these need to be tightened aggressively as nylon expands in salt water (we usually pre-soak the bolts overnight in a glass of water before sealing). Nylon expansion has also caused problems with the thick 250lb ties we use to anchor the loggers. In a high humidity environments, cheap nylon zip ties become brittle and break, while expensive industrial ties stretch and become loose. We’re still looking for better options but when you are working under water, you need something that can be deployed quickly.

We’ve tried many different epoxy / mounting combinations on the upper cap of those housings, but with the exception of display screens we stopped using the larger wells for underwater units because the wide flat disk of epoxy flexes too much under pressure. This torsion killed several sensor ICs on deployments below 10m even though the structure remained water-tight.

As our codebase (and my soldering skills) improved we were able to run with fewer batteries – so the loggers became progressively smaller over time. Current housings are made from only two Formufit table leg caps and ~5cm of tubing. The same swivel adapter used in our underwater connector now joins sensor dongles to the housing via threaded plugs. Sensor combinations can be changed easily via the Deans micro connectors we’ve used since the beginning of the project. Though the photo shows two stacked o’rings, we now use shorter bolts and only one. See this post for more details on the construction of this housing.

EPDM O-rings lose much of their elasticity after a couple of years compressed at 20-25m, so for deeper deployments I’d suggest using a more resilient compound. And there are now pre-made metal housing options in the ROV space that didn’t exist at the start of this project. With the dramatic size reduction in recent models, you occasionally find a good deal on older Delrin dive-light housings on eBay. Another interesting option is household water filter housings made from clear acrylic. They were too bulky for our diving installations, but this Sensor Network project at UC Berkeley illustrates their use as surface drifters.

Other Protection Methods

Mineral oil: PC nerds have been overclocking in tanks of mineral oil for ages, so it’s safe at micro-controller voltages. It’s also used inside ROV’s with a flexible diaphragm to compensate for changes in volume under pressure. Usually a short length of Tygon tubing gets filled with oil and stuck out into the water, or the tube can be filled with water and penetrates into the oil-filled housing. We use a similar idea to protect our pressure sensors from salt water:

The MS5803 pressure sensor is epoxied into a 1/2″-3/4″ male PEX adapter and a nitrile finger cot is inserted into the stem of a matching swivel adapter.

The sensor side gets filled to the brim with mineral oil

Then tighten the compression nut and use a lubricated cotton swab to *gently* check that the membrane can move freely.

Moving those membrane-protected sensors onto a remote dongle makes it much easier to recover the sensor after a unit gets encrusted with critters. Oil mounts have worked so well protecting those delicate MS58 gel-caps that I’ve now started using this method with regular barometric sensors like the BMP280. This adds thermal lag but there’s no induced offset in the pressure readings provided there’s enough slack in the membrane. Silicone oil is another option, and I’ve been wondering about adding dye so that it’s easier to spot when those membranes eventually fail. I avoid immersing any components with paper elements, like some old electrolytic capacitors, or parts that have holes for venting.

Bio-fouling on one of our loggers deployed in an estuary river. We only got three months of data before the sensor was occluded.

We remove calcareous accretions by letting the housings sit for a few hours in a bucket of dilute muriatic acid. Many of our loggers get this treatment every season.

Cable Protection: For the most part this comes down to either strain relief, or repairing cuts in the cable jacket. Air curing rubbers like Sugru are fantastic for shoring up worn cables where they emerge from a housing though I usually use plumbers epoxy putty for that because I always have it on hand for the housing construction. Sugru is far less effective at repairing cables than something that’s cheaper but less well known: self-fusing rubber electrical sealing tape (often called ‘mastic’ or ‘splicing’ tape). This stuff costs about $5 a roll and has no adhesive: when you wind it around something it sticks to itself so aggressively that it can not be unstuck afterward, yet remains flexible in all directions. This makes it perfect for repairs in the middle of a cable and we’ve seen it last months under water though it quickly becomes brittle under direct sun. And it does the job in places you can’t reach with adhesive lined heat shrink. I usually slap a coat of plasti-dip or liquid electrical tape over top of those repairs. This improves the edge seal and makes the patch look better. Self-fusing tape is also great for bulking out cables that are too thin for an existing cable gland, or combining several wires into a water-tight round-profile bundle for a single gland.

However the best advice I can give is to simply avoid the temptation of soft silicone jacket cables in the first place. Yes, they handle like a dream under water, but you will pay for it in the long run with accidental cuts and hidden wire breaks due to all that flexing. Another hidden gotcha is that silicone compresses at depth which brings the wires closer together – potentially increasing the capacitance of a long bus enough to interfere with sensor handshakes. Our go-to after many years at the game is harder polyurethane jacketed cables (like the ones Omega uses for their thermistors) It’s a pain in the arse to strip & solder, but you can pretty much drive a truck over it. And somehow that kind of thing always happens at least once during a field season.

Lost count of how many times ants/wasps have bunged up our rain gauges. And I should have coated those screws…

Double housings: Instead of sealing the housing to block out humidity, control the point where it condenses by surrounding an inner plastic housing with a second outer shell made of aluminum. Then let everything breathe naturally with the idea that condensation will happen first on the faster cooling aluminum, thereby protecting the inner components. I’ve heard of this being used for larger commercial monitoring stations but I’ve never been brave enough to try it myself. You want some kind of breathable fabric membrane over any vent holes to keep out dust (to IP6) and especially insects because if there’s a way into your housing they will find it and move in. Another simple but related trick is to fill any void spaces inside your housing with blocks of styrofoam: this minimizes the total volume of air exchanged when the temperature swings.

Addendum 2023-05-24: Testing Underwater Housings

People reading this post might also be interested in the DIY pressure chamber which we’ve been using to test our little falcon tube loggers. It’s made from a household water filter canister, with a total cost of about $70usd. The domestic water pressure range of 40-80psi overlaps nicely with sport diving depths.

A 2-Part Logger that runs >1 year on a Coin Cell

**This ‘two-part’ logger** fits nicely inside a 50mL Falcon tube. With a bit of practice, soldering the Pro Mini & RTC together **takes ~30 minutes**. The 4K EEprom on the RTC board will hold 4096 1-byte RTC temperature readings (~ 40 days worth @ 15 min. intervals) and that’s easily extended with $1 memory chips or modules.

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.

We **pressure tested** the centrifuge tubes: 50mL tubes can be deployed to 10m depth, 30mL tubes can go to 20m. And the loggers run fine under mineral oil for deeper deployments.

With just three core components as our starting point, the only hardware option was to remove the SD card. Groundwork for this change was already in place with our use of an EEprom to buffer data so that high-drain SD saves only occurred once per day. Getting rid of power hungry cards also opened up the possibility of running the entire unit from the coin cell on the RTC module. But a power budget that small will necessarily add complexity to the base code, which must minimize run-time even though EEproms are notoriously slow devices. And most garden-variety memory chips have a lower limit of 2.7v – so a nominal 3v CR2032 can only be allowed to fall about 250mv under load before we run into trouble. That voltage drop increases over time because the internal resistance of a coin cell is only 10 ohms when new, but approaches 100 ohms by end of life. In addition, it’s not unusual to see a 50mv delta at the battery terminals for every 5°C change in ambient.

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:

Clipping the VCC leg (the 2nd leg in from that corner) forces the DS3231 to run from the coin cell full time.

Disconnect the modules indicator LED by removing its limit resistor.

Remove the 200ohm charging resistor & bridge VCC to the backup power line at the black end of diode.

Three mods to the RTC module: Running from the Vbat also disables 32KHz output so I usually clip that header pin. Watch out for the ‘-M’ variant of the DS3231. We’ve had several batches of those over the years where the temperature register was off by 5°C or more. Try to use ‘-N’ or ‘-SN’ chips if you can get them.

Cutting the VCC leg depowers most of the logic inside the DS3231. However the chip will still consume an average of 3µA through VBat to keep the oscillator, temperature compensation & comparator logic working. RTC current can spike as high as 650µA every 64 seconds when new temperature readings occur. Bridging VCC to Vbat also means a 3.3v UART will push some sub-milliamp reverse currents through an older cell. But I’ve yet to have a single problem (or even any detectable warming) after many days with loggers connected during development. Despite dire manufacturer warnings that reverse currents beyond 1µA will heat manganese-dioxide/lithium cells until they explode, the ones I’ve used so far survive the abuse without issue. 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:

90° header tails on the left side are clipped to avoid accidental contact with the I2C jumpers later. Vcc & Gnd points left long. Load ‘Blink’ to test if the ProMini is working as soon as the header pins are on the board.

Carefully clip away the regulator from the 2-leg side. Also remove the power LED limit resistor.

**Optional:** Add the regulators orphaned 4.7µF input cap to the rail by bridging it to VCC.

Three removals & one addition prep this Pro Mini clone for assembly. The reset switch is removed to make room for a NTC thermistor circuit. **The logger can then only be restarted with a serial connection**, but that’s on purpose.

An 8Mhz Pro Mini continues as the heart of our loggers because the 328p is still the easiest low-power option for projects that aren’t computationally demanding. These eBay Pro Mini’s usually sleep below 1µA with the BOD turned off but 17µA with BOD on. It’s worth noting there are clones out there with fake Atmel chips that won’t go below 150µA sleep no matter what you do. Cheaper boards usually ship with ceramic regulator caps (instead of tantalums) but that just makes them more resilient if you accidentally connect power the wrong way. At 8Mhz the ‘official’ lowest safe voltage for the 328p is 2.7v, so that’s where the default BOD is usually set. But I sleep with BOD off because I’ve noticed that if the BOD gets triggered by low battery voltage then the processor goes into a high 1mA drain condition and this makes AA’s leak all over the inside of our normal 3-part loggers. 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.

Join the two components:

Resistor legs wrapped in heat shrink extend the A4/A5 I2C bus. **These two wires must cross over each other to align with connections on the RTC.**

Add a layer of double-sided foam tape to prevent contact between the two boards. Extend the VCC & GND headers with resistor legs. Then remove the tape backing.

Carefully thread the four I2C bus jumpers through the RTC modules pass-through port. Press the two boards together onto the double sided tape.

Solder the connections to the RTC module. Now you can see why I trimmed the three header pins on that one side.

**NOTE**: **Don’t trim** **the VCC & GND wires if you are going to add a rail buffering cap** – the leftover ‘tails’ make perfect connection points for that capacitor later. (see below for details)

Clip the (non-functional) 32kHz pin and add solder to the SQW header pin on the RTC module. Solder a resistor leg to interrupt input D2 on the Pro Mini.

Add heat shrink & **join D2 to the RTC SQW** alarm header.

Then heat shrink the entire stack with ~4.5cm of 25mm (1inch) diameter tubing & cut that away from the battery holder.

The 2-module stack usually draws ~1µA in powerDown, but with part variability some go up to 2µA. Cheap modules often have leftover flux residue which can cause current leaks. It’s worth the time scrub these boards with isopropyl alcohol before assembly to reach the lowest possible power consumption. I found *no significant difference* in sleep current between setting unused pins to INPUT_PULLUP or to OUTPUT_LOW.

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.

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 fairly aggressive 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 ‘raw’ option helps spot memory alignment errors when adding new sensors to the base code. There is also an unlabeled ‘test’ option which skips the EEprom erase during development & testing. **If you see random characters in the download window you have the baud rate set incorrectly.** (We have recently increased this to 500,000 baud in the github code) Reset the baud and the menu should display properly HOWEVER you then need to **close & re-open the window** (this restarts the promini with serial window at the correct baud). If you try to Ctrl-A copy out the data when the the window still has garbled characters at the top then **only** the bad start characters that will copy out.

The first menu 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.)

Battery replacement resets the DS3231 to Jan 1st 2000. After a data download the logger checks the clocks Oscillator Stop Flag (OSF) and, if needed, asks the user to enter current time as YYYY, MM, DD, HH(24h), MM, and SS to reset the clock:

**Note:** 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 time reset should only be done after installing a new battery or the settings will not be retained. You can force a time reset by temporarily removing the battery.

If you see this come up as the time stamp instead of 2000/01/01 then there’s a good chance the RTC’s memory 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.

Index TimeStamp(s) are then written to the internal EEprom at startup so the timestamp for each individual sensor reading can be reconstructed during data retrieval using the record number to create an offset that gets added to the original index value. 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 times in Excel.

After setting the RTC time, the sampling interval, and entering a brief deployment description, the on-screen menu then asks the user to enter the ‘start’ command again. Only when that second ‘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 slowly while the logger waits for the first sampling interval alarm to begin the run.

Main LOOP()

To save power, slow functions like digitalWrite() are 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; loosing about 1/2 milliamp-second of power per wakeup. 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 )

Here CLKPR restores the CPU to 8MHz just before entering powerdown sleep, and then slows the processor to 1MHz after waking. The extra height of that first spike is due to the pullup resistor on SQW. Cutting the trace to that resistor and using an internal pull-up reduces wake current by 750µA.

**Here the logger was left at 1MHz** when it entered powerdown sleep(s). Waking now takes 16 milliseconds – wasting a significant amount of power through the 4k7 pullup on SQW when the RTC alarm is still asserted at the start of the event.

[ 2023-05-31: UPDATE I came across several cheap eBay EEproms that would completely freeze the system when I lowered the system clock to 1MHz to save power in the Write_i2c_eeprom_array function. So I have removed that power saving technique from the code on GITHUB to make that codebase more generic.]

Sensor readings are captured every time the RTC alarms at SampleIntervalMinutes, but the ‘lowest’ coin cell voltage is usually recorded only ‘Once-Per-Day’ at the midnight rollover. The logger can be forced to log the battery voltage at every EEprom event by setting BatteryReadingEveryCycle=true at the start of the program. Two 16-bit buffer arrays are used to reduce the number of EEprom writes: sensorDataBuffer[ ] and it’s associated pointer are filled & written to the I2C EEprom in the forward direction while the opdDataBuffer[ ] gets filled and written backwards from the end of the memory space. So both can share the same EEprom and when the two EEprMemPointer(s) overlap that storage space is full and the logger shuts down. If there is more than one chip on the system then the two data streams can be sent to separate EEproms via the two EEpromI2Caddr defines at the start of the code.

CR2032 voltage is only checked during the Write_i2c_eeprom_array function because an unloaded coin cell voltage does not change – even when the battery is almost dead. At 1MHz the ProMini adds adds about 1.4mA to the EEproms 3mA*10msec sustained write current. ADC prescaler ratio is changed to compensate for the reduced main system clock speed. Peak load is reduced by looping through SLEEP_MODE_ADC readings until the battery voltage starts rising after the write finishes. This assures that the lowest coincell voltage 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 2785 mv cut-off, which happens when the internal resistance of the coincell rises at end of life.

Adding Sensors:

The ‘RTC_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.

We made extensive use these RTC temp records in our cave drip loggers at the beginning of the project. The accuracy spec is pretty bad at ±3°C, but they were usually within ±1 @ 25°C.

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.

The headers on this common BMP280 module align with the 32k headers in a ‘back-to-back’ configuration. The tails on the YL-90 breakout extend far enough to connect the two boards. Note **this sensor module has no regulator** which is better for low power operation.

Pin alignment between the YL-90 and this BH1750 module is slightly more complicated as you must keep the light sensor facing out. BMP280 sensors usually run about two years, but the BME280 variant (includes RH) has a shorter lifespan and should be replaced yearly.

After removing the EEprom’s redundant pullups, clip away the plastic spacers around the header pins. Then wiggle the BH1750 over the headers on the 32k module. Solder the points where the pins pass through the 1750 board. I2C pullups on the sensor boards can left in place.

I2C pin arrangement on the RTC doesn’t match the BH1750 module. Make the required cross-overs with a 4 wire F-F Dupont. (which comes with those red 32k boards) or soldering those connections is more robust.

NOTE: Support for both of the sensors shown above is included in the code on Github to serve as examples to guide other I2C sensor additions. Sensors are enabled by uncommenting the relevant defines at the start of the program and the base code also supports the ICU based NTC/LDR combination shown below.

I2C pullups on the sensor boards can be left in place to bring total pullup closer to the 3.3k ideal value that’s better for a 3v system than the existing 4k7 on the RTC. The open-drain implementation of I2C means that capacitance on the bus will slow down the rising edges of your clock and data lines, which might require you to run the bus more slowly. The more sensors you add, and the longer the wires, the worse the parasitic capacitance gets. So if you need long I2C wires drop the total bus pullup to 2k2.

The 662k LDO regulator on most eBay sensors wastes 3-4µA: For long deployments this can be removed & then bridging the in->out pads should bring your sleep back to ~1µA.

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. 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:

**D6=10kΩ** 1% reference resistor , **D7=10k NTC**, **D8=300Ω**, **D9=LDR** (5528). Note that the LDR could be replaced with any other type of resistive sensor. A typical 10kNTC reaches ~65kΩ near -10°C and a 10kLDR usually peaks near 55kΩ at night.

You MUST put the lines you are not reading into input mode to isolate them from the circuit when you read a specific sensor. It’s easy to kill the LDR with too much heat – in that case it becomes infinite resistance.

A 104 ceramic to GND completes the ICU timing circuit. With 0.1uF as the charge reservoir, each resistor reading takes ~1-2msec in sleep mode IDLE. With these sensors I jumper D2->SQW with a longer piece of flexible wire to avoid covering the D13 LED.

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 (or the freezer for -15°C). I add this NTD/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 the NTC/LDR at an ultra short five second interval till the EEprom is full. After passing that test you can be sure the core of the logger is ok before adding other sensors.

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

A **220µF 10-25v Tantalum** buffer cap can be added where the rail wires pass through the RTC module. Anything from 150 to 470µF will do the job of reducing older battery droop. After matching polarity, flip it over to bring the SMD solder pads to the top surface for easier soldering. Only necessary for long deployments where maximum lifespan is needed.

The code on GitHub assumes **A0=GND, A1=Green, A2=Blue**. No limit resistor is needed if you light the LED(s) by setting pins to **INPUT_PULLUP** which keeps the current below 50µA. **Leave the red led on D13** to show when you are trapped in a BOD restart loop. LED’s also make good frequency specific light sensors..

With a few strategic bends, single I2C sensors can be soldered directly to the pins.

EEprom & sensor additions push measured sleep currents to 2-3µA (so ~6µA actual w RTC’s 3.0µA) but that still gives a >1 year estimates on 110mAh. With all due respect to Ganssle et al, the debate about whether buffering caps should be used to extend operating time is something of a McGuffin because leakage currents are less important when you only have enough storage space for one year of operation. Even a whopper 6.3v 1000µF tantalum only increases sleep current by about 1µA. That’s 1µA*24h*365days or about ~ 8.76 mAh/year in trade for keeping the system above our 2.7v cutoff with barely a ripple. That means we don’t need to lower the BOD with fuses & custom bootloaders that bork code portability. Pushing the limits of fuse optimization can get a little flaky on these cheap boards, so it’s good to have those ‘Get out of jail free‘ defaults available at reboot. When you only service your loggers once a year, any tweaks that require you to remember ‘special procedures’ in the field are things you’ll probably regret. (And many of those cheap eeproms on eBay also have a 2.7v lower limit)

With a practiced hand you can do a memory expansion right on the RTC module without changing the sleep current: Here I’ve replaced the default 4k AT24c32 with a 64k AT24c512. 64k is the sweet spot for single sensors generating a 2-byte integer value as you can store ~340 days of data with a 15minute interval. The RTC modules default configuration pulls address pins high (=0x57) with a 4k7 resistor block, while the red YL-90 modules pull the address pins low (=0x50). So you retain the option of adding another eeprom on the I2C header pins after this upgrade. It is also possible to solder new chips onto those little red EEprom breakouts. Note: 128k AT24c1024 chips are slightly larger than the 32&64k so you have to bend the legs straight down which makes that soldering tricky. So I usually find it easier to just ‘stack’ two smaller 64k chips.

Here’s an example of stacking the EEproms. The rtc module pulls all address pins high (setting the lower default 4k eeprom in this picture to 0x57) but if you leave any address pins on the 64k chips ‘unconnected’ they get internally pulled to ground. (setting the bus address to 0x51 for the upper chip in this picture) AT24C512’s cost about 50¢ on eBay. The Write Protect pin can also be left unconnected. Each chip you add increases overall sleep current by ~1µA.

Then use both eeproms by changing defines at the start of the code:
define opdEEpromI2Caddr 0x57
define opdEEbytesOfStorage 4096
define sensorEEpromI2Caddr 0x51
define sensorEEbytesOfStorage 65536

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 10 to 30v if you can find them. While they are a bit bulky, electrolytics also work fine. The 220µF/25v caps I tested only added ~0.1µA to the loggers sleep current (whether tantalum or electrolytic) and these can be obtained on eBay for <50¢ each. Caps with high voltage ratings get you closer to the low leakage values you’d see with Polypropylene, Polystyrene or Teflon film.

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:

A triple event with a temperature sensor reading followed the transfer of two array buffers to EEprom. Battery current with no rail buffering cap. [Vertical scale: 500µA /division, Horizontal: 25ms/div]

Here a 220µF tantalum capacitor was used to reduce the peak battery currents from 2.5mA to 1.5mA for that same event.

Here a 1000µF tantalum [108J] capacitor reduces the peak battery current to 1mA. The 30msec sleep recovery times used here are not quite long enough for the larger capacitor.

Voltage across a coin cell that’s been running for two months with NO buffering capacitor. The trace shows the 2.5mA loads causing a 60mv drop; implying the cell has ~24 ohms internal resistance. [Vertical Scale: 20mv/div, Horizontal: 25ms/div]

The basic RTC-only sensor configuration reached a very brief 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)

This **very old coin cell** experiences a larger 250mv droop with no capacitor buffer. Note how the initial short spike at wakeup does not last long enough to cause the expected drop. [Vertical: 50mv/div, Horizontal: 25ms/div]

Adding a 220µF/25v tantalum capacitor cuts that in half but triples the recovery time. CR2032‘s usually plateau at 3.0v for most of their operating life, so the drop starts from there.
[Vertical: 50mv/div, Horizontal: now 50ms/div]

A 1000µF/6.3v tantalum added to that same machine limits droop to only 60mv. Recharging the capacitor after the save now approaches 200 milliseconds. [Vertical : 50mv/div, Horizontal: 50ms/div]

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 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….)

Current drawn in short bursts of 8MHz operation during sensor readings. The final EEprom save peaks at **~2.75mA draw** with CLKPR 1MHz CPU & Sleep_ADC readings.
[CH2: H.scale: 25msec/div, V.scale 500µA/div **via Current Ranger**]

Voltage droop on that same ‘old’ CR2032 used above reached a maximum **of 175mv** with NO buffering capacitor. Roughly equivalent to **64 ohms** of internal resistance.
[CH2: V.scale 25mv/div, H.scale 25ms]

Adding a 220µF tantalum capacitor to the rail holds that old battery to **only 50mv droop**. The 25v tantalum cap adds only 0.1µA leakage to the overall sleep current.
[CH2: V.scale 25mv/div, H.scale 25ms]

*This ‘solder-free’ AT24c256 DIP-8* carrier module is bulky compared to the red YL-90 boards, but it lets you easily upgrade to 64k AT24C512 & configure multiple I2C address. Here I’ve removed the redundant power led & pullup resistors.

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.

Most DIP8 EEproms are pin compatible with that carrier. 128k EEproms are usually divided into 64k blocks with sequential I2C addresses so the location variables don’t exceed uint16_t max of 65535. Heliosoph posted a way to combine multiple 64k EEproms into a single linear address range but with ‘combination’ sensors like the BME280 sometimes it’s easier to just send each sensor’s output to a different bank using the two bus addresses. Our code demonstrates how to do this with the OPD & sensor arrays.

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 arrays to 32 bytes each by increasing the wire library buffer length 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.

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.

Here wires extend connections for the thermistor & LED to locations on the surface of the housing. Alternate power is brought in from a small solar panel – but I will post more on that little experiment later 🙂

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 ‘ProMinillennium 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

30ml self-standing Caplugs from Evergreen Labware are another good housing option because they have a brace in the cap that just fits four 22gauge silicone jacket wires. Holes drilled through the lower stand enable zip-ties to secure the logger. The outer groove in the lid provides more surface area for JB-weld epoxy, giving you an inexpensive way to encapsulate external sensors. 1oz / 25ml is enough to cover about five of these sensor caps. Then clear JB weld can be used as a top-coat to protect optical sensors.

Drill the central channel to pass the I2C wires through the cap. Roughen the upper surfaces with sandpaper to give it some tooth for the epoxy.

Conformal coat the board before the epoxy. Work the epoxy over the sensor board carefully with a toothpick and wipe away the excess with a cotton swab.

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:

PTFE tape is also an excellent light diffuser to keep the logger cool or when reading the LDR

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:

Cr2032 voltage after 8months @30min sampling interval: BMP280 sensor reading Temp. & Pr. stored in 32k eeprom with NO 220µF rail buffering capacitor.

Coin cell after 8months @30min sampling interval: BH1750 sensor & 32k ‘red board’ eeprom (Sony brand battery: again, with no rail buffer cap).

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 reaches 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 usually reduced to about 1/2 that size.

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, but I expect rail caps to extend 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 4mA for 5-6ms which causes <50mv drop with a 220µF. My ‘scope shows that even with very old batteries the typical EEsave event doesn’t usually drop the rail more than 100mv, however the recovery time grows from less than 15msec to more than 100msec, so logging events look more like ‘blocks’ on the 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:

Typical sampling event peaks at 450µA with a 220µF rail buffer cap. The logger sleeps for 15msec battery recovery after every sensor reading or I2C exchange.

Every 64 seconds a DS3231 temperature conversion draws about 250-300µA for 170ms. There is no way to influence the timing of the RTC conversions.

Occasionally the RTC temp conversion happens in the middle of a logging event adding to the peak current.

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 temp conversions overlapping with the EEprom save will likely 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 after we initiate 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 220uF buffering the rail the logger can sleep for more than 10 minutes with no battery. So if you are trying to force a reset the RTC you may need to briefly short Vcc to GND (at the UART headers) after removing the coin cell. Note that we never use the brown out detection any more because on some occasions where it gets triggered the 328p draws ~1mA in that locked state until your batteries leak. The whole idea of BOD is to protect the logger, but high-bod-drain induced battery leakage sometimes destroys a logger before we can get back into the field. This is a mystery I have yet to resolve as brownout holds the MCU in reset, which floats all pins (even those that are being used as outputs) With the internal pull-ups disabled during reset, I have no idea where that current leak is coming from though it’s 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. 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.

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:

…and for those who already have soldering skills, we posted a RAPID 4 Minute review at 8x playback

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.

Also Note: 99¢ eBay sensor modules are cheap for a reason and it’s not unusual for us to see 25% of them rejected for strange behavior or infant mortality during week long burn-in tests. Relative accuracy spec for the BMP280 is supposed to be ±0.12 millibar, but when I run a batch of them side-by-side I usually see ±4 millibar between the records. So huddle test each batch to normalize them and be sure to look at each graph individually so you don’t included bad data in the normalization which could throw off ALL of the other corrections. Cheap BME280s sometimes refuse to operate with it’s individual RT/T/Pr sensors set at different oversampling levels, and at the highest x16 setting that sensor may use more power than your budget can sustain over a long deployment. Another thing to be aware of is that real-world installation means exposure to condensing conditions. For sensors with a metal cover (like the BMP280) internal condensation will happen at the dew point – often killing the sensor.

This $10 si7051 temp sensor module has ±0.1°C accuracy and sleeps in the nano amp range. You are more likely to find sensor modules with low power requirements on Tindie, than you are on eBay/Amazon. Be careful about boards with regulators, as their quiescent draw can be much larger than the sensors sleep current.

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 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

16x accelerated tests averaged about 1250 hours run time.

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. 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.

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

Adding two OLED displays to your Arduino logger (without a library)

Two I2C 0.96″ OLED screens used simultaneously. Left is split Yellow: 128×16 pixels & Blue: 128×48 pixels while the right screen is mono-white. The CODE ON GITHUB drives each screen in different memory modes to simplify the functions and uses internal eeprom memory to store fonts/bitmaps.

Oceanographic instruments rarely have displays, because they don’t contribute much to profilers being lowered off the side of a boat on long cables. And most of our instruments spend months-to-years in underground darkness, far from any observer. But a few years ago we built a hand-held flow sensor that needed to provide operator feedback while the diver hunted for the peak discharge point of an underwater spring. That prototype was our first compelling use-case for a display screen, and we used cheap Nokia 5110 LCDs because they were large enough to see in murky water. While driver libraries were plentiful, I realized that Julian Ilett’s shift-out method could pull font maps from the Arduino’s internal eeprom rather than progmem. This let us add those SPI screens to a codebase that was already near the memory limits of a 328p.

Modifications done to the second display: The only thing you must do for dual screens is change the bus address. Here I’ve also removed the redundant I2C pullups (R6&R7, 4k7) and bridged out the 662k regulator which isn’t needed on a 3.3v system. These changes usually bring sleep-mode current on 0.96″ OLEDs to about 2μA per screen. (or ~5μA ea. with the 662k regulator left in place)

Now it’s time to work on the next gen, and the 0.96″ OLEDs that we initially ignored have dropped to ~$2.50 each. Popular graphic libraries for these displays (Adafruit, U8G2, etc) provide more options than a swiss army knife but require similarly prodigious system resources. Hackaday highlighted the work of David Johnson-Davies who’s been using these screens with ATtiny processors where such extravagant memory allocations aren’t possible. His Tiny Function Plotter leverages the ssd1306‘s vertical access mode to plot a graph with a remarkably simple function. These OLED screens support two bus addresses, and that set me to work combining that elegant grapher with my eeprom/fonts method for a two screen combo. Updating Iletts shiftout cascade to I2C would loose some of the memory benefit, but I was already embedding wire.h in the codebuild for other sensors. It’s worth noting that David also posted a full featured plotter for the 1106, but these tiny displays are already at the limits of legibility and I didn’t want to lose any of those precious pixels. Moving the axis labels to the other screen forced me to add some leading lines so the eye could ‘jump the gap’:

My eyes had trouble with single-pixel plots so I made the line 2-pixels thick.

Histogram seems the best underwater visibility mode. Dashed lead-lines toggle off

A little repetition produces a bar graph variant.

The battery indicator at upper left uses the same function as the buffer memory progress bar in the center. Axis label dashes along the right hand side correspond to the lead lines on the next screen. My goal with this layout was ‘at-a-glance” readability. Horizontal addressing makes it easy to update these elements without refreshing the rest of the screen; so there is no frame buffer.

To drive these screens without a library it helps to understand the controllers different memory addressing modes. There are plenty of good tutorials out there, but the gist is that you first specify a target area on screen by sending (8-pixel high) row and (single pixel wide) column ranges. These define upper left & lower right corners of a modifiable region and the ssd1306 plugs any subsequent data that gets sent into the pixels between those corner points using a horizontal or vertical flow pattern. If you send more data than the square can hold, it jumps back to the upper left starting point and continues to fill over top the previous data. In ALL memory modes: each received byte represents a vertical 8-pixel stripe of pixels , which is perfect for displaying small fonts defined in 6×8-bit blocks. For the taller characters I use a two-pass process that prints the top of the large numbers first, changes eeprom memory offset, and then does a second pass in the next row to create the bottoms of the characters. This is different from typical scaling approaches, but gives the option of creating a three-row (24 pixel high) font with basically the same method, and since the fonts are stored in eeprom there’s no real penalty for those extra bits.

In addition to text & graphs, I need a battery status indicator and some way to tell the operator when they have waited long enough to fill sampling buffers. In the first gen units I used LED pips, but similar to the way vertical addressing made the Tiny Function Plotter so clean, horizontal mode makes it very easy to generate single-row progress bars:

void ssd1306_HorizontalProgressBar
(int8_t row, int percentComplete, int barColumnMin, int barColumnMax) {

// Set boundary area for the progress bar
Wire.beginTransmission(ssd1306_address);
Wire.write(ssd1306_commandStream);
Wire.write(ssd1306_SET_ADDRESSING);
Wire.write(ssd1306_ADDRESSING_HORIZONTAL);
Wire.write(ssd1306_SET_PAGE_RANGE);
Wire.write(row); Wire.write(row); // page start / end are the same in this case
Wire.write(ssd1306_SET_COLUMN_RANGE);
Wire.write(barColumnMin); Wire.write(barColumnMax); // column start / end
Wire.endTransmission();

//determine column for the progress bar transition
int changePoint = ((percentComplete*(barColumnMax-barColumnMin))/100)
+barColumnMin;

//loop through the column range, sending a ‘full’ or ’empty’ byte pattern
for (int col = barColumnMin ; col < barColumnMax+1; col++) {
Wire.beginTransmission(ssd1306_address);
Wire.write(ssd1306_oneData); // send 1 data byte at a time to avoid wire.h limits

// full indicator = all but top pixel on, also using the ‘filled’ byte as end caps
if (col<changePoint || col<=barColumnMin || col>=barColumnMax)
{ Wire.write(0b11111110); }
else { Wire.write(0b10000010); } // empty indicator = edge pixels only

Wire.endTransmission();
}
}

I mount screens under epoxy & acrylic for field units but hot glue holds alignment just fine at the prototyping stage, and it can be undone later.

And just for the fun of it, I added a splash screen bitmap that’s only displayed at startup. Since the processors internal eeprom is already being used to store the font definitions, this 1024 byte graphic gets shuttled from progmem into the 4k EEprom on the RTC modules we use on our loggers. It’s important to note that I’ve wrapped the font & bitmap arrays, and the eeprom transfer steps, within a define at the start of the program:

#define runONCE_addData2EEproms
—progmem functions that only need to execute once —
#endif

Since data stored in eeprom is persistent, you can eliminate those functions (and the memory they require) from the compile by commenting-out that define after it’s been run. One thing to note is that the older AT24c32 eeprom on our RTC module is only rated to 100kHz, while bus coms to the OLED work well at 400kHz.

You can update the memory in these screens even if the display is sleeping. So a typical logger could send single line updates to the graph display over the course of a day. There’s a scrolling feature buried in the 1306 that would make this perpetual without any buffer variables on the main system. Color might make it possible to do this with three separate sensor streams, and the 1106 lets you read back from the screens memory, providing an interesting possibility for ancillary storage. However with Arduino migrating to newer mcu’s I think creative code tricks like that are more likely to emerge from ATtiny users in future. As a logger jockey, the first questions that comes to mind are: can I use these screens as the light source in some interesting sensor arrangement that leverages the way I could vary the output?
What’s the spectra of the output? Could they be calibrated? What’s the maximum switch rate?

Screens are quite readable through the clear 3440 Plano Stowaway boxes used for our classroom logger. (here I’ve hot glued them into place on the lid) Avoid taking new sensor readings while information is being displayed on the OLED screens because they ‘pulse’ power to the pixels (100ms default) when information is being displayed. Each screen shown here peaks at about 20 mA (this varies with the number of pixels lit) so you could be hitting the rail with a high frequency load of about 40mA with dual screens – which could cause noise in your readings unless you buffer with some beefy caps. Also note that the screens tiny solder connections are somewhat fragile, so avoid putting hot glue on the ribbon cable.

As a final comment, the code on github is just an exploration of concepts so it’s written with readability in mind rather than efficiency. It’s just a repository of functions that will be patched into other projects when needed, and as such it will change/grow over time as I explore other dual screen ideas. Kris Kasprzak has a slick looking oscilloscope example (+more here) , and Larry Banks BitBang library lets you drive as many I2C screens as you have the pins for – or you could try a multiplexer on the I2C bus. These OLEDs will only get larger and cheaper over time. (& it will be a while before we see that with e-paper) An important question for our project is: which screens hold up best when subjected to pressure at depth? This was a real problem with the Nokia LCDs.

Addendum 2021-04-05:

I finally took a closer look at the noise from those cheap SSD1306 OLED screens, and was surprised to find the usual [104] & [106] decoupling combo simply weren’t up to the task. So I had to go to a 1000uF Tantalum [108] to really make a dent in it. Contrast settings reduced the current spikes somewhat, but did not change the overall picture very much.

The following are before & after graph of a start sequence from one loggers that end with 8 seconds of the logger sleeping while the latest readings get displayed on screen:

Logger current with a SSD1306 0.96″ OLED display: before & after the addition of a 1000uF Tantalum [108]

This unit was running without a regulator on 2x Lithium AA’s , and I had noticed intermittently flakey coms when the screen pixels were on. A forum search reveal people complaining about ‘audible’ noise problems in music applications, and others finding that their screens charge pump was driving the pixels near the default I2C bus frequency of 100kHz. I’ve dozens of these things lying around, and will add more to this post if testing reveals anything else interesting. The cap. pulls about 1A at startup so I’m not even sure I could put one that large on a regulated ProMini without pushing the MIC5205 into over-current shutdown.

Pro Mini Classroom Datalogger [2020 update]

2020 update to the Cave Pearl Classroom logger. This is a combination of inexpensive pre-made modules from the open-source Arduino ecosystem, and can usually be assembled by beginners in 1-2 hours.

(Latest Update: Mar 9, 2022)

Covid has thrown a spanner into the works for hands-on learning because even if you have the space to run a ‘socially distanced’ course, your students could still be sent home at any time. With that in mind, we’ve divided the build tutorial from 2019 into separate stages that make it easier to restructure the labs:

1) Component prep: requires the equipment you normally have access to in the lab like soldering irons, heat guns, drills, etc.

2) Logger assembly: can be done remotely with scissors, wire strippers & a screwdriver. All connections are made by Dupont connectors or by clamping wires under screw terminals.

The complete tutorial can be run in person or if students are ‘distance learning’, the instructor can do the soldering (~15-20 minutes per set) and send out kits for the overall assembly. Even that will be challenging through a zoom window, so you might want to add USB isolators to protect tethered student laptops from accidental shorts. One big challenge of running a course remotely is the extra time to test all the parts before sending them out. A ‘breadboard logger’ like the one shown later in this post lets you do that testing quickly. Another challenge is that other USB devices can push the bus too fast for the slow serial UARTS, causing them to drop off the system due to timing conflicts. (this is more common on Apple computers).

During ‘normal’ runs if a student gets a bad component, or accidentally zaps something in one of the labs, then it simply triggers a brief process-of-elimination lesson while they swap in replacements from the storage cabinet until things are working. But remote students won’t have that option unless you send two of every part – which might be viable approach considering how cheap these components are:

This is a variation of the logger described in our 2018 paper but we’ve removed the regulator/ voltage divider and added screw terminals + breadboards for faster sensor connections during labs. Bridging the I2C bus over the A2 & A3 pins leaves only two analog inputs on the screw-terminals. However for ~$1 you can add a 15-bit ADS1115 which provides differential analog readings using a fixed internal reference. So it’s unaffected by changes in battery voltage.

The main components:

(NOTE: complete parts list with supplier links can be found at the end of this post) You don’t need the cable glands if you are using sensors that will work inside the housing (light, temp, acceleration, magnetometers, GPS, etc.) Don’t put holes in your housing unless you are sure you need them.

Two FT232 adapters (in red) & a CP2102 UART module (blk) with a pin order that matches the ProMini headers:[DTR-RX-TX-3v3-CTS-GND]

You will need a UART adapter module to program your logger – This must support 3.3v output & is easier to use if the pin order matches the ProMini connections. UART modules available with the FT232, CP2102, & CH340 chips will all work if the chip maker supplies drivers for your operating system.
The Arduino IDE will NOT be able to communicate with your logger unless the driver for your UART module is installed on your Windows or MAC operating system. We use FTDI basic UART modules & you can download the driver at the FTDI website. There’s a basic installation guide at Adafruit , a more detailed one at Sparkfun, and PDF guides from FTDI.UART chips can only supply ~50mA so if your sensors need more current you might run out of power causing a restart of the ProMini. (A somewhat common problem when testing high-drain GPS modules or wireless transmitters)

(NOTE: I have connected ProMini’s to UART modules the wrong way round many, many, times, and none have been harmed by the temporary reversal. Also note that FAKE FTDI chips are a common problem with cheap eBay vendors, so it might be safer to buy a SiLabs CP2102, or CH340 UART from those sources. If you are using the ‘cheap ones’ it’s a good idea to include UART modules from two different manufacturers in the student kits to deal with the inevitable driver compatibility issues.)

Component Prep. Part 1: Pro Mini ( 3.3v 8Mhz ) (click any image to enlarge)

Install the UART driver & IDE. Solder the UART pins & test ProMini board with the blink sketch: Set the IDE to (1) TOOLS> Board: Arduino Pro or Pro Mini (2)TOOLS> ATmega328(3.3v, 8mhz) in addition to the (3)TOOLS> COM port to match the # that appears when you plug in the serial adapter.	With a known good Promini: Remove the power LED [in red square]. SPI bus clock pulses will flash the pin 13 LED – so leaving the pin13 LED connected will show you when data is being saved to the SD card.	Carefully remove the voltage regulator from the two leg side with snips. System voltage will vary over time, but the logging code we’ve provided on gitHub records the rail without a voltage divider by comparing it to the 328p’s internal bandgap. Lithium AA’s also provide a very flat discharge curve.
Add header pins to the sides but DO NOT SOLDER THE RESET pin HEADERS – we will be using those screw terminals as power rails.	Bridge the two I2C bus connections with the wire leg of a resistor. Connect A4->A2 & A5->A3.	Adding: DIDR0 = 0x0F; in Setup disables digital I/O on pins A0-A3 so they can’t interfere with I2C bus.

Lithium AA batteries are preferred when running a 2-cell unregulated system because the slope of an alkaline discharge curve will reach the ProMini’s 2.7v brown-out with >50% of the battery capacity unused. (note that SD cards are safe down to ~1.8v) While the voltage of a newLithium AA is usually 1.8v/cell, that upper plateau usually settles at ~1.79 v/cell within an hour or two of starting the logger. That briefly dips to 1.6v/cell during >100mA SD card save events at room temp. At temps near 5°C (in my refrigerator) the SD write battery-droop reached about 1.5 v/cell while on the upper plateau. Lithium cells only deliver ~50% of their rated capacity at temps below freezing, but that’s still an improvement. And alkaline batteries leak quite often – even when they are not fully discharged. To date, leaking batteries have been the most common reason for data loss on our project.

The MIC5205 regulator is not efficient at low currents, so removing it reduces your sleep current by ~50%. However that modification also forces you to deal with a rail voltage that changes over time. Thermal rise from 15 to 45°C will raise your rail voltage by about 100 millivolts on lithium cells that have been in service for a few months. (~ 5mv /°C) If your sensor circuit is a voltage divider that is being powered by the same voltage the ADC is using as a reference then the ADC readings are unaffected by this. However you will need to compensate for this in your calculations if your analog sensor circuits are not ratio-metric. Battery thermal mass will cause hysteresis unless you read your reference resistors under the same conditions. Regulated ProMini’s usually see the rail vary by ~10-20 millivolts over a similar range of temperatures however it’s worth noting the reg/cap combinations on cheap eBay modules can be subject to other problems such as noise; which can be even more problematic wrt the quality of your data. Most chip-based I2C sensor modules carry their own regulators (usually a 662k LDO) and use internal bandgap reference voltages so they are unaffected by the changing rail.

So making students deal with deal with power supply variation right from the start will save them from making more serious mistakes later because every component in your logger is a temperature sensor.

Component Prep. Part 2: Screw-Terminal Board & SD adapter

At the UART end of the board: Use a tinned resistor leg to repurpose the RESET terminals: Join RST & GND pins on the digital side and link the pins labeled RST, 5v and Vin for the positive rail. (include Vin only if the reg. has been removed! )	Label the screw terminal blocks that were connected under the shield with red & black markers to indicate the power rail connections. We have no reverse voltage protection – so insert AA’s w the correct polarity or the polarized Tantalum caps will burst.	Gently rock the Pro Mini back to front (holding the two short sides) until the pins are fully inserted. Some ST shields have slightly misaligned headers so this insertion can be tricky.
Remove the last three ‘unused’ female headers to make room for the SD adapter which fits perfectly into that pocket	NOTE: The SDfat library uses SPI mode 0 which sets the SCLK line low when sleeping causing a 0.33mA drain through the 10k SCLK pullup on the module.	Remove the bottom 3 resistors from the SD adapter – leave the top resistor near the C1 label in place!

Connection map for analog side of Nano S-Terminal board

NOTE: The Screw Terminal board we use in this build was designed for the 5v Arduino NANO, so the shield labels don’t match the Pro Mini pins on the ‘analog’ side. (the digital side does match) To avoid confusion may want to tape over those incorrect labels and hand write new labels to match the pattern above. Wire connections in this tutorial will be specified by ProMini pins: D10-13 are used for the SD card, A4/A2 is the I2C Data line, and A5/A3 is the I2C clock line.

Technically speaking, bridging the I2C bus (A4=data & A5=clock) over top of A2 & A3 subjects those lines to more capacitance and pin leakage. (regardless of whether that channel is selected as input for the ADC p257). However in practice, the 4K7 pull-up resistors on the RTC module handle that OK at the 100 kHz default bus speed.

Adding DIDR0 = 0x0F;

in setup disables digital I/O on pins A0-A3 to prevent interference with A0/1 ADC readings and the I2C bus on A2/3. If you want to disable only the digital IO on only A2 & A3 add

bitSet (DIDR0, ADC2D);
bitSet (DIDR0, ADC3D);

to setup{}.

Component Prep. Part 3: RTC Module, Indicator LED & Plano 3440 Housing

Remove two SMD resistors from the RTC board with the tip of your soldering iron. Note that this module includes 4k7 pullup resistors on SQW, SCL & SDA – leave those in place!	Optional! Cutting the Vcc leg lowers sleep current by 0.1mA but no I2C bus coms until coincell is installed.	Add 90 degree header pins to the I2C cascade port. Note: Cutting the VCC leg also requires you to ‘enable alarms from the backup battery’ with a registry setting.
Clean flux residue from both the main & cascade header pins with 90% isopropyl alcohol	Use a coin cell to determine the GND leg of a diffused common cathode RGB LED	Solder a 1-2k ohm limit resistor on the common GND. The precise value is not critical.
Add heat shrink, bend & trim the pins for connection to the screw terminal board. Pre-made 5050 modules also work but are not as good in light sensing mode.	Add holes in the rear struts of the Plano 3440 Stowaway housing to provide logger tie-down points later.	Stepped drill bits make clean holes in plastic housings for different thread diameters. We use glands with waterproof DS18b20 sensors on 1m cables.
Centered holes are ‘slightly’ closer the bottom of the box to allow the gland to rotate without hitting the rim. Inner nuts must also be able to rotate for tightening.	Rubber washers are added to both the inside AND the outside surfaces. PG7 sized washers also fit the M12 cable glands we use.	A 3440 Plano Box configured for two external sensors with nylon M12 cable glands for 3-6mm cables. After threading sensor cables I often seal the outside of the glands with a layer of silicone goop or nail polish.

As with the ProMini, it’s worth testing the RTC modules & SD adapters before logger assembly. I keep a breadboard version of the logger handy so I can test several at a time. If the RTC temp register reads too high I throw them out because the clock time is corrected based on those internal readings. You could also set the clock at this point if the coin-cell is already in place. Note the 5050 LED module on the breadboard shown above could replace the 5mm LED in this tutorial.

Forcing the RTC to run from the backup coin cell reduces sleep current by ~0.1mA, bringing a typical “no-reg & noRTCvcc” build to ~0.15 mA between readings. (with most of that for the sleeping SD card) As a rough estimate, Lithium AA’s provide ~7 million milliamp-seconds of power, and your logger will burn ~12,960 mAs/day at 0.15mA. So ‘in theory’ you could approach a year before you fall off the ‘upper plateau’. The clock will reset to Jan 1st, 2000 if you disconnect the RTC’s coin cell with a hard bump, but a couple of drops of hot glue should prevent this. If a reset does occur the time stamps will be wrong, but the logger will continue running the next day once the clock rolls around to the previous hour/minute alarm that was set. A CR2032 can power the RTC for about four years but if you cut the vcc leg you must set bit six of the DS3231_CONTROL_REG to 1 to enable alarms or the logger will not be able to wake up. (NOTE: our logger code does this by at startup with the enableRTCAlarmsonBackupBattery function, which only has to run once – the RTC remembers the setting after that)

The soldered components ready for assembly.

Cutting the Vcc leg on the RTC is optional: if you leave the RTC power leg attached you’ll see typical logger sleep sleep currents in the 0.25 mA range, which should still give at least 4 months of operation before you trigger a low voltage shutdown. I’m being conservative here because runtime also depends on sensors and other additions you make to the base configuration.

See our RTC page for more detailed information on this DS3231 module.

Assembly Part 1: The Screw-Terminal Stack

Part 1: This stack is the ‘core’ of your data logger.

It is very easy to get a couple of wires switched around at this stage so work through these instructions slowly & carefully. Connect the Dupont jumpers to the SD module so that the metal retainer clips are facing upwards after the logger is assembled. That way you can diagnose connection issues with the tip of a meter probe on the exposed metal and, if necessary, pull out & replace a single bad wire without taking everything apart. The extra wires you trim from the SD module are re-used.

Add 2-3 layers of double sided foam tape to the sides & center of the screw terminal shield. The tape needs to extend farther the height of the solder points.

Add single wires from the 20cm M-F Dupont cable to the SD adapter.

The ‘metal tabs’ of the Dupont ends are facing the large metal shield over the SD card.

A layer of double sided foam tape secures the connectors & extends over the solder points.

Red=3v3

Grey=CableSelect [d10]

Orange=MOSI [d11]

Brown=CLocK [d13]

Purple=MISO [d12]

Black =GND

Tape the SD adapter into place on the area that’s been cleared at the back of the screw terminal board.

Bend the jumper wires into place, mark the length & trim the original 20cm wires so that the final insulation length is 9cm or less.

Score the wire insulation about 1.5cm back from the wire end but do not remove the insulation.

Gently ‘pull & twist’ the scored insulation away from the wire to wind the thin strands together.

‘Fold-back’ about half of the stripped wire to provide more copper surface for the screw terminals to bite on to.

SD Connection pattern: Grey (CS) to ProMini D10, Orange (MOSI) -> pm D11, Purple (MISO) ->pm D12, Brown (CLK) -> pm D13 (NOTE the shield labels say A0-A3 which do not match the D10-13 pattern of the Pro Mini pins)

Bring the red SD wire over to the re-purposed RST power connection

and the black wire to GND on the digital side. At this point you could test the connections by inserting an SD card & running the CardInfo utility.

Connect the legs of the indicator LED at: D3=red, D4=GND, D5=green, D6=blue

Use the male ends of the wires you trimmed from the SD module to break out pin connections: Grey to A0, Brown to A1, Orange to D7, Purple to D8.

Add a layer of heavy duty (30Lb) double sided mounting tape to the back of the 2xAA battery holder. The battery holder wires need to be approx. 6inches/15cm long.

Attach the battery holder wires to RED>Vin & black>GND. The breakout wires from A0/1 & D7/8 should be about 12cm long to comfortably reach the breadboard area.

Checking continuity to the top of the ProMini confirms the header pins & solder connections under the terminal board are good.

Take a moment to check the continuity of the SD module wires. With one probe on the Dupont metal & the other on top of the corresponding ProMini pin – you should read ~1 ohm or less for each connection path. Occasionally you get a bad crimp-end on those multi-wire Dupont ribbons, and it’s easier to replace a bad wire at this stage than it is after the parts are in the housing.

Note: We’ve used the hardware interrupt port at D3 for the red LED channel, but if you have sensors that need that simply shift the LED over by one. Any digital I/O pins can be used for the LED, but 3,5 & 6 have PWM outputs which lets you do multi-color fades with analogWrite()

Assembly Part 2: Add RTC Module Jumper Wires

Attach Dupont jumper wires to the RTC module using White=I2C Data, Yellow = I2C Clock. Blue is the SQW alarm output line. Nothing is attached to the 32k output pin (cutting the Vcc leg disables 32k output)	Use 20cm M-F jumpers on the 6-pin side of the RTC module and shorter 10cm M-F wires on the smaller 4-pin cascade port.	Add a layer of double sided tape to secure the jumper shrouds, and provide housing attachment points for the module.
Add as small piece of 1/16″ heat shrink tubing to reinforce the contact spring. This reduces the chance that the connection will be bumped loose if the logger is dropped.	Write the installation date on the coin cell with a marker. A new coin cell should power the RTC for about 4 years. To avoid accidentally disconnecting the coin cell battery after the logger is assembled ->	Always check the backup voltage by placing the positive probe tip between the spring plates rather than on the surface of the cell.

Assembly Part 3: Connect modules inside the housing:

Part 3: This is what you are aiming for. (click any images in the table below to enlarge them)

The final assembly stage can be a bit tricky – sometimes the metal contact flaps under the green screw terminals are ‘sticky’ so take some time to loosen the screws and poke with the sharp end of your tweezers to make sure you can insert the bus wires from the RTC. It’s helpful to mark the wire lengths with a pen before cutting or stripping the RTC connections. When in doubt leave them a bit long. With screw terminals you always have the option of shortening those wire later on.

Attach the screw terminal stack onto the upper left corner of the housing, and the 2xAA battery holder in the lower right corner. These parts sb as far from each other as possible.	Add the first mini breadboard against the back so that it’s rear right edge aligns with the second rear support strut on the housing. Connect the long stack jumpers to that bboard to keep them out of the way.	Tape the RTC module into the lower left side of the housing, The blue board should be up against the front edge of the housing so that you can easily access the nearby screw terminals.
Measure, mark and trim: Red=3.3v, Yellow=>A3/A5 I2C clock, & White=>A2/A4 I2C data with enough wire to twist & fold the stripped ends under the terminals (~10cm of insulation length)	RTC module power & I2C bus connections: All ports on the analog side of the Pro Mini / Shield combination are occupied with a wire connection.	Connect the black wire to the re-purposed RST=GND, and the blue alarm wire to D2, leaving some extra wire length in a loop for strain relief. (5-6cm of insulation length)
Use the other side of the trimmed blue jumper wire to extend the D9 connection over to the breadboard. You want enough wire length that the pins reach back-most row on the breadboard.	Attach a cable mount to the back of the housing, as close to the bottom of the box as possible so that it does not interfere with closing the housing lid. You can trim those plastic mounts with scissors to make them thinner.	‘Loosely’ tie the long wires to the rear mount. Add another cable mount near the center and attach the 2nd b-board leaving equal side of the 2nd board.

Every year at least one student gets confused about the orientation of the connections inside the breadboard and connects all the jumper wires together in the same row – including the red and black power wires. The resulting short circuit usually kills either the Pro Mini, the UART module, and/or possibly even the USB port on the computer it’s connected to:

Each 5-hole row on the top of the breadboard is connected by a metal rail of spring contacts.

Also note that the internal connectors do not cross the ‘gutter’ depression in the middle, so each side of the breadboard board has its own separate set of connections.

Your Logger is now ready for testing!

A typical I2C sensor configuration with: BMP280 pressure, BH1750 lux & 0.96″ I2C OLED display – connected by short jumper wires made with a crimping tool. The combination shown above averages ~10mA with screen & cpu running, and a sleep current of 0.147 mA with a 1Gb Sandisk SD card. Without the SD, the sleep current on this unit was 37µA; with the sensor modules needing 2-3µA each & the sleeping 0.96″ OLED drawing ~7µA. A 25µA sleep current from the ProMini clone hints that the MCU might be fake but with a AA power supply it doesn’t really matter. Anything up to 250uA sleep current for a student build with an SD card connected should be considered good. Watch out for SD cards that don’t go to sleep properly as they can draw up to 30-50mA all the time.

(Note: Most of the time the tests listed below go well, however if you run into trouble at any point read through the steps suggested for Diagnosing Connection Problems at the end of this page.)

1. If you have not already done so, Install the UART driver. The IDE will NOT be able to communicate with your logger unless the driver for your UART module is installed on your operating system.

2. Install the Arduino IDE into whatever default directory it wants – we’ve had several issues where students tried to install the IDE into some other custom sub-directory, and then code wouldn’t verify without errors because the IDE could not find the libraries. The programming environment is written in Java, and the IDE installer comes with its own bundled Java runtime so there should be no need for an extra Java installation. However we have seen machines in the past which would not compile known-good code until Java was updated on those machines; but this problem is rare.

If you have not already done so, there are three things you need to set under the IDE>TOOLS menu to enable communication with the logger:

Note: that the “COM’ setting will be different for each computer, so you will have to look for the one that appears on your system AFTER you plug in the UART module.

Using 22AWG solid core jumpers to bridge a set of ‘power rails’ along each side keeps the wiring tidy. If you are using several I2C sensors you could also do this with those bus lines. After testing your prototypes, you can make them permanent by transferring your circuit to solder-able mini breadboards.

The one that’s easy to forget is choosing the 328P 3.3v 8Mhz clock speed. If you leave the 328p 5v 16mhz (default), the programs will upload OK, but any text displayed on the serial monitor will be random garbled characters because of the clock speed mismatch. Also be sure to disconnect battery power (by removing one of the AA batteries) whenever you connect your logger to a computer. There is no power switch on the loggers, which are turned on or off via the battery insertion. Use a screwdriver when removing the batteries so that you don’t accidentally cause a series of disconnect-reconnect voltage spikes which might hurt the SD card.

3. Test the LED – the default blink sketch uses the pin13 LED, but because that pin is shared with the SD card’s clock line it’s recommended that you test the RGB indicator instead by adding commands in setup which set the digital pin 4 act as the ground line for the LED:
pinMode(4, OUTPUT); digitalWrite(4, LOW);
Then change LED_BUILTIN in the blink code example to the number of a pin connected to your led module. (ie: for Red set it to 3, for Green use 5, or Blue use 6)

4. Scan the I2C bus with the scanner from the Arduino playgound. The RTC module has a 4K eeprom at address 0x56 (or 57) and the DS3231 RTC chip should show up at address 0x68.

The address of the eeprom can be changed via solder pads on the board, so it may have a different address. If you don’t see at least these two devices listed in the serial monitor when you run the scan, there is something wrong with your RTC module or the way it’s connected: It’s very common for a beginner to get some of the wire connections switched around during assembly but with the screw terminals this takes only a few moments to fix.

5. Set the RTC time, and check that the time was set – The easiest method would be to use the SetTime / Gettime scripts from our Github repository, but you first you need to download & install this RTC control library The SetTime script automatically updates the RTC to the moment the code was compiled (just before uploading) so only run SetTime once, and then upload the GetTime sketch to remove SetTime from memory. Otherwise SetTime will keep setting the RTC to the old ‘code compile time’ every time it runs – and one of the quirks of the Arduino environment is that it restarts the processor EVERY TIME you open a serial window. The SetTime script also has a function which enables the alarm(s) while running the RTC from the backup coin cell battery.

Note: the RTClib by Mr. Alvin that we use has the same name as the Adafruit library for this RTC and this can give you compiler errors if you let the IDE ‘auto-update’ all of your libraries because it will over-write the Alvin RTClib with Adafruit’s library of the same name. You then have to uninstall the Adafruit library ‘manually’ before re-installing Alvin’s RTClib again. This problem of ‘two different libraries with the same name’ was common back when this project started many years ago, but back then the IDE didn’t try to update them automatically.

Typical Cardinfo output on a windows computer when the connections are correct. If you format your SD card on an Apple computer there will also be a long list of ‘invisible’ .trash and .Spotlight files/folders at the root of the SDcard that show up with a CardInfo scan.

6. Check the SD card with Cardinfo
Note that the SDfat library we use to communicate with SD cards works well with smaller cards formatted as fat16, but ‘some’ Apple users find they can not write to cards in that format, requiring the SD cards to be reformatted as fat32 (note that most Apple systems have no problem with the fat16 SDcards). With either OS you should format the micoSD cards with this SDFormatter utility. With a 15 minute sampling interval, most loggers generate ~ 5Mb of CSV format text files per year. Older, smaller SD cards in the 256-512Mb range often use less power. Note that we apply internal pullup resistors on some of the SD card lines in setup to help the SD cards go into low power sleep modes more reliably.

7. Calibrate your internal voltage reference with CalVref from OpenEnergyMonitor.

This logger uses an advanced code trick to read the positive rail voltage to ~11mv resolution by comparing it to an internal 1.1v bandgap reference inside the processor. That internal ref. can vary by ±10% from one chip to another, and CalVref gives you a numerical constant which usually brings the starter script’s rail=battery readings within ±20mv of actual. An accurate rail reading is more important when you are using ANALOG sensors where the positive rail directly affects the ADC output, but you can skip this procedure if you are only using digital sensors because they use their own internal reference voltages.

Typical CalVref output (click to enlarge)

Load CalVref while the logger is running from USB power and then measure the voltage between GND and the positive rail with a voltmeter. (this voltage will vary depending on your computer’s USB output, and the UART adapter you are using) Then type that voltage into the entry line at the top of the serial monitor window & press the enter key. Write down the reference voltage & constant which is then output to the serial monitor window. I write these ‘chip-specific’ numbers inside the logger with a black marker as they are related only to the 328p processor on the ProMini board used to make that particular logger. You then need to change the line #define InternalReferenceConstant 1126400L in our starter code to match the long number returned by CalVref. Alternatively you could just tweak the value of the reference constant ‘by hand’, increasing or decreasing the value till the reported rail readings match what you measure with a voltmeter. Add or subtract ~400 to/from the constant to raise/lower calculated output by ~1 millivolt. After you’ve done this once or twice you can usually reach the correct value with a few successive guesses.

8. Find a script to run your on logger. For test runs on a USB tether, the simplest bare-bones logger code is probably Tom Igoe’s 1-pager at the Arduino playground. It’s not really deploy-able because it never sleeps the processor, but it is still a useful ‘1-pager’ for teaching exercises and testing sensor libraries. In 2016 we posted an extended version of Tom’s code for UNO based loggers that included sleeping the logger with RTC wakeup alarms. Our current logging “Starter Script” has grown since then to ~750 lines, but it should still be understandable once you have a few basic Arduino programming concepts under your belt.

Using the logger for experiments:

It’s important to understand that this logger was designed a teaching tool rather than a off the shelf, plug-&-play solution. Learning how to solder and getting some experience physically ‘putting things together’ are key outcomes. Wrangling code into shape driving some new sensor combination is another vital part of that process. So perhaps the best piece of advice I can give to new builders is:

Test, Test, and when you think your logger working: Test it Again

It’s nearly impossible to write code without little bugs and the only way to root them out is with multiple test runs. And even if the script you wrote is ‘perfect’ the processors on the sensor modules are also running code that you don’t have access to. For example, the mcu inside your SD card memory is more powerful, and may have more code on it than the ProMini at the heart of this logger. The only way to catch timing errors that might not get triggered until the 10th or 200th(?) pass is to run your code with a short 1 minute sampling interval until it’s crossed those roll-over thresholds many times. Use “Starting sensor X read” & “Finished sensor X read” print statements liberally during early USB tethered tests so you can observe the timing of events.

If you see water condensing like this on the lid of your logger then it’s time to examine the o-ring and add some extra sealant (nail polish or silicone) around the exterior of the cable glands. This logger quit after one week and it only lasted that long because of the desiccant pack.

Same thing applies to the sensor hardware in terms of durability, only now you have moisture to deal with. Everything that can be sealed in adhesive lined heat shrink, or potted in epoxy should be, once that hardware has passed your ‘dry’ tests. As a general rule no $10 sensor is going to be rated past IP68 which at best gives you 2-3 weeks of operation in the real world before water works it’s way in because of pressure imbalances caused by daily thermal cycling. You’d be surprised how easily moisture can wick along the air space ‘between the copper strands’ inside wires.

A doubling schedule works well for testing: Check the logfile at 1 hour, 2 hours, 4 hours, overnight, 1 day, 2 days, 4 days, 8, 16, 32… etc. Move to the next longer test only when the data from the previous run is confirmed. Keep a close eye on that battery burn down rate: Until you get the hang of putting your sensors into low current ‘sleep’ states – getting your first logger builds to run for a couple of months on new batteries should be considered a spectacular success. At every startup watch and wait for the pattern of LED flashes to confirm that the launch went smoothly – it is very easy to insert a battery or SD card crooked by ‘just enough’ that the unit does not start, and it’s very frustrating to discover you have no data a week later.

You never really know how long a sensor is going to last until you’ve deployed it – no matter what the manufacturer says in the data sheet. Even then we usually deploy three of every ‘new’ combination, and if we are lucky we get one complete data set for the year. Batteries leak, critters love to chew on things, and whenever humans come across something they’ve not seen before they will pick it up – especially if you had to invest a good deal of time securing your logger in exactly the correct position in the stream, on the tree, etc. We never deploy anything for real research until it has passed a several week-long rapid sample ‘burn-in’ test.

One positive aspect of the relatively loose fit of the Plano box lid is that it lets you run sensor tests quickly if you jumper your sensor module with thin 28-30 gauge wires:

A BMP280 pressure sensing module on long wires with crimped male dupont ends in the breadboard.	~1″ square of foam mounting tape with wires spaced evenly	Leave the red backing facing up as you fold the tape & wires over the corner edge.
The front corners of the box exert less pressure than the back corner shown here.	The sharp inner edge of the lid would cut the wire insulation if the tape was not there to protect, and even then you can only use this trick a few times.	The tape over the wires has to be replaced every time.

This gives you a chance to do some test runs before you commit to modifying the housing with holes or cable glands. For some indoor experiments this might be all you actually need, though I would still coat the ‘non-sensing’ parts of that dangling breakout with either conformal coating or clear nail polish. My general advice is: Do not put holes in the housing unless you are sure you need them. The most common failure mode for student loggers used in outdoor environments is from moisture seeping into the through the cable gland. Natural heating and cooling cycles creates pressure differences between the inside and outside of the logger that drive this vapor exchange. Moisture then condenses when temperatures fall at night, collecting on leftover flux residue to corrode contacts. An outer layer of self-fusing rubber mastic tape is often used on cable glands by electricians on out-door installations – even when using the expensive ones with soft rubber ‘cages‘.

After 1-2 minutes of kneading to mix the epoxy you have ~ 1 minute to work the putty into place. (it will become rock-hard within ~10 minutes). Be sure to leave yourself enough extra wire/space inside the housing so that you can open and close the lid easily without disconnecting anything after the putty hardens. This seal is not strong enough for underwater deployments, but it should easily withstand exposure to rain-storm events. HOT GLUE also works to seal pass-through ports with smaller wires & cables. Both pass-through methods can be helped by a layer of silicon caulking, nail polish, or conformal coating applied to the outside edges.

For a classroom project you could simply drill small a hole through the lid and stick the sensor/module on top of the housing, sealing the hole with double-sided tape. Thicker pass-throughs can be also be sealed reasonably well with plumbers epoxy putty which is non-conductive, and adheres quite well to metal, glass & plastic surfaces-> This putty is also a quick way to make custom mounting brackets, or even threaded fittings if you wrap it around a bolt (which you carefully remove before the putty hardens completely)

No matter which pass-through method you are using: Silica gel desiccant packs are important for any outdoor deployments and 5-10 gram packets are a good size for this logger.

Don’t subject these loggers to a lot of bashing around by deploying them in a rough surf-wash zone, or swaying freely in the wind off the end of a tree branch. Solid core wires are pretty good if you cut them to exactly the right length , but longer beadboard jumpers are very easy to bump loose, so once you have your prototype working, it’s usually best to re-connect the sensors directly to the screw terminals before deploying a logger where it could get knocked around. In a pinch you can secure breadboard pins with a small drop of hot glue to keep them from wiggling. Also remember that there are six ‘unused’ screw terminals on the base shield and these can be use to join wires together without soldering.

2019 Logger mounted on a south-facing window. The top surface was covered with white label-maker tape to act as a diffuser.

[Click HERE] to read about the many types of sensors can be added to this logger The transparent enclosure makes it easy to do light-based experiments. Grounding the indicator LED through a digital pin allows it to be used as both a status indicator, and as a light sensor. The code we use is a polarity reversal technique that relies on the tiny capacitance inside the LED. (~5 to 20pF & the processor port adds 10pF) This technique requires the LED to connected directly to ProMini inputs because breadboards can add random amounts of changing capacitance. At these sub pF ranges, any humidity that condenses between the pins will also upset the readings, so desiccants are required. And finally the reverse bias decay is affected by the starting voltage, so if you want to use the technique in a rigorous ‘analytical’ setting you should leave the regulator on your logger.

We have integrated this LED sensor technique into the starter script on GitHub. I’ve tweaked the playground version with port commands so the loop execution takes about 100 clock cycles instead of the default of about 400 clock cycles. The faster version was used to generate the following light exposure graph with a generic 5mm RGB LED, with a 4k7Ω limiter on the common ground.

Red, Green & Blue channel readings from the indicator LED (from a regulated logger) over the course of one day (logger photo above) The yellow line is from an LDR sensor the same unit, that was over-sampled to 16-bit resolution. The LED sensor has a logarithmic response and the left axis on the graph is a time- based measurement where more light hitting the LED sensor results in a lower number. Note how the RED signal changes before/after Blue & Green at sunrise & sunset. LED’s work well with natural full-spectrum light, but their limited frequency bands can give you trouble with the odd spectral distribution of indoor light sources. The peak response of LED’s is usually 30–50nm lower than their peak emission wavelength If we assume the Red was Aluminum gallium arsenide (AlGaAs) then that channel probably had an absorption band @ ~680 nm (~15 nm FWHM?) while the blue Indium gallium nitride (InGaN) channel is responding in the UV-A range, the Green channel (probably also InGaN ?) is most likely peaking around 420nm which is blue to our eyes. But without a spectrometer to test, these are just guesses. No temp. or cosine corrections were determined/applied, although blue/green channels tend to have low temperature coefficients because their bandgap is so far from the thermal spectrum. LED absorption bands have very little drift over time.

You can read more about LED based sensing techniques in the post about our leaf testing experiments which used two LEDs for a transmission-based variant of the NDVI ratio.

While the LED sensor idea is fun to work with, it’s a relatively slow method that can keep the logger running for many seconds when light levels are low. Figuring out how to take those light readings only during the day is a good coding exercise for students.

Note: VERY FEW light sensors can withstand exposure to direct sunlight. PTFE is an excellent light diffusing material which available in different sheet thickness. The ‘divot’ on the lid of the Plano box is just a bit larger than 55mm x 130mm x 3mm (depth). The “teflon” tape that plumbers use to seal threaded joints can also be used. PTFE introduces fewer absorbance artifacts than other DIY diffusers like ping-pong balls, thermoplastic, or hot melt glue. Most light sensors like the TSL2561 need 3-5mm of that PTFE sheeting to prevent the sensors from saturating in full sun. LED’s have logarithmic response so you lose quite a bit of detail above 40,000 lux unless you add a diffusion layer to attenuate the signal.

Full sun exposure can also cook your logger. Internal temps above 80°C may cause batteries to leak or damage the SD card. So if you are leaving the logger in full sun, add a bit of reflective film or some aluminum foil around the outside to protect the electronics. Of course if you have a light sensor you’ll need to leave some ‘window area’ for it to take a reading.

The RTC has a built-in temperature register which automatically gets saved with our starter script however that record only resolves 0.25°C, so we’ve also added support for the DS18b20 temperature sensor to the base code. A genuine DS18b20 (yes, fake sensors are a thing) draws very little power between readings and you can add many DS18b’s to the same logger.

Addendum: Diagnosing Connection Problems

If you successfully loaded the blink sketch to test the ProMini during your initial assembly, then issues during the testing stage are often due to incomplete connections to the I/O pins.

If you see only “Scanning I2C….. ” but nothing else appears when running the bus scanner, then it means that the ProMini can not establish communication with the RTC module. One common cause of this problem is that the white & yellow wires have been switched around at one end or the other. It’s also easy to not quite remove enough insulation from the wires to provide a good electrical connection under the screw terminals, so undo those connection and check that the wires were stripped, cleaned & wrapped together before being put under the terminals.

Scanner lockup can also happen if one of the I2C devices on the bus is simply not working: usually about 1 in 6 logger builds ends up with some bad component that you have to identify by process of elimination. (These are 99¢ parts from eBay…right?) It only takes a moment to swap in a new RTC board via the black Dupont connector and re-run the scan. If the replacement RTC also does not show up with the I2C scanner then it’s likely that one of the four bus lines does not provide a complete connection between the ProMini & the RTC module.

On this unit I measured 1 ohm of resistance on the I2C clock line between the ProMini A5 pin (on top of the board) and the SCL header pin on the RTC module. So this electrical connection path is good. It’s not unusual for each ‘dry’ connection to add 0.5-1 ohm of resistance to a signal path.

To diagnose: Unplug any power sources to the logger. Set a multi-meter to measure resistance and put one probe lead on the topmost point of the promini header pins, and the other probe on the corresponding header pin of the RTC module. If there is a continuous electrical connection between the two points then the meter should read one ohm or less. Higher resistances mean that you don’t have a good electrical path between those points even if they look connected:

1) the ground (black) wire should provide a continuous path from the ground pin on the digital side of the Promini board to the GND pin on the RTC module
2) the positive power (red) wire should provide a continuous path from the Promini positive rail pin (the one with the bundle of 4 red wires) to the VCC pin on the RTC
3) A4 (I2C data) near the 328P chip on the Promini must connect all the way through the screw terminal board and through the white Dupont wires to the SDA post on the RTC
4) A5 (I2C clock) nearest the UART end on the Promini must connect through through the yellow Dupont wire to the SCL header on the RTC .

You occasionally get a bad Dupont wire where the silver metal end is not in contact with the copper wire inside because the crimp ‘wings’ did not fold properly. With a pair of tweezers, you can ‘gently’ lift the little plastic tab on the black shrouds holding the female Dupont ends in place, and then replace any single bad wire. Be careful not to break the little black tab or you will have to replace the entire shroud.

Everyone uses short male-to-male Dupont jumper wires when they are creating test circuits because they are so convenient. But pre-made jumper wires are usually too long and so they get knocked around when you close the lid of the logger: so before you deploy take the time to convert your flexible-wire test circuit into one with solid core jumpers:

Flexible wires get used during the initial testing stages (when the lid of the logger is open).

Then the circuit gets re-done with solid core wires

Running wires ‘under’ the modules makes it easier to close the lid without disturbing the connections.

Also look at the little jumpers used to bridge the A4>A2 and A5>A3. If you have a ‘cold’ solder join, or an accidental bridge connection to something else, it could stop the bus from working. Re-melt each connection point one at a time, holding the iron long enough to make sure the solder melts into a nice ‘liquid flow’ shape for each solder point.

The connection diagnosis procedures described above also apply to the connections for the SD adapter board. Sometimes you end up with an adapter that has a defective spring contact inside the SD module, but the only way to figure that out is to swap it with another one.

Here a jumper wire from the ProMini pin is by-passing a bad connection on the screw terminal board. This is also how you would break out A6 & A7 if you need them.

Sometimes those screw terminal boards have a poor connection inside the black female headers below the ProMini. It’s also possible to accidentally over-tighten a terminal and ‘crack’ the solder connection below the board – or there may simply be a cold solder joint on one of the terminal posts. If you have only one bad connection, you can jumper from the ProMini header pins on top, down to the other wires under the corresponding screw terminal. If you accidentally strip the threads on a screw terminal, you can use this same approach but move that set of wires over to one of the three ‘unused’ screw terminals at the far end of the board. (beside the SD card adapter) If you’ve gotten through all of the above steps and still have not fixed the problem, then it might be time to simply rebuild the logger with a different screw terminal adapter board.

If you do accidentally kill the ProMini by shorting a pin, etc, you can carefully lever it up away from the screw terminal shield and replace it without having to rebuild the whole logger.

Build two loggers at a time, because that lets you determine whether problems are code related (which will affect both machines the same way) or hardware related. (which will only affect one of your two units) At any given time I usually have 2-3 units running overnight tests so that I can compare the effect of two different code/hardware changes the next morning. As a general rule you want to run a new build for at least a week before deploying to get beyond any ‘infant mortality’, and reach the good part of the bathtub curve.

An I2C OLED is quite readable through the lid of the housing. I often use Griemans text-only SSD1306Ascii library because it has a low memory footprint and sleeps well. While few loggers need live output when they are deployed, it’s often helpful to view diagnostic messages on battery power during testing. Adding two OLED displays let’s you view text & graphic output at the same time. Adding a capacitive touch switch lets you check your logger’s status at any time.

Addendum: A note about I2C sensors
The I²C bus is slow, so topology (star, daisy-chain, etc.) doesn’t matter much, but capacitance does. Both length & number of sensors increase capacitance. If you find that the devices work when you switch to a slower speed (e.g. 50 kHz), then this is probably your issue, and you need to minimize bus length and/or maybe decrease the combined resistance of the pull-ups to 2 kΩ or less. The DS3231 RTC module has 4k7 ohm pull-up resistors on the SDA & SCL lines & the Pro Mini adds internal 50k pull ups when the wire library is enabled. Typical I2C sensor modules usually add another set of 10k pullups so your ‘net pullup resistance’ on the I2C bus wires is usually: 50k // 4k7 // 10k = ~3k. With a 3.3v rail that means the devices draw 3.3v / 3k = 1 mA during communication which is fairly normal ( 3mA is max allowed) for total wire lengths below 1m. It’s common for pre-packaged sensors to arrive with housings at the end of about 1m of wire. If each sensor also adds another set of 10k pullups, the resistance generally compensates for the extra wire length, so the combination still works OK. But that depends on the cable too. A very bad cable might not even get to 0.5 meters and a very good cable (little capacitance to ground, no crosstalk between the wires) can go up to 6 meters.

For most sensor types there will be some options that draw much less power than others, and it’s always worth a look at the data sheet to make sure you are using one that will run longer. The best chip based sensors automatically go into low current modes whenever the bus has been inactive, but more often you need to ‘manually’ put the sensors to sleep via specific commands. So it’s also important to check if your sensor library supports those ‘go to sleep’ & ‘wake up’ commands – many common Arduino libraries do not.

Addendum: The importance of moisture protection

I was noodling around in the garden recently and installed a few loggers without desiccants because it was only a short experiment. It rained immediately afterward and I noticed a small amount of moisture condensed inside the plano-box housing. While this didn’t prevent the logger from functioning, it completely disrupted the LED light sensors because the increased humidity provided an alternate discharge path for the reverse bias charge on the LED’s:

Green channel data from a 5mm diffused RGB LED used as light level sensor. This logger was under some leaf cover, so there was considerable variability from the dappled light crossing over the sensor. An arbitrary cutoff of 200,000 was set in the code at low light levels.

After examining the O-ring I decided to add a little silicone to the channel holding the o-ring to improve the seal:

Gently pry the O-ring loose and apply sealant in the groove before replacing.

Bead only needs to be 3-4mm in diameter.

Close the housing & let the sealant set for a few days. The improved seal is especially visible at the corners

If you already have your logger assembled, try to find a silicone sealant that does not off-gas acetic acid (smells like vinegar) which could harm your circuits. If you are simply preparing empty boxes before assembly, then any regular bathroom sealant will do provided you give it about a week to finish curing.

Attach a mounting base to the lid so that a dessicant pack can be secured above the battery holder without interfering with any breadboard jumpers. Use a desiccant pack with color indicator beads, so you can check whether they are still working simply by looking through the transparent lid.

Addendum: If you want to leave the original regulator in place

It’s worth mentioning that an unregulated build will run for many months – even on 2x regular alkaline batteries which reach the system cutoff (at 2750mv) more quickly. The key deciding factor is whether your sensors require tight voltage regulation. The DS18b20 has a nominal low voltage limit of 3v. So if your project is making heavy use of those then there are only a few of modifications to the tutorial shown above to leave the ProMini’s default MIC5205 regulator in place:

Use straight header pins on the RTC modules cascade port to leave more space for the battery holder.

Only bridge the unused RST terminals to the rail connections – Leave the Vin terminal separate for the raw battery input.

Add a 10/3.3 Meg voltage divider to read the raw battery voltage on A0

You will need more space for the extra batteries. You could go with a 3xAA holder but that leaves about 50% or your alkaline battery capacity unused. Or you could keep the standard layout and use 4xAAA batteries.

An alternative would be to add a better regulator to some kind of intermediate battery connector. The the photo on the right shows two ceramic 105’s stabilizing an MCP1702-3302E/TO, while the 10/3.3M ohm divider provides a third output line so the ADC channel can monitor the raw battery voltage. This is the simplest way to retro-fit a unit that was built without a reg, with the added benefit that the new regulator is far more efficient than the original MIC5205 on the ProMini. It’s worth noting that even on a regulated logger you can monitor the rail voltage to determine when the main batteries are depleted because the regulators output will fall if the batteries reach a point below the minimum dropout voltage. If the rail falls under load by more than ~40mv, then it’s probably time to shut down the logger. With the regulator in place you probably don’t need the USB isolator, as the reg. itself cant pass more current than a USB port.

Addendum: Things to keep in mind when ordering parts

When a finished module arrives at your doorstep for less than you’d pay for any of its sub-components – it’s because you are doing the quality control.

My advice is to order at least 5-6 of each of the core components (Promini, RTC, SD module, screw terminal board, etc) with the expectation that about 10% of any cheap eBay modules will be DOA or have some other problem. I build in batches of six, and one logger typically ends up with a bad part somewhere. Having replacement bits on hand is your #1 way to diagnose and fix these issues. Bad parts tend to come “in bunches”, so if you scale up to ordering in quantities of 10’s & 20’s then spread those orders to a few different suppliers so you don’t end up with all your parts from the same flakey grey market production run. Order from different vendors in different odd-number quantities (11, 21, 9, etc.) because that will be the only way you can distinguish which supplier, sent which parts, because nothing on the package will be written in English.

The other thing I can’t stress enough is CLEAN ALL THE PARTS as soon as they arrive. Leftover flux is very hygroscopic, and solder points will start to corrode the moment your logger gets exposed to atmospheric moisture. I usually give everything about 10 minutes in a cheap sonic bath with 90% isopropyl alcohol, rinse with water, and then dry the parts out in front of a strong fan for an hour. Clean parts that can’t take the sonic vibration (RTC modules, humidity sensors, accelerometers, etc) by hand with a cotton swab. Then store parts in a sealed container with desiccant packs till you need them. I also coat the non-sensing/non-contact surfaces with a layer of MG Chemicals 422B Silicone Conformal Coating and let that dry for a day before assembling the loggers. One hint that you may have moisture issues is that the sensors seem to run fine during indoor tests but start to act strangely when you deploy the unit outside.

Used nut containers make excellent “dry storage” once the parts have been cleaned – but any air-tight container will do.

Another insight I can offer is that the quality of a sensor component is often related to the current it draws – if your ‘cheap module’ is pulling significantly more power than the data sheet indicates, then theres a good chance it’s a junk part. Usually if the sleep current is near spec, then the sensor is probably going to work. It is much easier to check low currents with a µCurrent or a Current Ranger. (I prefer the CR for it’s auto-ranging features) Sensors which automatically go into low current sleep modes take time – so you might need to watch the current for several seconds before they enter their quiescent states. A common reason for a short operating lifespan on a logger is an SD card that refuses to go into sleep mode. If there is an SD card connected to your logger you must initialize it (with sd.begin in setup) or it may ‘stay awake’ causing a constant 30-40mA drain and/or may even cause the logger to freeze up. Also with SD cards, if the freshly formatted throughput drops below its rated write speeds when tested with H2testw, then find another card to use. I avoid cards bigger than 2Gb because they usually draw too much current, and it’s rare to need that much space for a logger.

With cheap part variation & beginner soldering skills, student builds range from 0.15mA to .5mA sleep current. But even at that high end you should still get a couple of months of operation of from the logger on fresh batteries.


Bill of Materials:		~$22.00
	Plano 3440-10 Waterproof Stowaway Box Sometimes cheaper at Amazon. $4.96 at Walmart and there are a selection of larger size boxes in the series. 6″ Husky storage bins are an alternate option.	$5.00
	Pro Mini Style clone 3.3v 8mHz Get the ones with A6 & A7 broken out at the back edge of the board. Just make sure its the 8 MHz 3.3v version because you can’t direct-connect the SD cards to a 5v board. Watch out for non Atmel 328p chips.	$2.20
	‘Pre-assembled’ Nano V1.O Screw Terminal Expansion Board by Deek Robot, Keyes, & Gravitech (CHECK: some of them have the GND terminals interconnected) You will also need to have a few 2.0-2.5mm flat head screw drivers to tighten those terminals down. Since this shield is was originally designed for an Arduino Nano many of the labels on ST board will not agree with the pins on the ‘analog side’ of the ProMini.	$1.85
	DS3231 IIC RTC with 4K AT24C32 EEprom (zs-042) Some ship with CR2032 batteries already installed. These will pop if you don’t disable the charging circuit!	$1.25
	CR2032 lithium battery	$0.40
	SPI Mini SD card Module for Arduino AVR Buy the ones with four ‘separate’ pull-up resistors for removal if you decide to mosfet-switch the SD power lines.	$0.50
	SD card 256mb -to-1Gb Test used cards from eBay before putting them in service. Older Nokia 256 & 512mb cards have lower write currents in the 50-75mA range. This is less than half the current draw on most cards 1gb or larger. I tend to avoid older cards labeled as ‘TransFlash’ because they seem to have more controller artifacts during saves. Small 128mb & 256mb cards under the name Cloudisk have appeared on eBay, and so far they seem to be working ok.	$2.00
	Small White 170 Tie-Points Prototype Breadboard These mini breadboards for inside the logger are also available in other colors.	$0.60
	30cm Dupont 2.54mm M2F 40wire ribbon cable Dupont connector hook-up wires might be expected to add an ohm or two of resistance and carry at most 100mA reliably with their thin 28-30 gauge wires. Each 40-wire cable will let you make at least 2 loggers.	$1.55
	10cm Dupont 2.54mm M2F ribbon cable Sometimes these 10cm cables are harder to find, so you can just use the longer 20cm wires in a pinch. It’s usually also helpful to have a few Male-to-Male 10cm cables for interconnections on the breadboard.	$1.00
	2×1.5V AA Battery Batteries Holder w Wire Leads If you are running an unregulated system on 2 lithium batteries, then you can use a 2x AA battery holder. If you need to keep the regulator in place to stabilize the rail voltage for particularly picky sensors, use alkaline batteries and a 4xAA battery holder. Watch out for ‘cheap’ battery holders with weak plastic at the connection ends which will slowly bend away from the batteries until they pop out in warmer climates. If that happens you can add a zip tie belt around the holder to keep the cells in place when the plastic softens.	$0.50
	5mm Common cathode RGB LED Although you might want to use 10mm LEDs to increase surface area when using the LED as a light sensor. They also look better.	$0.10
	M12 Nylon Cable Glands (pack of 20 pcs) You will also need some extra rubber washers.	$0.70 /2pcs
	3.3V FT232 UART Module (get at least 2-3 modules – they are easy kill with a brief short) *jumper the pads on your UART module to 3.3v output before using it!* You will also need a few USB 2.0 A Male to Mini B cables. You may need to install drivers from the FTDI website depending on your OS. These boards can only supply ~50mA which can be tricky if your sensors need more for sustained periods. If you are running the class via distance learning it’s probably a good idea to also get some CP2102 (c231932) UART boards and send your students one of each type. If they are unable to get the drivers working for the FT232, they have a second option. You may have to hunt around for non-FTDI chip boards with the same pin order as the ProMini [ DTR-RX-TX-3v3-CTS/gnd-GND ] The DTR pin is critical for uploading code, while the CTS (clear to send) is an input pin for the FTDI chip only and CTS is not used by the ProMini (so it’s usually just tied to ground). So many UART adapters only have 5 connections and you have to cross the wires over each other to get the connections sorted out. Watch out for 6-pin UART modules that put a (+)ive power connection in the same physical alignment as the GND connection on the ProMini – those boards can create a short circuit unless you re-route the wires. It’s also worth knowing that UARTs can communicate directly to serial sensors like GPS modules for testing. Premade 30cm 6-pin Dupont jumper cables are also available..	$2.75
	3M Double-side Foam Tape, LEDs, header pins, 3/4 inch zip Tie Mounts, etc… I use 30lb ‘outdoor’ or VHB (high bond) foam tape, each logger takes ~30cm length	$1.00
Some extra tools you may need to get started: (not included in the total above)
	2in1 862D+ Soldering Iron & Hot Air station Combination a combination unit which you can sometimes find as low as $40 on eBay. Or you can get the Yihua 936 soldering iron alone for about $25. While the Yihua is a so-so iron, replacement handles and soldering tips cost very little, and that’s very important in a classroom situation where you can count on replacing at least 1-2 tips per student, per course, because they let them run dry till they oxidize and won’t hold solder any more. Smaller hand-held heat-shrink guns are available for ~$15, $10 80Watt-AC & $5 USB soldering irons are quite useable.	$15.00 – $50.00
	SYB-46 270 breadboards (used ONLY for soldering header pins ) Soldering the header pins on the pro-mini is MUCH easier if you use a scrap breadboard to hold everything in place while you work. I use white plastic breadboards that only have one power rail on the side since I won’t mistake them for my regular breadboards. I also write ‘for soldering only’ on them with a black marker.	$1.30
	SN-01BM Crimp Plier Tool 2.0mm 2.54mm 28-20 AWG Crimper Dupont JST I use my crimping pliers almost as often as my soldering iron – usually to add male pins to component lead wires for connection on a breadboard. But making good crimp ends takes some practice. But once you get the hang of it, Jumper wires that you make yourself are always better quality than the cheap premade ones.	$16.00
	Micro SD TF Flash Memory Card Reader Get several, as these things are lost easily. My preferred model at the moment is the SanDisk MobileMate SD+ SDDR-103 or 104 which can usually be found on the ‘bay for ~$6.	$1.00
	Side Shear Flush Wire Cutters & Precision Wire Stripper AWG 30-20 HAKKO is the brand name I use most often for these, but there are much cheaper versions.	$5-10
	Dt380 Multimeter Dirt Cheap & good enough for most classroom uses.	$3.50
	Syba SY-ACC65018 Precision Screwdriver Set A good precision screwdriver set makes it so much easier to work with the screw terminal boards. But there are many cheaper options. The screw terminal boards need 2mm (or less) flat slot tips.	$12.00
	Donation to Arduino.cc If you don’t use a ‘real’ Pro Mini from Sparkfun to build your logger, you should at least consider sending a buck or two back to the mother-ship to keep the open source hardware movement going…	$1.00

.. and the required lithium AA batteries are also somewhat expensive, so a realistic estimate is about $25-30 for each logger when you add a couple of sensors. Expect parts from low-end suppliers to take 4-6 weeks to arrive and always order at least 50% more than you actually need so you have spares. If you’re pressed for time everything on this list is also available from trusted first-tier suppliers like Sparkfun, Adafruit, Pololu, etc – but you will pay 5-10x as much, with an additional $10-15 shipping charge unless you pass the minimum order level. Amazon is now in a kind of weird grey zone between the two as many vendors that sell on eBay, are also selling on Amazon for 2-3x the price.

Addendum: Using a more advanced processor

Moteino MEGA based Cave Pearl Logger

After you’ve built a few ProMini based loggers, you might want to try a processor upgrade. The 1284p CPU has twice the speed & 4x the memory, but delivers comparable sleep current & operating life.

Addendum: Low Temp. effects on 2x Lithium powered logger

2x LithiumAA millivolts (blue-left) vs RTC Temp °C (orange-right) on cells that have been in service for 5 months. We will leave this unit running over winter to see how DS18b20 on that logger handles it if/when the cells fall below the DS18’s 3V minimum, and then rise back up again. (click image to enlarge)

A crop of these loggers have been running in our back-yard garden since mid-summer with various sensor combinations. Winter is finally reaching us so we can now observe how the cold affects an unregulated 2x Lithium AA supply. This ‘student build’ sleeps at ~170uA and has been running for five months. The battery curve was virtually flat above 15°C but it is now being quite strongly affected. Peak loads from the SD card are in the range of about 150mA and the unit is running with a 5 minute sampling interval.

Note: 2022-10-01: We’ve had several unregulated 2xLithium cell loggers running over winter now, with temperatures varying from -20°C to +40°C throughout the year. On units where the sleep current is in the low 20uA range, we typically see the voltage supplied by two cells in series vary due to that that 60 degree range from a low of 3350 to about 3550 mv on hot summer days. So about 200mV thermal delta in normal environmental conditions.

According to Energizer: In ultra-low drain applications like these dataloggers, the discharge curve has a distinct two stage profile. The first ‘very flat’ plateau occurs at slightly higher voltage (nominally 1.79V (or ~3.58v for two cells) @ 21°C) is nearly independent of depth of discharge. This unchanging stage lasts for about 2/3 of the batteries lifetime. The second stage occurs at a slightly lower voltage (nominally 1.7V (or ~3.4v for two cells) @ 21° C) where the cell voltage then decreases slowly as a function of depth of discharge. In my longer run tests, when the two lithium AA cells in series have fallen below ~3.1v, it’s time to shut down the logger.

Addendum: Adding a TTP233 Capacitive Switch lets you check your logger ‘any time’

With a capacitive touch switch that works through the housing, you can check the status of your logger at any time.

Our next tutorial post in the student logger series: Enhance your Logger with an OLED & T233 Capacitive Touch Switch is an excellent ‘next step’ for people using this logger in a classroom setting. The method is easily adapted to trigger ‘opportunistic’ readings in environments that require manual control, but it’s also handy when you need to check the battery level on a complex installation that you don’t want to disturb before the end of the experiment.

Addendum: Another fine crop of student loggers this year!

A soil sensing lab where students characterize daily water use by various potted plants.

Pro Mini & DS322 RTC module data logger using a standard Falcon Tube for a housing. The 4k EEprom on the RTC module provides enough room for approximately 1.5 months of RTC temperature readings at a 15 minute interval

Addendum: A 2-Part ‘mini’ logger developed in 2022

Dr. Beddows instrumentation students have been building this Plano-boxed logger for years, and the ability to swap sensors or add an OLED screen has allowed continuous course development. But for those wanting a quick & simple ‘bare-bones’ logger for ‘single sensor tasks’ we’ve developed a 2-Part logger that can be built in about 20 minutes. Without the SD card this unit is memory constrained, and data download is handled via through the serial monitor window in the IDE. Running from a coin cell required the addition of several more advanced code techniques than the 2020 student logger at the beginning of this post. But for instructors, this is the least expensive option that still provides your students with an opportunity to directly edit the code and change the hardware to configure their own projects. The 2-part logger works well with standard I2C sensors like the BMP280 or the BH1750. Note that one-wire DS18b20’s may not like running from the CR2032 which plateaus right at the 3v lower limit of their voltage range. But it’s generally better to us an NTC thermistor as described in the post. Also the coincell does not have enough power to drive an OLED, and from a teaching perspective, adding screens to the logger really increases student engagement because of the real time feedback.

How to make Resistive Sensor Readings with DIGITAL I/O pins

AN685 figure 8: The RC rise-time response of the circuit allows microcontroller timers to be used to determine the relative resistance of the NTC element.

For more than a year we’ve been oversampling the Arduino’s humble ADC to get >16bit ambient temperature readings from a 20¢ thermistor. That pin-toggling method is simple and delivers solid results, but it requires the main CPU to stay awake long enough to capture multiple readings for the decimation step. (~200 miliseconds @ 250 kHz ADC clock) While that only burns 100 mAs per day with a typical 15 minute sample interval, a read through Thermistors in Single Supply Temperature Sensing Circuits hinted that I could ditch the ADC and read those sensors with a pin-interrupt method that would let me sleep the cpu during the process. An additional benefit is that the sensors would draw no power unless they were actively being read.

Given how easy it is drop a trend-line on your data, I’ve never understood why engineers dislike non-linear sensors so much. If you leave out the linearizing resistor you end up with this simple relationship.

The resolution of time based methods depends on the speed of the clock, and Timer1 can be set with a prescalar = 1; ticking in step with the 8 mHz oscillator on our Pro Mini based data loggers. The input capture unit can save Timer1’s counter value as soon as the voltage on pin D8 passes a high/low threshold. This under appreciated feature of the 328p is more precise than typical interrupt handling, and people often use it to measure the time between rising edges of two inputs to determine the pulse width/frequency of incoming signals.

You are not limited to one sensor here – you can line them up like ducks on as many driver pins as you have available. As long as they share that common connection you just read each one sequentially with the other pins in input mode. Since they are all being compared to the same reference resistor, you’ll see better cohort consistency than you would by using multiple series resistors.

Using 328p timers is described in detail at Nick Gammons Timers & Counters page, and I realized that I could tweak the method from ‘Timing an interval using the input capture unit’ (Reply #12) so that it recorded only the initial rise of an RC circuit. This is essentially the same idea as his capacitance measuring method except that I’m using D8’s external pin change threshold at 0.66*Vcc rather than a level set through the comparator. That’s almost the same as one RC time constant (63%) but the actual level doesn’t matter so long as it’s consistent between the two consecutive reference & sensor readings. It’s also worth noting here that the method doesn’t require an ICU peripheral – any pin that supports a rising/ falling interrupt can be used. (see addendum for details) It’s just that the ICU makes the method more precise which is important with small capacitor values. (Note that AVRs have a Schmitt triggers on the digital GPIO pins. This is not necessarily true for other digital chips. For pins without a Schmitt trigger, this method may not give consistent results)

Using Nicks code as my guide, here is how I setup the Timer1 with ICU:

#include <avr/sleep.h> // to sleep the processor
#include <avr/power.h> // for peripherals shutdown
#include <LowPower.h> // https://github.com/rocketscream/Low-Power

float referencePullupResistance=10351.6; // a 1% metfilm measured with a DVM
volatile boolean triggered;
volatile unsigned long overflowCount;
volatile unsigned long finishTime;

ISR (TIMER1_OVF_vect) { // triggers when T1 overflows: every 65536 system clock ticks
overflowCount++;
}

ISR (TIMER1_CAPT_vect) { // transfers Timer1 when D8 reaches the threshold
sleep_disable();
unsigned int timer1CounterValue = ICR1; // Input Capture register (datasheet p117)
unsigned long overflowCopy = overflowCount;

if ((TIFR1 & bit (TOV1)) && timer1CounterValue < 256){ // 256 is an arbitrary low value
overflowCopy++; // if “just missed” an overflow
}

if (triggered){ return; } // multiple trigger error catch

finishTime = (overflowCopy << 16) + timer1CounterValue;
triggered = true;
TIMSK1 = 0; // all 4 interrupts controlled by this register are disabled by setting zero
}

void prepareForInterrupts() {
noInterrupts ();
triggered = false; // reset for the do{ … }while(!triggered); loop
overflowCount = 0; // reset overflow counter
TCCR1A = 0; TCCR1B = 0; // reset the two (16-bit) Timer 1 registers
TCNT1 = 0; // we are not preloading the timer for match/compare
bitSet(TCCR1B,CS10); // set prescaler to 1x system clock (F_CPU)
bitSet(TCCR1B,ICES1); // Input Capture Edge Select ICES1: =1 for rising edge
// or use bitClear(TCCR1B,ICES1); to record falling edge

// Clearing Timer/Counter Interrupt Flag Register bits by writing 1
bitSet(TIFR1,ICF1); // Input Capture Flag 1
bitSet(TIFR1,TOV1); // Timer/Counter Overflow Flag

bitSet(TIMSK1,TOIE1); // interrupt on Timer 1 overflow
bitSet(TIMSK1,ICIE1); // Enable input capture unit
interrupts ();
}

With the interrupt vectors ready, take the first reading with pins D8 & D9 in INPUT mode and D7 HIGH. This charges the capacitor through the reference resistor:

//========== read 10k reference resistor on D7 ===========

power_timer0_disable(); // otherwise Timer0 generates interrupts every 1us

pinMode(7, INPUT);digitalWrite(7,LOW); // our reference
pinMode(9, INPUT);digitalWrite(9,LOW); // the thermistor
pinMode(8,OUTPUT);digitalWrite(8,LOW); // ground & drain the cap through 300Ω
LowPower.powerDown(SLEEP_30MS, ADC_OFF, BOD_ON); //overkill: 5T is only 0.15ms

pinMode(8,INPUT);digitalWrite(8, LOW); // Now pin D8 is listening

set_sleep_mode (SLEEP_MODE_IDLE); // leaves Timer1 running
prepareForInterrupts ();
noInterrupts ();
sleep_enable();
DDRD |= (1 << DDD7); // Pin D7 to OUTPUT
PORTD |= (1 << PORTD7); // Pin D7 HIGH -> charging the cap through 10k ref

do{
interrupts ();
sleep_cpu (); //sleep until D8 reaches the threshold voltage
noInterrupts ();
}while(!triggered); //trapped here till TIMER1_CAPT_vect changes value of triggered

sleep_disable(); // redundant here but belt&suspenders right?
interrupts ();
unsigned long elapsedTimeReff=finishTime; // this is the reference reading

Now discharge and then repeat the process a second time with D7 & D8 in INPUT mode, and D9 HIGH to charge the capacitor through the thermistor:

//==========read the NTC thermistor on D9 ===========

pinMode(7, INPUT);digitalWrite(7,LOW); // our reference
pinMode(9, INPUT);digitalWrite(9,LOW); // the thermistor
pinMode(8,OUTPUT);digitalWrite(8,LOW); // ground & drain the cap through 300Ω
LowPower.powerDown(SLEEP_30MS, ADC_OFF, BOD_ON);

pinMode(8,INPUT);digitalWrite(8, LOW); // Now pin D8 is listening

set_sleep_mode (SLEEP_MODE_IDLE);
prepareForInterrupts ();
noInterrupts ();
sleep_enable();
DDRB |= (1 << DDB1); // Pin D9 to OUTPUT
PORTB |= (1 << PORTB1); // set D9 HIGH -> charging through 10k NTC thermistor

do{
interrupts ();
sleep_cpu ();
noInterrupts ();
}while(!triggered);

sleep_disable();
interrupts ();
unsigned long elapsedTimeSensor=finishTime; //this is your sensor reading

Now you can determine the resistance of the NTC thermistor via the ratio:

unsigned long resistanceof10kNTC=
(elapsedTimeSensor * (unsigned long) referencePullupResistance) / elapsedTimeReff;

pinMode(9, INPUT);digitalWrite(9,LOW);pinMode(7, INPUT);digitalWrite(7,LOW);
pinMode(8,OUTPUT);digitalWrite(8,LOW); //discharge the capacitor when you are done

The integrating capacitor does a fantastic job of smoothing the readings and getting the resistance directly eliminates 1/2 of the calculations you’d normally do with a thermistor. To figure out your constants, you need to know the resistance at three different temperatures. These should be evenly spaced and at least 10 degrees apart with the idea that your calibration covers the range you expect to use the sensor for. I usually put loggers in the refrigerator & freezer to get points with enough separation from normal room temp with the thermistor taped to the surface of a si7051. Then plug those values into the thermistor calculator provided by Stanford Research Systems.

Just for comparison I ran a few head-to-head trials against my older dithering/oversampling method:

°Celcius vs time [1 minute interval] si7051 reference [0.01°C 14-bit resolution, 10.8 msec/read ] vs. Pin-toggle Oversampled 5k NTC vs. ICUtiming 10k NTC. I’ve artificially separated these curves for visual comparison, and the 5K was not in direct contact with the si7051 ±0.1 °C accuracy reference, while the 10k NTC was taped to the surface of chip – so some of the 5ks offset is an artifact. The Timer1 ratios delver better resolution than 16-bit (equivalent) oversampling in 1/10 the time.

There are a couple of things to keep in mind with this method:

si7051 reference temp (C) vs 10k NTC temp with with a ceramic 106 capacitor. If your Ulong calculations overflow at low temperatures like the graph above, switch to doing the division before the multiplication or use larger ‘long-long’ variables. Also keep in mind that the Arduino will default to 16bit calculations unless you set/cast everything to longer ints. Or you could make you life easy and save the raw elapsedTimeReff & elapsedTimeSensor values and do the calculations later in Excel. Whenever you see a sudden discontinuity where the result of a calculation suddenly takes a big jump to larger or smaller values – then you should suspect a variable type/cast error.

1) Because my Timer1 numbers were small with a 104 cap I did the multiplication before the division. But keep in mind that this method can easily generate values that over-run your variables during calculation. Ulong MAX is 4,294,967,295 so the elapsedTimeSensor reading must be below 429,496 or the multiplication overflows with a 10,000 ohm reference. Dividing that by our 8mHz clock gives about 50 milliseconds. The pin interrupt threshold is reached after about one rise-time constant so you can use an RC rise time calculator to figure out your capacitors upper size limit. But keep in mind that’s one RC at the maximum resistance you expect from your NTC – that’s the resistance at the coldest temperature you expect to measure as opposed to its nominal rating. (But it’s kind of a chicken&egg thing with an unknown thermistor right? See if you can find a manufacturers table of values on the web, or simply try a 0.1uF and see if it works). Once you have some constants in hand Ametherm’s Steinhart & Hart page lets you check the actual temperature at which your particular therm will reach a given resistance. Variable over-runs are easy to spot because the problems appear & then disappear whenever some temperature threshold is crossed. I tried to get around this on a few large-capacitor test runs by casting everything to float variables, but that lead to other calculation errors.

(Note: Integer arithmetic on the Arduino defaults to 16 bit & never promotes to higher bit calculations, unless you cast one of the numbers to a high-bit integer first. After casting the Arduino supports 64-bit “long long” int64_t & uint64_t integers for large number calculations but they do gobble up lots of program memory space – typically adding 1 to 3k to the compiled size. Also Arduino’s printing function can not handle 64 bit numbers, so you have to slice them into smaller pieces before using any .print functions)

2) This method works with any kind of resistive sensor, but if you have one that goes below ~200 ohms (like a photoresistor in full sunlight) then the capacitor charging could draw more power than you can safely supply from the D9 pin. In those cases add a ~300Ω resistor in series with your sensor to limit the current, and subtract that value from the output of the final calculation. At higher currents you’ll also have voltage drop across the mosfets controlling the I/O pins (~40Ω on a 3.3v Pro Mini), so make sure the calibration includes the ends of your range.

There are a host of things that might affect the readings because every component has temperature, aging, and other coefficients, but for the accuracy level I’m after many of those factors are absorbed into the S&H coefficients. Even if you pay top dollar for reference resistors it doesn’t necessarily mean they are “Low TC”. That’s why expensive resistors have a temperature compensation curve in the datasheet. What you’re talking about in quality references is usually low long-term drift @ a certain fixed temperature (normally around 20 ~ 25°C) so ‘real world’ temps up at 40°C are going to cause accelerated drift.

The ratio-metric nature of the method means it’s almost independent of value of the capacitor, so you can get away with a cheap ceramic cap even though it’s value changes dramatically with temperature. (& also with DC bias ) In my tests thermal variation of a Y5V causes a delta in the reference resistor count that’s about 1/3 the size of the delta in the NTC thermistor. Last year I also found that the main system clock was variable to the tune of about 0.05% over a 40°C range, but that shouldn’t be a problem if the reference and the sensor readings are taken immediately after one another. Ditto for variations in your supply. None of it matters unless it affects the system ‘between’ the two counts you are using to make the ratio.

The significant digits from your final calculation depend on the RC rise time, so switching to 100k thermistors increases the resolution, as would processors with higher clock speeds. You can shut down more peripherals with the PRR to use less power during the readings as long as you leave Timer1 running with SLEEP_MODE_IDLE. I’ve also found that cycling the capacitor through an initial charge/discharge cycle (through the 300Ω on D8) improved the consistency of the readings. That capacitor shakedown might be an artifact of the ceramics I was using but you should take every step you can to eliminating errors that might arise from the pre-existing conditions. I’ve also noticed that the read order matters, though the effect is small.

Code consistency is always important with time based calibrations no matter how stable your reference is. Using a smaller integrating capacitor makes it more likely that your calibration constants will be affected by variations in code execution time. Any software scheme is going to show some timing jitter because both interrupts and the loop are subject to being delayed by other interrupts. Noise on the rail from a bad regulator will directly affect your readings. Using a larger 1uF (105) capacitor is a safer option than a 104. This method bakes a heap of small systemic errors into those NTC calibration constants, and this approach works because most of those errors are thermal variations too. However code-dependent variations mess with the fit of the thermistor equation as they tend to be independent of temperature, so make sure the deployment uses EXACTLY the same code that you calibrated with. We are passing current through the thermistor to charge the capacitor so there will inevitably be some self heating – if your calibration constants were derived with 1-pass, then your deployment must also read only one pass. If you calibrate with a 104 cap & then switch to a 105, then the temps recorded with the larger 105 will be offset to higher than actual. Oversampling works fine to boost resolution, but since it leverages multiple passes that also cause much more self heating.

Will this method replace our pin-toggled oversampling? Perhaps not for something as simple as a thermistor since that method has already proven itself in the real world, and I don’t really have anything better to do with A6 & A7. And oversampling still has the advantage of being simultaneously available on all the analog inputs, while the ICU is a limited resource. Given the high resolution that’s potentially available with the Timer1/ICU combination, I might save this method for sensors with less dynamic range. I already have some ideas there and, of course, lots more testing to do before I figure out if there are other problems related to this new method. I still haven’t determined what the long-term drift is for the Pro Mini’s oscillator, and the jitter seen in the WDT experiment taught me to be cautious about counting those chickens.

Addendum: Using the processors built in pull-up resistors

After a few successful runs, I realized that I could use the internal pull-up resistor on D8 as my reference; bringing it down to only three components. Measuring the resistance of the internal pull-up is simply a matter of enabling it and then measuring the current that flows between that pin and ground. I ran several tests, and the Pro Mini’s the internal pullups were all close to 36,000 ohms, so my reference would become 36k + the 300Ω resistor needed on D8 to safely discharge of the capacitor between cycles. I just have to set the port manipulation differently before the central do-while loop:

PORTB |= (1 << PORTB0); // enable pullup on D8 to start charging the capacitor

A comparison of the two approaches:

°Celcius vs time: (Post-calibration, 0.1uF X7R ceramic cap) si7051 reference [±0.01°C] vs. thermistor ICU ratio w 10k reference resistor charging the capacitor vs. the same thermistor reading calibrated using the rise time through pin D8’s internal pull-up resistor. The reported ‘resistance’ value of the NTC themistor was more than 1k different between the two methods, with the 10k met-film reference providing values closer to the rated spec. However the Steinhart-Hart equation constants from the calibration were also quite different, so the net result was indistinguishable between the two references in the room-temperatures range.

In reality, the pull-up “resistor” likely isn’t a real resistor at all, but an active device made out of transistor(s) which looks like a resistor when operated in its active region. I found the base-line temperature variance to be about 200 ohms over my 40°C calibration range. And because you are charging the capacitor through the reference and through the thermistor, the heat that generates necessarily changes those values during the process. However when you run a calibration, those factors get absorbed into the S&H coefficients provided you let the system equilibrate during the run.

As might be expected, all chip operation time affects the resistance of the internal pull-up, so the execution pattern of the code used for your calibration must exactly match your deployment code or the calibration constants will give you an offset error proportional to the variance of the internal pull-up caused by the processors run-time. Discharging the capacitor through D8, also generates some internal heating so those (~30-60ms) sleep intervals also have to be consistent. In data logging applications you can read that reference immediately after a long cool-down period of processor sleep and use the PRR to reduce self-heating while the sample is taken.

Another issue was lag because that pull-up is embedded with the rest of the chip in a lump of epoxy. This was a pretty small, with a maximum effect less than ±0.02°C/minute and I didn’t see that until temperatures fell below -5 Celsius. Still, for situations where temperature is changing quickly I’d stick with the external reference, and physically attach it to the thermistor so they stay in sync.

Addendum: What if your processor doesn’t have an Input Capture Unit?

With a 10k / 0.1uF combination, I was seeing Timer1 counts of about 5600 which is pretty close to one 63.2% R * C time constant for the pair. That combination limits you to 4 significant figures and takes about 2x 0.7msec per reading on average. Bumping the integrating capacitor up to 1uF (ceramic 105) multiplies your time by a factor of 10 – for another significant figure and an average of ~15msec per paired set readings. Alternatively, a 1uF or greater capacitor allows you to record the rise times with micros() (which counts 8x slower than timer1) and still get acceptable results. (even with the extra interrupts that leaving Timer0 running causes…) So the rise-time method could be implemented on processors that lack an input capture unit – provided that they have Schmitt triggers on the digital inputs like the AVR which registers a cmos high transition at ~0.6 * Vcc.

void d3isr() {
triggered = true;
}

pinMode(7, INPUT);digitalWrite(7,LOW); // reference resistor
pinMode(9, INPUT);digitalWrite(9,LOW); // the thermistor
pinMode(3,OUTPUT);digitalWrite(3,LOW); // ground & drain the cap through 300Ω
LowPower.powerDown(SLEEP_30MS, ADC_OFF, BOD_ON); // 5T is only 1.5ms w 10k

pinMode(3,INPUT);digitalWrite(3, LOW); // Now pin D3 is listening

triggered = false;
set_sleep_mode (SLEEP_MODE_IDLE); // leave micros timer0 running for micros()
unsigned long startTime = micros();
noInterrupts ();
attachInterrupt(1, d3isr, RISING); // using pin D3 here instead of D8
DDRD |= (1 << DDD7); // Pin D7 to OUTPUT
PORTD |= (1 << PORTD7); // Pin D7 HIGH -> charging the cap through 10k ref
sleep_enable();

do{
interrupts ();
sleep_cpu ();
noInterrupts ();
}while(!triggered);

sleep_disable();
detachInterrupt(1);
interrupts ();
unsigned long D7riseTime = micros()-startTime;

Then repeat the pattern shown earlier for the thermistor reading & calculation. I’d probably bump it up to a ceramic 106 for the micros method just for some extra wiggle room. The method doesn’t really care what value of capacitor you use, but you have to leave more time for the discharge step as the size of your capacitor increases. Note that I’m switching between relatively slow digital writes (~5 µs each) outside the timing loop, and direct port manipulation (~200 ns each) inside the timed sequences to reduce that source of error.

Addendum 20191020:

After running more tests of this technique, I’m starting to appreciate that even on regulated systems, you always have about 10-30 counts of jitter in the Timer1 counts, even with the 4x input capture filter enabled. I suspect this is due to the Shimitt triggers on the digital pins also being subject to noise/temp/etc and because other system interrupts find a way to sneak in. A smaller 104 integrating capacitor you make your readings 10x faster, but the fixed jitter error is a correspondingly larger percentage of that total reading (100nF typically sees raw counts in the 3000 range for the 10k reference). By the time you’ve over-sampled 104 capacitor readings up to a bit-depth equivalent of the single-pass readings with the 105 ceramic capacitor ( raw counts in the 60,000 range for the same 10k ref), you’ve spent about the same amount of run-time getting to that result. (Keep in mind that even with a pair of single-pass readings using the 10k/104 capacitor combination; raw counts of ~3500 yield a jitter-limited thermistor resolution of about 0.01C)

So, as a general rule of thumb, if your raw Timer1 counts are in the 20,000-60,000 range, you get beautiful smooth results no matter what you did to get there. This translates into about 2.5 – 7.5 milliseconds per read, and this seems to be a kind of ‘sweet-spot’ for ICU based timing methods because the system’s timing jitter error is insignificant at that point. With 5 significant figures in the raw data, the graphs are so smooth they make data from the si7051 reference I’m using look like a scratchy mess.

Another thing to watch out for is boards using temperature compensated oscillators for their system clock. ICU methods work better with the crappy ceramic oscillators on clone boards because their poor thermal behavior just gets rolled into the thermistors S&H constants during calibration. However better quality boards like the 8mhz Ultra from Rocket Scream have compensation circuits that kick in around 20C, which puts a weird discontinuity into the system behavior which can not be gracefully absorbed by the thermistor constants. So the net result is that you get worse results from your calibration with boards using temperature compensation on their oscillators.

The thermistor constants also neatly absorb the tempco and even offset errors in the reference resistor. So if you are calibrating a thermistor for a given logger, and it will never be removed from that machine, you can set your reference resistor in the code to some arbitrary perfect value like 10,000 ohms, and just let the calibration push any offset between the real reference and your arbitrary value into the S&H constants. This lets you standardize the code across multiple builds if you are not worried about ‘interchangeability’.

And finally, this method is working well on unregulated systems with significant battery supply variations as I test the loggers down to -15C in my freezer. In addition to battery droop, those cheap ceramic caps have wicked tempcos, so the raw readings from the reference resistor are varying dramatically during these tests, but the ‘Ratio/Relationship’ of the NTC to this reference is remaining stable over a 30-40C range, with errors in the ±0.1°C range, relative to the reference. (Note: si7051 itself has ±0.13°C, so the net is probably around ±0.25°C)

Addendum 20201011:

Re: the temperature coefficient of resistance (TCR) of your reference resistor:

“Using a thin film resistor at ±10 ppm/°C would result in a 100 ppm (0.01%) error if the ambient changes by only 10°C. If the temperature of operation is not close to the midpoint of the temperature range used to quantify the TCR at ±10 ppm/°C, it would result in a much larger error over higher temperature ranges. A foil resistor would only change 0.0002% to 0.002% over that same 10°C span, depending upon which model is used (0.2 ppm/°C to 2 ppm/°C.) And for larger temperature spans, it would be even more important to use a resistor with an inherently low TCR.”

During calibration, I usually bake the reference resistor’s tempco into the thermistor constants by simply assuming the resistor is a ‘perfect 10k ohm’ during all calculations. (this also makes the code more portable between units) However this does nothing to correct long-term drift in your reference. If you want to tackle that problem with a something like a $10 Vishay Z-foil resistor (with life stability of ± 0.005 %) then it’s probably also worth adding Plastic film capacitors which have much better thermal coefficients: Polyphenylene sulfide (PPS ±1.5%) or Polypropylene (CBB or PP ±2.5%). A quick browse around the Bay shows those are often available for less than $1 each, and the aging rate (% change/decade hour) for both of those dielectrics is listed as negligible. The trade off is that they are huge in comparison to ceramics, so you are not going to just sneak one in between the pins on your pro-mini. Be sure to check the rated voltage – and don’t order them if they are rated >100v as the common 650v film caps are too big to be practical on small logger builds. For the coup de grâce you could correct away the system clock variation by comparing it to the RTC.

Addendum 2020-03-31: Small capacitors make this method sensitive to a noisy rail

After a reasonable number of builds I have finally identified one primary cause of timing jitter with this technique: a noisy regulator. To get sleep current down I replace the stock MIC5205’s on clone ProMini boards with MCP1700’s and I noticed a few from a recent batch of loggers were producing noisy curves on my calibration runs. One of them was extreme, creating >0.5°C of variation in the record:

ICU based Thermistor readings VS si7051 reference. Sensors in physical contact with each other. Y axis = Celsius

But in the same batch, I had others thermistors with less noise than the si7051’s I was using as a reference. All were using small 104 ceramic capacitors for the integration, producing relatively low counts (~3500 clock ticks) on the 10k reference resistor.

For the unit shown above I removed the regulator, and re-ran the calibration using 2x Lithium AA batteries in series to supply the rail voltage. No other hardware was changed:

Same unit, after regulator was removed. Samples taken at 1 minute interval on both runs.

In hindsight, I should have guessed a bad regulator was going to be a problem, as few other issues can cause that much variation in the brief interval between the reference resistor & thermistor readings. Reg. noise/ripple translates instantaneously into a variation in the Schmitt trigger point on the input pin – which affects the ICU’s timer count. It’s possible that this issue could be eliminated with more smoothing so I will try a few caps across the rails on the less problematic units. (~1000µF/108 Tantalums can be found for 50¢ on eBay but I will start with a 10µF/106 & work up from there)

Addendum 2020-04-05: 106 ceramic across rails increased ICU reading noise (w bad reg)

Adding a cheap 106 (Y5V ceramic) across the rails more than doubled the noise in the readings of the NTC with this ICU technique. This is interesting, as it goes completely against what I was expecting to happen. Possibly that 10µF cap was just badly sized for this job or had some other interaction via inductance effects that actually accentuated the noise? I probably need a smaller, faster cap for the job.

Changing the sampling capacitor from a 104 (0.1µF) , to a 105 (1µF) dramatically reduced the problem. Not surprising as the rail noise from the regulator is relatively consistent, while the reference timer counts change from ~3500 with a 104 capacitor to ~60,000 with the larger 105. So the jitter is still there, but it is proportionally much smaller. I’m currently re-running the thermistor calibration with that larger capacitor. If the gods are kind, the S&H thermistor constants will be the same no matter what sampling capacitor is used.

It’s worth noting that this issue only appeared with the most recent crop of crappy eBay regulators. But if you are sourcing parts from dodgy vendors, you’d best go with a 105 sampling capacitor right from the start to smooth out that kind of noise

Addendum 2020-04-06: Re-use old S&H constants after changing the sample capacitor?

After discovering the reg. issue, I re-ran a few thermistor calibrations once the sampling capacitor had been changed from a 104 to a 105: This reveals that the thermistor constants obtained with a 104 sampling capacitor, still work, but it depends on the tolerance you are aiming for: with the older 104 cap constants drifting over a 40°C range by about ±0.3 Celsius. The extra resolution provided by the larger 105 cap is only useful if you have the accuracy to utilize it (ie: It doesn’t matter if the third decimal point is distinguishable of the whole number is wrong) I generally aim for a maximum of ±0.1°C over that range, so for our research loggers that’s a complete do-over on the calibration. From now on I will only use 105 caps (or larger) with this ICU technique on regulated systems. The battery-only units were smooth as silk with smaller 104 caps because the rail had zero noise.

Addendum 2020-05-21: Using the ADS1115 in Continuous Mode for Burst Sampling

For single resistive sensors, it’s hard to beat this ICU method for elegance & efficiency. However there’s still one sensor situation that forces me to go to an external ADC module: Differential readings on bridge sensors. In those cases I use an ADS1115 module, which can also generate interrupt alerts for other tricks like ‘event’ triggered sampling.

Addendum 2021-01-24 Don’t sleep during the do-while loop with regular I/O pins.

I’ve been noodling around with other discharge timing methods and come across something that’s relevant to using these methods on other digital pins. Here’s the schematic from the actual 328 datasheet, with a bit of highlighting added. The green path is PINx. It’s always available to the databus through the synchronizer (except for in SLEEP mode?) The purple path is PORTx. Whether or not it is connected to PINx depends on the state of DDRx (which is the yellow path.)

As shown in the figure of General Digital I/O, the digital input signal can be clamped to ground at the input of the Schmitt Trigger. The signal denoted SLEEP in the figure, is set by the MCU Sleep Controller in Power-down mode and Standby mode to avoid high power consumption if some input signals are left floating, or have an analog signal level close to VCC/2.

When sleeping, any GPIO that is not used an an interrupt input has its input buffer disconnected from the pin and in clamped LOW by the MOSFET.

Clearly the ICU on D8 must make it one of those ‘interrupt exceptions’ or the cap charging method would have been grounded out when entering the sleep state. If you use a similar timing method on normal digital IO pins you can’t sleep the processor in the central do-while loop.

The datasheet also warns that on pins where this is overridden, such as external interrupts, you must ensure these inputs don’t float (page 53). The implication being that when you put anything near 1/2 of the rail voltage on the input’s Schmitt trigger this will cause current to flow into or out of the pin. Yet another source of error that gets rolled into those catch-all S&H constants.

Addendum 2022-03-09: Adding a second resistive sensor

The LDR goes to very large resistance at night, so we cap the reading at one timer overflow.

We usually integrate this ICU method with our low-power 2-part loggers as they have only a single Cr2032 as their power supply. Once the pins are pulled low these resistive sensors add nothing to the sleep current. With the stability of battery power, a 104 is sufficient for stable readings of about 6000 counts for 10k ohms.
For more details see: Powering a ProMini logger for one year on a coin cell.

Easy 1-hour Pro Mini Classroom Datalogger [Feb 2019]

Dupont jumper variant of the “fully soldered’ Classroom Data Logger from the Cave Pearl project: This version uses dupont jumpers to reduce assembly time to about 1 hour

Note: An updated version of the classroom logger was released in 2020: CLICK THIS LINK to view the newest build tutorial.

It’s only been a couple of weeks since the release of the 2019 EDU logger, and we’re already getting feedback saying all the soldering that we added to that tutorial creates a resource bottleneck which could prevent some instructors from using it:

“Our classroom has just two soldering stations, and the only reason there are two is I donated my old one from home. So we simply don’t have the equipment to build the logger you described. And even if we did, some of my students have physical / visual challenges that prevent them from working with a soldering iron safely…”

Or goal with that design was to give students their first opportunity to practice soldering skills that are needed when repairing kit in the field. However helping people do science on a budget is also important – so that feedback sent us back to the drawing board. After a little head scratching we came up with a new version that combines the Dupont jumper approach we used in 2016, with this flat-box layout. In the following video, I assemble one of these ‘minimum builds’ in about one hour. To put that in perspective, the fully soldered version takes 2 – 2.5 hours for someone with experience.

Note: After you’ve seen the video to get a sense of where you are headed, it’s usually much better to work from the photos (below) when assembling your logger. Youtube videos make it look easier than it actually is when you are just starting out. So the first one you build could take several hours as you figure out what you are doing, the second will take half as long, and the third one you make usually takes less than two hours. With some practice you can easily make 4-5 of these things a day.

This variation of the basic 3-component logger is optimized for quick assembly, so the soldering has been reduced to adding header pins and bridging the A4/A5 I2C bus to the outer terminals. An instructor could easily do that ahead of time with about 15 minutes of prep per unit, leaving only the solder-less steps for their students. After the header pins are in place, connections to the central Pro Mini are made by simply twisting stripped wire ends together and clamping them under screw terminals.

You should use Lithium AA batteries with a 2-cell unregulated supply because the slope of an alkaline batteries discharge would bring the system down to ProMini’s brown-out of ~2.7v when only 40% of the battery capacity has been used. (note the SD card safe down to 1.8v) While the voltage of a ‘brand new’ Lithium AA is usually 1.8v/cell, that upper plateau provides a sleeping logger voltage of ~1.76 v/cell once the batteries settle, and that briefly dips to about 1.625v/cell under load during data saves. At low temps of about 5°C (in my refrigerator) those SD card voltage dips go down to about 1.525 v/cell. Unloaded readings of 1.5v on a Li AA = battery is dead.

This time reduction involves a few trade-offs, and bringing the I2C bus over to A2 & A3 leaves only two analog ports readily accessible ( although A6 & A7 are still available if you add some jumpers). Removing the regulator & battery voltage divider adds ~30% more operating life, but it also forces you to deal with a changing rail voltage as the Lithium AA batteries wear down. The daily variation is usually quite small, but for quantitative comparisons on monthly scales you will need to correct for the change in rail voltage over time if your sensor circuits are not ratio-metric. To do this voltage compensation multiply your raw sensor readings by the the ratio of (3300mv) / (current rail voltage). Here 3300mv is just an arbitrary comparison point, which you could replace with any rail voltage reading from the data saved by your logger. Batteries have a lot of mass, so thermal lag in battery voltage can also cause hysteresis for analog temperature sensors unless you read the reference under the same conditions.

(NOTE: complete parts list with supplier links are located at the end of this post)

Pro Mini Prep:

Solder the UART pins & test ProMini board with the blink sketch: Set the IDE to (1) TOOLS> Board: Arduino Pro or Pro Mini (2)TOOLS> ATmega328(3.3v, 8mhz) in addition to the (3)TOOLS> COM port to match the # that appears when you plug in the serial adapter board.	Once you know you have a working Promini board: Remove the power LED [in red]. Removing the pin13 LED [yellow square above] is optional. Leaving the pin13 LED in place lets you know when data is being saved to the SD card because the SPI bus SClocK signal flashes the LED.	Remove the voltage regulator with snips. Your system voltage will vary over time, but our starter script records that rail voltage without a voltage divider.
Add pin headers to the sides & Serial input end of the Pro Mini.	Bridge the two I2C bus connections for side access with the leg of a resistor. Connect A4->A2 & A5->A3.	Adding DIDR0 = 0x0F; in Setup disables digital I/O on pins A0-A3 so they don’t interfere with I2C bus coms.

NOTE: The Screw Terminal board we use in this build was designed for the 5v Arduino NANO, so the shield labels don’t match the actual 3.3v Pro Mini pins on the ‘analog’ side. (the digital side does match) To avoid confusion may want to tape over those incorrect labels and hand write new labels to match the pattern above. Wire connections in this tutorial will be specified by ProMini pin labels: D10-13 are used for the SD card, A4=A2 is the I2C Data line, and A5=A3 is the I2C clock line, A0 & A1 are not used.

Technically speaking, bridging the I2C bus (A4=data & A5=clock) over to A2 & A3 subjects those lines to the pin capacitance and input leakage of those analog pins (regardless of whether that channel is selected as input for the ADC p257). But in practice, the 4K7 pull-up resistors on the RTC module can easily handle that at the 100 kHz default bus speed. Adding DIDR0 = 0x0F; in setup disables digital I/O on pins A0-A3 to prevent interference with the I2C bus. If you want to disable the IO on A2 & A3 ‘only’ add bitSet (DIDR0, ADC2D); bitSet (DIDR0, ADC3D); to your code.

Also note: On the UART adapter in the picture above, the USB to TTL adapter pins are in the reverse order to the Pro Mini board. This is a fairly common issue with clones and if the blink sketch never uploads flip the adapter around and try again. I have connected 3.3v ProMinis to UART modules the wrong way round many, many times, and not one of them has been harmed by the temporary reversal.

Screw-Terminal Component Stack:

Add 3 layers of double sided tape so the tape is thicker than the solder pins.	Align RX&TX corner pins before inserting. The GND points on the screw terminal board may be interconnected (via the back-plane) & must match the ProMini’s GND pins.	Gently rock the Pro Mini back to front (holding the two short sides) until the pins are fully inserted. Some ST shields have mis-aligned headers so this insertion can be tricky.
Remove the last three ‘unused’ pin headers to make room for the SD adapter	Note: Screw-terminal board labels do not match the ProMini pins on the ‘analog’ side	Remove bottom 3 resistors from the adapter – leave the top one in place!
Separate Dupont Cable wires & click them into a 6-pin shroud.	Cable Color Pattern: Black =GND, Purple=MISO, Brown=CLocK, Orange=MOSI, Grey=CSelect, and Red=3v3	Use foam tape to attach SD module to the Screw Terminal board. Metal tabs should be visible on top surface.
Measure, cut & strip the 4 SPI bus wires (NOTE the ‘Nano’ ST board labels say A0-A3 which does not match the D10-13 Pro Mini pins on this side of the board)	Grey (CS) to ProMini D10, Orange (MOSI) -> pm D11, Purple (MISO) ->pm D12, Brown (CLK) -> pm D13	Add three jumper wires to the red power line from the SD module, one with a male end pin. I often add Dupont ends with a crimping tool, rather than using a pre-made jumper.
Strip & twist the 4 red power wires together & add heat-shrink for strain relief. Bundling wires like this is easier if you make the stripped area a bit longer.	A short red jumper goes to RAW(pm)=VIN(st) to recruit the orphan capacitor.	Long red jumper bridges power to ‘unused’ screws on other side of the Terminal board, and the wire with the Dupont male end will go to the breadboard.
Add 2 extra wires to the black GND wire from the SD module (1 with a male Dupont end ). Jumper one black wire across the Promini to an unused terminal beside the red power wire.	The GND bundle completes Pro Mini / ST board / SD module stack. The ‘pinned’ Red & Black ‘pinned’ jumpers shown here are about 1 inch too short to reach the breadboard easily… make yours longer.	Note: You could connect the battery holder lead wires directly into the multi-wire Vcc & GND bundles: skipping the 2 jumpers crossing over to the other side of the ST shield. But adding those jumpers provide extra Vcc/GND connection points & the ability to easily replace the battery holder later if you have a battery leak.

I always try to make my Dupont connectors so that the metal & plastic retainer clips are accessible (in this case facing upwards) after the logger is assembled. That way you can diagnose bad wire connection with the tip of a meter probe, and if necessary, pull out & replace a single bad wire in the Dupont connector without taking everything apart.

RTC module:

Remove two SMD resistors from the RTC board with the tip of your soldering iron.

The DS3231 modules often have flux residue – clean this off with 90% isopropyl.

Brand	Run Time (h)	Cost / Cell	\|	Brand	Run Time (h)	Cost / Cell
Panasonic	1500	$ 1.04	\|	Duracell	1298	$ 1.81
Voniko	1448	$ 0.83	\|	AC Delco	1223	$ 0.79
Maxell	1444	$ 0.58	\|	Nightkonic	1186	$ 0.24
Toshiba	1325	$ 0.64	\|	MuRata	1175	$ 0.45
Energiser	1307	$1.28	\|	Hua Dao	642	$ 0.14