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

Dupont jumper variant of the 2019 Classroom Pro Mini Data Logger from the Cave Pearl project: This version uses solderless dupont jumpers to reduce assembly time to about 1 hour

It’s only been a couple of weeks since the 2019 classroom logger was released, and we’re already getting feedback from instructors saying the extra soldering that we added to that build creates a resource bottleneck that might prevent some of them 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 the new design was to give students their first opportunity to practice skills that are vital for field research. 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 version that combines the Dupont jumpers we used in 2016, with this more flexible flat-box layout. In the following video, I assemble one of these ‘minimum builds’ in approximately one hour.  To put that in perspective, the soldered version takes 2 – 2.5 hours.

Note: After you’ve seen the video to get a sense of where you are headed, its usually much better to use the photos (below) when building your logger. Videos make it look easier than it actually is when you are just starting out. 

This variation of the 3-component logger is optimized for quick assembly so the soldering has been reduced to just pin headers and bridging the I2C bus.  An instructor could easily do that ahead of time with about 15 minutes of prep per unit, leaving the solder-less steps for their students. Wire connections are made simply by twisting stripped ends together and clamping them under screw terminals.

This time reduction involves a few trade-offs, and the bringing the I2C bus to A2&A3 leaves only two analog ports readily accessible ( although A6 & A7 are still available). Removing the regulator & battery voltage divider adds ~30% more operating lifespan, but it also forces you to deal with a changing rail voltage as the Lithium AA batteries age. That daily variation is quite small, but for quantitative comparisons on monthly scales you may need to correct for the change in Vcc (included in the data file automatically) over time.  Another proviso is that you have to add a few more components to the part list from the soldered build:

This pushes the cost for a complete unit close to $20 (before adding sensors) and the required lithium AA batteries are also more expensive.

Pro Mini Prep:

First, test your pro mini board with the blink sketch

Remove two SMD resistors with iron

Remove the voltage regulator with snips. few regs tolerate output voltage with no input.

Add pin headers

Bridge I2c bus connections with a resistor leg. Connect A4->A2, A5->A3. 

The command: DIDR0 = 0x0F; in Setup disables  digital I/O on A0-A3 so they don’t interfere with the I2C coms.

Screw-Terminal Component Stack:

Add 3 layers to extend past the pins. On DeekRobot boards the two ground terminals are connected.

Gently rock the Pro Mini back & forth until the pins are fully inserted.

IMPORTANT! Align RX&TX corner. The GND points on the ST board may be interconnected & should match ProMini’s GND pins.

Remove unused pin headers to make room …

…for the SD adapter

Remove bottom 3 resistors – leave the top one in place!

Separate Dupont Cable wires & click into housing

Color Pattern: Black GND, Purple MISO, Brown SCl, Orange MOSI, Grey CS, and Red Vcc

Attach SD module to the Screw Terminal board

Measure, cut & strip the SD modules 4 SPI bus wires

Attach Grey D10, Orange D11, Purple D12, Brown D13

Add three jumper wires to the SD modules power line, one with male end pin

Add 3 wires to the power line & heat-shrink for strain relief

Short Jumper recruits the orphan capacitor at Vin

Longer red jumper bridges power to other side of the board

Add two extra wires to the black GND bundle, one with male Dupont end pin.

The completed Pro Mini, ST board & SD module stack. Those Red & Blk jumpers should be a bit longer…

Note: You could connect the battery holder lead wires directly into the multi-wire Vcc & GND bundles: skipping the 2 jumpers to the other side of the ST shield.  But those jumpers provide extra Vcc/GND points & the ability to change the battery holder later if you have a battery leak.

RTC module:

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

The DS3231 modules often have flux residue – remove this with 90% isopropyl

 

Cable shroud retainer clips facing up & no wire on the RTC’s 32K output.

First tape layer

Tape stage 2

Write the date on the coincell with a black marker

Final Assembly:

Attach stack & RTC to housing.

Trim wht & yellow I2C wires  & add extra jumper 2 each

Attach yellow beside Vcc connection, then white

The extra jumpers on Vcc, GND, & both I2C lines…

…get patched over to the breadboard so you can add sensors

RTC power line joins the short red jumper on Vin

Some the box bottoms have slight bowing. If something doesn’t stick, add another layer of tape.

GND & blue RTC alarm line to D2

Tape 2xAA battery holder down. Trim wires to length. Use 30lb Mounting Tape for the battery holders.

Battery wires join the black and red jumpers from other side of the terminal board. All 6 ‘unused’ screw terminals can be used make very secure ‘dry’ wire connections like this.

Connections now complete except for the indicator LED

5050 RGB LED on pins D3=GND, D4-Bl, D5-Gr, D6-Red

Since this build is a variation of the soldered version, so you can test your new unit using the procedures at the end of that post. Also see that tutorial for a description of how we attach external sensors with a cable gland passing through the housing. Of course, for an indoor classroom project you could simply drill small a hole through the lid and stick the sensor/module on top of the housing with double sided tape. Remember that breadboard connections are very easy to bump loose, so once you have your prototype circuit working, re-connect the components directly to the screw terminals before real-world deployments.

Using the logger for experiments:

Logger mounted on a south-facing window and held in place with double sided tape. The top surface of the housing is covered with two layers of white label-maker tape to act as a diffuser.

Many types of sensors can be added to this logger and the RTC has a temperature register which automatically gets saved with the starter script. The transparent enclosure also makes it easy to do light-based experiments. Grounding the LED through pin D3 allows it to be used as both a status indicator, and as a very capable 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 those two color channels 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) has shown the readings from red LED’s alone are a good proxy for total PAR.  Photoperiod measurements also have important implications for plant productivity.

The code for using LEDS 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 stray capacitance) . We have integrated this into the starter script which you can download from GITHUBThat method was used to generate this light exposure graph with a typical 5mm RGB LED, with a 4k7Ω limiter on the common ground connected to pin D3:

Red, Green & Blue channel readings 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 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. The blue channel is somewhat less sensitive than the red & green, but that actually gives you more useful information.  LED’s work well with natural light, but their sharp frequency sensing bands can give you trouble with the odd spectral distribution of some indoor light sources. You may be able to use a floating point mapping function like fscale to linearize your data – depending on the range of output from your particular LED.

Characterizing light absorption and re-emission is one of the primary climate science techniques. 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 collumnated readings, and on bright sunny days you usually have to place the LED-sensor beneath a good thickness of white diffusing material to prevent it from being over-saturated.  Older LEDs that emit less light can sometimes be easier to work with because they are less sensitive, so the readings do 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. Chlorophyll fluorescence is another interesting application, and the response of plants to UV is fascinating.

One thing to watch out for is that full sun exposure can cook your logger, so consider adding a bit of reflective film to protect the electronics. Add a couple of desiccant pouches to control condensation.  You might need to add a few holes to the housing as tie-down points:

4 thoughts on “Easy 1-hour Pro Mini Classroom Datalogger [Build Update: Feb 2019]

  1. Brian Davis

    I’m consistently impressed that you keep coming up with new and even easier ways of doing this while I struggle at times to keep my own more modest efforts moving along. Thank You for doing a lot of “heavy lifting” for the rest of us!

    I wondered if there might be times in a classroom build you could leave the on-boasrd LED on. Since it is under SW control, couldn’t you just turn it off while not in use? Could you also use it as a light detector? Would there be any particular problems with this approach? I admit I’ve not thought about it much before as I’ve just been disabling it on all my builds, but now I’m curious, especially if it could function as a poor man’s integrated light sensor. Putting a cover over it and removing it, exposing it to light, could serve as a ‘switch’ of sorts in SW for example. For high-altitude balloon projects, you often power them up but then have a “remove before flight” piece of tape that either connects the batteries or in some other way triggers the payload that “the flight is now beginning”… and something like this would work great for that.

    For power-saving, I still haven’t gone unregulated… but I am thinking about the RTC power modification (now that it’s easier… even I can probably *cut* a SMD connection 🙂 ). The more I look at power budgets (I know I should replace the cheap regulator with a better one, that too), the more I’m thinking of (for MY deployments, not for teachers) an EEPROM replacement for the SD card. As an I2C device I could swap out EEPROM chips in the field about as easily as I swap SD cards, the only real issue being having a dedicated set-up back at the computer to interface with the EEPROM via an Arduino and dump the data through the serial terminal to the laptop.

    One caution I found with these “flat” AA battery holders – you sort of want beefy ones. My first deployment used two 2XAA battery holders like these, and after a 5 month deployment in-cave the plastic at the two ends had been stressed enough that it had deformed out; a mild jolt was all it took to knock the batteries right out of the holder (the unit that had been in the surface subjected to thermal swings was in even worse shape). In-class this isn’t likely to be a big problem, but in the field or over time it is.

    The thing I really love about this build? If your battery case wears out, just pull it out and replace it – with this build, that’s a quick and easy job.

    Reply
    1. edmallon Post author

      I love the idea of using the D13 LED as another sensor! And these are usually yellow, so it could add another detection color to the RGB set. My only reservation would be that I don’t know how it might affect the SD controller, since pin 13 is also one of the SPI bus lines. That’s why I removed it in the first place – in case it was causing some kind of odd voltage mis-match on that one line compared to the others. If you go with an all eeprom build then there would be no reason not to use that LED as either a sensor, or as a light activated switch. This could be especially useful if you had sensors that only deliver useful data during the day: First check the LED to measure the overall light level and then only take the other sensor reading if it’s day-time.

      I also been wondering about a build using 256-Kbyte AT24CM02 EEproms. Although they have been the source of at least half of my problems on the project, the convenience of simply replacing SD cards, desiccants & batteries for on-site turn around has kept me plugging away with them. They also let me use simple code for concatenation/saving and I’m worried that if we went with structs, compression, etc to squeeze the data into the limited space of an eeprom, we’d make the code base too complicated for students/beginners. Using the serial terminal would be the easiest way to do a data dump, but that also assumes you have a laptop on site… which is not always practical in a cave, or a tropical rain storm, etc. I have been thinking about cobbling together an optical modem “downloader” like Onset uses, as this could also save us from removing the underwater units. But then again in the real world, we have to take them out to clean the biogrowth off the units anyway.

      You are quite right about the cheap battery holders, and when I can get an old lot of them on eBay, I much prefer the beefy plastic, or even metal holders from Keystone. There’s no way you’d shake a battery loose from them, but they also cost $3-5 each, and are probably overkill for classroom level loggers. And of course the number one problem with alkalines is that they leak all over the battery holder – so the easy replacement is probably better than spending more money. You can wedge a square of sponge/foam rubber between the batteries and the housing to hold the batteries in better when the lid is closed.

      Reply
      1. Brian Davis

        “…a light activated switch…”

        I was also thinking of this in terms of cave loggers. If there’s light, there’s somebody around, and the logger could go in to a “awake and listening” mode. For running the display only when people are there? Or for turning on a LoRa or low power BT system to look for a host to communicate with? The nice thing is in a completely dark environment, the only way this should trigger is if people are there.

        “…the convenience of simply replacing cards, desiccants & batteries for on-site turn around has kept me plugging away with [SD cards]”

        Agreed, they are extremely easy to collect swap and use, with the downside of being a little touchy and a bit of a power draw. What I’m thinking is a four contact female header that a EEPROM I2C breakout can simply plug in to – instead of swapping cards in the field, you swap entire EEPROM breakouts. Since they’re I2C they’re pretty easy to address and add (your code already tries to autodetect they size that is available).

        I agree this is not something for the casual teaching environment – using pure EEPROM is either going to be less efficient (because of page breaks) or significantly more complex (encoding and page breaks), although data compression and encoding is something that might be handy to teach in more advanced classes (or for advanced students) anyway. One of the things is the availability of authentic small SD cards (between you and I we may have driven up the market price of the Muve music cards, as they seem fairly reliable), while EEPROM breakouts are common… and fairly cheap (per unit, not per Mb… but when was the last time you filled a 2 Gb SD card with a datalogger?).

        An optical window downloader seems an obvious step (I used an Onset logger with this ability for my thesis work back in the 1990’s, and loved it). I’m actually looking at LoRa or low-power BT (especially the second, as it’s so common with the IOT that there are commonly available apps that will let me use my smartphone to get the data). Obviously underwater is not the place for BT or LoRa… but I wonder if you held the device right up next to the datalogger antenna, and slowed the rate down, if you could use that approach.

        Reply
        1. edmallon Post author

          I like the idea of a “removable” eeprom module…that gets me thinking…

          Now that we have power shutdown on the SD cards working reliably, the EEproms probably would use more power – mostly due to the fact that they are pretty slow and this sandbags the system. Back when I started doing eeprom buffering before data saves, I was surprised by how little power benefit I got from their use. Because of this I’ll probably go with Fram if I switch over to an SDcard-less build, on the fastest spi connection I can get.

          Also I tend to use Nokia 256 & 512mb cards now (when I can find them). They don’t sleep much better than the MUVE cards, but they consistently have peak currents in the 50mA range, while the MUVES usually go up to 100mA ish, and no-name cards often hit 130-150mA during write cycles. And especially with the 2xAA lithium units, I’d like to keep currents down during those random housekeeping load events…

          I think the real motivation for the SD cards was the number of times we were burned by commercial equipment suppliers for expensive download cables/adapters/software. Every time a laptop was lost in the field the most expensive part of the replacement was for proprietary software licenses. Just don’t want to setup another situation like that for others with our project.

          Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s