Go Down

Topic: A really inexpensive data logger with only three components. (Read 15805 times) previous topic - next topic

nickgammon

Please, the labelling of the six pins in the SD card adapter am using is quite different, there is no MOSI, MISO and SPCLK, just a bunch of things I dont understand. I need help
Please start a new thread. This is nothing to do with showing off your project. Also state what adapter you have and what labels you see (photo).
Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics

EKMallon

#16
May 07, 2015, 05:32 pm Last Edit: May 07, 2015, 05:42 pm by EKMallon Reason: formatting
Apologies for the confusing labeling, (and the late reply)

Without knowing any better, I used the same numbering as the examples shown at http://www.sdcard.org/downloads/pls/simplified_specs/part1_410.pdf

The SD card adapter I am currently using is a "microSD card adapter for Raspberry Pi" from Adafruit. But there are many other options available, and I provided links to several of them at the bottom of the post with the schematic at:

http://edwardmallon.wordpress.com/2014/10/07/the-diy-data-logger-v2-with-low-power-shut-down-capability/

I have found that some boards conduct heat to the pads holding spring pins much faster than others, which means if you linger while soldering, and hear a "snap" then you probably need to start over with a new board. Also, I have sometimes have very fine solder hairs bridging the contacts, which prevents the sd card from working. So I inspect the springs, and the jumper wires on the back of raspberry pi card adapter very carefully before connecting to the Arduino. It's also really easy to get the connections switched around, so I always use different colored wires for each SPI line

Attached is the back side of the Adafruit adapter, next to my schematic. With the numbering I used:

1 = Chip Select
2 = Data in = MOSI
3 = GND
4 = VDD  (supply voltage, not over 3.3v)
5 = SCLK
6 = GND
7 = Data out = MISO

8&9 are not used, but are pulled up to VDD with a resistor from 20-50K ohm because I found that some  SD cards drew much more sleep current if those pins were left floating.

EKMallon

And apologies to the thread in general if the housing photos were out of place.  In my head, the weather proof housing is a necessary part of building a datalogger.  I was just happy to finally have one that could be made with so few fabrication steps.  

Also the space limitations of the 2" pipe design lead me to put the components in a dramatically different physical configuration than the builds I posted about in 2014, and this taught me some lessons that are not in the schematic.  For example, flipping the RTC board over makes it much easier to change the backup battery after the unit has been running for a while.

EKMallon

I finally found the time to produce a full set of tutorials to help people interested in trying to build these logger units.

A DIY Arduino data logger:
Build Instructions - Part 1 (component preparation)

Build Instructions - Part 2 (platform assembly)

Build Instructions - Part 3 (Mounting sensors on the housing)

Build Instructions - Part 4 (power optimization)

That last part is optional, but worth tackling once you have built a few as it can easily extend your operating life to a year or more on 3 AA batteries.

EKMallon

Just thought I'd post the latest build update for these three (+1) component loggers:
https://edwardmallon.wordpress.com/2017/06/19/arduino-data-logger-2017-build-update/



the basic build sleeps below 0.25mA and can be assembled in under one hour.

I've also included a list of step wise modifications which will let you bring the sleep current as low as 0.02mA.

EKMallon

After years of underwater deployment, I am thrilled to announce that the Cave Pearl Project has finally published:

Cave Pearl Data Logger: A Flexible Arduino-Based Logging Platform for Long-Term Monitoring in Harsh Environments,     Sensors 2018, 18(2), 530; doi:10.3390/s18020530

http://www.mdpi.com/1424-8220/18/2/530    

I am sure a few people will grumble that we've been using everything from Genuine UNO's to cheap eBay clones, but that was one of our design goals from the beginning: To make a working logger using a "lowest common denominator" approach that was agnostic about whatever parts you could get your hands on. 




However, our project builds upon the hard work of many members of the Arduino community (especially the contributors & moderators of this forum) so we chose an open access journal, so the paper is free for everyone to download and, hopefully, build upon for their own projects.

Thank you everyone!


 

zoomx


EKMallon

A visiting researcher dropped by our humble basement workshop with questions about the physical skill level students would need if they added one of our DIY data loggers to their environmental curriculum. I figured the easiest way to cover that was to simply build one, while they recorded the process.
The result of that 3 hour session is now available on YouTube

https://www.youtube.com/playlist?list=PL79ZjHgoYtfzvDKPADJH7HPYDFFlxSLXt

EKMallon

While the logger core is generic, the surface deployments tend to use the 4" housing (which is easy to build) while the underwater deployments (~ half of the current fleet)  use the 2" body style. Usually those deployments are too deep to record with our little point & shoot camera, but we recently did an install in a coastal outflow that was shallow enough to capture a clip of the method we use to anchor the sensors into place. In this video we are placing the anchor in the fresh water, with extension rods to move the actual sensor into the zone where the saline water in intruding into the system.

https://youtu.be/yrrKCdw234k

EKMallon

This is a follow-up to mypost about using Nokia 5110 screens on three unused analog lines with shift-out​.

Adding the Nokia 5110 LCD to your Arduino Data Logger

 That saved me from messing with the hardware SPI bus which we reserve for the SD cards on our loggers.  A secondary benefit is that the code is really lean, on the order of about 250 bytes for the default font after the compile if you already have EEprom.h in the build anyway.  The font, however takes up about 500 bytes, and I wanted the smallest possible footprint so that we could add live data output to loggers that are already compile near the memory limits. 

As it turns out, stuffing those fonts (and some calibration data) into the internal EEprom was pretty easy to do:

Using the Arduino's Internal EEprom to Store Calibration Data & LCD Screen Fonts

Go Up