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
Thanks for working on this - looking forward to the solution!
Have you had chance to make any progress on this?
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.
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.
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:
- 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.
please let me know if this works now for you.
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?
postboot.log (3.6 KB)
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
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,
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,
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?
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.
can you please provide your log files as well?
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?
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.
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.
shake373.log.tar (10 KB) shake2374.logs.tar (3.2 MB)
the 373 unit tar file is empty, i’m afraid. can you have a look and re-send?
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.
shake373.logs.tar (4.9 MB)
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?
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.