I've been using the nuelectronics data logger shield for several months now and slowly learning how things work. All my testing up until recently has been done with Uno's and everything has worked fine, once I understood how things work. I recently hooked one of the shields up to my Mega 2560 and started getting garbage from the ds1302 RTC on it. It just gives 2165 as year and 165 for other numbers. If I take the same shield off (I have seven of them and I have tried them all) and put it on one of my Unos it runs the same sketch just fine, so it's not a software problem and the boards themselves seem to be fine. The Mega is still able to use the SD slot and the other pins on the shield, so it seems like everything is fine there, so I cannot understand why the Mega would be a problem. Is this a problem with using the SD card on the Mega since the software SPI interface is necessary? I'm using the sd.h library that's part of Arduino and the ds1302 library that is described here: http://sheepdogguides.com/arduino/ar3ne1rtc.htm. It's part of a library using Petit FAT file library that is suggested for use by Nuelectronics, and while I no longer use the petit FAT library, I didn't see a reason to change the RTC stuff since it works fine on the Uno. I've seen there are several other libraries for use with this chip and I'm considering switching to one, but that's going to add a lot of learning and debugging which would be fine if it works, but I don't want to waste a lot of time if it just turns out that there is some bug in the shield that keeps it from working with a Mega. Even the hope that this would work would be worth switching to a new library...

Has anyone run into this problem and found a workaround or had success with a particular library? I've contacted Nuelectronics three times and haven't heard back (my first email was over a month ago when I first found this problem). I have to admit that I can get away without the RTC for the current project I'm working on, but there are some good things I could do if I did have it working properly. Any suggestions/help would be appreciated! I have attached the simplest code I'm using that just reads and displays the RTC time every second or so. Since it's not doing anything else, it seems it should work (and it does work on the Uno's) so I'm stumped...

void loop() {int iYr,iMth,iDay,iDOW,iHr,iMin,iSec;ds1302.gettime(&rtc);//As usual: the case of letters matters.iYr=rtc.year;//Must be put into "int" type variable... byte won't do.iMth=rtc.month;//The "rtc" part is chosen by the programmer of this code.iDay=rtc.mday;//Day of month, e.g. Christmas's is "25"iDOW=rtc.wday;//Day of week... 0,1,2...6. Or is it 1,2,3...7?iHr=rtc.hour;//What comes after the "." is defined within theiMin=rtc.min;//code included with #include, above. Not easily changed.iSec=rtc.sec;//Yes... what is in next block IS done crudely. I know.//The point is to show you where things are... not to be//clever with printing to the serial monitor!Serial.print(iDay);Serial.print("-");//Print Jan 2nd, 2010 as 2-1-2010Serial.print(iMth);Serial.print("-");Serial.print(iYr);Serial.print(", Day of week: ");Serial.print(iDOW);Serial.print(". Time is ");Serial.print(iHr);Serial.print(":");//Then the timeSerial.print(iMin);Serial.print(":");Serial.print(iSec);Serial.println();//and start new linedelay(1000);//Will print the time ALMOST once per second. Once//in a while, the DISPLAY will, skip, leave out a second, i.e.//jump, say, from 12:13:14 to 12:13:16... but the time reported//will always be correct.}

I think the pins that are communicating with the rtc are different on the UNO and the mega. The twi/i2c pins on an UNO are A4 and A5 ( i think, check the hardware website) and on the mega they are 20 and 21, so that may be the source of your problem when using the nuelectronics shield on the mega.

It may help you to connect the Mega and the shield with wires on just the essential signal lines, rather than plugging it in, i.e. rather than taking advantage of the mechanical interconnect virtues of the "shield" system.

There is some discussion... not all of it 100% right I suspect(!)... of the signals involved at...