Public Lab Research note

  • 1

Riffle campout

by cfastie |

The Riffle had a campout all by itself in the back yard last night. Here are some details about this healthy outdoor activity.

  • Location: Middle of the lawn under the stars
  • Time: About 11 PM to 9 AM (sleepyhead campers)
  • Sensors: Three I2C MCP9808 temperature sensor modules
  • Sketch: riffle_MCP9808_logging3c.ino
  • Logging interval: Every 10 seconds because I forgot to change it to something more reasonable
  • Logged data: 3600 timestamps, 187KB file
  • Power: Three eneloop AAA with a Pololu boost regulator
  • Enclosure: Nalgene bottle for the Riffle and batteries, sensors were exposed but under cover

The ports through the bottle lid are not potted to make them waterproof, so this was just a trial run with the enclosure. A case for four AAA batteries fits into the bottle. The bottle was on its side on a wicker tray with a plastic snow sled propped several inches above everything in case of rain or dew.

The logged data include the cooling off curve after I brought the thing out of my hot office into the cool back yard. I started the logging in the office because I don't know how to start the Riffle logging without a computer. The warm up in the morning is slow as the hazy sunshine made its way onto the lawn and finally onto the black plastic sled above the enclosure.

Temperature traces for three I2C temperature sensors and the sensor in the real time clock (RTC). The RTC on the Riffle was in the Nalgene bottle and the other sensors were exposed (but under cover).

After the temperature dropped to its lowest point around 3:30 AM, the three traces for the MCP9808 sensors became very noisy. These fluctuations about every 10 to 20 minutes of about 1 to 4 degrees C look suspicious to me. That is, I don't think the air temperature varies like that at 4:00 AM. So this could be noise introduced by the switching regulator in the battery pack I used. Don warned me about that. I will have to repeat this logging with the lithium battery to see if the data behave differently. The higher frequency signal present before 3:00 AM might also be electronic noise. On the other hand, warm woodland creatures could have been dancing around the Riffle in the wee hours.

The three external sensors did not track each other perfectly, but they were separated by a few inches and some were closer to damp grass than others.

The sketch logs these two parameters. I don't know what they are or what they mean. The switching regulator was adjusted to deliver 5.2 volts from the battery pack. The same time period is covered in this and the previous graph.

I have some extra hardware for making cable ports and extra JST connectors for making battery packs. I put them both at the KAPtery. The male JST connectors I have don't fit perfectly into the female connector on the Riffle (lax standards) so I had to whittle away some plastic on the male part to allow it to fit.

Here is the sketch that was running overnight. I had to change the extension from ino to txt to circumvent the rock solid security here at riffle_MCP9808_logging3c.txt

Post your attempt to replicate this activity  Browse other activities for "riffle"

Replications (0)

None yet. Be the first to post one!

This is marked this as an activity for others to try.
Try it now   Click here to add some more details.

arduino temperature sensors water-quality riffle noise micro-sd

response:13128 category:test-limits activity:riffle


Cool! One question: I thought I read in the riffle documentation that you could only log in multiples of 8 seconds. That seemed liked a weird multiple to choose. You said you were logging at 10 seconds. So did I read something wrong?

Don thinks that eight seconds might be the minimum interval during which the system can be put into deep sleep. So all the sleep stuff happens in multiples of eight seconds. But it must take some time to do some housekeeping (writing data, turning out the lights, getting under the covers), so the timestamps on the data writes from this overnight deployment were mostly close to 10 seconds apart.

When you want to log data every 10 minutes, I guess the housekeeping chores will only happen once every ten minutes, so dividing 10 minutes by eight seconds will get you the proper multiplier. We will see.

I think 8 seconds is the "maximum" interval with a 16MHz crystal. You wake up every 8 seconds and can go back to sleep if there is no work to be done.

George that's a good point. Although the real time clock is running all the time, it is not smart enough to do something as complicated as setting an alarm and waking something else up. Only the Arduino cpu (Atmel 328p) can do that. But for some reason I guess the Atmel is not capable of sleeping deeply for more than eight seconds. That must be wildly inefficient if you want to log data every hour. But maybe waking up and going right back to sleep doesn't use much battery power.

That must explain why the interval between data writes is determined with a for loop:

for (int i=0;i<numIntervals;i++) {
LowPower.powerDown(SLEEP_8S, ADC_OFF, BOD_OFF);

That loop must tell the cpu to keep going back to sleep a certain number of times (numintervals) and only after all those eight second naps do some work when you wake up. I do pretty much the same thing some days.


I really don't know the actual time but assuming 800usec (nice for the math) to sleep and wake up it would be 800 / 8,000,000 or 0.01% which seems fine to me. This is another of the functions we should instrument and evaluate. I suspect users would appreciate knowing the typical usable battery life with known loads such as the demo data logging sketch.

BTW, there is still some current drawn in sleep mode.

The RTC can be set to shutdown and wake the AT328P, it just uses another pin that could be used for a sensor. @donblair left an exposed pin available on the board, and wire can be soldered to it and attached to one of the header pins (not sure which on) I don't have a riffle in front of me this second but it looks like pin D5 in the riffle schematic. @donblair correct me if I'm wrong/tell folks where that pin can go.

D5 appears to connect the INT/SQW on the RTC to PD5 on the CPU. I would be very interested in how one uses the feature. I'm assuming that it requires configuring the DS3231 and writing code that enables the CPU to respond to the signal. I am a novice with ATMEL chips but would be willing to test any algorithms that are proposed.

You must be logged in to comment.