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

Have you had chance to make any progress on this?

hi there,

sorry for the delay, time has been, well, strange. i anticipate being able to look into this in more detail in the coming week.

apologies for the inconvenience, your continued patience is appreciated.

richard

hi again,

good news: we have recreated the problem and now understand the cause. we will be issuing a hot fix in the coming days, i.e., the relevant programs to make this work will be attached to this issue that you can download and copy to your unit directly. it will also be made available in the next update coming out in the next month or so, if you’d rather wait.

apologies again for the long wait.

warm regards,

richard

hello,

the fix has arrived. please download the two programs attached to this post and copy to your shake’s /tmp directory. then, log in in to the shake using ssh and issue the following commands:

> chmod a+x /tmp/gps* /tmp/postboot*
> sudo mv /tmp/gps* /tmp/postboot* /usr/local/bin

(ignore the colors, markdown…)

from there you can reboot the unit.

when a GPS module is attached, this fix will:

  1. wait until GPS gets a lock on at least 1 satellite
  2. once GPS clock is locked, system will take this time and set the computer HW clock
  3. start NTP services
  4. start the Shake data services

for the moment, you can know if the clock has been successfully set by looking at the output in the file
> tail -f /opt/log/postboot.log
in a near-future update, this information will also be displayed in the front-end configuration interface.

again, my apologies that this took so long to fix.

please let me know if this works now for you.

richard

postboot.rshake (43.8 KB)
gps-time-set (13.9 KB)

Hey Richard,

I tried this exact process with my Raspberry Shake, but following the reboot the web front end does not seem to be accessible. Checking out that postboot.log there definitely seems to be something wrong. One possibility is that when I followed these steps, I had just plugged the Shake into my desktop instead of to the modem directly. Trying to plug it into the modem afterward, the issue did not resolve itself, and the web front end never loaded. I am still able to SSH in just fine. I’ve attached the log, is there any way that I can resolve this issue?

-David
postboot.log (3.6 KB)

hi,

looking at the log file i suspect you are not running the latest version, but i can’t be sure. my recommendation here would be:

  1. re-burn the latest Shake-OS image to your SD card
  2. re-install the GPS fixes
  3. if you attach your unit directly to your computer, or do not want internet access to be recognized, turn on stand-alone mode using the program rsh-stand-alone, followed by a reboot

downloading and burning the Shake-OS image is described here.
stand-alone mode is described here. if you have a GPS module attached, you do not need to set the time manually.

cheers,

richard

Hello Ivor,

is it possible to have the source files you used to get postboot.rshake and gps-time-set?,
this is just to have an idea if there is a possibility to avoid the web-front functionality to disappear (I have discovered the same problem following the procedure you underlined) without any need to re-burn the Shake-OS image.
Or also is it possible to avoid the usage of executables to get the same result using eg a bash file to be read at the startup of the system?

Thanks for your attention,
Diego

hello diego,

sorry, but i really don’t understand what you’re trying to do here. providing the source code is not possible, in any case, but i really don’t think that would help you anyway.

version 0.19 was released earlier this week. if your unit hasn’t updated itself already, please connect it to a network with access to the internet, power up your unit, and it will update itself to the latest version. version 0.19 has this GPS fix in it, so by-hand solutions for this are no longer necessary.

hope this helps,
richard

Hi Ivor,
thanks for your suggestion. I usually use my shakes in the field in stand-alone mode. I recently connected them to the internet and I hope they will update to the latest version.
In the bug fixes of the 0.19 release, I read “GPS clock management now handles the case when GPS clock lock is delayed after system boot-up.”
Till now, I relied on a simple code I wrote to get the GPS timing from the GPS antenna. However, I noticed a systematic delay (about 50 samples) when I compared the Rshake data with data collected with a reference sensor (see this post Delay in nominal nensor response). Is the above bug fix somehow related to the delay I also experienced? May I ask what the delay was due to?

Cheers
Diego

1 Like