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.
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.
Pro Mini Prep:
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:
|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.
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.
(Note: references here are to pin numbers/labels on the ProMini which do not match ST board labels on the analog side)
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:
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.
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 Cardinfo – Changing 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.
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.
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:
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:
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.
|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.
|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.
|‘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.
|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!
|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.
|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.
|Small White 170 Tie-Points Prototype Breadboard
These mini breadboards for inside the logger are also available in other colors.
|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.
|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.
|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)
|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.
|3M Dside Mounting Tape, 22awg silicone wire, header 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.
|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.
|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.
|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.
|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.
|Syba SY-ACC65018 Precision Screwdriver Set
A good precision screwdriver set makes it so much easier to work with the screw terminal boards.
|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!
.. 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.
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!
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.
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 .
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.
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:
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:
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.
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 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:
After examining the O-ring I decided to add a little silicone to the channel holding the red o-ring to improve the seal:
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.
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.
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.
“…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.
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.
Hi, your blog an the explanations are great and really helpful!
Though I’m facing a “problem”. I followed your instructions above and removed the two smd resistors and clippt the vcc leg of the rtc. As I understood you, I’m now powering the RTC Module just by the coin cell. But without connecting the vcc pin of the Module to to 5v, I can’t read/write i2c and the rtc Module has a power consumtion of about 1.4 mA (at 5V) and 0.6 mA in deep sleep modus of the controller.
Did I miss something? Or did I do something wrong?
Thank’s a lot, Markus
If the RTC module alone is drawing 1.6mA – and you’ve disconnected the charging circuit & the red power LED via that smd resistor removal – then my first guess is that you have a defective RTC module. The RTC chip is only supposed to draw about 0.9 mA when powered via the Vcc pin, and the eeprom on that module is barely even measureable when it’s not being directly accessed. So my guess is that there is an accidental solder bridge somewhere under one of the chips bleeding current/voltage. I’ve seen this under the eeproms occasionally but usually this happens under one of the two 4x pullup resistor bridges.
Try a different module with the two SMD resistors removed, but leave the vcc leg in place. If you can access the module ok like that (setting the time, etc) measure the module current which should be about 0.9mA.
After you’ve confirmed the DS3231 is communicating OK over I2C with the coin cell inserted & vcc leg still in place – THEN clip the vcc leg and test it again. You should find that the modules overall current goes down to almost zero since the backup battery is now powering the RTC.