We had more diving with UNAM, and a few days of work with Trish’s own students ahead of us. But as luck would have it I had a nasty run in with señor Moctezuma, so I was forced to bow out of field work for a few days.  And now that we knew the data loggers were working, we were flirting with the idea that we could simply leave the data loggers running in another system, and come back to get them some time in the spring. I knew that the power consumption was only projecting out to about 45 days (with 15 minute sample intervals), so I had some real work to do if we were going to try a deployment of months!

I parked myself, and my little loggers, at a local restaurant where the internet connection actually worked, and the owner was friendly to researchers; despite the fact that they often spend their whole day glued to a laptop, when everyone else was out at the beach.  The waiters soon learned to ignore the guy in the corner with the laptop that had wires coming out of it…especially since he seemed to subsist on coffee alone.

I will just summarize a few notes from the daily progress journal here:

December 11th:

I examined the logger files from the 3 day test run, and there is more noise in the rubber end cap units data…I bet that’s from vortex shedding off the flat surface!

If we are going to leave these things running, they will eventually run out of power, so I need to protect the SD cards from brown out, or I risk all my data . I implemented low VCC cutoff in the code using the internal bandgap trick from this Arduino playground forum, but was left wondering if the one from Adafruit might work better?

Also posted to the Tiny circuits forum about the inconsistent behavior of the LED indicators. One unit blinks as expected when writing to the SD card. The other unit does not?  Also tried to implement a special “start up went ok” one time loop, but it did not go.
(Evidently the SD card attached to SPI bus as follows: MOSI – pin 11,MISO – pin 12, and CLK – pin 13 which is the same pin as the internal led…)

December 12th:

Yesterdays overnight tests worked fine in Unit1, giving approximately 30 readings per 16mv drop on VCC (with 6 cells) but Unit 2 showed the same drop in only 8 reads cycles. This is worse than the 3AA performance! Perhaps I have a bad cell in the powersupply? or just a bad solder joint that is letting one bank suck power from the other? Will run another overnight test tonight….

December 13th:

I duplicated the main loop data reads, with a second set of variables to cut the SD card access by ½. On an overnight run test, at one minute samples, this buffering of only one set of readings reduced the power drain by more than 50%, so obviously the SD card writing is the big achilles heel in the system.

And “Half your RAM will be taken up with the SD card’s 512 byte buffer, so you only have 512 bytes left to play with.” I need to concatenate those print statements into 512 byte strings?

I discovered that you can store constant unchanging things in the flash, like string literals.  But only if the function you are using them with supports it (which the SD card functions unfortunately don’t) – so anything with print or println with the contents in quotes can be “flashified”.

Found a snippet of code to monitor “Free memory”

December 14th:

Last days in the field now: I spent the most of the day doing multiple “elegant” for/while loops, with array variables, only to watch the free memory whittle down, cycle by cycle, bit by bit, till the “heap hit the stack” and the units start spewing junk characters faster than infinite number of monkeys….

Finally, that evening, I went back to the “dumb&simple” method. So I just copy/paste the entire block of data reading code again, and make a new set of variables for that loop. With three “buffer cycles” for each SD write cycle, its stable. But there is not enough ram to buffer 4 cycles though, so this will have to do.

December 15, 2013

Returning home after a day of fieldwork in a bug infested swamp.

From the overnight run tests: Even with the ram buffering Unit 2 it’s still drawing the power supply down three times as fast as Unit 1 with the same code? Grrr. Have to leave for fieldwork now.

Came back from field work at 8pm, but had to fix a Ph meter before I could check the run log. Unit 2 is still wonky, but our final deployment is tomorrow!  I just pulled it apart and replaced every board I had spares for. Will leave it running over night to see if that helps…

OMG! I popped a spare 128mb SD Sandisk card in for that last hour long test run after replacing the boards in unit 2, and even with read cycles every minute I saw only one 16mv drop on the power supply in over 60 readings! Those smaller size memory cards must draw way less power than the 2Gb Sandisk ones I had been using. Unit 2 is now set to run at least twice as long as Unit 1 – I might get 6 months or more out of it now. I wish I had discovered this months ago!

Last coding task of the day was to set the ChronoDots to wake the processor every 30 minutes. That’s a very long sampling cycle, but we may not be back down here for many months, so we are really stretching it out every way we can.