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!
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.
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:
GPS dongle detected, GPS services started
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:
see your log files, since this isn’t supposed to happen
have a full description of how you are able to recreate this problem
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.
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 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.
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.
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:
wait until GPS gets a lock on at least 1 satellite
once GPS clock is locked, system will take this time and set the computer HW clock
start NTP services
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.
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?
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:
re-burn the latest Shake-OS image to your SD card
re-install the GPS fixes
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.
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?
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.
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?
Dear Richard,
I successfully updated my RS3Ds to version 0.19, still they do not get the clock from the GPS antenna. I read through the forum, but I could not find any useful hint on how to solve this issue. Any advice?
I attach the specs of the GPS antenna I use GR-801_flyer-150703.pdf (289.6 KB) . I know it should works, as it worked when I manually set it.
Thank you for your help.
Diego
