I still have a long road ahead of me when it comes programming. But I figure that I since I started pretty near zero at the beginning of this project, I could share some thoughts on the process; before I forget what it was like. There were real benchmarks along the way, which made me feel pretty good when I achieved them, even if the goal posts seemed to move every single time.

Stage 1: Ummm, Is this thing on?

Initially, I was just reading the data from the sensors and sending that to the serial monitor to see what kind of numbers were being produced.  With the original Uno, and analog sensors like the MMA7260 this was just a few analogRead() statements. With a few simple lines of code, you know if you connected the wires properly. Still, it was cool to (carefully) move my little contraption around, see the numbers changing, and start thinking about how to calibrate the sensor, and whether I should  change AREF to get more juice out of the ADC. Also, to wonder if I should massage that data to get rid of all the jitter I was seeing in those numbers.

Stage 2: Going to the library.

Then I tackled writing the to the SD cards, copying code directly from the Adafruit datalogger shield tutorials. This introduced me to the concept of libraries: mysterious extra bits of code that I had to go find, and then #include with the program, to get the Arduino sketch to work. This was true for the SD cards, the RTC, and basically anything else that sent information to the microprocessor, rather than just putting a voltage on a pin.  These libraries are like the “killer apps” of the Arduino world. Without them, the best chip in the world remains unusable, hiding up in the rarefied atmosphere of embedded system engineers.  But as soon as one of those boffins decides to “release the library” he came up with for chip “IC-123”, then suddenly the forums light up, and all the lesser mortals start using that device in a big way.  Being one of those humbler people myself, my first step when wondering whether I can use a new widget, is to see if I can find libraries for it on github. And even though part suppliers like Adafruit, Sparkfun et. al. have turned this phenomenon into a thriving business model, the actual chip makers themselves almost never make the special sauce; leaving you to chew on the dry, salty, datasheets.

Stage 3: Can you I2C me?

Pullup resistors added to the chronodot RTC

Getting different two wire interface chips to share the same data “party line”, has benchmark status for me, because it was the first time software issues really forced me to go back and learn about the electronics seriously enough to raise my game. I spent days trying to figure out what pullup resistors were really doing, and whether the different boards I was cobbling together had put just the right amount on the lines. This was an important issue to resolve before moving on to the next stage of the game, but it also changed my understanding from “It either works or it doesn’t”, to the realization that there are many shades of grey in the way circuits are designed. Generally speaking, you get what you pay for.

Stage 4: Does this thing run on batteries?

Once all the chips were on speaking terms, and the data was being recorded on the SD card, it was time to cut the umbilical.  From a benchmark point of view, this is were all the software power management strategies come into play: the sleep codes really had to work, and the SQW alarm pulse had to wake the whole thing up again.  I also had to think about what would happen to all the circuits as the voltage started dropping. I had to learn about things like voltage regulators & level shifters, trying to find the weakest link in the chain, and then dug further into the forums to find out how far outside the specs you could actually go before you got into trouble.  In my project for example, I had prevent memory card writing if the voltage got too low or I would toast the memory cards, and loose all the data.

Stage 5: To infinity and beyond…

So this where I am now, and I am sure that there are many more “stages” ahead of me. The units are working for a reasonable length of time on batteries, but I still need to multiply that by a factor of two or three, to reach my year+ run time target. Preserving every last micro amp raises issues like data buffering to reduce the power hungry SD writes. This takes me even further into programming issues like variable optimization, because the code I cobbled together is now so large, that memory management is has become crucial. Or, if i work on my chops, I might be able to eliminate the SD cards entirely, and use eeproms for storage. Of course, each time I add a new chip or sensor into the mix, it sends me right back to stage 1 again.

The real take home message, for the people thinking about their first Arduino project is this: At each step of the way, getting a piece of  hardware to work required me to learn more programming, and each software problem I faced, forced me to learn more about the devices I was trying to connect. It’s sort of like climbing a ladder, by lifting one leg, and then the other. And as I passed each stage, the previous code folded into one small corner of the next version, adding layers of complexity like an onion. But I had no idea this was what the process would actually be like when I started out, because almost every thing I read at the time seemed to be written by technical geniuses that don’t have time for this kind of retrospective stuff.