This project is for a set of automated water samplers, which use peristaltic pumps to slowly draw in water samples over the course of the day and/or night. This current design is the third iteration for this project, and the first one to use a programmable microprocessor as opposed to off-the-shelf components.

My Goal- To control 2 separate pumps (1 for day time and 1 for night time) for multiple days of underwater deployment.

Equipment :

Rocket Scream Mini Ultra 8MHz board- I love this little board. For my first attempt at using a microprocessor to control this project I used an Arduino Uno with a relay motor shield, which worked fine on the bench but used way too much power for our deployment needs (see below for a power draw comparison). The power regulator on this board can only take a range of 3.3-6v (as opposed to the 3.3-12v range on the SparkFun Pro Mini), but the regulator itself is more efficient than the other boards I've tested.

MOSFET- As stated above, I started off using relays to turn my pumps on and off. But the relays themselves are incredibly power hungry, so I needed to swap them out for a more efficient control method. I briefly toyed around with using a latching relay, which only requires a momentary use of power to change the state of the relay  (as opposed to a traditional relay which requires constant power to change states). But I scrapped the idea of using latching relays as I was concerned that in the event of a power loss to the board, the pumps might remain on indefinitely. So I ended up using a MOSFET, which has the benefit of a traditional relay (only energizes the pumps when the board is powered) but has a much lower power draw. I decided to use the SparkFun MOSFET power control kit, which is a small kit that has all the little pieces I need plus a small PCB board,  but in the future I will probably just build the MOSFET parts without the actual kit.

RTC- Using a DS3231 RTC.

Peristaltic Pumps- I've been very happy with the Welco WP10-P1 pumps I chose for this project. I've used them for the previous version of these samplers, and they have proven to be very dependable. I purchased some of the cheaper pumps out there on the market and was extremely disappointed.  At $100 a pump they are pricey, but well worth the money.

Lithium Battery- Since I'm using DC motors in this circuit, I need to keep the motor power supply separated from the board power supply. The Rocket Scream VIN only has a range from 3.3v-6v, so I'm using two SAFT 3.6v AA batteries wired up in parallel to power my board.

Pump Battery Supply- I need to get at least 12 days of deployment time from each water sampler, so I need a sizeable battery pack to run the pumps. Most similar oceanographic instrumentation is powered by commercially available pre-made alkaline battery packs. These packs work great, but are extremely expensive. The packs themselves are basically a large bundle of D cell batteries wired up in series/ parallel, and then shrink wrapped to make a compact battery pack. I plan to make my own battery packs for this project, and will discuss the making of these packs in a separate blog post.

Below is the breadboard diagram of the wiring for this project. Please note the added text describing the actual components used (may differ from the icon used in diagram).

Pin Layout:

RTC GND -> Common GND
RTC VCC -> 3.3v
RTC SDA -> Pin A4
RTC SCL -> Pin A5

**Note Pins A4 and A5 can be used as I/0 pins, but also have the special function as I2C protocol pins. Since the RTC runs using 12C, we must use pins A4 and A5 for the SDA (Data Signal)  and SCL (Clock Signal).

MOSFET Kit 3 Screw Terminal
+ -> 6v Batt
- -> Common GND
C-> Pin 3 (Pin 5 for Pump 2)

MOSFET Kit 2 Screw Terminal
+ -> Positive Pump Terminal
- -> Negative Pump Terminal

The code for this project is not nearly as straight forward as I had hoped it would be. It's pretty simple to set up a timer to turn things off and on at certain times of the day, but I ran into several issues when the pump control crossed over the midnight hour.  The logic I was using was "greater then or less than time X", which got funky with the changeover from one day to the next.

So the result is a clunky, far from elegant, hunk of code that also just happens to work well. So while I'm not proud of it, I'll post it here because it works. But I'd be happy to hear from anyone who has a better approach.

Power Comparison:

My original design involved an Arduino Uno with a relay motor shield. The amp draw for the UNO was 56mA when not driving a pump, and 98mA when driving a single pump. Even when putting the unit to sleep the unit still used 48mA.

Between using a much more efficient board (Rocket Scream) and switching to MOSFET technology I've brought my power consumption waaaaaaay down. My current draw is 6.30 mA for driving a single pump (at 230 speed). When not driving a pump the board draws 5.99mA, and when sleeping  the board draws 2.16mA. The power draw is dramatically less with the new configuration and the samplers should last well over the planned deployment period.

How long will the board last you ask?  How about a  little back of the envelope math to ballpark how long my board should last in the current configuration.

The life of a battery can (roughly) be calculated with the following formula:

           Battery Life (in hours)= Battery Capacity  (in mA Hours) / Load Current (in mA) * 0.7

Side Note- The 0.7 is a fudge factor to take into account various environmental factors as well as the power consumption rate, both of which can affect battery life.


The Saft AA battery has a listed capacity of 2450 mA. So at my maximum amp draw of 6.3 mA I have:

            2450 mAh / 6.3mA * 0.7 = 272.22 hours/ or approx  11 days of deployment time

But as I have set up my sampling schedule, I'm only running the pumps for 12 hours out of each day. The rest of the time the board is using much less power. How much less power you ask? Let's dive in a little deeper into the back of the envelope.

The sleep cycle is controlled by a watch dog timer on the RTC, which puts the board to sleep on 8 second cycles. So the board sleeps for 7 seconds, wakes up for 1 second to make sure it doesn't need to be doing anything, and then falls back asleep for another 7 seconds. So while the board is sleeping 1/8 of each cycle is using 5.99 mA, and 7/8 of each cycle  is using 2.16 mA.

If we start thinking about a day as a single cycle lasting 86400 seconds, our board is awake for 43200 seconds per cycle and sleeping for 43200 seconds per cycle.

Of that sleep cycle 1/8th of the time (5400 seconds per cycle) the board draws 5.99 mA. And 7/8ths of the time (37800 seconds per cycle) the board is drawing 2.16mA.

So if we want an average current draw over the course of a deployment, we need to add all the above factors together like so:

      Driving Pump= 6.3 mA * 43200/ 86400 = 3.15 mA

      Watchdog Cycle= 5.99mA * 5400/ 86400= 0.374 mA

       Sleep Cycle = 2.16mA * 37800/ 86400 = 0.945 mA

       3.15 mA + 0.374mA + 0.945 mA = 4.469 mA

And finally to calculate our final battery draw:

      2450 mAh / 4.469mA * 0.7 = 383.75 hrs or ~ 15 days of deployment time.

And since I'm going to be extra cautious, I'll be doubling my battery power by placing 2 SAFT batters in parallel which will double my deployment time giving me a large enough buffer where I shouldn't have to worry about the current draw of my board (......famous last words).

Future Goals- It strikes me as a bit wasteful (in terms of space and $$) to have two different pumps running (one for daytime samples and one for night time samples). Further down the road I'm hoping to design a similar system capable of taking up to 24 discrete samples. Thinking of a project like this it quickly becomes untenable to use 1 pump per sample. So I'd like to design a new system that only uses 1 pump to take samples, with downstream sample control to shunt water into the proper collection bags.

I can envision a set up that uses only 1 pump to draw water in, which passes the water into a solenoid controlled gang valve system. But like relays, solenoids are power hungry and I'll have to find another way to control water downstream of the pump.

My current project is for a PAR (Photosynthetically Active Radiation) Logger. PAR is a specific spectrum of sunlight (400-700 nanometers) and is an important measurement for marine biology and ecology. The sensor I use as part of my research is a Li-Cor Li-193 Spherical Underwater Quantum Sensor. I've been happy with the sensor, but the Li-Cor logger is not the best fit for my research needs.

My goal is to design a logger for this sensor that meets the following requirements:

Compact- I want the logger to fit into a small underwater housing to reduce buoyancy and  for ease of deployment

Low battery draw- Lower amp draw equals less batteries used per deployment

Real Time Clock- Need a RTC for Time Stamps, and potentially for controlling sampling protocols and instrument sleeping

Data Logging- the whole point of a logger! I'm a fan of a simple csv file on a removable SD card

LED- visible through housing to insure logger is running

A time stamped data logger is a staple for any monitoring project, so I'm happy to start off my blog with this one. So here is what I have so far-


Equipment List:

Board- The brain of the logger, I'm going with an Arduino Pro Mini. After being burned by the more common Arduino Uno and it's heavy amp draw, I've switched to using these smaller boards for all of my battery powered projects. Not all Arduino's are equal, and not all Pro Mini's are equal. I've noticed a lack of quality with some of the cheaper boards I've picked up, so I've been using the original SparkFun Pro Mini. But my absolute favorite board so far is the power stingy Rocket Scream Mini Ultra, mainly for the fact that this board has an awesome power regulator and draws incredibly low amps. But also because the A4 and A5 pins (used with the RTC) run along the edge of the board, as opposed to inset on the SparkFun board.

SD Card- I'm using the SparkFun SD breakout board. It's a straight forward SD card board, and I've been happy with the results so far.

RTC- I'm using a DS3231 RTC. This is the RTC I've been using for a while now, so I'm comfortable with it. I'm not a huge fan of this particular model, but I've got a code library for it and it's been pretty reliable for me so I'll stick with it for now.

Universal Transconductance Amplifier (UTA)- I need a signal amplifier to increase the sensor signal for use with the 3.3v logic on my board. Li-Cor makes an amplifier that will work for my needs, but  I came across this great article on a similar PAR logging system which is where I found out about the UTA made by EME systems. I decided to go with EME systems as its a great product and the owner was very helpful in explaining to me exactly how to set up my UTA.

A picture is worth a thousand words, so here is a breadboad mockup of what my logger ended up looking like:

Pin Layout:

SD CD -> Pin 5
SD DO -> Pin 12
SD GND -> Common GND
SD SCK -> Pin 13
SD VCC -> 3.3v
SD DI -> Pin 11
SD CS -> Pin 10

RTC GND -> Common GND
RTC VCC -> 3.3v
RTC SDA -> Pin A4
RTC SCL -> Pin A5

UTA Red -> 6v Batt
UTA Green -> Pin A2
UTA Black -> Common GND

UTA Black/ Blue -> Yellow Dot Pin on PAR sensor
UTA Brown/ Green -> Opposite Pin on PAR sensor

LED + -> Pin 3
LED - -> Common GND (through 1K resistor)

The above drawing lays out the all the equipment used and how it is connected. I'm going to hold off fitting all the above components into a waterproof housing until I've had a chance to bench test this set up vs. a certified sensor. But as of now I've got the above components soldered together on a PCB prototype board and so far the logger gives me values within the expected norm.

Arduino Code:
The code I wrote for this is pretty simple for now. For other projects I've done I usually put my boards to sleep when not in use. And this makes even more sense with this project as no one is concerned with PAR values during the middle of the night (spoiler....... it's just a lot of zeros).  But for now the code runs 24 hours a day.

Even over a time frame measured in seconds, PAR  can vary greatly depending on environmental conditions (cloud cover, turbidity, ect), so I've chosen to use an averaging routine to log the data. Ultimately I'll  choose to log the data once per minute, with each logged data point representing the mean of 60 measurements (60 seconds per minute). But the included code logs data every 10 seconds as I didn't want to wait that long when troubleshooting my code.

Above: The housing sled for mounting all of the electronics

Below: The logger in a water proof housing ready for deployment

Future Goals:

The above code is pretty basic, and as I mentioned I'd like to add a sleeping function to it. I'd also like to add the option of using a LCD screen to display real time PAR data. The LCD would not be used when logging data due to power constraints, but would be helpful to use in hand held lab situations.

Yahoo! My first entry-

After spending many hours (sometimes satisfying hours, sometimes frustrating hours) teaching myself electronics and building my first few projects, I've got a small project library building up. And I find myself with a fair amount of information I'd like to remember about each project, but with a brain that loves to forget all the little important bits.

So my hope for this blog is to use it as a diary to keep track of my progress, as well as a place to document whatever notes, diagrams, and code I write for each project. Most everything I've learned about electronics has come from online reading, so in addition to keeping this space as a reference for myself I'd hope other people can come through and pick up useful bits of information.