GPS timing without manual intervention

Is there a way of getting the gps to adjust the shakes time without the need to manually preset a ‘roughly correct’ time first?

I’m using the shake in ‘stand alone’ mode (no network connection) and using a gps antenna for timing. From what I understand so far, for the gps to correct the time automatically it is necessary to first manually set the shakes time to within about 2 hours of the correct time (otherwise the time never corrects). This is a problem when running on an unreliable / intermittent power supply that could potentially go off for up to several days at a time (unfortunately it’s not an option to add any further battery back-up)… After a prolonged outage the timing will never recover as the shakes clock will always start from the time it was at prior to the outage - if this has been more than about 2 hours the gps time correction doesn’t work…

Please help- it would be awesome to get the gps time correction working fully autonomously!

Standard NTP allows stand-alone operation without intervention. Some earlier notes are here:

https://www.satsignal.eu/ntp/Raspberry-Pi-quickstart.html#stand-alone

Cheers,
David

NZ_VolcTech
February 28

Is there a way of getting the gps to adjust the shakes time without the need
to manually preset a ‘roughly correct’ time first?
[]

Have you thought about adding a real time clock to the Raspberry Pi? Adafruit has several versions, one being “Adafruit PiRTC - PCF8523 Real Time Clock for Raspberry Pi”. The RTC has a button battery and will keep the correct time until the power comes back on. You would probably need an expansion board to fit the shake board and the RTC board. I’m not sure all of that would fit in the shake case. You might need a different case to keep everything enclosed.

hi,

some time ago (version 0.9), there was an addition made to the /etc/ntp.conf file, namely the line tinker panic 0 was added. what this does is tell ntpd to take whatever time it gets from the server and set the local clock to whatever it says the time is, regardless a > 1000 second offset between HW clock and NTP server clock times. what version of the Shake-OS are you on?

with this addition, it means that you don’t need to worry about manually setting it within two hours of correct time to get ntpd to properly set the local HW clock.

the Shake boot-up procedure, (in stand-alone mode, with GPS dongle attached), performs the relevant tasks in the following order:

  1. GPS dongle detected, GPS services started
  2. NTP services started

meaning that the GPS PPS will already be updating the shared memory where NTP retrieves its time from (this assumes GPS has a lock on at least one satellite). and since the NTP configuration file says change the clock no matter what, the clock is updated to whatever GPS says the time is.

since the system has been designed to handle this specific case, i wonder how / why you came to these conclusions. have you encountered the problem you describe with a Shake? if so, i would be very interested to:

  1. see your log files, since this isn’t supposed to happen
  2. have a full description of how you are able to recreate this problem

cheers,

richard

Hi,

RS is running OS 0.18. Log files are attached.

Before downloading the log files I recreated the problem the following way;

At UTC 01/03/2020 19:11 the RS was powered up with GPS antenna connected and placed outside with full sky view. $date command revealed that the HW clock was at UTC 28/02/2020 02:18 (this was the time that the RS power supply had previously been disconnected).

Numerous “$date” checks were then made to confirm that the HW clock didn’t self correct throughout the following 3 or so hours.

At UTC 01/03/20 23:04 the HW clock was still incorrect
At UTC 01/03/20 23:07:00 the HW clock was forced to 01/03/20 22:00:00 using command $sudo date --set “01 Mar 2020 22:00:00”
Within 20 seconds the $date command confirmed that the HW clock had self-corrected.

Hope this helps…

Cheers

RSH.R46C3.2020-03-01T23_42_10.logs.tar (3.0 MB)

hi,

thanks for all the info, i will be digging into this deeper once i get a couple of other things out of the way.

but at first glance, the problem is not that ntpdate can’t adjust the clock, it’s that it is timing out wanting to find NTP servers, even though stand-alone mode is turned ON. this is something that will be fixed once i’m able to spend some time on it (no pun intended). it is my very strong conviction that this should work unattended the way you need it to.

thanks again, i will be getting back to you,

richard

hi,

thanks for all the info, i will be digging into this deeper once i get a
couple of other things out of the way.

but at first glance, the problem is not that ntpdate can’t adjust the clock,
it’s that it is timing out wanting to find NTP servers, even though
stand-alone mode is turned ON. this is something that will be fixed once i’m
able to spend some time on it (no pun intended). it is my very strong
conviction that this should work unattended the way you need it to.

thanks again, i will be getting back to you,

richard

2 Likes

David, not sure if you meant to reply to this, but if so it seems your answer has been swallowed up by Richard’s previous answer somehow :upside_down_face:

Thanks for working on this - looking forward to the solution!

1 Like