I use the DS1307 real time clock chip in almost every project I do. Adafruit’s RTCLibrary is the best one I’ve found, and a Spark Core port would be much appreciated by the community! https://github.com/adafruit/RTClib
1 Like
This might not be needed as much soon, since the Core has internet access it can use NTP to set an internal clock on boot, then just count ticks while periodically re-adjusting via NTP. This is planned functionality for the future.
1 Like
Very true, I hadn’t thought of that!
I just took a look at the Adafruit DS1307 Library, it’s going to be a bit of a PITA to port as-is. That said, I’ve got a small library I wrote for the MSP430 that I could easily bring over to the Spark Core if you really needed it. Like I said though, I’d hang on for the network time implementation.
Speaking of which, I’m working on a little function right now that will pull time down from the internet on demand. It doesn’t permanently save anything or keep the time, but a call to it will return the current time. I figure it will be a useful stop-gap for people until the Spark Team gets around to implementing the real thing (or I just end up writing it myself).
Just thought I’d mention that it sounds like you might want to use the DS1307 externally connected to the Spark Core… but the STM32 actually has a RTC built into it and there is a low frequency oscillator already on the Spark Core to support it. There’s just no official functions/libraries for it yet. Even though I think the NTP server should be a fine way to go, the internal RTC will also be pretty crucial for low power time critical applications. It’s almost a toss-up because I can’t think of too many cases where you wouldn’t have an internet connection… but I’m also not sure of the differences in RAM/FLASH usage.
^^^ Yeah, this! ^^^ (That’s what I was trying to say in my first post of the thread, but I didn’t feel like typing the whole thing out on my iPad.)
I imagine it would poll an NTP server on startup, set the internal RTC and then hit it every 24 hours or so afterwards to compensate for drift.
Once TCPClient stops locking up everyone’s Cores, I’ll have a little getNetTime class ready that will use TimeAPI.org to get the current time/date and return it in whatever format you want (pre-compensated for a time zone if you want). This should tide anyone over who needs time access before the internal RTC stuff is done. 
1 Like
Awesome, that way you can use the onboard rtc to keep time and back it up for offline, low power use, and then update it once connected to the web for accuracy. Perfect! Thanks everyone! Great ideas!
There’s another reason why you might want to attach an external RTC module:
Suppose you want to use a Spark to make a remote sensor logger of some kind. Data from attached sensors could be stored in the ~1.5MB flash memory for short periods while there is no cloud connection is available, but would need to be time-stamped.
What if the Spark looses power temporarily, and when power is restored, connection to the cloud is not available? As there is no way to connect a backup battery to the internal RTC (without hacking the core’s hardware, which is way beyond me I suspect), with no internet access to reset the time, sensor measurements can’t be timestamped.
At the moment, its a moot point, because our code won’t run anyway (see this link) until the connection is re-established. But hopefully that will be fixed at some point.
An external RTC module, most of which will have battery backup, would fix this problem. Either the user code reads the RTC each time a sensor measurement is made, or uses it to initialise the internal RTC.
Thoughts?
Edit: I suppose with some clever coding, it might be possible to timestamp sensor readings saved in flash memory, even without an external RTC. These timestamps would not be “real” time, and might start at “00:00:00”. When cloud connection is finally restored, and the internal RTC is updated, it might be possible to then retrospectively correct the timestamp data stored in the flash memory, before uploading it to its final destination.
Paul
2 Likes
+1 for having things work offline, including RTC
That’s what I was going for! 
The Spark Core’s RTC will actually keep going if you put a coin cell on the VBAT pin. I’m not sure where they’ve got that routed, but I imagine you could solder directly to that pin if you were so inclined.
In the next revision of the Core, I’d like to see one of the two 3V3 pins replaced with a VBAT input. Or at the very least bring it to a small solder pad or plated via! You could actually glue a little coin cell battery holder onto the top of the CC3000. 
2 Likes
That's what I meant when I said "way beyond me" - in particular my soldering skills!
Isn't one of those for use as the reference for analog inputs?
+1 to that.
As far as I know, one of them is a direct output from the 3V3 regulator, the other (3V3*) is the same output with filtering capacitors attached.
There is an inductor between 3.3 and 3.3*, and then a cap from 3.3* to ground.
It’s pretty tight on the board, but I like the idea of a small solder pad for VBAT.
@Thetinkerer saw you on the Adafruit Show and Tell last night, nice watch! At least I’m pretty sure that was you…
So I was working on porting this over to the Spark Core, but this one has not gone so smoothly as most of the rest. I have it compiling, and it’s trying to work… but I’m finding issues with the I2C and it’s not the 7-bit address thing… stay tuned.
Yep, it’s me! Glad you like it! The next one’s gonna have one of these babies! - http://www.buydisplay.com/default/color-oled-display-module.html
Ok here we go! Tested and working with different times and dates:
Take note of this:
#define DS1307_ADDRESS 0xD0 // Switch back to 0x68 when I2C 7-bit addressing is fixed
Pinouts on line 254 for DS1307 and Spark Core 
Have fun!
2 Likes
I have posted my time library for Spark here:
https://community.spark.io/t/real-time-clock-library-for-spark/2925
It uses NTP time from a server and millis() to give the real time. You can set the update interval for NTP updates to be a day or week if you like, but the millis() clock can drift around +/- 4 seconds per day.
3 Likes