high-accuracy clock system using GPS

[jerabaul29]

@jvoermans I have unfortunately no GPS breakout for debugging / testing... Can you help me a bit?

Could you:

• connect the GPS breakout to your due as usual.

• in addition, connect the PPS output to any digital pin of the Due

• write a bit of code that:

  • runs the same code as mine:

https://github.com/jerabaul29/interrupt_GPS_synchronization/blob/630fe059a415b19f7c4d920e2101dffff564b3b2/interrupt_catch_micro/src/main.cpp#L20-L45

• at the same time, checks for messages from the GPS, and also prints timing. Something like:

if (SERIAL_GPS.available()>0){
  char c_GPS = SERIAL_GPS.read();
  Serial.print(c_GPS);

  if (c_GPS=='\n'){
    Serial.print(F("newline at "));
    Serial.println(micros());
  }
}

The reason for that is that I want to know when the PPS output is set high by the GPS receiver. Guess this is just before the serial transmission happens, but want to check.

[jerabaul29]

(and show me the serial output you get on the computer).

[jvoermans]

Sorry, bit confused. What should I do with pin 2? And regarding the PPS, I assume I should read the output of the digital pin then?

[jerabaul29]

You can put pin 2 connected to PPS and otherwise loge the GPS as I show.

When a rising / falling edge is applied on 2 from PPS this will trigger an interrupt and measure time very accurately.

[jerabaul29]

Actually, when running this with the GPS, can you use RISING instead of FALLING?

[jvoermans]

@jerabaul29 Could you explain in words exactly what is happening in this sketch? I uploaded it to the mega without issues. Serial monitor gives 'micros' after each GPRMC and GPGGA message. But what do they mean exactly? I assume the micros correspond to the instant at which the GPRMS message and GPGGA message were received, but how does this then related to UTC?

I understand that the rise of the PPS signal corresponds to the start of the UTC seconds. So identifying the instant the PPS rises to 3.3V and relating this to the micros time stamp gives a reference of time for all the measurements. So if we get this reference at a certain frequency, say once every 10-30 minutes, than the timeseries of the different instruments can be matched.

[jerabaul29]

So basically:

• interrupt pins are pins that can force the program to jump to a small piece of code "in hardware", i.e. to react very quickly to an external input

• the GPS has a PPS pin that gives a rising edge at the start of each second, with an accuracy of around 10ns

• The sketch couples the PPS pin to an interrupt pin, and then a bit of codes makes sure that, when the PPS pin is triggered, the current arduino us time is caught. The value caught is then guaranteed to be the beginning of a second, with an accuracy of just a few us (due to the uncertainty of the Arduino clock, which is higher than the ns uncertainty of the GPS).

• this means that this is a simple 'proof of concept' of how a very accurate time reference can be obtained. From there on, converting between UTC and arduino us of ms is very easy. I have not implemented this 2-ways conversion yet, as we will have to decide if it should be done directly on the Arduino, or for example on a RPi if we need to include it inside this logger design too for external data processing. If we have a RPi, it may be a good idea to not to the UTC / arduino time conversion on the Arduino but on the RPi, as we have more tools / resources available there, so it is easier to implement slightly complex logics.

[gauteh]

Noticed this, I implemented something similar a while ago that might be of interest: https://github.com/gauteh/sonobuoy-gautebuoy/blob/master/buoy/gps.cpp#L99