Hey all,
This might be a little bit of a lengthy problem, so I’d appreciate any and all help. Simply put, I’m installing a number of Raspberry Shakes in the ground as a part of some graduate research. We’re hooking them up to a battery and using one of the GPS antennas sold by RS to provide the NTP. The plan is to leave the ethernet cable plugged in on one end to the RS and visit periodically to download data onto the laptop via the ethernet cable. I’ve run into some baffling technical problems that I just can’t seem to figure out. Simply put, the Shake doesn’t seem to be able to be powered off and then turned on again while using the GPS for an NTP without ceasing to use it and defaulting to a different time. And now additionally, I cannot even access the web front end of the Shake when it is set up normally on my home network. (Additional details follow)
I’ve been plugging my Shakes into my local home router (the university one doesn’t really work for this) to get them set-up with the wireless antenna, powering them down and then powering them up back again unattached to the router. I then will plug my laptop in via the ethernet cable and check to make sure it’s synched to UTC. This generally works fine, but lately when I power the RS back on, usually hours or a day later to install them, the Shake has lost its NTP and has defaulted back to the time that I turned it off. I’ve used Putty to check and I can still see that it can see the GPS plugged in, but its not using it for its NTP. I’ve made sure never to turn the Shake back on without the GPS antenna attached and always in places where it can actually pick up the satellite signal, but no dice. Sometimes it powers on with the NTP and sometimes not, apparently at random.
The secondary problem that has developed as I’ve tried to solve the first problem is that now even when I try to plug the Shake my home router to set up the GPS again and communicate with it, I can’t even pull up the web front end on any device or browser, despite the fact that it has worked previously. So I’ve essentially gone from being unable to keep the RS from using the GPS NTP to being unable to even safely shut it down. I ended up unplugging the Shake from the router and plugging the ethernet cable into my laptop to shut it down safely. I’ve made no recent changes to how my home network, so I’m kind of at a loss as to why this would suddenly stop working.
When I shut it down this time, I did download log files in case those would be potentially helpful in figuring out why I can’t use another device on my home network to access the web front-end. Any ideas would be appreciated, we have bought several Raspberry Shakes at this point, because they were inexpensive and easy to set up, but this issue has essentially brought me to a standstill. I’m happy to provide any additional details or try any suggestions!
RSH.RB299.2019-09-11T18_32_47.logs.tar (1.6 MB)
Ok let’s tackle one thing at a time. First, the GPS problem.
The timing problem should go away if you enable our standalone mode. You can do this by issuing the command rsh-stand-alone ON on the Shake. This will tell NTP that it shouldn’t wait for an internet connection in order to set the OS time.
Some background:
You can tell when the GPS is plugged into the Shake by looking in gpsd-mgr.log. This
========== TEST BEGIN ==========
2019 253 20:39:54
========== TEST END ==========
means that the GPS is plugged in, while this
========== TEST BEGIN ==========
2019 253 20:24:13
No device named /dev/ttyUSB* found, dongle appears to be not plugged in.
========== TEST END ==========
means it was not able to find the device. So it is able to see the GPS most of the times you boot it. You can confirm that by looking at myshake.out or issuing this command:
ntpq -p
Either of which should have output similar to the following (this is from your myshake.out file):
remote refid st t when poll reach delay offset jitter
==============================================================================
SHM(0) .GPS. 0 l - 16 377 0.000 375.911 12.827
*SHM(1) .PPS. 0 l 15 16 377 0.000 0.425 0.519
74.6.168.72 .XFAC. 16 u 701 64 0 0.000 0.000 0.000
204.2.134.162 .XFAC. 16 u 261 64 0 0.000 0.000 0.000
23.31.21.164 .XFAC. 16 u 1217 64 0 0.000 0.000 0.000
The .XFAC. here means that the Shake was not able to contact this server. The asterisk * means that PPS timing from the GPS is in use. However…
For reasons that involve more detail than you need, NTP needs to set the system time right at startup, or else it will have to be slowly incremented slightly faster than realtime in order to catch up to the current time. So what’s happening on your Shake is that NTPD is waiting for the servers so long that it times out and the OS starts without adjusting the system time. Therefore the OS’s date has to be incremented slowly from some time in the past (near when you shut the device off, as you mention). This slow clock adjustment is a feature of the Pi OS—not a bug—which purposefully avoids dramatic time adjustments. When your Shake finally realizes that the GPS is attached, it’s too late and the OS has already fallen back to using the old system time. So it is using the GPS timing solution, but is only able to catch up to present very slowly…so it still looks like it lives in the past.
Okay, thank you for the help! I had seen the stand-alone page and I guess, I was a little confused. I do not have to set the date manually if I’m using the attached GPS antenna, correct? This seems to be the case, but I just want to be absolutely certain.
And if I put it in stand-alone mode, this avoids all the problems with the NTPD timing out and the OS starting up before it realizes the GPS is attached?
That’s correct. As long as ntpq -p shows the asterisk next to the PPS from the GPS receiver, the date will be set by the GPS. Also, the stand-alone page had some incorrect text prior to yesterday when I clarified the functionality of rsh-stand-alone with Richard. That page should be correct now.
Also correct. Let me know if you have problems with it, but it is tested and working both here in the office and at various field locations.