GPS timing without manual intervention

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

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

hi diego,

can you please provide your log files as well?

thanks,
richard

Hi Richard,

I tried to download them using the web interface, but it is not working (it keeps me waiting). I see that in /opt/log there is a bunch of *.log files. Can you tell me which log files you need, so I can manually copy and send them to you?

Thanks
Diego

hi,

if you can use this command to send them all, that would be great.

> tar cf /tmp/shake.logs.tar /opt/log

and then copy the file located in /tmp to your local computer and attach them here.

thanks,
richard

Hi Richard,
please find attached the log files for my two RS3D (v5) units.
The 2374 unit yesterday afternoon (Nov 29, 2021) has been tentatively connected to a GPS antenna to test if it could get the timing from it. The 373 unit has been connected to the LAN only.
Let me know in case you need anything else.
Thanks
Diego
shake373.log.tar (10 KB) shake2374.logs.tar (3.2 MB)

hi diego,

the 373 unit tar file is empty, i’m afraid. can you have a look and re-send?

thanks,
richard

Hi Richard,
I apologize for replying so late, but I did not get any message about your request.
Please find attached the correct 373 unit tar file.
Thanks
Diego
shake373.logs.tar (4.9 MB)

1 Like

hello diego,

for both units, the GPS log file gpsd-mgr.log is reporting that no GPS module is attached:

========== TEST BEGIN ==========
2021 333 14:08:17

Required output from command 'cat /dev/ttyUSB[0-9]' not found, please investigate.

========== TEST END ==========

verify it’s plugged in and try again. (fyi: it did previously successfully connect, then stopped, see the gpsd-mgr log file for exact details on which day this happened.)

and what brand of GPS module are you using? it’s possible it will not be coming in on the ttyUSB port. is there a port named \dev\ttyACM0 by chance?

Dear Richard,
I believe the units started to have problems with the GPS module after the OS update to version 0.19.
I restarted both the units and I plugged the GPS module just in the 373 unit. Below you can find some screenshots for both the units. Actually there is a port named ttyACM0 and, if I’m not wrong’, the GPS module seems to be connected to that port.

I forgot to say that, for unit 373, the GPS log file gpsd-mgr.log is still reporting that no GPS module is attached.
Please, let me know what you think.

hi,

can you please also include the log files? you can download them from the home page of the rs.local front-end config screen.

thanks,
richard

Hi Richard,
apologies for my late reply, but I could not reach my units remotely.
I just made a further test (restarted both my units after I plugged in the GPS USB antennas) but it seems that I still have the same issues.
I attach the log files for both the units.
log373_20220112.tar (5.0 MB) log2425_20220112.tar (3.6 MB)
Let me know
Thanks and happy new year
Diego

hi diego,

what’s very strange about all this is that when the units were first started back in 2018.281, the dongle was successfully detected on /dev/ttyUSB0 (or some other number), followed by a successful install of the GPS support software.

but then, on 2018.282, the port is no longer found:

========== TEST BEGIN ==========
2018 282 14:43:14

No device named /dev/ttyUSB* found, dongle appears to be not plugged in.

========== TEST END ==========
========== TEST BEGIN ==========
2018 283 14:00:24


========== TEST END ==========
========== TEST BEGIN ==========
2018 283 14:42:07


========== TEST END ==========
========== TEST BEGIN ==========
2018 283 14:19:17

No device named /dev/ttyUSB* found, dongle appears to be not plugged in.

========== TEST END ==========

(a section without an error indicates success, i need to fix this…)

after this initial success, it never again finds the GPS dongle. i was recently looking at the u-blox receiver and did find that when it’s plugged in it automatically defines the /dev/tty name, which was a surprise. this would explain what’s going on now, but doesn’t explain why this initially worked back when the unit was set up. was the initial setup done with a different GPS receiver than the u-blox currently attached?

fyi: there was no update to how the GPS dongle is detected in v0.19. this problem started back in 2018, in fact, so there is no relationship to the recent update.

one way to solve this (in the short term) is to set up a udev rule that will create a soft-link between /dev/ttyUSB0, for example, and /dev/ttyACM0. i will find the details of this later today and send them to you. do you still have access to the boxes to make changes?

cheers, more info on the udev rule coming later.

and happy new year to you as well,
richard

Hi Richard,
actually we have been using the same GPS receiver since the beginning.
To make the story short, initially (2018 or 2019?) the GPS dongle was successfully detected but we had to manually set a time close to the actual one in order for the unit to align with the GPS clock. When the OS of our units was still 0.15 or 0.16 (in the beginning of 2020 I think) we wrote a simple routine to be executed at boot in order to automatically get the GPS clock from the attached USB GPS receiver (see also the title of this post). Then, in another post in this forum, I was told that bugs related to GPS dongle detection are solved with OS 0.19, so I updated the units (second half of 2021). Since the update, the GPS dongle is no longer detected.
I do have access to the units and appreciate your help.
Thanks
Diego