Shield - RF24, UNIX time, SD

I am in the early stages of designing a combo shield that encompasses a good portion of my project builds. I am looking for feedback before committing to the project in hopes that others may find the shield useful.

I envision a shield with:

  1. RF24 socket, either low power or the higher power with antenna which I often use. I would include a 3.3v supply to avoid a common issue.

  2. A UNIX time http://www.epochconverter.com as battery baked-up realtime hardware clock. Currently I fetch UNIX time from an NTP server and increment locally. This works well enough but other tasks can cause drift. I also wish to accurately increment UNIX time in milliseconds. Using a hardware UNIX time feature, I could accurately log data when network access was not possible. I despise currently available hardware chips. They only supply text strings that need converting to binary. I have only really needed to know date/time for an irrigation controller to meet local bylaws regarding odd/even days and time for watering. It's easy to compute local day, week day, date, hour, minute from UNIX time.

  3. A SD card slot for logging data. What little experience I have had with SD and FAT 8.3 format makes me wish there was a better way to store binary data.

  4. Remaining shield edge with six or so screw terminals for sensors.

Should I use SPI or I2C (wire) to fetch the UNIX time? SPI is my current plan. Should I use 5v or 3v3 logic? I do realize that using 3v3 will limit board compatibility. Selectable?

2

Why not GPS time? The modules are under $17 including shipping and the math is very simple, the library is lightweight. No Internet connection needed. You can use a RT clock module for those times when a storm would eliminate reception of the GPS signal. These U-Blox modules with integrated patch antennas have gotten very good and I have built several GPS clocks using the technology and the clocks work perfectly in a basement. http://forum.arduino.cc/index.php?topic=199216.0

3

SD is all about the library you use. Member Fat16lib has some very good code. Check him out: https://code.google.com/p/fat16lib/

Now, personally, I do not subscribe to running the SD card from the main uC. Some forum members simply freak-out when I suggest using a separate processor dedicated to logging and timestamping ... but for me, it makes sense. Spending $2 differential for the atmega28p-pu chip and integrating that with the SD card makes for a serial logger... it's just too simple but the technique is best suited for recording only. If you need to read from the SD, then integrating it into your main build is likely the correct technique. http://forum.arduino.cc/index.php?topic=154864.0

Ray

Added link to representative U-Blox unit: http://www.ebay.com/itm/181293242043 The link above is provided solely as a representation of what is available and not as a purchase recommendation.

Thanks for the suggestions Ray.

3 SD card buffering is a great concept. My upcoming controller project is for my yacht (think small 12m).

The data I currently log on most controllers is circular buffered in EEPROM, then sent to a bridge controller via RF24 periodically for logging on my OS X file system. Issue is, the boat may be far from any networks access which will drop excess log data as the circular write EEPROM fills. The half-baked plan is to log the data to SD instead. Then when RF24 or WiFi network is restored at the dock, transfer the SD data to the bridge controller over the network and my OS X file system. So reading the data will be a requirement and I would rather not perform a manual SD card swap.

I should be able to glomp-on a buffered read using the approach you suggest.