-
In terms of external synchronisation, I'd really consider just soldering on a 32kHz crystal - that'll save you a whole bunch of time and should be more than accurate enough for pretty much everything.
Maybe I didn't explain myself properly @Gordon. As far as I understand things, the crystal is there to prevent the clock drifting by making sure the frequency is exactly 2^15 cycles per second. That doesn't help much if the micro RTC is off by an hour to start with or has a completely incorrect date/time (e.g. after losing power).
What I am aiming to achieve is to have a datalogger, that is installed in some remote place, automatically update its RTC on start up and then once a day (or more frequently if desired) during long term operation from the GPS timestamp (via serial) and the time pulse pin.
As I have applications in the scientific research and energy domains, I'd like to make it autonomous and as accurate as I can to ensure that data collected from a geographically distributed network of my devices can be reliably compared.
You are reading a single comment by @Gordon and its replies.
Click here to read the full conversation.
roy.emmerich
@Gordon
Well, if you want to access the RTC directly, you'll have to use the peek and poke functions. In terms of external synchronisation, I'd really consider just soldering on a 32kHz crystal - that'll save you a whole bunch of time and should be more than accurate enough for pretty much everything.
Having said about accessing the RTC directly, on the Espruino Board the value from
getTime()comes from the RTC (via a special arrangement which allows it to be accurate to 1uS). That's not implemented on the F4 yet (because the F4's RTC has a calender, and the F1's has a simple 32 bit counter). Since I've added the Date class, adding the same functionality to the F4 should be relatively easy though, and I imagine that would be the ideal solution - It'll end up being a lot of use to all F4 users.