Tag Archives: data logger

How to measure PAR (Photosynthetically Active Radiation) using a BH1750 Lux Sensor

A 3d printed stack of radiation shields goes around the 30mL centrifuge tube housing our 2-module logger. A universal ball joint by DiZopfe was adapted for the leveling mechanism which is critical for the calibration.

Space nerds have an old saying that ‘LEO is half way to the moon…‘ and Arduino hobbyists tend to feel the same way about getting sensor readings displayed on a live IoT dashboard. But that ignores the real work it takes to generate data that’s actually useable. To paraphrase Heinlein: ‘Calibration is half way to anywhere…’ Now that our 2-Part logger is both easy for students to build and robust enough for field use, we can focus on developing sensor calibration methods that are achievable by teachers and researchers in low-resource settings.

Light sensors seem straight forward, with numerous how-to guides at Hackaday, Adafruit, Sparkfun, etc. In reality, light sensors are some of the trickiest ones to actually deploy – which is why so few low-end climate stations include them. This post describes a method for calibrating a Bh1750 lux sensor to estimate Photosynthetically Active Radiation (PAR). Not everyone can afford a LI-COR 190 or Apogee SQ quantum sensor to use as a benchmark, so here we will use a clear-sky model calculation for the cross-calibration despite the dynamic filtering effects of the atmosphere on natural sunlight. Using a diffuser to restore cosign behavior means we can’t calculate PPFD directly from Lux without some y=mx+b coefficients.


Jump links to the sections of this post:


Light Sensor Issue #1: Changing Spectral Distribution

Peak solar irradiance received on any given day varies by latitude and season, as does the overall pattern. Light emitted from the sun has a stable distribution of frequencies, however the spectrum at the earth’s surface varies across the day, with more short wavelengths (blue) around mid day and enriched in longer wavelengths (red) at sunrise & sunset when the rays travel further through the atmosphere. We will avoid this source of error by calibrating with data from the hours around solar noon as determined by the NOAA Solar Calculator. Even with high quality sensors, morning and evening data can be compromised by other factors like condensation which changes the refractive index of lenses and diffusers.

Light Sensor Issue #2: Sensitivity Bands

Average plant response to light as Relative Photosynthetic Efficiency (%) vs Wavelength (nm) compared to Bh1750 Response Ratio vs Wavelength

Lux sensors have a maximum sensitivity near 550nm, mimicking the response of photo-receptors in the human eye. Plants are similarly limited to frequencies that can be absorbed by the various chlorophylls. These two bands have a high degree of overlap so we can avoid the Badder UV/IR-Cut cut filters (420–685nm bandpass) or stack of Roscolux filters that would be needed with photodiodes that respond to a wider range of incoming radiation. The cross-calibration still requires the relative ratio of frequencies within the targeted region to remain stable, so a PAR conversion derived under full sunlight may not be valid under a canopy of tree leaves or for the discontinuous spectra of ‘blurple’ grow-lights.

Light Sensor Issue #3: Dynamic Range

I tested two inexpensive Bh1750 sensor modules, and the diffuser dome that comes with the red ‘Light Ball’ version turned out to be the deciding factor. When powered from a 3v coin cell, these sensors add 8µA to the loggers sleep current if you leave the 622 reg in place and <1µA if you remove it.

Full summer sunlight can exceed 120,000 Lux and there aren’t many sensors in the Arduino ecosystem that handle that entire range. The BH1750 can with registers set to it’s least sensitive configuration. Our logger code already does this because QUALITY_LOW & MTREG_LOW(31) integration take only 16-24 milliseconds, rather than the 120-180ms of power needed for high resolution readings. The data sheet implies that the sensor will flatline before 100,000 lux, but at its lowest sensitivity it delivers reasonable data above 120k, though linearity may be suspect as flux approaches sensor saturation. The sensor also has a maximum operating temperature of 85°C which can be exceeded if your housing suffers too much heat gain. Alternative sensors like the MAX44009, TSL2591 and SI1145 have a similar thermal limits. Like most light sensors, the Bh1750 increases its output readings by a few percent as the sensor warms.

Commercial vs DIY diffusers. Bullseye level indicators are epoxied to the top shield with white JB Marine Weld. The larger 43mm diameter bubble (right) was far more effective than the smaller 15mm (left).

DIY builders often add diffusers made from translucent #7328 Acrylite or PTFE sheets to reduce sunlight intensity into a given sensors range. I tried printing domes with clear PETG and hand sanding them with fine grit to increase the diffusive power. While these did reduce light levels by more than 50%, my DIY diffuser didn’t quite match the smooth overall response seen with the diffusers that came with the round PCB modules. This may have been due to a slight misalignment between the sensor and the focal point of the low-poly dome I could make in Tinkercad. The white dome that comes with the red Bh1750 module reduced peak light levels in full sunlight from the 110k Lux reported by a ‘naked’ sensor to about 40k Lux. Each sensor varied somewhat in its response but I didn’t do any batch testing to quantify this as I was calibrating each sensor directly to the reference model. I initially tried clear JB weld as a sealant but this caused problems: sometimes contracting enough peel parts away from the PCB and yellowing significantly after a couple of weeks of full sun exposure. In later builds I used only a thin coating of silicone conformal, relying on an epoxy seal around the base of the diffuser to provide most of the waterproofing.

Light Sensor Issue #4: Angular Response

Bh1750 Directional Characteristics [Figs 4&5] from the datasheet. Sensor response is different on the two axes so orientation must be labeled on the outside during assembly. The left graph is closer to Lambertian so the sensor gets deployed with its connection pads oriented North – South relative to the suns east-west motion. Based on these curves alone we would expect a ‘naked’ BH sensor to under-report relative to the Lambertian ideal. That is indeed what I observed in our early sensor comparison tests, leading to our selection of round red PCB modules for the calibration because the included diffuser dome compensated nicely.

Lambert’s cosine law describes the relationship between the angle of incidence and the level of illuminance on a flat matte surface as being proportional to the cosine of the zenith angle (as the suns changes position throughout the day). At an incident angle of 60°, the number of photons hitting a sensor surface is half what it would be if the same light source was positioned directly above the sensor. This effect is mathematically predictable, but imperfections, diffraction, and surface reflection means that sensor response tends to diverge from ideal as the angle increases. So manufacturers surround their sensors with raised diffuser edges and recesses on the top surface which change light collection at low sun angles to restore a perfect cosign response. In general, diffusers make the compass orientation of the sensor less likely to interfere with calibration but leveling the sensor is still absolutely required.

Light Sensor Issue #5: Temporal Resolution

Unlike most environmental parameters, light levels can change instantaneously. Most commercial sensors aggregate 1 or 2 second readings into 5 to 15 minute averages. This makes it much easier to estimate energy output from solar panels, or calculate the Daily Light Integral for a crop because both of those use cases are more concerned with area under the curve rather than individual sensor readings. However, in our case of calibrating a sensor against an irradiance model, we must use instantaneous readings so we can exclude data from periods where the variability is high. Averaging would smooth over short term interference from clouds, birds, or overhead wires, potentially leading to bad data in the calibration. We read the BH1750 once per minute at its fastest/lowest resolution.


A Radiation Shield

My original concept was to epoxy the light sensor directly onto the cap and slide separate radiation shields over the housing tube with a friction fit – but that approach suffered excessive heat gain. It took several design iterations to discover that plastics are often transparent to IR – so most of the 3D printed weather station shields you find in maker space won’t work very well. While PLA does block/reflect the visible spectrum, it then re-emits a portion of any absorbed energy as IR which passes right through – turning the central housing tube into a tiny greenhouse. You need to add layers of metal foil to reflect that IR and there must be an air gap between the materials or the heat still crosses by conduction. The process of moving those surfaces away from the logger also meant placing the sensor onto a small raised ‘stage’ that could pass through the upper shield. This allows easier replacement after the sensors expire, or the use of an entirely different sensor without changing the rest of the design. I still don’t know the operating life of these sensors at full sunlight exposure levels.

2″ Aluminum HVAC tape is applied to the IR shield layer. (click to enlarge these photos)
The IR shield slides to about 8mm below the top shield which has holes along the rim to vent heated air.
The sensor stage slides on the vertical rails and passes through the upper shield.
The loggers green cap then pushes the sensor stage into place with a snug click-fit. Foil is wrapped around the logger housing tube.
Three smaller gill shields slide onto the rails, with plenty of aligned holes for vertical airflow through to the top shield.
A lower IR shield is added to the bottom with metal side down to reflect thermal radiation emitted from the ground.

Here are temperature records of two side-by-side loggers with identical 3D-printed shields except that one has the three metal foil layers added and one does not:

Temp (°C) vs Time: Comparison of heat gain with, and without metal foil layers. Measured with the NTC sensor inside the logger housing at the center of the stack. The night time data shows a 0.25°C offset between the two sensors, indicating that they were not normalized before this run.

Interestingly, the 3°C delta seen in my foil vs no foil tests matched the discrepancies identified by Terando et.al in their 2017 paper examining ad hoc Stevenson shields in ecological studies. Air gaps are required for IR reflecting layers to do their job, so most of the foil backed roofing shingles on the market are ineffective because of direct surface contact. Both aluminum and stainless steel foils are common, but aluminum has a lower emissivity than stainless steel, meaning it should reflect more and emit less IR. There are also radiant barrier coating sprays used in industrial settings. High-end weather stations use fan ventilation or helical shields, but those designs may be a bit too complicated for DIY. And even 3D prints from tough materials like PETG or ASA would benefit from coating with something like Krylon UV protectant to extend their lifespan. I’ve also been thinking about adding some infrared cooling paint on the top surface of our weather stations. The challenge with anything that emits in the atmospheres transparency window between wave lengths of 8 and 13 microns is that you get significant accumulation of debris on surfaces in as little as one month of actual deployment: especially in the spring/fall when the surfaces get covered with morning dew which then captures any windborne dust.

I’m still tweaking the shield design as more test data comes in, and hope to compare it to a fan aspirated model soon. Radiation shields are only needed if you want to capture accurate temperatures with the light readings on the same logger. The Bh1750 calibration alone could be done without shields, but mounting the sensor on some kind of flat surface makes it easier to add the required leveling bubble beside the sensor. The tradeoff for preventing solar heat gain is that shields introduce lag in the temperature response.

Pole Mount & Leveling Mechanism

As this is the first of our ‘garden series’ that will be built around the 2-part logger, I created a complete mounting system from a combination of 3D printed parts and PVC pipes. This adjustable leveling mechanism was modified from the Open Source Universal Ball Joint posted on Thingiverse by Arthur ZOPFE.

This socket slides over the end of a 1/2″ PVC pipe. A zip tie through the drilled cross-hole secures the pieces together.
A self standing 30mL centrifuge tube slides snugly into this fitting, again with holes for zip ties.
A large diameter twist ring makes it easy to adjust the sensor assembly while watching the bulls-eye level on the top shield.

This ball & socket approach works well for leveling, but to make the adjustments easier (ie. with less compressive force) I will add an O-ring to the bottom cup for some friction and give.

This ground spike has a foot plate to assist insertion and is asymmetric to provide more contact with the bed. It just barely fits on my Ender3 when printed diagonally. I created this model from scratch in Tinkercad, but the offset idea is not mine. Unfortunately, I saw the original so long ago I don’t know who to credit for it. The pole insert and holes are six-sided because internal 45° slopes can be printed without any supports, and you can simply bridge the internal 1cm top span.

A length of standard 1/2 inch PVC pipe is used for the riser between the spike and the leveling mechanism. Ideal height for temperature sensors is approximately five feet above the ground, usually in a shaded location facing away from the sun.


The Apogee Clear Sky Calculator

With this model we could even attempt a calibration against the shortwave spectrum for a DIY pyranometer, but it’s a much bigger stretch to say the 550nm peak of BH sensitivity is a good proxy for the whole 300 -1300nm band of frequencies.

The Apogee Clear Sky Calculator helps operators of their many light sensor products check if those need to be sent in for re-calibration. When used near solar noon on clear unpolluted days the accuracy is estimated to be ±4 %. We can cross-calibrate the readings from our humble Bh1750 to that model provided we use data from a cloudless day. I’m not sure what the temporal resolution of the ClearSky model is (?) The U.S. Climate Reference Network generally uses two-second readings averaged into five minute values so it is likely that the ClearkSky model has a similar resolution. This model has the best accuracy within one hour of solar noon but we will push that out a few hours so we have enough data for the regression.

We could have used the Bird Clear Sky Model from NREL, with validation against real world data from one of the local SURFRAD stations at NOAA. That data is for full-spectrum pyranometers measuring in W/m2, but you can estimate the PAR as photosynthetic photon flux density (PPFD) from total shortwave radiation using a conversion factor into µmol s-1 m-2. Many solar PV companies provide online calculators for power density that could also be used for this kind of DIY sensor calibration.

Our Deployment Location

Most who live in urban areas are familiar with noise pollution, however it is also hard to find undisturbed light environments. My best option for those critical hours around solar noon was my neighbours backyard garden:

The two sensors here are aligned on the east-west axis so they can be compared.

This location was relatively free of power lines and tree tops, but reflections from that white door caused a slight positive offset in the afternoon. Fences prevented the capture of morning and evening data which would have been interesting. But sunrise to sunset data is not required for our calibration.

The Calibration

After several weeks of logger operation we finally managed to capture data from a beautiful cloud-free day:

2024-07-27: Lux from a diffused ‘Light Ball’ Bh1750 sensor (Orange, left axis @1min) VS ClearSky Model PPFD (Purple/right Axis @ 5min). You can see some stair-stepping in the model data, indicating that it’s temporal resolution might be only 10-15 minutes.

We logged raw single-shot Lux readings at one minute intervals and because there is no averaging applied you can clearly see where overhead lines or birds created occasional short-duration shading. These outliers were excluded before generating the trendline shown below. The PAR values from the model were calculated using the ‘Auto fill’ option for humidity and temperature. On this day solar noon was at 12:57

Linear y=mx+b fit between ClearSkyCalculator PPFD (yAxis) vs Diffused BH1750 Lux (xAxis) using 5 minute data points on 2024-07-27 between 10:00 and 16:00 [bracketing solar noon by three hours]. Two shadow outliers at 10:05 and10:15am were excluded from the dataset.

Aerosols and variations in local temp/humidity produced some scatter but this is a good result for calibration with natural light. The result might be improved by co-deploying a humidity sensor, but it’s not clear to me if humidity at ground level is what the model actually uses for its calculation. Some scatter is also being created by the temporal resolution of the model. Using one type of sensor as a proxy for another limits the scope of the device and we probably approached an accuracy of ±15% at best with this conversion. It’s worth remembering that most commercial light sensors are only calibrated to ±5%.


Discussion

The biggest challenge at our mid-west location was that we had to run the loggers for several weeks before capturing the blue-sky day shown above. Typical time series from that Bh1750 sensor (under a light-reducing diffuser dome) looks like this:

Lux vs Time: 1 minute data captured with our 2-Part logger reading a red ‘light-ball’ Bh1750 module.
This unit had an extra 64k EEprom added to store the large amount of data that was generated.

Clouds often cause light levels to exceed that seen on clear days. This makes sense if you imagine a situation where there are no clouds directly over-head, but radiation reflected from the sides of clouds is reaching the sensor from multiple directions. The fact that clouds at different atmospheric levels have different effects is one of the things that makes climate models so complicated.

The Clear-Sky Calculator lets you generate data for any date/time, so it would be possible to do this calibration by aggregating cloudless periods from multiple days:

Detail of data from 7/15 and 7/12: what you are looking for is the smooth curve that indicates there were no high level clouds causing subtle variations in light level.
Inexpensive (~$60USD) PAR meters have started appearing on Amazon recently. I’m more than a little dubious about the term ‘quantum’ in the marketing (?) as they are probably just a photodiode and some filters

Someone in Nevada would have no trouble gathering this kind of calibration data, but it might not be possible for people living in Washington. A low-cost alternative to using a clear-sky model for the calibration could be to compare the Bh1750 to one of the many smartphone grow light meter apps, with a clip-on diffuser & cosine corrector. Every phone has a different sensor so programs like Photone or PPFDapp usually have their own calibration procedures. While developing this exercise I also found a ‘for parts’ Seaward Solar Survey 100 on eBay for $20, and all it needed to bring it back to life was a good cleaning inside. I also found an old Li-1400 logger with a 190 pyranometer for only $120 and was pleasantly surprised when Apogee’s calculator showed it was still within 5%. As mentioned, you’d need to convert total radiation from those last two into PAR or you could do the calibration to total shortwave. Hardware references that lack logging capability require more effort to gather calibration points, but they save you from having to wait for agreeable weather.

Other projects have built similar sensors and with calibration Lux sensors are comparable to commercial PAR sensors if the spectral environment is consistent. Multi-channel sensors with overlapping frequencies do a better job in situations with discontinuous light sources like those used for indoor growing or for measuring the extinction of PAR frequencies under water. In those cases a TCS3471 (3-channel), AS7341(10-channel), or AS7265 (18-channel) sensor could be used, and finer frequency division can enable calculation of interesting ratios like NDVI or SPAD. Beyond that point you’re entering the realm of diffraction grating spectrometers which allow a more nuanced approach to the spectral function which differs from standard PAR.

And if building your own datalogger is too challenging, you could reproduce the exercise described in this post with a bluetooth UNI-T or a UT381 Digital Luminometer which has some logging capability. But you will need to add extra diffusers to bring full sunlight down below its 20,000 Lux limit.


NREL Bird Clear Sky Model
Clear Sky Calculator from Apogee Instruments
NOAA SURFRAD data from irradiance measuring stations
Downloading from the National Solar Radiation Database.
Shortwave Radiation by Steve Klassen & Bruce Bugbee
Fondriest Solar Radiation & Photosynthetically Active Radiation
Designing a Low-Cost Autonomous Pyranometer by Peter van der Burgt
Various DIY PAR meter discussions at Planted Tank
Build Your Own Pyranometer by David Brooks
Ad hoc instrumentation methods in ecological studies produce biased temperature measurements. Terando et al. (2017)
Choosing Standard Bulbs for DIY PAR meter calibration
Daily Light Integral requirements for different plants.
PARbars: Cheap, Easy to Build Ceptometers
Creating a Normalized Vegetation Index Sensor with two LEDs
Hacking the Rubisco enzyme boosts crop growth 40%
Plants recycle UV into red light
How to calibrate NTC thermistors
How to build our 2-Part ProMini Data Logger

How to Normalize a Group of Pressure Sensors so they can be Deployed as a Set

Once your project starts to grow it’s common to have multiple different sensors, from different vendors, measuring the same environmental parameter. Ideally, those sensors would produce the same readings but in practice there are significant offsets. Datasheets for the MS5837-02BA and MS5803-14BA that we will compare in this post claim an accuracy of (±0.5mbar) and (±2ºC) for the 2-bar while the 14-bar sensors are only rated to (±20mbar) and (±2ºC). Sensors from Measurement Specialties are directly code compatible so the units here were read with the same Over Sampling settings.

Barometric pressure from a set of nine MS58xx pressure sensors running on a bookshelf as part of normal burn-in testing. The main cluster has a spread of about 10millibar, with one dramatic outlier >20 mbar from the group. These offsets are much wider than the datasheet spec for those 2-bars sensors.

But this is only a starting point: manufacturers have very specific rules about things like the temperature ramps during reflow and it’s unlikely that cheap sensor modules get handled that carefully. Housing installation adds both physical stress and thermal mass which will induce shifts; as can the quality of your supply voltage. Signal conditioning and oversampling options usually improve accuracy, but there are notable exceptions like the BMP/E 280 which suffers from self-heating if you run it at the startup defaults.

As described in our post on waterproofing electronics, we often mount pressure sensors under mineral oil with a nitrile finger cot membrane leading to thermal lag.

Sensors like NTC thermistors are relatively easy to calibrate using physical constants. But finding that kind of high quality benchmark for barometric sensors is challenging if you don’t live near a government-run climate station. So we typically use a normalization process to bring a set of different sensors into close agreement with each other. This is a standard procedure for field scientists, but information on the procedures is hard to find because the word ‘normalization’ means different things in various industry settings. In Arduino maker forums it usually describes scaling the axes from a single accelerometer with (sensor – sensor.min )/( sensor.max – sensor.min ) rather than standardizing a group of different sensors.

When calibrating to a good reference you generally assume that all the error is in your cheap DIY sensor and then do a linear regression by calculating a best fit line with the trusted data on they Y axis of a scatter plot.  However, even in the absence of a established benchmark you can use the same procedure with a ‘synthetic’ reference created by drawing an average from your group of sensors:

Note: Sensor #41 was the dramatic outlier more than 20millibar from the group (indicating a potential hardware fault) so this data is not include in the initial group average.

With that average you calculate y = Mx + B correction constants using Excel’s slope & intercept functions. Using these formulas lets you copy/paste equations from one data column to the next which dramatically speeds up the process when you are working through several sensors at a time. It also recalculates those constants dynamically when you add or delete information:

The next step is to calculate the difference (residuals) between the raw sensor data and the average: before and after these Y=Mx+B corrections have been applied to the original pressure readings. These differences between the group average and an individual sensor should be dramatically reduced by the Mx+b adjustments:

After you copy/paste these calculations to each sensor, create x/y scatter plots of the residuals so you can examine them side-by-side:

Now we can deal with the most important part of the entire process: Normalization with bad input data will produce even more misleading results. While the errors shown above are centered around zero, the patterns in these graphs indicate that we are not finished. In the ideal case, residuals should usually be soft fuzzy distributions with no observable patterns. But here we have a zigzag that is showing up for most of the sensors. This is an indication that one (or more) of the sensors included in the average has some kind of problem. Scrolling further along the columns identifies the offending sensors with nasty looking residual plots after the corrections have been applied:

Sensor #41 (far right) was already rejected from the general average because of its enormous offset, but the high amplitude jagged residual plots indicate that the data from sensors #45 and #42 are also suspect. If we eliminate those two from the reference average the zigzag pattern disappears from the rest of the sensors in the set:

There’s more we could learn from the residual distributions, but here we’ve simply used them to prune our reference data, preventing bad sensor input from harming the the average we use for our normalization.

And what do the sensor plots look like after the magic sauce is applied?

The same set of barometric pressure sensors, before and after normalization corrections. (minus #41 which could not be corrected)

It’s important to note that there is no guarantee that fitting your sensors to an average will do anything to improve accuracy. However, sensors purchased from different vendors, at different times, tend to have randomly distributed offsets. In that case normalization improves both precision and accuracy, but the only way to know if that has happened is to validate against some external reference like the weather station at your local airport. There are several good long term aggregators that harvest METAR data from these stations like this one at Iowa State, or you can get the most recent week of data by searching for your local airport code at weather.gov

METAR is a format for weather reporting that is predominately used for pilots and meteorologists and they report pressure adjusted to ‘Mean Sea Level’. So you will have to adjust your data to MSL (or reverse the correction on the airport data) before you can compare it to the pressure reported by your local sensors. For this you will also need to know the exact altitude of your sensors when the data was gathered to remove the height offset between your location and the airport stations.

Technically speaking, you could calibrate your pressure sensors directly to those official sources. However there are a lot of Beginner, Intermediate and Advanced details to take care of. Even then you still have to be close enough to know both locations are in the same weather system.

Here I’m just going to use the relatively crude adjustment equation:
Station Pressure = SLP – (elevation/9.2) and millibar = inchHg x 33.8639 to see if we are in the ballpark.

Barometric data from the local airport (16 miles away) overlayed on our normalized pressure sensors. It’s worth noting that the airport data is at a strange odd-minute intervals, with frequent dropouts which would complicate a calibration to that reference.

Like most pressure sensors an MS58xx also records temperature because it needs that for internal calculation. So we can repeat the entire process with the temperature readings from this sensor set:

Temperatures °C from a set of MS58xx Pressure sensors: before & after group normalization. Unlike pressure, this entire band was within the ±2ºC specified in the datasheet.

These sensors were sitting pretty far back on a bookshelf that was partly enclosed, so some of them were quite sheltered while others were exposed to direct airflow. So I’m not bothered by the spikes or the corresponding blips in those residual plots. I’m confident that if I had run this test inside a thermally controlled environment (ie: a styrofoam cooler with a small hole in the top) the temperature residuals would have been well behaved.

One of the loggers in this set had a calibrated NTC thermistor onboard. While this sensor had significant lag because it was located inside the housing, we can still use it to check if the normalized temperatures benefit from the same random distribution of errors that were corrected so nicely by the pressure normalization:

Once again, we have good alignment between a trusted reference (in red) and our normalized sensors.

Comments:

Normalization is a relatively low effort way to improve sets of sensors – and it’s vital if you are monitoring systems that are driven primarily by gradients rather than absolute values. This method generalizes to many other types of sensors although a simple y=Mx +B approach usually does not handle exponential sensors very well. As with calibration, the data set used for normalization should span the range of values you expect to gather with the sensors later on.

The method described here only corrects differences in Offset [with the B value] & Gain/Sensitivity [the M value] – more complex methods are needed to correct non-linearity problems. To have enough statistical power for accuracy improvement you want a batch of ten or more sensors and it’s a good idea to exclude data from the first 24 hours of operation so brand new sensors have time to settle. Offsets are influenced by several factors and some sensors need to ‘warm up’ before they can be read. The code driving your sensors during normalization should be identical to the code used to collect data in the field.

All sensor parameters drift so, just like calibration, normalization constants have a shelf life. This is usually about one year, but can be less than that if your sensors are deployed in harsh environments. Fortunately this kind of normalization is easy to redo in the field, and it’s a good way to spot sensors that need replacing. You could also consider airport/NOAA stations as stable references for drift determination.


References & Links:

Decoding Pressure @ Penn State
Environmental Mesonet @ Iowa State
Calibrating your Barometer: Part1, Part2 & Part3
How to Use Air Sensors: Air Sensor Guidebook
ISA Standard Atmosphere calculator
Starpath SLP calculator
SensorsONE Pressure Calculators
Mean Sea Level Pressure converter

How do you deal with I2C bus resistance/capacitance issues with so many sensors connected?

I have to add a special mention here of the heroic effort by liutyi comparing different temp. & humidity sensors. While his goal was not normalization, the graphs clearly demonstrate how important that would be if you were comparing a group of sensors. Humidity sensors have always been a thorn in our side – both for lack of inter-unit consistency and because of their short lifespan in the field relative to other types of sensors. The more expensive Sensirons tend to last longer – especially if they are inside one of those protective shells made from sintered metal beads. KanderSmith also did an extensive comparison of humidity sensors with more detailed analysis of things like sensor response time.

You can use the map function to normalize range sensors where both the upper and lower bounds of the sensor varies. And you can use Binary Saturated Aqueous Solutions as standards.

How to calibrate NTC thermistors (A DIY method you can do at home)

This post describes a thermistor calibration achievable by people who don’t have access to lab equipment with an accuracy better than ±0.15°C. This method is particularly suitable for the 10k NTC on our 2-module data logger handling them in a way that is easy to standardize for batch processing (ie: at the classroom scale). We use brackets to keep the loggers completely submerged because the thermal conductivity of the water around the housing is required or the two sensors would diverge. The target range of 0° to 40°C used here covers moderate environments including the underwater and underground locations we typically deploy into. This method is unique in that we use a freezing process rather than melting ice for the 0°C data point.

Use stainless steel washers in your hold-downs to avoid contamination of the distilled water and provide nucleation points to limit super-cooling. Before creating this bracket we simply used zip-ties to hold the washer weights.

Reading a thermistor with digital pins uses less power, and gives you the resistance of the NTC directly from the ratio of two Interrupt Capture Unit times. Resolution is not set by the bit depth of your ADC, but by the size of the reservoir capacitor: a small ceramic 0.1µF [104] delivers about 0.01°C with jitter in the main system clock imposing a second limit on resolution at nearly the same point. Large reservoir capacitors increase resolution and reduce noise but take more time and use more power. The calibration procedure described in this post will work no matter what method you use to read your NTC thermistor.

The I2C reference sensor is connected temporarily during the calibration via Dupont headers. Always give your reference sensors serial numbers so that you can normalize them before doing the thermistor calibrations.

Off-the-shelf sensors can be used as  ‘good enough’ reference thermometers provided you keep in mind that most accuracy specifications follow a U-shaped curve around a sweet spot that’s been chosen for a particular application. The Si7051 used here has been optimized for the medical market, so it has ±0.1° accuracy from 35.8 to 41° Celsius, but that falls to ±0.13° at room temperatures and only  ±0.25° at the ice point. If you use some other reference sensor (like the MAX30205 or the TSYS01) make sure it’s datasheet specifies how the accuracy changes over the temperature range you are targeting with the calibration.

The shortened Steinhart–Hart equation used here is not considered sufficiently accurate for bench-top instruments which often use a four or five term polynomial. However in ‘The Guide on Secondary Thermometry‘ by White et. al. (2014) the three-term equation is expected to produced interpolation errors of about 0.0025°C over a range from 0 to 50°C, and that is acceptable for most monitoring. To calculate the three equation constants you need to collect three temperature & resistance data pairs which can be entered into the online calculator at SRS or processed with a spreadsheet.

While these technical sources of error limit the accuracy you can achieve with this method, issues like thermal lag in the physical system and your overall technique are more important. In general, you want each step of the calibration process to occur as slowly as possible. If the data from a run doesn’t look the way you were expecting – then do the procedure over again until those curves are well behaved and smooth. Make sure the loggers stay dry during the calibration – switching to spare dry housing tubes between the baths: Moisture is the greatest cause of failure in sensors and humidity/water always lowers the resistance of thermistors. If in doubt, let everything dry for 24 hours before re-doing a calibration.

Data Point #1: The freezing point of water

The most common method of obtaining a 0°C reference is to place the sensor into an insulated bucket of stirred ice slurry that plateaus as the ice melts. This is fine for waterproof sensors on the end of a cable but it is not easily done with sensors mounted directly on a PCB. So we immerse the loggers in collapsible 1200ml silicone food containers filled with distilled water. This is placed inside of a well insulated lunch box and the combined assembly is left in the freezer overnight, reading every 30 seconds.

Weighted holders keep each logger completely immersed. Soft-walled silicone containers expand to accommodate any volume change as the water freezes. This prevents the centrifuge tube housings from being subjected to pressure as the ice forms. Position the loggers so that they are NOT in direct contact with the sides or the lid of the silicone container.
The outer box provides insulation to slow down the freezing process. After testing several brands it was found that the Land’s End EZ wipe (9″x8″x4″) and Pottery Barn Kids Mackenzie Classic lunch boxes provided the best thermal insulation because they have no seams on the solid molded foam interior which also doesn’t absorb water spilled while moving the containers around.

For the purpose of this calibration (at ambient pressure) we can treat the freezing point of pure water as a physical constant. So no reference sensor is needed on the logger while you collect the 0°C data. Leave the lunch box in the freezer just long enough for a rind of ice to form around the outer edges while the main volume of water surrounding the loggers remains liquid. I left the set in this photo a bit too long as that outer ice rind is much thicker than it needed to be for the data collection. Do not let the water freeze completely solid (!) as this will subject the loggers to stress that may crack the tubes and let water in to ruin your loggers.

The larger bubbles in this photo were not present during the freeze, but were created by moving the container around afterward for the photo.

The trick is recognizing which data represents the true freezing point of water. Distilled water super-cools by several degrees, and then rises to 0°C for a brief period after ice nucleation because the phase change releases 80 calories per gram while the specific heat capacity of water is only one calorie, per degree, per gram. So freezing at the outer edges warms the rest of the liquid – but this process is inherently self-limiting which gives you a plateau at exactly 0°C after the rise:

NTC (ohms) gathered during the freeze/thaw process graphed with the y axis is inverted because of the negative coefficient. The warm temperature data has been removed from the graphs above to display only the relevant cold-temperature data. Only the 10-20 minutes of data immediately after the rise from a super cooled state is relevant to the calibration. Cooling the insulated chamber from its room temperature starting point to the supercooling spike shown above took 7-8 hours.

Depending on the strength of your freezer, and the quality of the outer insulating container, the ice-point may only last a few minutes before temperatures start to fall again. An average of the NTC readings from that SHORT plateau immediately after the supercooling ends is your 0°C calibration point.  This is usually around 33000 ohms for a 10k 3950 thermistor. Only the data immediately after super cooling ends is relevant and the box can be removed from the freezer any time after that event. I left the example shown above in the freezer too long but you have a reasonable window of time to avoid this. Once the freeze process initiates, it usually takes about 8 hours for the entire volume to freeze solid – after which you can see the compressor cycling as the now solid block cools below 0°C. You want to pull the sensors out of the freezer before that solid stair-step phase (at 8:00 above) if possible.

If the supercooling spike is not obvious in your data then change your physical configuration to slow the cooling process until it appears. You want the inner surface of your silicone container to have smooth edges, as sharp corners may nucleate the ice at 0°C, preventing the supercooling spike from happening. Use as much distilled water as the container will safely hold -the loggers should be surrounded by water on all sides.

In this image a freezer compressor cycle happened during post supercooling rise making it hard to see where the plateau occurred. This run was re-done to get better data.

Most refrigerators cycle based on how often the door is opened and those cycles can overprint your data making it hard to interpret. If you put a room-temperature box of water in the freezer between 6-7pm, it usually reaches the supercooling point around 2am, reducing the chances that someone will open the refrigerator/freezer door at the critical time. Even then, unexpected thermal excursions may happen if the freezer goes into a defrost cycle or an automatic ice-maker kicks in during the run. The time to reach that supercooling event can be reduced by pre-cooling the distilled water to ~5°C in the refrigerator before the freezer run. If any of the points on your curves are ambiguous, then do that run again, making sure the water is completely ice free at the start.

As a technical aside, the energy released (or absorbed) during the phase change of water is so much larger than its typical thermal content that water based heat pumps can multiply their output significantly by making slushies.

Data Point #2:  Near 40°C

We have used the boiling point of water for calibration in the past, but the centrifuge tube housings would soften considerably at those temperatures. Ideally you want to bracket your data with equally spaced calibration points and 100°C is too far from the environmental conditions we are targeting. Heated water baths can be found on eBay for about $50, but my initial tests with a Fisher Scientific IsoTemp revealed thermal cycling that was far too aggressive to use for calibration – even with a circulation pump and many layers of added insulation. So we created an inexpensive DIY version made with an Arctic Zone Zipperless Coldloc hard-shell lunch box and a 4×6 inch reptile heating mat (8 watt). Unlike the ice point which must be done with distilled water, ordinary tap water can be used to collect the two warm temperature data pairs.

These hard-sided Arctic Zone lunch boxes can often be obtained for a few dollars at local charity shops or on eBay.
Place the 8-watt heating pad under the hard shell of the lunch box. At 100% power this tiny heater takes ~24 hours to bring the bath up to ~38°C. The bath temp is relatively stable since the heater does not cycle, but it does experience a slow drift based on losses to the environment. These heating pads sell for less than $15 on Amazon.

To record the temperature inside each logger, an Si7051 breakout module (from Closed Cube) is attached to the logger. A hold down of some kind must keep the logger completely submerged for the duration of the calibration. If a logger floats to the surface then air within the housing can thermally stratify and the two sensors will diverge. That data is not usable for calibration so the run must be done again with that logger.

The reference sensor needs to be as close to the NTC sensor as possible within the housing – preferably with the chip directly over top and facing the NTC thermistor.

Data Point #3: Room Temperature

The loggers stay in the heated bath for a minimum of 4 hours, but preferably 8 -12 hours. The idea is you want the whole assembly to have enough time to equilibrate. Then they are transferred to an unheated water-filled container (in this case a second Arctic Zone lunch box) where they run at ambient temperatures for another 8 -12 hours. This provides the final reference data pair:

Si7051 temperature readings inside a logger at a 30 second sampling interval. The logger was transferred between the two baths at 8am. Both baths are affected by the temperature changes in the external environment.
Detail: Warm temp. NTC ohms (y-axis inverted)
Detail: Room temp. NTC ohms (y-axis inverted)

As the environment around the box changes, losses through the insulation create gentle crests or troughs where the lag difference between the sensors will change sign. So averaging several readings across those inflection points cancels out any lag error between the reference sensor and the NTC. Take care that you average exactly the same set of readings from both the Si7051 and from the NTC. At this point you should have three Temperature / Resistance data pairs that can be entered into the SRS online calculator to calculate the equation constants ->

I generally use six digits from the reference pairs, which is one more than I’d trust in the temperature output later. I also record the Beta constants for live screen output because that low accuracy calculation takes less time on limited processors like the 328p.

The final step is to use those constants to calculate the temperature from the NTC data with:
Temperature °C = 1/(A+(B*LN(ohms))+(C*(LN(ohms))^3))-273.15

Then graph the calculated temperatures from the NTC calibration readings over top of the reference sensor temperatures. Provided the loggers were completely immersed in the water bath, flatter areas of the two curves should overlap one another precisely. However, the two plots will diverge when the temperature is changing rapidly because the NTC exhibits more thermal lag than the Si7051. This is because the NTC is located near the thermal mass of the ProMini circuit board.

Si reference & NTC calculated temperatures: If your calibration has gone well, the curves should be nearly identical as shown above. With exceptions only in areas where the temperature was changing rapidly and the two sensors got out of sync because of different thermal lags.

Also note that the hot and warm bath data points can be collected with separate runs. In fact, you could recapture any individual data pair and recalculate the equation constants with two older ones any time you suspect a run did not go smoothly. Add the constants to all of the data column headers, and record them in a google doc with the three reference pairs and the date of the calibration.

Validation

You should always do a final test to validate your calibrations, because even when the data is good it’s easy to make a typo somewhere in the process. Here, a set of nine calibrated NTC loggers are run together for a few days in a gently circulating water bath at ambient temperature –>

(Click to enlarge)

Two from this set are a bit high and could be recalibrated, but all of the NTC temperature readings now fall within a 0.1°C band. This is a decent result from a method you can do without laboratory grade equipment, and the sensors could be brought even closer together by using this validation data to normalize the set.

Comments

The method described above uses equipment small enough to be portable, allowing easy classroom setup/takedown. More importantly this also enables the re-calibration of loggers in the field if you have access to a freezer. This makes it possible to re-run the calibrations and then apply compensation techniques to correct for sensor drift. Validating calibration before and after each deployment is particularly important with DIY equipment to address questions about data quality at publication. Glass encapsulated NTC thermistors drift up to 0.02 °C per year near room temperatures, while epoxy coated sensors can drift up to 10x that.

At the ice-point, our resolution is ~0.0025°C but our time-based readings vary by ±0.0075°C. This is due to timing jitter in the ProMini oscillator and in the interrupt handling by a 328p. So with a [104] reservoir capacitor in the timing circuit, our precision at 0°C is 0.015°C.

Having a physical constant in the calibration data is important because most of the affordable reference sensors in the Arduino landscape were designed for applications like healthcare, hvac, etc. So they are usually designed minimize error in warmer target ranges, while getting progressively worse as you approach 0°C. But accuracy at those lower temperatures is important for environmental monitoring in temperate climates. The method described in this post could also be used to calibrate commercial temperature sensors if they are waterproof.

Calibrating the onboard thermistor a good idea even if you plan to add a dedicated temperature sensor because you always have to do some kind of burn-in testing on a newly built logger – so you might as well do something productive with that time. I generally record as much data as possible during the calibration to fill more memory and flag potentially bad areas in the EEprom. (Note: Our code on GitHub allows only 1,2,4,8, or 16 bytes per record to align with page boundaries) . And always look at the battery record during the calibration as it’s often your first clue that a DIY logger might not be performing as expected. It’s also worth mentioning that if you also save the RTC temperatures as you gather the NTC calibration data, this procedure gives you enough information to calibrate that register as well. The resolution is only 0.25°C, but it does give you a way to check if your ‘good’ temperature sensors are drifting because the DS3231 tends to be quite stable.

While the timing jitter does not change, non-linearity of the NTC resistance reduces the resolution to 0.005°C. Precision at 35°C also suffers, falling to 0.02°C. Using a 10x larger [105] reservoir cap would get us back to resolution we had at 0°C, as would oversampling which actually requires this kind of noise for the method to work. Either of those changes would draw proportionally more power from the coincell for each read so its a tradeoff that might not be worth making when you consider sensor lag.

For any sensor calibration the reference points should span the range you hope to collect later in the field. To extend this procedure for colder climates you could replace the ice point with the freezing point of Galinstan (-20°C) although a domestic freezer will struggle to reach that. If you need a high point above 40°C, you can use a stronger heat source. Using two of those 8 watt pads in one hard sided lunch box requires some non-optimal bending at the sides, but it does boost the bath temp to about 50°C. 3D printed PLA hold-downs will start to soften at higher temps so you may need to alter the design to prevent the loggers from popping out during the run.

If your NTC data is so noisy you can’t see where to draw an average, check the stability of your regulator because any noise on the rail will affect the Schmitt trigger thresholds used by our ICU/timer method. This isn’t an issue running from a battery, but even bench supplies can give you noise related grief if you’ve ended up with some kind of ground loop. You could also try oversampling, or a leaky integrator to smooth the data – but be careful to apply those techniques to both the reference and the NTC in exactly the same way because they introduce significant lag. Temperature maximums are underestimated and temperature minimums are overestimated by any factor that introduces lag into the system. In general, you want to do as little processing to raw sensor readings as possible at capture time because code-based techniques usually require some prior knowledge of the data range & variation before they can be used safely. Also note that our digital pin ICU based method for reading resistors does not work well with temperature compensated system oscillators because that compensation circuitry could kick in between the reference resistor and NTC readings.

And finally, the procedure described here is not ‘normalization’, which people sometimes confuse with calibration.  In fact, it’s a good idea to huddle-test your sensors in a circulating water bath after calibration to bring a set closer together even though that may not improve accuracy. Creating post-calibration y=Mx+B correction constants is especially useful for sensors deployed along a transect, or when monitoring systems that are driven by relative deltas rather than by absolute temperatures. Other types of sensors like pressure or humidity have so much variation from the factory that they almost always need to be normalized before deployment – even on commercial loggers.

Normalize your set of reference sensors to each other before you start using them to calibrate NTC sensors.


References & Links:

SRS Online Thermistor Constant Calculator
Steinheart & Heart spreadsheet from CAS
S&H Co-efficient calculator from Inside Gadgets
Molex Experimenting with Thermistors Design Challenge
Thermistor Calibration & the Steinhart-Hart Equation WhitePaper from Newport
ITS-90 calibrates w Mercury(-38.83), Water(0.01) & Gallium(29.76) Triple Point cells
Guide on Secondary Thermistor Thermometry, White et al. (2014)
Steinhart-Hart Equation Errors BAPI Application Note Nov 11, 2015
The e360: A DIY Classroom Data Logger for Science
How to make Resistive Sensor Readings with DIGITAL I/O pins
Single Diode Temperature Sensors
Measuring Temperature with two clocks
How to Normalize a Set of Sensors

Testing Cr2032 Coin Cell Batteries with μA to mA pulsed duty cycles

Cr2032 Internal Resistance vs mAh [Fig6 from SWRA349] Our peak load of ~8 mA while writing data to the EEprom creates a voltage drop across the battery IR. The load induced transient on the 3v Cr2032 can’t fall below 2.775v or the BOD halts the 328p processor. This limits our useable capacity to the region where battery IR is less than 30 ohms. This also makes it critical to control when different parts of the system are active to keep the peak currents low. With this relatively high cutoff we can only use about 100 milliampseconds of power from a typical CR2032.

Reviewers frequently ask us for estimates based on datasheet specifications but this project is constantly walking the line between technical precision and practical utility. The dodgy parts we’re using are likely out of spec from the start but that’s also what makes our 2-module data loggers cheap enough to deploy where you wouldn’t risk pro-level kit. And even when you do need to cross those t’s and dot those i’s you’ll discover that OEM test conditions are often proscribed to the point of being functionally irrelevant in real world applications. The simple question: “How much operating lifespan can you expect from a coin cell?” is difficult to answer because the capacity of lithium manganese dioxide button cells is nominal at best and wholly dependent on the characteristics of the load. CR2032’s only deliver 220mAh when the load is small: Maxell’s datasheet shows that a 300 ohm load, for a fraction of a second every 5 seconds, will drop the capacity by 25%. However, if the load falls below 3μA for long periods, then this also causes the battery to develop higher than normal internal resistance, reducing the capacity by more than 70%. The self-discharge rate increases with temperature due to electrolyte evaporating through the edge seal. Another challenge is ambient humidity which can change PCB leakage currents significantly.

Voltage Under EEprom load VS date [runtime hours in legend] with red LED on D13 driven HIGH for 1.4mA sleep current, 30second interval, 8-byte buffer. These are serial tests performed on the same logger. 1.4mA continuous is probably is not relevant to our duty cycle.

Surprisingly little is known about how a CR2032 discharges in applications where low μA level sleep currents are combined with frequent pulse-loads in the mA range; yet that’s exactly how a datalogger operates. As a general rule, testing and calibration should replicate your deployment conditions as closely as possible. However, normal run tests take so long to complete that you’ve advanced the code in the interim enough that the data is often stale by the time the test is complete. Another practical consideration is that down at 1-2μA: flux, finger prints, and even ambient humidity skew the results in ways that aren’t reproducible from one run to the next. So a second question is “How much can you accelerate your test and still have valid results?” Datasheets from Energiser, Duracell, Panasonic and Maxell reveal a common testing protocol using a 10-15kΩ load. So continuous discharges below 190μA shouldn’t drive you too far from the rated capacity. Unfortunately, that’s well below what you get with affordable battery testers, or videos on YouTube, so we are forced yet again to do our own empirical testing.

The easiest way to increase our base load is to leave the indicators on: all three LEDs will add ~80μA to the sleep current when lit using internal the pullup resistors. 80μA is ~16x our normal 5μA sleep current (including sensor draw & RTC temp conversions). A typical sampling interval for our work is 15min so changing that to 1 minute gives us a similarly increased number of EEprom save events. With both changes, we tested several brands to our 2775mv shut-down:

Cr2032 Voltage Under EEprom Load VS Date: Accelerated Cr2032 run tests with 3xLED lit with INPUT_PULLUP for ~80μA sleep current although each unit was slightly different as noted, 1min sampling interval. Blue Line = Average excluding Hua Dao. CLKPR reduced system clock to 1MHz during eeprom save on this test to reduce peak currents to about 6mA. All units had 227E 25V 220μF rail buffering caps.
BrandRun Time (h)Cost / Cell|BrandRun Time (h)Cost / Cell
Panasonic1500$ 1.04|Duracell1298$ 1.81
Voniko1448$ 0.83|AC Delco1223$ 0.79
Maxell1444$ 0.58|Nightkonic1186$ 0.24
Toshiba1325$ 0.64|MuRata1175$ 0.45
Energiser1307$1.28|Hua Dao642$ 0.14
Note: With the slight variation between each loggers measured sleep current, the times listed here have been adjusted to a nominal 80μA. Also note that the price/cell is highly dependant on vendor & quantity.

Despite part variations these batteries were far more consistent on that 20ohm plateau than I was expecting. This ~15x test gives us a projected runtime of more than two years! That’s twice the estimate generated by the Oregon Embedded calculator when we started building these loggers. We did get a 30% delta between the name brands, but these tests were not thermally controlled and we don’t know how old the batteries were before the test. The rise in voltage after that initial dip is probably the pulse loads removing the passivation layer that accumulates during storage. The curves are a bit chunky because the 328P’s internal vref trick has a resolution of only 11mv, and we index-compress that to one byte which results in only 16mv/bit in the logs.

One notable exception is the Hua Dao cells, which I tested because, at only 14¢ each, they are by far the cheapest batteries on Amazon. My guess they are so cheap because they used a lower grade of steel for the shell which increases the cell resistance. We have many different runs going at any one time, and to make those inter-comparable you need to start each test with a fresh cell. Even if the current run test doesn’t need a batteries full capacity sometimes you just need to eliminate that variable while debugging. You also use a lot of one-shot batteries for rapid burn-in tests so it makes sense for them to be as cheap as possible. Now that I know Hua Dao delivers half the lifespan of name brand cells, I can leverage that fact to run some of those tests more quickly. I had planned on doing this with smaller batteries but the Rayovac Cr2025 I tested ran for 1035 hours – longer than the Hua Dao Cr2032!

Cr2032’s used since January for bench testing.

Testing revealed another complicating factor when doing battery tests: With metal prices sky-rocketing, fake lithium batteries are becoming more of a problem. We’ve been using Sony Cr2032’s from the beginning of the project but the latest batch performed more like the Hua Dao batteries. This result was so unexpected that I dug through the bins for some old stock to find that the packaging looked slightly different:

Fake (left) vs Real (right)

On closer inspection it didn’t take long to spot the fraud:

Fake Sony Battery : laser engraved logo
Real Sony Battery: Embossed logo

More tests are under way so I’ll add those results to this post when they are complete. A couple of the 80μA units have been re-run after removing the 227E 25V 220μF rail buffering caps, confirming that the tantalum does not extend overall run time on good batteries very much because their internal resistance rises slowly, but rail caps can more than double the lifespan with poor quality batteries like the Hua Dao. In my 20min tests at 3 volts, [477A] 10v 470μF caps eventually fell to a leakage of about 25nA which was not much more than the 15nA on a [227E] 25v 220μF tantalum. 6v volt [108J] 1000μF rail caps have much higher 980nA leakage which is larger than the DS3231’s typical constant Ibat of 840nA. This shortens overall logger runtime to only 6-7 months: so very large rail caps are only useful with high drain sensors or in cold conditions. It’s also worth mentioning that the spring contacts on those RTC modules are quite weak and may need a bit of heat shrink tubing behind them to strengthen the connection to the flat surface of the coin-cell. A small bead of hot glue on top also helps protect the battery from bump-disconnects.

Northern caves hold near 5-10°C all year round, so the current set is running in my refrigerator. I will follow that with hotter runs because both coin cell capacity AND self-discharge are temperature dependant. We also plan to start embedding these loggers inside rain gauges which will get baked under a tropical sun .

Addendum 2023-08-01

To avoid bump-disconnects in rough fieldwork conditions I sometimes add a bit of double-sided foam mounting tape behind the contact spring. This holds the battery well but is also a significant pain in the backside to remove at the end of the deployment. Usually that’s a good trade to guarantee the data.

This summers fieldwork required all of the units in my testing fleet so I only have a handful of results from the refrigerator burn down tests [@5°C]. The preliminary outcome is that, compared to the room temperature burns, the lithium cell plateau voltage lowers between 80-100mv (typically from 3000mv to 2900mv). Provided the loggers were reading a low drain sensor the ‘cold’ lifespan was only about 20% shorter because the normal 50-70mv battery droop (during sensor reading / eeprom save) only becomes important after the battery falls off its plateau. This is approximately the same lifespan reduction you see running at room temp without a rail buffering capacitor – as the buffer also only comes into play when the battery voltage is descending. This is also the reason why the larger 1000μF rail capacitors usually only provide about 10% longer life than the 220μF rail caps as the reduced battery droop with the larger cap only matters when the cell is nearing end of life. Net result is that increasing to 1000μF rail buffers almost exactly offsets the lifespan losses at colder ambient temps around 5°C . But for longer deployments, at normal room temps, the 1-2μA leakage of a 6v 1000μF [108j] tantalum removes any advantage over the 25v 220μF [227e] which has only 5nA leakage at 3 volts. Also note that some caps seem to need a few hours to ‘burn in’ before they are saturated enough to measure their leakage properly.

The freezer results are an entirely different situation where are only seeing a few days of accelerated 100μA sleep current operation because once you get below -15°C the coin cell plateaus below our 2800mv shutdown voltage. So the logger only operates for the brief span of time where the initial overvoltage on new Cr2032 is still above its nominal voltage. Even a 1000μF cap will not fix that problem so for truly cold weather deployments you’d need a different battery chemistry like lithium-thionyl chloride (LiSOCl2) which is good to -40°C provided you add a large rail buffering capacitor to compensate for it’s current limitations. Loggers drawing the a more normal 2-5μA sleep current run OK in a domestic freezer if the sensor is not too demanding. In fact we use waters 0°C phase transition as a physical reference when calibrating the onboard thermistors – and that’s done on a normal CR2032.

Addendum 2025-01-25

Finally getting the 2024 deployments swapped out, so I have some real-world burn down curves to add here. These units were in a U.S. cave rather than our typical Mexico field sites, so temps were cool enough to have some effect on the cell voltage:

11 months of [°C] temperature variation near the entrance of the cave, read by an NTC thermistor on the logger.
A new NightKonic Cr2032 coin cell was installed at the start of the deployment. This logger had a continuous sleep current of 1.2µA, but the RTC TXCO corrections bump that to >3µA average.
[°C] temperature variation is reduced as you move further into the cave (until eventually there is little of the outside annual climate signal left.)
Again a new NightKonic battery was used with this 1.6µA (continuous) sleeper. Lowest battery under load was saved once per day for these records.

With normal runtime operations the CR2032s plateaued near the nominal 3v with a 220µF rail buffering cap. It’s hard to tell if that slight shift indicates the end of the batteries 20ohm plateau or was just a response to the lower winter temperatures. Assuming that was the end of the plateau, then I’d expect another three (?) months of operation before the internal resistance pushes the voltage droop during EEprom saves to our 2800mv cutoff. Both were deployed with 1 gram of desiccant, which probably was not enough for the 30mL polypropylene tubes (given the color of the indicator beads when the loggers were downloaded). Unsaturated silica gel holds the air near 20%, but these loggers probably spent half of their deployment at high RH. I rarely put desiccant in my testing loggers and on the rare occasion when I forget one of them long enough for the Cr2032 to fall below 1000mv there is “a particular smell” that is quite noticeable when the logger is opened. That makes me wonder if electrolyte off-gassing also affects the color of the desiccant indicators beads.

The take home lesson is: when your accelerated testing indicates a two year lifespan under optimal conditions, you should expect to reach only half of that on a real-world deployment. If I assume a 3.5µA sleep current (ie: the DS3231’s timekeeping average incl. TXCO conversions) with four 3.5mA x 50msec logging events per hour, then the Oregon Embedded calculator gives me an 100mAh battery life of 958 days. Interestingly, the capacity of a 256k EEprom @ 15min interval storing 4bytes/record is also about 680 days. Taken together, these factors mean our loggers should only be expected to operate for a year – plus – a healthy 3-6 month margin if you used a good Cr2032 battery.

One unknown variable is the self-discharge rate of the Cr2032. I’ve seen references to a nominal 1% loss in battery capacity per year under ideal conditions, which would be like adding another 300nA of continuous load. But that loss can be up to 10x larger in high humidity environments.

Another variable that can have a serous impact on lifespan is the number of EEprom save events per day. In my tests a typical EEsave uses between 0.3-0.5 milliamp seconds of power, with sensor readings using a similar amount/record. (in comparison to a ‘good’ loggers sleep-current baseload of about 250-300 milliamp-seconds per day) So a few hundred EEsave events could potentially use power comparable to the sleep current each day. EEproms have to erase and re-write an entire page of memory any time you save a number of bytes less than the hardware page size. If you increase the two wire library buffers, and pre-buffer the sensor data into temporary arrays, you can increase the bytes per EEsave event from 16 to 64 (or even 128) to reduce the number of save events. When you transfer the same number of bytes as the EEproms hardware page size then the chip can skip any ‘pre-erase’ steps entirely – cutting ALL save events to 1/2 the time/power they would use saving a smaller number of bytes. This both increases speed and can extend operating lifespan significantly with multi sensor configurations collecting many bytes of data per record over short 1-5 minute sampling intervals.

Links & References:

Evaluating Battery Models in Wireless Sensor Networks, Rohner et.al.
ATmega328 Calculation Speed tables

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

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 your the luggage. 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 tropical hurricane destroys half your stations.

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

This station has never been disturbed.
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.
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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 development blockers for large landowners waiting for property values to rise high enough for their own development project to become profitable. 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 rooftop 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 with a section in the middle 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 you can also find 3d printable models for constant flow Mariotte bottle rigs in the open source literature. In a pinch your can do a field check simply by poking a tiny pin-hole in a plastic milk jug or coke bottle filled with 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 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 gauge 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 between 100 to 125ms with 1-2ms of bounce either side. After the FALLING trigger, sleep for ~120msec before re-enabling the interrupt. You can eliminate the 5k pull using the 25k internal pullup on D3, but your rise time increases from 10ms to 25ms and the resulting divider only drops to 15% of Vcc rather than zero.

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 upper 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 the heck?

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 and baking soda. 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 other components of gauge, we repurpose these virtually indestructible innards for drip monitoring in caves. You can 3d print a new base, or mould feet from nylon bolts and plumbers putty.

Waterproofing your Electronics Project

We’ve been deploying our loggers under water since 2013 and although we’ve posted many detailed build tutorials along the way, it’s time to gather some of that distributed material into a summary of the techniques we use. This post will focus on options available with a modest budget and also include a few interesting methods we haven’t tried yet for reference. To put all this in context; we deploy our DIY loggers to typical sport diving depths and usually get solid multi-year operation from our underwater units.

Jump links to the sections of this post:

Arielle Ginsberg examines the sponges covering a flow sensor deployed in a coastal outflow canyon.

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 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 even though silicone coatings are not water vapour proof. 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. CA glue & spray-on accelerant can also be used to improve the strength of 3D prints, as demonstrated by the ever-mirthful Robert Murray-Smith. The sealed surface of your print can then be written on with a sharpie marker without the black ink bleeding into the PLA layers, although I also use clear mat-finish nail polish for this labeling.

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. Silica gel desiccant beads bring the air above them down to about 20% RH in 24-48 hours but only if there is enough mass for your volume. The best way to determine how much your build needs is to do test runs logging an RH sensor like the BME280 inside the box with different amounts of desiccant. 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. Another factor to consider is the different expansion rates of the circuit you are trying to protect vs the compound you are using for the encapsulation: hard epoxies may cause electrical failures by subjecting components to more stress when the environment is cycled between extreme temperatures. In those cases it is probably better to use softer compounds.


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
The two pieces are brought together
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: 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. The 30mL tubes are stronger for single sensor builds, but the 50mL tube provide more space for our 2-Module classroom data logger. This model uses two mini breadboards for convenient sensor swaps.

Addendum: 3D printed housings

PLA (or poly-lactic acid) is made from glucose that is converted to lactic acid with an H2O molecule removed to trigger the polymerization process. While water doesn’t degrade most printable polymers PLA slowly gets brittle when wet because it recaptures the H2O. But there is an energy barrier that requires the right temperature, pH, or UV conditions. Bacteria can also accelerate that chemistry and just anecdotally we’ve seen biofilms grow much faster on prints deployed to wet environments compared to our PVC housings. But it’s impossible to distinguish if it’s the polymer or some other lubricant/additive in the mix that they are attracted to. We’ve also seen ‘compression/tension’ mechanisms in PLA fail because of reduced strength even though there was no visual indications that the parts had degraded. This has motivated of our increasing conversion over to PETG for installations although I still use PLA while a new design is being developed because it prints faster. Most polymers are about 1.25 grams per cubic centimeter, so around 85% infill gives neutral buoyancy in water. Nylon can absorb a great deal of water and swell making submerged prints unusable.

The first thing to do when printing a housing is to make sure your filament is bone dry before starting, but all 3D prints are still going to be porous to some extent. There’s an interesting article on 3-d printed underwater housings over at the Prusa Research blog. The initial strategy is to increase the flow rate and temperature so less air gets trapped between the polymer lines that get laid down by the nozzle. Then I’d try a coating of CA glue with spray on accelerant to seal the outer surfaces. Or you could switch to SLA resin printing like RCtestflight – even then they still filled the space around their servos with silicone grease. Our little loggers work fine immersed in mineral oil which is relatively easy to clean up later with alcohol. Ironing produces smooth flat layers that you would think are more water resistant, but this Reddit contributor found that once bubbles are in the print, they can not be removed by ironing. ‘Brick layers’ would help reduce the air gaps but unfortunately that technique is tied up with patent issues. CPS drone had excellent results making prints waterproof by treating them with Dichtol AM Hydro which is very low-viscosity specifically for impregnation and sealing. This makes me think about testing the many waterproofing sealers at my local hardware store. Multiple thin coats of an epoxy should create an external seal if they get sanded between coats, but the underlying print would have to be strong enough to resist deforming & cracking. CPS also created interesting epoxy & print combination endcaps. Pass throughs are critical weak points in any design because water under pressure can rapidly wick between multi-strand wires if the outer insulation gets cut. Stripping to raw copper and embedding in the epoxy is usually required and you need to add soldered break-point or even a solid wire bridge through the housing because there is no way to get the epoxy to fill all the spaces between the strands without a vacuum chamber. Gyroid fills form continuous tubes that you can pour something like glass fiber-filled epoxy into for strength but heat from the curing resin can cause deformation. Re-melting the prints with powdered salt also seems to work for both water and gas hardening. Even if you eventually get all the bubbles out, the polymers themselves still have a vapour penetration rate. This is an issue in labs where you can’t do isotopic analysis on samples that have been left in poly centrifuge tubes too long. And it’s not unusual for 15ml Eppendorf’s to loose 1/3 of their volume in 8 months even if they are sealed well. If you have the budget for SLA printing, Formlabs have posted an interesting design where the o-ring seals are directly printed into the parts and the enclosure is sealed using a hand-screwed bezel. This is much like the seal you find in PVC plumbing parts like non-glued unions.

Slant3d demonstrated an interesting idea for enclosure boxes that keep water out without a seal although in our project condensation of ambient humidity is equally damaging in the long term. 3D printing is also handy for making angular connection joints for complex protective structures or custom sensor mounts that have to last underwater without rusting. But sometimes in the field you are better off using plumbers putty for those PVC tripods. I’ve lost count of how many times I jury-rigged something on site with plumbers putty that then lasted for years of outdoor exposure.

2-Part ProMini Logger that runs >1 year on a Coin Cell [2022]

This ‘two-part’ logger fits nicely inside a falcon tube which can be deployed to 10m water depth. With a bit of practice, complete logger assembly can be done in about 30-60 minutes depending on additions. 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 I2C memory chips or modules.

The ‘solderless’ 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 course being run remotely. (Although 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 lab subjects it’s a stretch for other instructors. And thanks to COVID shortages, modules that were only a buck at the beginning of the project might 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. That new baby is now ready for release with data download & control done through the serial monitor window.

Instead of connecting the red channel of the 5mm LED I use the onboard D13 LED for red. Other libraries and programs often require that LED.

With just three core components our only option was to remove the SD card. Groundwork for this change has been in place for a long time in our research loggers, with sensor readings first getting buffered to the 4k to reduce the number of high-drain SD saves. Getting rid of those power hungry cards opened up the possibility of running the entire unit from the coin cell on the RTC module. But a power budget that small adds some complexity to the base code which must minimize CPU run-time and limit peak current.

Internal Resistance with 6.8mA Pulse Discharge, from the Energiser Cr2032 datasheet. (Note: The 8mhz ProMini only draws about 3.3mA when its running)

Most garden-variety chips have a lower operating limit of 2.7v – so a 3v Cr2032 can only fall about 300mv under load before triggering the brown out detection (BOD) circuit. Voltage droop changes over time because the internal resistance of a coin cell is only 10 ohms when new, but increases to 100 ohms by end of life. According to Maxell’s 1Meg-ohm (3.3µA continuous) discharge test, coin cells should stay at their voltage plateau until they deliver about 140mAh. In our testing, 200uF battery buffering capacitors can extend runtime up to 30% but this varied with the quality of the battery. Of course, if you can reach a year without the rail buffer, then you’ve probably filled the memory. So rail caps may only be necessary with high-drain sensors or in low temperature deployments where the battery chemistry slows. It’s not unusual to see a 50mv delta at the battery terminals for every 15°C change in ambient so a standard coin cell will not power the logger very long at temperatures very far below freezing.

However, theres only so much you can predict about system behavior in the real world – especially with stuff constructed from cheap modules carrying half a dozen unspecified components. So let’s just build one and see how it goes.


Jump links to the sections of this post:


PREPARE the RTC module:

Clipping the main VCC leg (the 2nd leg in from that corner) forces the DS3231 to run from the backup power input on the other side of the chip.
Disconnect the modules indicator LED by removing its limit resistor with a hot soldering iron tip.
Remove the 200ohm charging resistor & bridge VCC to the coin cell backup power at the black ring end of diode.

Running from Vbat depowers most of the logic inside the DS3231 and disables the 32kHz output (I usually cut away that header). According to the -M and -SN datasheets, but both RTC chips draw the same average of 3.0µA timekeeping battery current to keep only the oscillator, temperature compensation & comparator working. The default 4k EEprom draws between 20-40nA when not being accessed. Bridging VCC directly to Vbat also means a 3.3v UART will push some sub-milliamp reverse currents through an older coin cell. Despite dire manufacturer warnings that reverse currents beyond 1µA will heat manganese-dioxide/lithium cells until they explode, I’ve yet to have a single problem (or even any detectable warming) with loggers connected for many days during code development. Drift on these RTCs is usually a loss of ~3-5 seconds per month, but you can reduce this considerably by calibrating the DS3231 Aging Offset Register with a GPS module. The only annoying issue with these RTC’s is that, once enabled, the alarms continue to be generated forever unless you set an ‘unreachable’ next alarm time, or shut down the main oscillator completely.

3 mods to the RTC module
It’s a good idea to test of those RTC modules (with the logger base-code) before assembling your logger. After successful testing, I add conformal to the RTC & let dry before joining the two modules.

OPTIONAL: Add another EEprom to the RTC module

With a practiced hand you can add more EEprom memory right onto the RTC module. 64k is the sweet spot for single sensors generating 2-byte integers because they can store ~340 days of data at a 15min. interval. Each additional EEprom adds 0.2 to 0.4µA to the loggers overall sleep current. 64K’s are about $1 up to 256K chips selling for about $3.50 at Digikey. AT-series EEproms larger than 64k, show up on the I2C bus as multiple 64k chips.

For an AT24c512 you only need connect the four pins shown because the chip internally grounds any pin left floating. The rtc module pulls all connected address pins high (setting the lower 4k to 0x57) but an upper 64k EEprom with the connections above would go to 0x50.
Stacked EEproms in a 0x57 & 0x51 configuration. If this soldering is a bit too advanced see the ‘adding sensors’ section for a way to increase storage space with modules. Of course you can stack on those boards as well!

PREPARE the Pro Mini:

Carefully clip away the regulator from the 2-leg side to prevent 80µA of back-leakage thru the regulator under battery power.
Clip away the reset switch. This logger can only be started with serial commands via a UART connection.
Remove the limit resistor for the power indicator LED with a hot soldering iron tip. This is near the regulator area.

An Arduino Pro Mini continues at the heart of our loggers because it is still the easiest low-power option for projects that aren’t computationally demanding. 328p’s normally sleep well below 1µA with the BOD turned off but 17µA with BOD left on. It’s worth noting that component level testing of the tiny sleep current on an isolated ProMini board requires stable battery power, as UART supplied voltages are too noisy for sensitive devices like a Current Ranger. You will occasionally get clones with fake Atmel chips that won’t go below ~100µA sleep no matter what you do.

At 8Mhz the ‘official’ lowest safe voltage for the 328p is 2.7v and the BOD cutoff circuit is always on while the processor is running. So you want to stop logging if the rail starts falling below ~2850mv. Keep in mind that there is wide range of actual brownout thresholds, from a minimum of 2.5v to a max. of 2.9v. So if you get a logger that consistently quits while the battery voltage is still high, you might want to check that units actual BOD trigger point with a bench power supply.

Attach UART header pins and trim three of the tails flush to avoid accidental contact later.
Do not progress with the build until you have confirmed the ProMini has a working bootloader by loading the blink sketch from the IDE.

OPTIONAL: Add a Thermistor, LDR & Indicator LED

One of my favorite sensor combinations for this logger is an NTC thermistor & CDS cell which adds nothing to the sleep current. Range switching with two or more NTCs could also be done if the max / min resistance values of one thermistor can’t maintain your resolution requirements. We explained how to read resistive sensors using digital pins in 2019; so here I will simply show the 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. Each [104] 0.1uF of capacitance you use in this circuit gives you about 3000 raw clock counts for the 10k reference resistor.

D6=10kΩ 1% metfilm reference resistor , D7=10k 3950 NTC, D8=300Ω (any type), D9=LDR (5528). Note that the LDR is optional, and could be replaced with any other type of resistive sensor up to ~65kΩ. A typical 10kNTC reaches that limit near -10°C and the LDR usually reaches that at night.
The code puts all lines that are not being read into input mode to isolate them from the circuit when reading each individual channel. With these sensors I usually jumper D2->SQW with a longer piece of flexible wire to avoid covering the D13 LED.
A 104 ceramic cap to GND completes the ICU timing circuit. With a 0.1uF as the charge reservoir, each resistor reading takes ~1-2msec in sleep mode IDLE. With this small capacitor, timing jitter produces a band of readings about 0.02°C wide on the output plots if temp. readings are repeated rapidly.

We created a how-to guide on calibrating thermistors which makes use of an online calculator to determine the equation coefficients. You should never expect the NTC you have in your hands to match the values provided by its manufacturer, but even if it did our method leverages the behavior of the ProMini itself as part of the measuring system. So there is no point buying expensive interchangeable thermistors – the cheapest penny-parts will do just fine. I add a thermistor to all my loggers (even if they will eventually drive I2C sensors) because a good way to test new loggers is to read the NTC at a short one-second interval until the EEprom has been completely filled a few times. After that burn-in you can be sure the core of the logger is reliable before adding other sensors.

[OPTIONAL] Common cathode RGB w red leg cut on A0=GND, A1=Green, A2=Blue. The colors are lit via internal pullups to keep below 50µA. Leaving the RED LED on D13 in place is useful to let you know when the bootloader has been triggered and that gets used by default if no other LED is enabled at the start of the logger code. The 1k D13 limit resistor must be left in place to use the onboard LED.

Join the Two Modules:

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.
Extend the VCC & GND headers with resistor legs.
Add a strip of double-sided foam tape across the chips on the RTC module and remove the protective backing.

Carefully thread the four I2C jumpers through the RTC modules pass-through port.
Press the two boards together onto the double sided tape and solder the four connections.
OPTIONAL: use the VCC & GND wire tails to add an SMD tantalum rail buffering capacitor and trim away any excess wire. Anything from 220 to 1000µF will reduce battery voltage droop as the coin cell ages. 10V 470uF caps provide a good overall balance between buffering ability and leakage currents in the 50nA range. After checking polarity, flip the SMD solder pads to the upper surface for easier soldering. Rail buffering caps can extend runtime by 20-30%, depending on the quality of your coin cell, but they are not necessary for short-term logger operation.
Trim away the (non-functional) 32kHz pin and tin to the SQW header pin. Solder a resistor leg (or a short length of 26AWG wire) to interrupt input D2 on the Pro Mini.
Add heat shrink to the D2 jumper & solder it to the SQW alarm header pin.
The minimum 2-module stack usually draws about 1µA constant sleep current, but with it’s TXCO corrections the RTC alone brings the average to at least 3µA. Cheap modules often have leftover flux which can cause current leaks. It’s worth the time scrub these boards with alcohol before assembly. I found no significant difference in sleep current between setting unused pins to INPUT_PULLUP or to OUTPUT_LOW.

The basic two-module combination usually sleeps around 1-2µA continuous. Most of that is the RTC’s timekeeping current as a 328p based ProMini only draws ~150nA in power-down (with regulator removed & BOD off) and the 4k eeprom should be less than 50nA in standby. If we assume four readings per hour at 5mA for 30msec, 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 the typical Ibat timekeeping current for the DS3231 is `700nA (dsheet pg7 with EN32KHZ=0 @3v) but TXCO temperature conversions bring the RTC average up to 3µA – which can’t be seen 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 the typical 328p brown-out at 2.77v. 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). For conservative lifespan estimation we can round that all up to about 5µA continuous, with four 5mA*10millisecond sensor readings per hour, and we still get an estimated lifespan of about two years. So the most significant limitation on this logger is usually the EEprom memory. It’s worth noting that newer DS3232 variants of the RTC lets you push the TXCO corrections out to 512 seconds. This lowers the average RTC standby to about 1µA -if- you are willing to spend $10 for the RTC chip alone on DigiKey.

Build video: ( 3 minute rapid review)

Note: the order of operations in the video is slightly different from the photos.

The Code: [posted on Github]

In 2023 the logger base code was updated to match the newer the e360 model, being essentially identical except for the changes required for the alternate NTC and LED connections. The code requires the LowPower.h library for AVR to put the logger to sleep between readings and this can be installed via the library manager.

One important difference between a coin cell powered logger and our older AA powered models 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 overwritten by an accidental restart.

Setup()

Purple callouts on the following flow diagrams indicate the places that would need to be altered to add a new sensor to the base code. If all you do is enable sensors via defines at the start of the program you won’t have to deal with the code that stores the data. However to add a new sensor you will need to make changes to the I2C transaction that transfers those sensor readings into the EEprom ( with matching changes to the sendData2Serial function that reads them back out later).

Note: The options on the startup menu will change over time as new code updates are released.

A UART connection is required at start-up so those menu-driven responses can occur through the serial monitor in the IDE. These have 8minute timeouts to avoid running the CPU too long during unintentional restarts. The menu sequence can be re-entered at any time simply by closing & re-opening the serial monitor window: This restarts the Pro Mini via a pulse sent from the UARTs DTR (data terminal ready) pin.

If you see random characters in the serial window, you have the baud rate set incorrectly. Reset the baud to 500,000 and the menu should display properly HOWEVER you also need to close & re-open the window. If you copy data from the serial monitor when the window still has garbled characters, then only the bad starting characters will copy out. On a new logger the Hardware, Calibration & Deployment fields will display rows of question marks until you enter some text via each menu option. There are additional debugging options that are not displayed unless serial out is enabled, and this menu will CHANGE over time as I add new features.

The first menu option asks if you want to download the contents of the logger memory to the serial monitor window. This can take up to 2 minutes with 256k EEproms at 500000 baud, which is the fastest rate an 8MHz ProMini can reliably sustain. Then copy/paste everything from the IDE window into an Excel sheet. Then below the data tab, select Text to Columns to separate the data fields at the embedded commas. Or you can paste into a text editor and save as a .csv file for import to other programs. While that process is clunky because the IDE’s serial interface doesn’t export, everyone already has the required cable and data retrieval is driven by the logger itself. And yes, the exchange could also be done with other serial terminal apps like PuTTY with logging turned on, CoolTerm, or Termite with the ‘logfile’ filter. You can also redirect Windows COM port output to a file, although it seems limited to only 19k baud. These options may be required on builds with large memory expansions as the IDE serial monitor starts to forget the initial data in it’s buffer after displaying about 100,000 lines. I have successfully used Termite at 1,000K baud downloading an 8mhz logger, but when the amount of data gets large the ProMini starts limiting you to an effective 500K baud. Functions like itoa() before serial.print() or using Rob Tillaart’s splitDigits4 & splitDigits10 with serial.write() speeds things up considerably. In summary, 250k BAUD is stable, 500k is usually fine with occasional serial dropouts in a very long download, while 1,000k Baud exhibits frequent flaky behaviors with the IDE’s serial monitor. Those character dropouts don’t happen using Coolterm or PuTTY.

Vref compensates for variations in the reference voltage inside the 328p processor. Adjusting the 1126400 (default) value up or down by 400 raises/lowers the reported voltage by 1 millivolt. Adjust this by checking the voltage supplied by your UART with a multimeter while running the logger with #define logCurrentBattery enabled and serial output ON. Note the difference between the millivolts you actually measured and the current voltage reported on screen, and then multiply that difference by 400 to get the adjustment you need to make to vref for accurate battery readings. After you [7] Change Vref and enter the adjusted number it will be used from that point onward. Stop adjusting when you get within ±20mv.

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

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

After setting the clock time and deployment parameters like the sampling interval, the logger will request the user to manually type a ‘start’ command before beginning a run. Only when that second ‘start’ confirmation is received are the EEproms erased by pre-loading every location with ‘Zeros’ which also serve as End-Of-File markers during download. The selected LED will then ‘flicker’ rapidly to indicate that the logger is ‘waiting’ until the current time aligns with the first sampling alarm before beginning the run.

Main LOOP()

EEprom writes usually draw about the same 3mA current the ProMini draws during CPU up time. ‘Lowest’ battery voltage is checked immediately after the data transfer because an unloaded Cr2032 will always read nominal – even when it’s nearly dead. Timing of events at that point is critical because EEproms freeze if the rail voltage fluctuates too much while they are actively writing – so don’t change those LowPower.idle sections of the code! Also don’t run OLED screens during sensor readings or EEsaves because they are noisy as heck. Logger shutdown gets triggered at the end of the main loop if the EEprom save brings the rail voltage below the 2850mv systemShutdownVoltage or if the memory is full.


Adding I2C Sensors to the logger:

The minimum configuration for this logger can log the 0.25°C temperature record from the DS3231, index-encoded to one byte per reading. Approximately 4000 of these readings can 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.

We made extensive use of RTC temperature records in our cave drip loggers at the beginning of the project. The accuracy spec is only ±3°C, but most were within ±1 of actual @ 25°C and you can calibrate them against more accurate sensors. The RTC only updates its temperature registers every 64 seconds and any temperature sensors inside the body tube will have about 15 minutes of thermal lag relative to outside air.

The 4K AT24c32 on the RTC module fills rapidly with sensors that generate 2 or 4 byte integers. An easy solution is to combine your sensor module with 32k (AT24c256), or 64k (AT24c512) chips so the sensors bring the extra storage space they will need. These EEprom modules can usually be found on eBay for ~$1 each and after you update the EEpromI2Caddr & EEbytesOfStorage defines at the start of the program, all AT series chips will work with the same code as the default 4k.

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 preferred for low power operation.
Pin alignment between the YL-90 and this BH1750 module is slightly more complicated as you can’t cover the light sensor.
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. Note: I2C pullups on the sensor boards can usually be left in place on this low voltage system.
I2C pin order on the RTC doesn’t align with the BH1750 module. So you need to make the required cross-overs with a 4 wire F-F Dupont. Soldering those connections is more robust but do that after calibrating the thermistor.

In addition to the NTC / LDR combination, support for both of the sensors shown above is included in the code on Github although you will need to install hp_BH1750 and BMP280_DEV with the library manager to use them. Sensors are enabled by uncommenting the relevant defines at the start of the program. No matter what combination of sensors you enable, the total bytes per record must be 1,2,4,8 or 16. Otherwise you will get a repeating error at download because trying to save data beyond a hardware page-boundary inside the EEprom over-writes previously saved data at the start of that same page/block.

I2C devices are usually rated to sink about 1mA which on a 3v system would require 3300 ohm pullups. This means you can leave the 10k’s on those sensor modules to bring combined bus pullup ( incl. 4k7 on the RTC & 35k pullup on the ProMini pins) to 2930 ohms, which is close to the 3.3k ideal. The open-drain implementation of I2C means that adding more capacitance to the bus will round off the rising edges of your clock and data lines, which might require you to run the bus more slowly with multiple sensors or with longer wires to your sensors. In those cases you can drop the total bus pullup to 2k2 to offset the capacitance.

The 662k LDO regulator on most eBay sensor modules increase the loggers sleep current by 6-8µA due to back leakage. For long deployments this can be removed & then bridging the in->out pads should bring your sleep back to ~1-2µA. That regulator is below spec any time your supply falls below ~3.4v which is > than the initial over-voltage on a Cr2032.

You must use low power sensors with a supply range from 3.6v to our 2.7v BOD cutoff. A good sensor to pair with this logger should sleep around 1µA and take readings below 1mA. You are more likely to find these no-reg sensor modules with low power operation at Sparkfun or on Tindie, than you are on eBay/Amazon. A coin cell simply doesn’t have enough power to supply a high drain CO2 sensor or GPS unless you take heroic measures. Sometimes you can pin-power sensors that lack low current sleep modes although if you do that be sure to check if that creates current leaks in other places such as pullup resistors or the I2C bus may go into an illegal state (idle is supposed to leave SCL & SDA lines high) requiring a power reset of all the sensors on the bus. Choose sensor libraries which allow non-blocking reads so you can sleep the ProMini while the sensor is gathering data and replace any delay() statements in those libraries with 15msec powerdown mode sleeps.

30ml self-standing Caplugs from Evergreen Labware are a good housing option because they have a brace in the cap that just fits four 22gauge silicone jacket wires. The ‘non-sterile’ versions with separate caps are much cheaper to buy than the sterile ones. 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 sensors. 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.

We’ve done pressure tests to 45psi and these tubes can be deployed to ~20m depth, although we don’t yet have any data yet on how long they will endure at that pressure. These housing tubes should be replaced every three months if they are exposed to sunlight because UV makes the plastic brittle. Adding a very small amount of silicone grease to only the upper edge of the tube before closing improves the seal with the lid but don’t add too much or the threads will slip. Holes drilled through the bottom stand enable zip-ties to secure the logger. In our cross calibration of a Bh1750 Lux sensor to measure PAR (Photosynthetically Active Radiation) , we wrapped the body tubes with 2″ aluminum foil tape to reduce heat gain inside the body tubes.

We have produced small printable rails for the 30ml tubes often used with this two module logger. So here is a link to that shared model on Tinkercad. That internal rail & an external mounting bracket is posted at Github. The easiest way to secure the logger to these rails is with a drop of hot glue from the underside but I usually twist and solder the legs of a scrap resistor as the tie as I have lots of these lying around:

Insert a scrap resistor into the mounting holes and twist the legs together.
Solder the twisted legs and trim. Angle the joint inwards to avoid scratching the tube.
Angle the I2C headers slightly toward the point of the tube to leave more room for Dupont connectors during the NTC calibration.
There’s room for two or three 0.5gram silica gel desiccant packs in the lid area. Because the ProMini remains exposed, I don’t usually add conformal to the ProMini until the logger has passed all of its pre-deployment run tests. After that I add a generous layer of conformal to everything but the battery contacts and the header pins. Clear nail polish also works for this.

For deeper aquatic deployments, you could use a stronger PET preform for the enclosure. These have very thick walls because they are the blanks that are thermally blow-molded to create soda bottles. You will need to find ones larger than the standard 2L bottle preforms which have an internal diameter of only 21mm. This is just a bit too tight for the RTC module. The 30ml centrifuge tubes shown above have an internal diameter of 26-27mm.


Testing Your New Logger

Make at least two machines at a time. I usually build in batches of six, and for every dozen at least one usually ends up with some kind of issue like an RTC temp. register outside the ±3°C spec, or a ProMini with one of those fake 328p processors that draws too much sleep current. Having more than one logger makes it easy to identify when you’ve got an 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 in less time. Seriously! The part cost on these things is well below $10, which is often less than you’d pay just to replace the battery on other loggers. This also applies to maintenance: just run till it fails and then replace it. In our experience, most inexpensive sensors have a reliable lifespan of less than two years in the field.

A good general approach to testing any DIY build is to check them with a doubling schedule: Start with rapid UART tethered tests via the serial monitor at second intervals, then initial stand-alone tests for 1,2,4 & 8 hours till you run overnight, followed by downloads after 1day, 2days, 4days, 8days, etc. For those initial burn-in tests, set the interval short enough that the entire memory gets filled. Valid sampling intervals must divide evenly into 60 and second-intervals can be set for rapid testing if you first enter 0 for the minutes.

Occasionally you get an RTC module with a really weak contact spring and this generally shows up as battery readings that jump all over the place, or even as unexpected quits from accidental bumps disconnecting power. A small bit of double sided foam mounting tape behind the spring will usually make the battery connection quite robust.

The shape of the battery burn-down curve during your pre-deployment testing is and excellent predictor of reliability! But to use that information you need to be running several identical machines at the same time, and start those runs with fresh batteries. I use the cheapest batteries I can get for these tests, knowing the better quality batteries I use on deployment will last much longer.

Remember that eBay/Ali/Amazon sensor modules are cheap for a reason and it’s not unusual to see 20% of them rejected for strange behavior or infant mortality. So huddle test each batch to normalize them. 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. Cheap BMEs sometimes refuse to operate with it’s individual RT/T/Pr sensors set at different oversampling levels, and at the highest resolution (16x oversampling) that sensor may draw more than your power budget can sustain over a long deployment. Real-world installation inevitably exposes the logger to condensing conditions. Sensors with a metal covers (like the BMP/E series) will experience internal condensation at the dew point. Moisture creep is the largest cause of data loss on the project after theft/vandalism. So cleaning leftover flux from all parts with cotton swabs + 90% isopropyl alcohol before & after assembly is always worth your time. So is conformal coating and you can use clear nail polish for that if silicone coatings are hard to find.

And all the other quid-pro-quos about vendors apply: Split your part orders over multiple suppliers with different quantities, ordered on different days, so you can isolate the source of a bad shipment and/or identify suppliers that are OK. Don’t be surprised if that batch of sensor boards you ordered transmogrifies into a random delivery of baby shoes. Amazon is often cheaper than eBay and AliExpress is 1/4 the price of both. Trusted suppliers increase part costs by an order of magnitude but that may still be worth it if you don’t have time for enough test runs to eliminate the duds.


Power Optimization on this Data Logger:

A (relatively high) average sleep current of ~5µA*86400 sec/day would use ~432 milliAmpseconds/day from a Cr2032 that can provide roughly 360,000 mAs of power [100mAh] on its main voltage plateau . Any power saving strategy must be weighed against this daily amount to determine if the complexity it adds to your code will deliver a proportional increase in operating time. I rarely see a sensor sample reading use more than 1 milliamp-second of power – even with relatively high drain sensors like the BME280. So most of the power used by this logger is due to the DS3231 RTC’s 3µA timekeeping current which can not be changed but battery voltage droop during peak current events is usually what triggers the low voltage shutdown and that is affected by code execution.

8MHz ProMini boards draw about 3.5mA when running at 3v. Slow functions like digitalWrite() and pinMode() are replaced with much faster port commands wherever power and/or timing are critical. Pin states, peripheral shutdowns (power_all_disable(); saves ~0.3mA) and short sleeps are used throughout for battery voltage recovery. Waking the 328p from those powerdown sleeps takes 16,000 clock cycles (~2milliseconds @8MHz +60µS if BOD_OFF) and but the ProMini only draws ~300µA while waiting for the oscillator to stabilize. These wakeups only use about 1mAs/day.

The original code released in 2022 used CLKPR to bring the ProMini down to 1MHz (lowering runtime current from 3.5mA to ~1.3 mA) however testing later revealed that the total energy cost per logging event actually increased slightly when the system clock was divided. In addition, I came across several EEproms that would freeze if I lowered the system clock to 1MHz during save. So I have removed the CLKPR calls to make the codebase more portable. I also found that the startup-time also gets multiplied by the CLKPR divider. This might be the only documentation of this on the web, so I’m leaving this information here – even though CLKPR is no longer relevant to the logger:

( 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 these oscilloscope screen shots = 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 328p was left CLKPR’d down to 1MHz when it entered powerdown sleep(s). Waking the processor now takes 16 milliseconds – wasting a significant amount of power through the 4k7 pullup on SQW while the RTC alarm is still asserted.

Using the 328s internal oscillator to save power is a non-starter because it’s 10% error borks your UART to the point it can’t upload code. Our ICU based timing method also needs the stability of the external oscillator.

That bridge between the coin cell and VCC means UART connection time probably is shortening battery lifespan a bit. 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 coin cell if you are spending an extended time on serial. But given our tight operational margin we can’t afford to lose 200mv 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.

EEprom & sensor additions usually push directly measured continuous sleep currents to 2µA (so ~5 µA average when you add the RTC temp conversions) 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 is far less important when you only have enough memory space for one year of sensor readings. Even a whopper 6.3v 1000µF tantalum only increases sleep current by ~1µA. That’s 1µA*24h*365days or about 10 mAh/year in trade for keeping the system well above the 2.8v cutoff. That means we don’t need to lower the BOD with fuse settings & custom bootloaders. 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.

Capacitor leakage scales linearly so use the Falstad simulator to see what size of rail buffer you actually need. Capacitors rated 10x higher than the applied voltage reduce leakage currents by a factor of 50. So your buffering caps should be rated to 30v if you can find them. The 220µF/25v 227E caps I tested only add ~15nA to the loggers sleep current and these can be obtained for <50¢ each. (& 440uF 10v caps leak around 25nA) High voltage ratings get you close to the leakage values you’d see with more expensive Polypropylene, Polystyrene or Teflon film caps and moves away from any de-rating issues. The one proviso is that as the buffering cap gets larger you will need to add more ‘recovery time’ in the code before the rail voltage is restored after each code execution block. Sleeping for 30msec after every I2C transaction is a safe starting point, but you’ll need a scope to really tune those sleeps for large sensor loads like you see with a BME280 at 16x oversampling. If moisture condenses inside the housing on deployment, and the logger mysteriously increases from 1-2 µA sleep current to something higher then replacing the tantalum rail buffering cap is one of my first diagnostic steps.

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 16-bytes into the 4K EEprom on the RTC module while the CPU takes ADC readings of the rail voltage. Note that our current code saves readings as a single event at the end of each pass through the main loop, but I forced multiple large saves for this test to show 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 minimal RTC-only sensor configuration reached a very brief battery current peak of ~2.7mA with no buffering cap, 1.5mA with 220µF and less than 1mA with 1000µF. The amount of voltage drop these currents create depend on the coin cells internal resistance but a typical unbuffered unit usually sees 15-30mV drops when the battery is new and this grows to ~200mV on old coin cells. The actual voltage 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 large 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 plateau near 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]

According to Nordic Semi: “A short pulse of peak current, say 7mA 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.” After many tests like those above, our optimal ‘peak shaving’ solution is to run the processor at 8MHz, breaking up the execution time with multiple 15-30 millisecond POWER_DOWN sleeps before the CR2032 voltage has time to fall very far. (especially necessary if you start doing a lot of long integer or float calculations) This has the benefit that successive sensor readings start from similar initial voltages but those extra sleeps can easily stretch the duration of a logging event out toward 300 milliseconds – putting limits on the loggers maximum sampling rate:

Current drawn in short bursts of 8MHz operation during sensor readings. The final EEprom save peaks at ~2.75mA draw (in this old example with CLKPR 1MHz CPU which we no longer do)
[CH2: H.scale: 25msec/div, V.scale 500µA/div converted via Current Ranger]
Voltage droop on that same ‘old’ CR2032 used above reached a maximum of 175mv with NO buffering capacitor across the rail. This battery has about 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]

EEprom save events are typically around 3.5 mA for 6ms. Without a rail buffer a new coincell will fall about 100mv. With a 200µF rail buffering cap supplying the initial demand the peak current drawn from the coin cell is less than 1.5mA – which limits the overall voltage droop to less than 50mv. Even with very old batteries a typical EEsave event doesn’t usually drop the rail more than 150mv with a rail buffer cap, however the recovery time grows significantly with battery age – from less than 25 msec when new to more than 150 milliseconds for a full recovery. So old battery logging events look more like ‘blocks’ on the oscilloscope trace rather than the series of short spikes shown above.

This ‘solder-free’ AT24c256 DIP-8 carrier module is bulky but it lets you easily set multiple I2C address. Here I’ve removed the redundant power led & pullup resistors. Heliosoph posted a way to combine multiple EEproms into a single linear address range

Even with fierce memory limitations we only use the 328’s internal 1k EEprom for startup index values and text strings 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 3mA draw. This exceeds the recommended 10mA max for a garden variety Cr2032. Multi-byte page writes aren’t possible so data saved into the 328p costs far more power than the same amount saved to an external EEprom. However it is worth noting that reading from the internal EEprom takes the same four clock ticks as an external with no power penalty, while PROGMEM takes three and RAM takes two clock cycles. So it doesn’t matter to your runtime power budget where you put constants or even large lookup tables.

A simple optimization we haven’t done with the code posted on GitHub is to buffer data into arrays first, and then send that accumulated data with larger wire library buffers. All AT-series EEproms can handle the 4k’s 32-byte page-write but the default wire library limits you to sending only 30 bytes per exchange because you lose two bytes for the register location. So to store sensor readings in 32-byte buffer arrays and transfer those you need to increase the wire library buffers to 34 bytes. This has to be done by manually editing the library files:

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

That twi buffer gets replicated in three places so the wire library would then require proportionally more variable memory at compile time . With larger EEproms you could raise those buffers to 66 bytes for 64 data-byte transfers. It’s also worth mentioning that there are alternate I2C libraries out there (like the one from DSS) that don’t suffer from the default wire library limitations. AT series EEproms always erase & rewrite an entire page block no matter how many bytes are sent, so increasing the number of bytes sent per save event reduces wear and can save significant amounts of power. In my tests, newer larger EEproms tend to use about the same power as smaller older EEproms for identical save events because even though they are re-writing larger blocks, they do these internal operations much faster. So a ‘typical’ EEprom write event uses somewhere between 0.30 to 0.5 millamp-seconds of power no matter how many bytes you are saving. If your daily sleep-current burn is about 300milliampseconds, then it takes a few hundred of those EEprom save events to use the same amount of power. Increasing the transfer payload (with temporary accumulation arrays) from the I2C default of 16 bytes to 64 bytes cuts EEsave power use by 75%. That can extend the loggers operating life with short sampling intervals of 1-5 minutes, or where your sensors generate many bytes per record. Despite several technical references saying otherwise, I saw no significant difference in save duration or power (on the oscilloscope) with EEprom locations prewritten to all zeros or 0xFF before the data save events. One thing that does make an enormous difference is transferring blocks that exactly match the EEproms hardware page size – if you get the alignment perfect then EEproms can write the new information without all the preload & insertion operations you see when saving smaller amounts of data. This cuts both the time and the power for EEprom saving by 50% if you have enough memory for all the pre-buffering that requires.

Because of the code complexity we have not implemented array buffering in the current code-build so that the codebase is understandable for beginners. Every pass through the main loop saves data to the external EEprom and these loggers still have an excellent operating lifespan without it. For many EEprom types, when doing a partial write of fewer bytes than the hardware page size, the data in the rest of the page is refreshed along with the new data being written. This will force the entire page to endure a write cycle, so each memory location in the EEprom may actually get re-written [EEprom hardware page size / Bytes per Save ] times, which for the 4k would typically be 32/4 = 8 times per run. EEproms have a ‘soft’ wear limit of about 1,000,000 write cycles, so even in that worst-case scenario the logger could fill that chip 125,000 times before wearing the EEprom out. But buffering can make the eeprom last longer, or extend operating life in ways other than the battery power that’s saved.

FRAM takes about 1/50th as much power to write data compared to standard EEproms but those expensive chips often sleep around 30µA so they aren’t a great option for low-power systems like this logger unless you pin-power the chips so you can disconnect them during sleep. FRAM can endure more than 10 billion, 50 nano-second, write cycles, making it better suited for applications where rapid burst-sampling is required. The I2C bus is not really fast enough take advantage of FRAMs performance, but with the SD card removed from the logger the four SPI bus connections are now available. Once your code is optimized, the majority of the loggers runtime power is consumed by the 328p burning 3.5mA while it waits around for the relatively slow I2C bus transactions – even with the bus running at 400khz.

Here wires extend connections for the thermistor & LED to locations on the surface of the housing.

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

An important topic for a later post is data compression. Squashing low-rez readings into only one byte (like we do in the base code with the RTC temperature & battery voltage) is easy; especially if you subtract a fixed offset from the data first. But doing that trick with high range 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 power for heavy calculations on a 328p so I’m still looking for an elegant solution.


Some Run Test Results

Since we covered adding BM & BH 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. In this test, Battery was logged each time 16-byte buffer-arrays were written to a 32k EEprom. Both loggers have a measured sleep current of ~1.5µA and they were downloaded periodically. Although the curve spikes up after each download, these are runs used the same coin cell battery throughout:

Cr2032 voltage after 11 months @30min sampling interval: BMP280 sensor reading Temp. & Pr. stored in 32k eeprom with NO 220µF rail buffering capacitor. This test run is complete. At x16 oversampling the BMP uses considerably more power than the BH1750.
Coin cell after more than 12 months @30min sampling interval: BH1750 sensor & 32k ‘red board’ EEprom (Sony brand battery: again, with no rail buffer cap). Both of these records show only the lowest battery reading in a given day.

I ran these tests without a rail buffering cap, to see the ‘worst case’ lifespan. A pulse loaded Cr2032 has an internal resistance of ~20-30Ω for about 100 mAh of its operational life, so our 3.5mA EEprom writing event should only drop the rail 100mv with no rail buffer cap. But once the cell IR approaches 40Ω we will see drops reaching 200mv for those events. The CR2032’s shown above have plateaued near their nominal 3.0v, so we will see the rail droop to ~2800mv when the batteries age past the plateau. Again, our tests show that with a 220 µF rail capacitor those drops would be reduced to less than 50mv and with 1000µF the battery droop is virtually eliminated.

Note that the UART 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 internal passivation layer, but that voltage restoration is short lived. On future tests I will enable both logCurrentBattery (after wake) and logLowestBattery (during EEwrite) to see if the delta between them matches the drops I see with a scope.

And here we compare our typical logging events to the current draw during a DS3231-SN RTC’s internal temperature conversion (with a 220µF/25v cap buffering the rail). The datasheet spec for the DS3231 temp conversion is 125-200ms at up to 600µA, but the units I tested draw half that at 3.3v. On all three of these images 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. This logger slept for 15msec battery recovery after every sensor reading or I2C exchange.
Every 64 seconds a DS3231 (-N or -SN) temperature conversion draws between 200 to 300µA for ~150ms. There is no way to change the timing of the RTC conversions.
Occasionally the RTC temp conversion starts in the middle of a logging event, adding that current the peaks.

The datasheet spec for the DS3232-SN temp conversion is 125-200ms at up to 600µA, but the units I tested draw half that at 3.3v. The rail cap can’t protect the coin cell from the SN’s long duration load so temp conversions overlapping the EEprom save may be the trigger for most low voltage shutdowns during deployment. 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 temperature conversion will start in the middle of an EEprom save event. These ‘collisions’ may be more frequent with the -M variants of the chip which do temperature conversions every 10 seconds when powered by Vbat, although they only take 10msec for the conversion instead of 150msec for the -SN. Seeing those conversions on an oscilloscope is one way to verify which kind of RTC you’ve got with so many -SN modules out there today being relabelled -M chips:

DS3231-M Temp. conversion: At 3v, this unit drew 230µA for 10milliseconds, but this occurs every 10 seconds. (1mV on scope = 1µA via Current Ranger)
DS3231-SN Temperature Conversion: At 3v, This chip drew 280µA for 130 milliseconds, every 64 seconds. (1mV=1µA via C.R.)

Given that the average timekeeping current is the same for both chips, we try to use ±2ppm SN’s for longer deployments instead of the ±5ppm M’s. In real world terms ±1ppm is equivalent to about 2.6 seconds of drift per month, and that’s what we see on most -SN RTCs. I’ve also seen occasional comments in the forums of some DS3231M oscillators stopping spontaneously during field deployment. Note that on several of the RTC modules the SQW alarms continue to be asserted even after you disable them in the control register (by setting the alarm interrupt enable A1IE and A2IE bits to zero) and this draws 6-700uA continuously through the pullup on the module. The only way to be absolutely sure the RTC alarm will not fire after a logger shut-down is to turn off the RTC’s main oscillator. We do this in the codes shutdown function, because you can just reset the time via the start menu before the next run. When you remove the coincell, DS3231 register contents are lost – usually becoming zeros when power is restored although the datasheet says they are ‘undefined’ at powerup. The RTC oscillator is initially off until the first I2C access.

If your code hangs during execution, the processor will draw 3.5mA continuously until the battery drains and the logger goes into a BOD restart loop with the D13 red led flashing quickly. The logger will stay in that BOD loop from 4-12 hours until the battery falls below 2.7v without recovering. This has happened many times in development with no damage to the logger or to any data in the EEprom.

Most of the units I’ve tested trigger their BOD just below 2.77 volts. And 10 to 20 millivolts before the BOD triggers the internal voltage ref goes a bit wonky, reporting higher voltages than actual if you are using the 1.1vref trick to read the rail. The spring contact in the RTC module can be weak. That can trigger random shutdowns from large voltage drops so I usually slide a piece of heat-shrink behind it to strengthen contact with the flat surface of the coin cell. The rail capacitor protects the unit from most impacts which might briefly disconnect the spring contact under the coin cell. However hard knocks are a such common problem during fieldwork that we use a drop of hot glue to lock the RTC coin-cell in place before deployment. Normal operation will see 40-50mv drops during EEprom saves up to with 200µF rail buffers. If those events look unusually large or rail voltage recovery starts stretching to 100’s of milliseconds on the scope you probably have poor battery contact. Even with good contact, long duration loads can deplete the rail buffering cap so a 200µF reaches the same v-drop as a ‘naked’ battery after ~8-10msec, and 1000µF after ~15-20msec. In all cases, your first suspect when you see weird behavior is that the coin cell needs to be replaced.

Another thing to watch out for is that with sleep currents in the 1-2µA range, it takes a minute to run down even the little 4.7µF cap on the ProMini boards. If you have a larger capacitor buffering the rail the logger can run for more than 10 minutes after the battery is removed.

More Cr2023 Battery Testing

16x accelerated battery tests averaged about 1250 hours run time before hitting the BOD.

Ran a series of Cr2032 battery tests with these little loggers and was pleasantly surprised to find that even with the default BOD limiting us to the upper plateau of those lithium cells; we can still expect about two years of run time from most name brand batteries with a 200-400uF rail cap. Also keep in mind that all the units in the battery test had BOD’s below 2.8v – about 1 in 50 of the ProMini’s will have a high BOD at the maximum 2.9v value in the datasheet. It’s worth doing a burn test with the crappy HuaDao batteries to spot these high cutoff units more quickly so you can exclude them from deployment. We increased the sleep current for the accelerated test by leaving the LEDs on during sleep, but 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.


Addendum: Build video (w EEprom Upgrade)

We finally released a 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

Addendum: (2023-12-01) The e360 EDU variant

Released the classroom version of this 2-module logger, with substantial code simplifications that make it easier to add new sensors and 2Module code build has been updated to match. This new variant has two breadboards supported on 3D printed rails so that sensor connections can quickly be changed from one lab activity to the next. The default code reads temperature via the RTC, and NTC thermistor, Light via an LDR and the Bh1750, and Pressure via a Bmp280. It also has support for a PIR sensor, and a mini-OLED display screen.

6pin Cp2102 UARTS are cheap, with good driver support, but you have to make your own crossover cable.

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


Last Word:

“If you need one, then you need two. And if you need two, you better have three.” The benefit of loggers this easy to produce is that you can dedicate one to each sensor, since the sensors often cost more than the rest of the unit combined. Then you can deploy duplicates to capture long time-series. This gives you redundancy in case of failure and makes it easier to spot when sensors start to drift. Deploying at least two loggers to every site also lets you use a trick from the old days when even the expensive commercial loggers didn’t have enough memory to capture an annual cycle: Set each logger to sample at twice the interval you actually want, and then stagger the readings (or set one of the logger clocks late by 1/2 of that interval). This way both loggers operate long enough to capture the entire dataset, and you can weave the readings from the two machines back together to get the higher sampling interval you originally wanted but did not have enough memory for. If one of the loggers fails you still get the complete season, but at the longer interval.

RH% gain (Y axis) over time (X axis) in submerged 30mL housings: The upper purple lines were controls with no desiccant added to the logger, the orange curve had 0.5 gram packet and the lowest blue curve had two 0.5 gram packets of small desiccant beads. So 1 to 1.5 grams are adequate for a typical one-year deployments with about 1 to 1.5% rise in RH% per month due to the vapour permeability of the centrifuge tubes. This test was done at typical room temps, but the rate increase bump near the end of the test was due to an 8°C rise – so the diffusion rate is temp dependant. BME280 sensors were used.

Dedicated loggers also provide the non-obvious benefit of reducing the potential for interference between sensors. Cross-talk is particularly common with water quality sensors because the water itself can form a circuit between them. It is nearly impossible to predict this kind of problem if all you did was benchtop calibration of the isolated sensors before your deployment. And even if your base code is robust, and you don’t have any weird ground-loops, it’s not unusual for sensor libraries to conflict with each other in a multi-sensor build.

Hopefully this new member of the Cave Pearl logger family goes some way toward explaining why we haven’t moved to a custom PCB: Using off-the-shelf modules that have global availability is critical to helping other researchers build on our work. And when you can build a logger in about 30 minutes, from the cheapest parts on eBay that still runs for a year on a coin cell – why bother? Bespoke PCBs are just another barrier to local fabrication, with potential for lengthy delays at customs to increase what may already be unpredictable shipping and import costs.

We’ve been having fun embedding these ‘ProMini-llennium Falcons’ into rain gauges and other equipment that predate 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. Much of that older equipment was retired simply because the manufacturer stopped updating the software/drivers. While IOT visualization apps are all the rage in hobbyist electronics, they may end up creating similar dependencies that open source projects aiming for longevity should avoid. Not to mention the fact that those wireless packet transfers require a power budget orders of magnitude larger than the rest of the logger, while relying on back-end infrastructure that doesn’t exist in the parts of the world where more environmental monitoring is desperately needed.


References & Links:

Setting Accurate Logger time with a GPS
How to calibrate the NTC thermistors on this logger
Heliosoph: Arduino powered by a capacitor
Nick Gammon: Power Saving techniques for microprocessors
AVR4013: picoPower Basics for AVR Microcontrollers
Jack Ganssle: Hardware & Firmware Issues Using Ultra-Low Power MCUs
An Arduino-Based Platform for Monitoring Harsh Environments
Oregon Embedded Battery Life Calculator & our Cr2032 battery tests
A summary of Port/PIN mappings for Atmel based Arduinos
Waterproofing your Electronics Project
Calibrating a BH1750 Lux Sensor to Measure PAR
How to Normalize a Set of Pressure Sensors
WormFood’s AVR Baud Rate Calculator
ATmega328P Datasheet

Pro Mini Classroom Datalogger [2020 No-Solder 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.

   
Cave Pearl data loggers

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.

Remove Limit Resistor to disable power indicator

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.

A4 & A5 I2C bus bridged to side rails

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

Reset terminals repurposed with jumpers under the board

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 D10Orange (MOSI) -> pm D11Purple (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 sensorThe 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.

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


A 2-Part ‘mini’ logger released in 2023

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 simpler ‘bare-bones’ version we’ve developed a 2 module classroom logger using 3D printed rails. Without the SD card this unit is memory constrained, and data download is handled via through the serial monitor window in the IDE. This model requires fairly detailed soldering so students get a complete practice lab soldering header pins onto perf-board before attempting the assembly. 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 change the sensors to develop their own projects.


DIY Data Logger Housing from PVC parts (2020 update)

Basic concept: two table leg caps held together with 3″ 1/4-20 bolts & 332 EPDM o-ring. Internal length is 2x3cm for the caps + about 5mm for each o-ring. SS bolts work fine dry, but we use nylon in salt water due to corrosion; tightening the bolts enough that the o-rings will expand to compensate for nylons 2-3% length expansion when hydrated. PVC is another good bolt material option if you deploy in harsh environments.

We’ve been building our underwater housings from 2″ Formufit Table Screw Caps since 2015. Those housings have proven robust on multi year deployments to 50m. While that’s a respectable record for DIY kit, we probably over-shot the mark for the kind of surface & shallow water environments that typical logger builders are aiming for.

The additional RTC & SD power control steps that we’ve added to the basic ‘logger stack’ since 2017 are now bringing typical sleep currents below 25μA.  So the extra batteries our original ‘long-tube’ design can accommodate are rarely needed. (described in Fig. A1 ‘Exploded view’ at the end of the Sensors paperIn fact, pressure sensors often expire before power runs out on even a single set of 2xAA lithium cells.

This raises the possibility of reducing the overall size of the housing, while addressing the problem that some were having drilling out the slip ring in that design. Any time I can reduce the amount of solvent welding is an improvement, as those chemicals are nasty:
(click to enlarge)

Basic components of the  smaller 2020 housing cost about $10. O-rings shown  are 332 3/16″width 2 3/8″ID x 2 3/4″OD EPDM (or other compound )

Double sided tape attaches a 2xAA battery pack to the logger stack from 2017 ( w MIC5205 reg. removed, unit runs on 2x Lithium AA batteries)

The o-ring backer tube does not need to be solvent welded. Cut ~5cm for 1-ring build, & 5.5cm for a 2-ring. Leaving ~1.5cm head-space for wires in the top cap.

The logger stack fits snugly into the 5.5cm backer tube with room for a 2 gram desiccant pack down the side.

The screw-terminal board is only 5.5cm long, but the 2x AA battery stack is just under 6cm long.  With shorter AAA cells you can use only one o-ring.

With several 4-pin Deans micro-plug breakouts & AA batteries things get a bit tight with one o-ring. So I add a second o-ring for more interior space.

Sand away any logos or casting sprues on the plugs & clamp the pass-through fitting to the upper cap for at least 4 hours to make sure the solvent weld is really solid. (I usually leave them overnight) Then wet-sand the large O-ring seat to about 800 grit.  Sensor connections are threaded 1/2″ NPT, but I use a slip fit for the indicator LED, which gets potted in clear Loctite E30-CL epoxy w silica desiccant beads as filler. Most clear epoxies will yellow over time with salt water exposure, so for optical sensors or display screens I usually add an acrylic disk at the upper surface.

The only real challenge in this build is solvent welding the pass through ports. In the 2017 build video we describe connectors with pigtails epoxied to the housing.  But you don’t necessarily need that level of hardening for shallow / surface deployments. The potted sensor connections shown in the video (& our connectors tutorial) can be threaded directly to the logger body via 1/2 threaded NTP male plugs. 

Note: Position the NPT risers on the caps directly opposite the bolt struts, and as near to the edges of the cap as you can so that there is enough separation distance to spin the lock down nuts on your sensor dongles. In the photos below I had the pass-through in line with the struts, but with long bolts this may limit your finger room when tightening the sensor cable swivel nuts. These direct-to-housing connections do make the unit somewhat more vulnerable to failures at the cone washer, or cuts in the PUR insulating jacket of the sensor dongle.

Threaded bulkhead pass-throughs get drilled out with a 1/2″ bit. Alignment with bolt struts shown here is suboptimal.

This closeup shows a slight gap near the center – I could have done a better job sanding the base of the NPT to make it completely flat before gluing & clamping!

the pass through style sensor cap mates to the the lower half of the housing. We’ve always used our o-rings “dry” on these pvc housings.

I describe the creation of the sensor dongles with pex swivel connectors in the 2017 build video series.

Dongle wires need to be at least 6cm long to pass completely through the cap.

“2-Cap” housing: Aim for 5 to 15% o-ring compression but stop if there is too much bending in the PVC struts.

It’s also worth noting that there are situations where it’s a good idea to have another connector to break the line between the sensor and the logger. (shown in 2017)  We often mount rain gauges on top of buildings with 10-20m of cable – so we aren’t going to haul the whole thing in just to service the logger. But on-hull connections like the ones shown with this new housing necessarily open the body cavity to moisture when you disconnect a sensor, and nothing makes a tropical rainstorm more likely to occur during fieldwork than disconnecting the loggers that were supposed to be measuring rainfall.

With a double o-ring and additional seal(s) in the cap, we probably won’t be deploying this new design past ~10m. Given how quickly they can be made, this short body will be a standard for the next few years; perhaps by then those fancy resin printers will be cheap enough for regular DIY builders to start using them – at least for shallow water work.  For now we’ll continue with the long body style for deeper deployments or remote locations that we might not get to again for a long time. The second o-ring is not really necessary if you make a nice tight stack when you assemble the logger.

In general I’d say these ‘plumbing part’ housings reach their long term deployment limit at about ~60m because the the flat end caps starts blowing noticeably at that depth. That overlaps nicely with the limit of standard sport diving, but if your research needs more depth it’s worth looking into the aluminum body tubes/endcaps becoming available in the ROV market. As an example:  Blue robotics makes some interesting enclosures if you need clear acrylic endcaps for camera based work.

(UPDATE: the double o-ring shown in the photo above was required when using 3.5″ bolts. That was a mistake as they tended to extrude easily.  Using shorter 3″ bolts lets you go with only a single o-ring which is gives you a solid seal with no accidental extrusions.)

Addendum 2023-05-25

We needed a way to see how far we could take the new falcon tube loggers and water filter housings are a good solution as the domestic water pressure range of 40-80psi overlaps nicely with sport diving depths. The internal clearance of the filter housing we used is slightly larger than 4.5″ x 9.5″ so could accommodate these older PVC style housings as well:
https://thecavepearlproject.org/2023/05/24/a-diy-pressure-chamber-to-test-housings/

A household water filters make a good low-range pressure chamber.

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

 

Cable: Blk(gnd), Red(vcc), White(sda), Yellow(scl), Blue(sqw).  Shroud retainer clips face up & there is no wire on 32K output.

First tape layer

Next two tape layers

OPTIONAL: adding header pins to the cascade port provides a convenient attachment point for I2C sensors later.

Optional: After removing the two SMD resistors on the module, you can clip the Vcc leg on the RTC chip which forces the clock to run entirely from the backup coin-cell battery. This reduces the loggers overall power use by 0.09mA bringing a “no-reg & noRTCvcc” build below 0.1mA when the logger sleeps between sensor readings (this should run for more than 2 years on fresh lithium AA cells) . But the risk is that if you bump the RTC backup battery loose, that disconnection resets the clock time to Jan 1st, 2000. (note: while the time stamps will be wrong after that kind of reset, the logger will continue running after the next hour/min alignment occurs with the ‘old’ alarm time)   A couple of pieces of soft 1.6mm heat shrink tubing under the spring makes the negative coin-cell connection stronger, an a touch of hot melt glue will secure the battery on the top edges.  A CR2032 can power the RTC about four years but you have to set bit six of the DS3231_CONTROL_REG to 1 to enable alarms when running from the coin-cell. (our starter code does this by default) This modification also disables the 32.768 kHz output pin on the RTC.  Visit our RTC page for more detailed information on this clock module.

Final Assembly:
(Note: references here are to pin numbers/labels on the ProMini which do not match ST board labels on the analog side)

Attach the Pro Mini stack & RTC to housing with the double-sided tape.

Trim white & yellow I2C wires from the RTC & add 1 extra wire with dupont ends for each I2C line to bring the bus over to the breadboard

Attach yellow SCL line from the RTC beside the red 3v rail (ie to A3=A5 on the ProMini) then the white SDA line from the RTC to A2=A4.

The four extra jumper wires with male Dupont ends on Vcc, GND, & both I2C lines. These get patched over to the breadboard so you can add I2C sensors.

Each wire must be plugged into its own separate vertical column on the breadboard. Add a 2nd layer of foam tape to the bottom of the bread-board before attaching.

The RTC power line joins that short red jumper on RAW(pm)=VIN(st) at the end of the screw-terminal board.

Some of the box bottoms have slight bowing. If any component doesn’t stick well enough: add another layer of foam tape.

Attach the RTC’s black ground wire to GND & the blue SQW alarm line to ProMini pin D2

Attach 2xAA battery holder with 2 layers of foam tape. Trim wires to length. Use black 30lb Mounting Tape for extra strength.

Battery wires join the black & red jumpers from other side of the terminal board. All six of the ‘unused’ screw terminals we clipped earlier can be used to make secure ‘dry wire’ connections in this way.

Connections complete except the indicator. 5050 LED modules often come with pre-installed limit resistors which make them safer for the classroom. But you can use a raw 5mm LED if you only light the LED  with the INPUT_PULLUP command.

A ‘common cathode’ RGB LED module on pins  Red=D6, Green=D5,   Blue=D4, &  GND=D3.

Your Logger is ready for testing!

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

Install the Arduino IDE into whatever default directory it wants to be in – we’ve had several issues where students tried to install the IDE into some other custom sub-directory, and then code will not verify without errors because it doesn’t know where to look for libraries. 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.

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 just be a random bunch of 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.

1. Test the LED – Edit the default blink sketch, adding commands in setup which set the digital pin 3 connected to the ground line of the LED to “OUTPUT” and “LOW”
      pinMode(3, OUTPUT);   digitalWrite(3, LOW); 
Since we removed the ‘default’ indicator led on the Pro Mini board, you will also need to change LED_BUILTIN variable in the blink code example to one of the pins connected to one of the color channels on your led module. (in this example change LED_BUILTIN to either 4, 5, or 6)

2. 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 should show up at address 0x68.

The address of the eeprom can be changed via solder pads on the board, so sometimes it moves around. 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 at least one set of wire connections switched around during the assembly. With the screw terminals this takes only a few moments to fix. Also have a spare RTC module on hand in case you get a defective module…which is fairly common.

NOTE: Some sensors really need the stability provided by the on-board voltage regulator. Here is an alternative arrangement of parts for the classroom logger that leaves the 3.3v regulator in place on the ProMini and powers the logger from 4xAAA alkaline batteries (NOTE: regulated builds also leave out the short red jumper that was used to recruit the orphan capacitor after the reg was clipped.  The RTC & added sensors now get connected ONLY to the Pro-Mini’s regulated 3.3v rail )   We’ve designed the Cave Pearl Logger for maximum flexibility, so you can easily change components and positions like this to suit the needs of your design / experiment.

3. 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 first you need to download & install this RTC control library  The SetTime script, automatically updates the RTC to the time the code was compiled (just before uploading) so you only run SetTime once, and then immediately upload the GetTime sketch to get the SetTime code out of memory after it’s done it’s job. Otherwise SetTime will reset the RTC to the ‘code compile time’  every time the Arduino restarts (and the Arduino restarts EVERY TIME you open the serial window…) 

There are dozens of other good Arduino libraries you could use to control the DS3231, and there is also a script over at TronixLabs.com that lets you set the clock without installing a library. [ in 24-hour time, & year with two digits eg: setDS3231time(30,42,21,4,26,11,14);  ] The trick with Tronix’s “manual” method is to change the parameters in the line: setDS3231time(second, minute, hour, dayOfWeek, dayOfMonth, month, year);  to about 2-3 minutes in the future, and then upload that code until about 20 seconds before your computers clock reaches that time (this compensates for delay caused by the compilers processing & upload time). Open the serial window immediately after the upload finishes, and when you see the time being displayed (and it’s not too far off actual…) upload the examples>blink sketch to remove the clock setting program from memory.

Another option would be to try setting the clock’s time using one of the serial window input utilities from Github.

4. Check the SD card is working with CardinfoChanging chipSelect = 4; in that code to chipSelect = 10;  Note that this logger requires the SD card to be formatted as fat16, so most 4GB or larger High Density cards will not work because they get formatted as fat32. Most loggers only generate 5 Kb of CSV format data per year when they are running, so you don’t need a big SD card. In fact older, smaller SD cards in the 256-512mb range often use less power if it’s a good name brand like Sandisk or Nokia.

Zip-Tie Mounting Bases are an easy way to add attachment points inside your logger to secure sensor cables, or desiccant packs. These adhesive cable tie mounts come in many varieties, and cost about 10¢ each at most hardware stores.

5. Optional: If you are running with no regulator & using analog sensors: 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 reference  inside the processor. That internal ref. can vary by ±10% from one chip to another, and CalVref gives you a constant which will make the rail=battery voltage reading more accurate. Load CalVref while the logger is running from USB power and then measure the voltage between GND and the positive rail with a good quality 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 serial monitor window entry line & hit enter. Write down the reference voltage & constant which is output to the serial monitor window. I usually write these ‘chip-specific’ numbers inside the logger with a black sharpie. You will need to add that info to the core data logger code later by changing the line #define InternalReferenceConstant 1126400L to match the long number returned from CalVref. Alternatively you could just tweak the value of the constant ‘by hand’, increasing or decreasing the value till the reported rail readings match what you see with a voltmeter. After you’ve done this once or twice you can usually get within 15mv of actual with about 10 trials.

This calibration brings the starter script’s battery readings within ±15mv of actual but you can skip the CalVref procedure if you are only using digital sensors, as the script will still produce reasonably good battery readings with the default 1126400L value. Increasing the rail reading accuracy is more important when you are using ANALOG sensors which use that rail voltage to drive your sensors – so the +ive rail directly affects their output if you are not reading a ratiometric circuit.

6. 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 useful for teaching exercises and testing sensors after you set chipSelect = 10;  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 latest logging “Starter Script” has grown in complexity to ~750 lines, but it should still be understandable once you have a few basic Arduino programming concepts under your belt.

After 1-2 minutes of kneading to mix the epoxy you have ~ 60 seconds to work the putty into place. (it will become rock-hard within ~5-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. 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)

In the previous tutorial we attached external sensors with a cable gland passing through the housing and epoxying them into a pvc cap.  Cheap cable glands are notoriously unreliable and I always add a second rubber oring on the inside – and often over-seal the outside with  conformal coating. But for a simpler classroom project you could simply drill small a hole through the lid and stick the sensor/module on top of the housing, seal the hole with double-sided tape. Thicker pass-through wires can be sealed reasonably well with plumbers epoxy putty from the hardware store. This putty is non-conductive, and adheres quite well to both metal & plastic surfaces. 

Remember that breadboard connections are very easy to bump loose, so once you have your prototype circuits  working, its usually best to re-connect the sensors directly to the screw terminals before deploying a logger where it could get knocked about. In a pinch you can secure breadboard pins with a ‘tiny’ drop of hot glue to keep them from wiggling around.

There is no power switch on the loggers, which are turned on or off via the battery insertion. Use a screwdriver, or some other tool, when removing the batteries so that you don’t accidentally cause a series of disconnect-reconnect voltage spikes which might hurt the SD card.

Using the logger for experiments:

Logger mounted on a south-facing window and held in place with double sided tape. Here the top surface of the housing was covered with two layers of white label-maker tape to act as a light diffuser. PTFE is another excellent light diffusing material available in different sheet thicknesses.  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 in a pinch. PTFE introduces fewer absorbance artifacts than other diy diffusers like ping-pong balls, 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 daylight. LED’s don’t saturate that badly, but you still lose all the useful detail in your data at peak brightnesses > 80,000 lux unless you add a diffusion layer to attenuate the light.

Many types of sensors can be added to this logger and the RTC has a built-in temperature register which automatically gets saved with our starter script. The transparent enclosure makes it easy to do light-based experiments. Diodes, LED’s & solar panels are basically the same device. So grounding the indicator LED through a digital pin allows it to be used as both a status light, and as a light sensor.   The human eye is maximally sensitive to green light so readings made with that LED channel approximate a persons impression of overall light levels.  Photosynthesis depends on blue and red light, so measurements using LED’s that detect those two colors can be combined for readings that compare well to the photosynthetically active radiation measurements made with “professional grade” sensors. In fact Forest Mimms (the man who discovered the light sensing capability of LEDs in the first place) has shown the readings from red LED’s can be used as a reasonable proxy for total PAR.  Photoperiod measurements have important implications for plant productivity, as do  measurements of transmittance through the plant canopy. Chlorophyll fluorescence is another potential application, and the response of plants to UV is fascinating.

The original code for using LEDs as sensors is from the Arduino playground. This polarity reversal technique does not require the op-amps that people typically use to amplify the light sensing response but it does rely on the very tiny parasitic capacitance inside the LED. (~50-300pF) This means that the technique works better when the LED is connected directly to the logger input pins rather that through the protoboard (because breadboards add random capacitance) . Another thing to watch out for is moisture condensation inside your logger housing: this provides an alternate discharge path for the reverse-charge on the LED, which effectively shorts out the light level reading.

We have integrated this into the starter script which you can download from 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 this light exposure graph with a generic 5mm RGB LED, with a 4k7Ω limiter on the common ground which was connected to pin D3:

Red, Green & Blue channel readings over the course of one day from the indicator LED in the 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 more quickly than Blue & Green at sunrise & sunset.  LED’s work well with natural full-spectrum light, but their limited frequency sensing bands can give you trouble with the spectral distribution of  indoor light sources. The peak spectral response of LED’s is usually around 30–50nm lower than their peak emission wavelength So the blue channel is actually recording in the near-UV range, the Green channel is responding at ~ 420nm (blue) and the red channel is actually responding to a wide band of yellow-green light. 

Characterizing light absorption and re-emission is also a primary technique in climate science . For example, measuring light intensity just after sunset with LEDs inside a heat-shrink tube pointed straight up can provide a measure of suspended particles in the stratosphere. An “ultra bright” LED has more than enough sensitivity to make these columnated readings, in fact on bright sunny days you usually have to place the LED/sensor beneath a fair thickness of white diffusing material (like PTFE tape) to prevent it from being completely saturated.  Older LEDs that emit less light can sometimes be easier to work with because they are less sensitive, so the discharge time does not go to zero in high-light situations. Other sensor experiments are possible with LED’s in the IR spectrum which can be used to detect total atmospheric water vapor. A light transmission-based variant of the NDVI ratio can be used to determine plant health after adding an IR LED to the logger.

Of course, full sun exposure can also cook your little logger: temps above 80°C may cause batteries to leak or damage the SD card. If you have to leave the logger in full sun, add a bit of reflective film or a layer of aluminum foil around the outside to protect the electronics. Though if use a light sensor you’ll need to leave a little un-covered window for it to take a reading. 

You might also find it handy to add a few holes to the Plano box as tie-down points:

and it’s always a good idea to add desiccant packs inside the box to prevent condensation. If you use a desiccant with color indicator beads, you can check whether they are still good simply by looking through the transparent housing.

If you clipped the RTC leg, your logger should pull less than 0.1mA while sleeping. Back of the envelope for Lithium AA’s is about 7 million milliamp-seconds of power, with your logger burning about 8600 mAs/day at 0.1mA.  So clipping the voltage regulator and cutting the vcc leg on the RTC should easily get you out to about a year before you fall off the “upper plateau” of the lithium burn-down curve, and more likely to ~two years if your sensors don’t use much power (…and you have a well behaved SD card).  With the RTC power leg still attached you’ll see sleep currents in the 0.18-0.22 mA range, so at least 6 months of operation before you come close to triggering the low voltage shutdown (which is embedded in the logger code). I’m being conservative here because it all depends on your sensors and other additions you make to the base configuration. For every type of sensor the market, there will be some brands that draw much less power than others, and it’s always worth a look at the data sheet to make sure you are buying one that will run longer on a given set of batteries. Good sensors automatically go into a low current sleep mode whenever the bus has been inactive for a period of time.

While the LED sensor idea is fun to work with, it’s a very slow method that keeps the logger running for many seconds per reading when light levels are low -> so reading all three color channels will probably cut your operating life in half again. Figuring out how to only take those light readings during the day is a good coding exercise for students that saves quite a bit of power. The RTC’s temperature record is pretty crude, so we’ve also added support for the DS18b20 temperature sensor in the base code. If you have a genuine DS18b20 (yes, crummy fake knock-off sensors are a thing) , these venerable old temperature sensors draw virtually no power between readings.


TransparentSinglePixl
Bill of Materials: $20.50
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 3.3v version because you can’t direct-connect the SD cards to a 5v board.
$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 small 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 so that you can remove three of them.
$0.50
Sandisk or Nokia Micro SD card 256mb-512mb 
 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.
$2.00
Small White 170 Tie-Points Prototype Breadboard
These mini breadboards for inside the logger are also available in other colors.
$0.60
Dupont 2.54mm F2F 40wire ribbon cable Without Housing
Cheaper if you get the ones with the black plastic shrouds on the ends. 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. Poorer quality crimped ends can add significant contact resistance. Each 40-wire cable will let you make at least 2 loggers, and you”l need a couple of  6-pin connector shrouds.
$1.55
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.
$0.50
5050 LED module (with built-in limit resistors) 
(Alternatively, you can also use cheaper 5mm diffused LEDs with a  4K7 limit resistor on the GND line – that you solder into place on the LED yourself)  
$0.75
3.3V 5V FT232 Module
  *set the UART module to 3.3v before using it!* and 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. Get at least 2-3 of these as they do wear out and you can kill them with a short circuit. These boards can only supply about 50mA which can be tricky with sensors that draw more than that.
$2.75
3M Dside Mounting Tape, 22awg silicone wireheader pins, etc… $1.00
You might need some extra tools 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 also available for ~$15.
$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 they only have one power rail on the side since they do not look like regular breadboards &  I write ‘for soldering only’ on them with a black sharpie to make sure I don’t get the heat-damaged boards mixed up with the good ones.
$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.  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
Syba SY-ACC65018 Precision Screwdriver Set
A good precision screwdriver set makes it so much easier to work with the screw terminal boards.
$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…so more cool stuff like this can happen!
$1.00

When a finished module with 20 sub-components arrives at your doorstep for less than you’d pay for any one of those components individually, then the tradeoff is that you are the quality control.

.. and the required lithium AA batteries are also somewhat expensive, so a realistic estimate is about $25 for each logger before you add sensors & tools.

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-20% of any cheap eBay modules will be DOA due to some quality control problem. I build loggers in batches of six, and one unit typically ends up with a bad part somewhere. Having replacement parts on hand is your #1 way to diagnose and fix these issues. I’ve noted over the years that 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 coming from the same flakey production run. 

The other thin I can’t stress enough is CLEAN ALL THE PARTS as soon as they arrive. Leftover flux is very hygroscopic, and pretty much guarantees that solder joints will start to corrode the moment your logger gets exposed to any atmospheric moisture. So 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. Store parts in a sealed container with a dessicant pack till you need them.  I clean parts that can’t take the sonic vibration (like RTC modules, humidity sensors, accelerometers, etc) by hand with cotton swabs. Then I coat everything I can 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 have moisture issues is that the sensors seem to run fine in the house but start to act weird 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 much more power than the data sheet for that sensor indicates, then it’s probably a junk part. If the sleep current is on spec, then your part is probably going to work OK. It is much easier to check low current devices with at Ucurrent or a Current Ranger.  Keep in mind that sensors which automatically go into low current sleep modes usually take some time to do so after the bus has gone quiet – so you might need to watch the sleep current for 30 seconds or more before they fall down into their quiescent state. With SD cards, if the throughput drops below the typical write speed for that model with H2testw, then you should just find another card to use with your logger.

I strongly recommend that you build at least two loggers at a time, because that lets you isolate whether problems you run into during testing are code related (which will always affect both machines the same way) or hardware related. (which will usually 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 it to make sure you’ve made it past any ‘infant mortality’, and moved onto the good part of the bathtub curve.


Addendum: Diagnosing Connection Problems

If you loaded the blink sketch to test the Prominin during your initial assembly, you know that part of the logger is working, so issues during the testing stage are due to incomplete connections from the outside to the Promini I/O ports. Before you start your troubleshooting it’s worth remembering that after you’ve built a few of these units you can simply rebuild the whole logger in about a hour. So it really doesn’t make sense to spend much more time than that – especially when a few five-minute part swaps are likely to fix the problem. The  components are only worth a couple of bucks each, and your time is more valuable than that!

This is the connection pattern inside the white breadboard. Take care that you don’t connect the breadboard jumper wires together by accidentally plugging them in to the same row or – the I2C bus will stop working. NEVER CONNECT the GND & 3.3v wires or the short circuit will likely kill your logger, and possibly even the computer they are connected to . . .

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. The most common cause of this problem is that the white & yellow wires were 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 ‘clean’ before being put under the  terminals. Those screws need to be clamped down relatively tight on the thin Dupont wires and if you are not careful, you might have accidentally cut away some of the thin copper wires inside the Dupont cable when you stripped the insulation.

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 have 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 this: 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) beside A4 on the Promini must connect through through the yellow Dupont wire to the SCL header pin on the RTC .

For ‘single-wire’ connections under the screw terminal with those thin dupont wires, strip enough insulation that you can ‘fold-back’ some extra wire to give the terminal more wire to bite onto.

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’ folded over plastic insulation. With a pair of tweezers, you can ‘gently’ lift the little plastic tab on the black shroud 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.

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

A note about I2C sensors: The I²C bus is slow, so topology (star, daisy-chain, etc.) doesn’t matter much, but capacitance does. Length and number of devices 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 minimise 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 10k 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) 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.

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 pins is by-passing a bad connection.  This is also how you would break out A6 & A7 connections if you need them.

Sometimes those screw terminal boards have a 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.

 

Also note: The 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 working code due until Java was updated on those machines; but this problem is rare. More likely some permission limitation meant that you’ve ended up installing the IDE in a directory other than the default, and now it can’t find its libraries.


Addendum 2020-02-02:  Refining the build

The ‘solderless’ classroom build includes a breadboard for flexibility, but if you are building a logger for a single sensor application you can leave out the breadboard, and add some under board jumpers to avoid those finicky multi-wire bundles:

Using the tined leg of a resistor to add some under-board connections to give you more 3.3v & GND attachment points. Clean any residual solder flux thoroughly!

To repurpose those  screw terminals, leave the corresponding pins un-soldered so they can be  removed.

 

Here, we are repurposing the TX, RX, & RST terminals as GND connections. DO not repurpose TX & RX if you need serial comms with NEMA sensors like GPS.

Use a Black marker to label the repurposed GND points. NOTE: The GND-labeled terminals can not be repurposed because they are bridged via the back plane of the screw terminal board itself.

Label the connections with red. NOTE: ONLY join the Vraw & Vcc like this if you have removed the regulator. If you are keeping the reg. in your build then Vraw must remain separate, & you can only repurpose the reset pin for one extra 3.3v rail.

In a no-regulator build, you now have three (+)ive rail connections. This is handy if you accidentally strip one of the terminals by over-tightening.

Adding header pins to the RTC module’s cascade port provides a more convenient attachment point for I2C sensors, and removing the breadboard leaves room for a desiccant pack:

Example of a typical “dedicated sensor” build  without the breadboard, and with the under-board jumpers to provide extra (+)ive & GND terminals. This photo also shows a mosfet controlling the SD ground line, and a thermistor is tucked under the Promini board – but it’s probably better to tackle those additions when you have a few successful logger builds under your belt.

‘Single shroud’ 40-wire 20cm FF Dupont cables are ~$1 each – 1/3 the cost of the ones without housings.

We deliberately put students through the creation of custom sized Dupont connectors because it’s a useful thing to know about, however single shroud wires also work on the RTC and SD module because you are using the double sided tape to hold everything in place. I also tend to use RAW diffused LEDs as indicators, and simply light the individual channels with INPUT_PULLUP mode which uses the internal pullup resistor to limit current. However a single mistaken OUTPUT-HIGH can kill your Arduino if your not careful with that approach. I also leave one of my battery leads long enough that I can tap in to that line & measure sleep currents later on with a Current Ranger.

MCP1702-3302E/TO dead-bug hanging off a Deans style T-plug connector.

The unit pictured above has had its regulator removed so it can run more efficiently on 2x AA lithium batteries. But if you later find out that your sensors need strict voltage regulation, you can always replace the battery holder with a 4xAA, and add a regulator in-line on a battery connector. In the photo (right) two ceramic 105’s stabilize the MCP1700, while a 10/3.3M ohm divider provides a third output line so the ADC can monitor the raw battery status. This is the simplest way to retro-fit a regulator onto a unit that was built without one.

You occasionally get a plano box where the plastic ridges of the housing don’t mate well with the red rubber o-ring. In those cases it’s relatively easy to pull the o-ring out of its groove in the lid, and add some gasket compound to the recessed trough before carefully putting the o-ring back in. The additional height then compensates for casting error in the housings, though don’t add to much or you won’t be able to close the lid. One positive aspect of the relatively loose fit on that lid is that it lets you run prototype tests quickly if you jumper to your sensor module with thin 28-30 gauge wires:

This is a BMP280 pressure sensing module. Wires must extend beyond the edge

~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

The sharp inner edge of the lid would cut the wires insulation if the tape was not there to protect

The tape has to be replaced every time.

This gives you a chance to do overnight run tests before you commit to modifying the housing with holes, putty, or pass-throughs with cable glands. And for indoor sensor deployments this might be all you actually need to do, though I would still coat the exposed solder joints on that dangling breakout module with either conformal coating or clear nail polish to prevent oxidation.


Addendum 2020-07-29:  Better 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 it provided an alternate discharge path for the reverse bias charge:

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


Addendum 2020-05-11:  Using a more advanced processor

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 still delivers comparable sleep current / longevity.