STM32F4 Discovery, RTC and GPS PPS synchronisation

Goal:
I want to accurately update the STM32F4 RTC:

• using a GPS pulse per second (PPS) signal or
  
• using the GPS RTC as external reference clock
  
  

Some background:

I am using the following hardware

1. STM32F4 Discovery board
   
2. MikroElektronika STM32F4 Discovery shield
   
3. MikroElektronika GPS click board (ublox LEA-6S receiver)
   
   

which pretty much looks like this:

So far I have integrated the GPS receiver into my project pretty well and have extended the basic GPS module to include configuration commands and a few other features.

The STM32F407 has a highly capable, built-in RTC which I would like to make use of within the Espruino JavaScript environment.

For the inquisitive, the ST manual on how to use the RTC can be found here.

From what I can see I have the following options to synchronise the STM32F4 RTC:

• The RTC calendar can be synchronized to a more precise, remote clock using the RTC shift feature (see page 19 of the ST RTC manual for more details).
  
• Use the "zero on write" method as described in the "Clock Synchronisation Methods" link below.
  
• Figure out RFC2783 and RFC1589 and hack something using the PPS signal (as used in the gpsd Linux project).
  
• Hack something according to the IEEE1588 Precision Time Protocol.
  
  

Questions:

1. I'd appreciate some guidance on how to expose the functionality contained in stm32f4xx_rtc.c to the Espruino JavaScript interpreter.
   
2. Has anybody tried to synchronise the RTC to a more precise, external time source and is willing to share some tips?
   
   

References:
Here are a few interesting links that have edified me somewhat:

• Clock Synchronisation Methods
  
• Time synchronization with a Garmin GPS
  
• Syncing Arduino with GPS time
  
• Synchronizing and Correlating Measurements to a Global Timebase with GPS
  
• Testing and Verifying Time Synchronization
  
  

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.

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.

Well, the way Espruino's Clock module works is to keep track of the 'real' time and Espruino time when the time is 'set' - which can be done any time. It can then work out the 'real' time whenever it wants to... You could use exactly the same module with the F4.

In fact you could do it right now - it just wouldn't be quite as accurate right now as it works of the high speed oscillator.