I am having an issue where, periodically and unpredictably, I am unable to check the NTP to see where timing is coming from/how the timing is going (and also the timing is not updating). The most common error I get is:
This also happens if I precede the command with sudo.
I (am trying to) use GPS timing in offline mode. Below are the main “non-default” settings of the shake. Otherwise, I am using a gps antenna purchased from raspberry shake. When this happens, I can usually fix it via instructions here, namely:
However, this is quite annoying in field situations when I would just hope/expect the timing to work with everything connected correctly. I have not been able to figure out why it does not work (there does not seem to be a consistent reason). I suppose sometimes this may happen when I have not had the shake on in a few days, but I do not think that is the only/consistent reason.
Hello rbalik, and thank you for the very detailed explanation you have provided. That’s a great installation, especially with the high microSD card capacity!
I think that what is causing the issue you are seeing is related to the fact that there is another USB device connected to the Pi alongside the GPS module. As you can read here (GPS Antenna) it is not recommended to do so for the reason pasted below:
To clarify (also for other readers) how the boot-up sequence is with a GPS module connected to the Shake:
GPS module detected
gpsd daemon started
Timing is not “started” until gpsd reports that a lock has been achieved
Only then is ntpd started
Usually, if the GPS has a good view of the sky, this happens quite fast, and the Shake continues its standard booting and then working processes.
To address your problem, could I please ask you to disconnect the WiFi dongle, turn on the Shake again with only the GPS module attached, and see if the error persists?
Could you also send two sets of log files, one with both USB devices connected, and one with only the GPS?
Ah, thank you for this explanation, this is very helpful. Your explanation clarified things. I had seen that warning, but I have not experienced any issues with timing with the wifi dongle outside of the ntpd not starting, so I had assumed that it as an issue with the ntpd. This makes sense, though, that it is not detecting it.
I unplugged the dongle and reset everything and I have not had a problem with GPS timing/ntpd thus far. I will try to send log files. I had some other customizations, so there may be some weird stuff in the log files. I will try to send that next week regardless.
I am going to play around with some things. If you have any advice for how to get wifi (from a dongle since internal adds noise to the data) while using GPS (there will always be GPS, so I could start gpsd automatically at boot?), this would make data acquisition much easier than connecting with the ethernet at each site to do a graceful shutdown…let me know! I am going to paly around with some things in the meantime. I
It’s great to hear that the GPS time data returns to full working status by unplugging the WiFi dongle. That common buffer was behind the timing issue, as (now we know) the signal was lost when the buffer switched between the GPS module/WiFi dongle.
At this point, if you want to keep the WiFi solution for your Shake, I think you are restrained to:
Visit the unit
Connect the wifi
Copy the data off the unit to your laptop
Reboot the unit / remove the wifi dongle
But, at this point, I feel it would be way easier to quick connect an Ethernet cable, copy all the data, and disconnect it.
If you find anything WiFi-side, please let us know!
Thank you. I suppose I will use the ethernet for now.
I think what I may end up doing is using a switch and an OR gate (or something like that) into one of the open GPIO pins. To make a “smart” off switch that first does a graceful shutdown, then turns off the power. We’ll see how that goes.
So, I realize I’m reviving an older thread here. But, I have a similar issue to this, but in my case I’m not using any other USB devices.
When the shake boots up (in standalone mode), there is no ntpq. I get the same error message. I have to run the stop, restart, then start commands to be able to run ntpq -p. Then I can see the shm GPS and pps status.
I don’t have any other USB devices plugged in.
I’m curious, on a cold boot with a gps antenna, what is the expected behaviour in terms of the various components of the system?
System boot
Ntp waits to set the date/time until GPS lock
Do the rsh-data-consumer/producer wait until the time is set to start?
How does this behave differently if it take 10-20 minutes for a GPS lock versus a few seconds (assume no internet at all).
If GPS only, should stand alone mode be used specifically? Ie, will ntp behave differently if standalone is on or off and the internet is or isnt available.
I’m setting up 6 remote instruments that will record with GPS only in an offline setting. There will be no internet in the field. These will have a sleep/wake controller with a solar system to handle graceful shutdowns of the PI before the Low voltage disconnect of the solar controller kicks in. Therefore it is likely that when the pi reboots, the clock could be well off. I want to avoid it sitting there for too long not fixing the clock or recordinging data if the GPS takes a while to get a lock.
Do you have the logs from the Shake that don’t show any ntpq once booted? They would greatly help by providing some more insight into the situation.
Regarding the procedure, I tested with one of the Shakes I have here. Once set to Offline Mode (which is recommended, as the Shake will know it doesn’t need to look for an internet connection), I turned the Shake off, moved it (to simulate your field deployment), and turned it on again. Everything seemed to work pretty well (once I moved the GPS antenna outside the window), so I wonder if there is another reason behind what’s happening in your case.
And, for a complete review on what happens in the different timing situations (offline mode, GPS, no GPS, and more), you can check this page in our manual.
Regarding the sequence, here’s what our software team sent me:
Wait for GPS LOCK
On LOCK:
2.1. Start NTP services:
2.1.1. Set clock
2.1.2. Start daemon to keep clock in sync with GPS PPS
2.2. Start data services
while NO LOCK:
3.1. No NTP services available - this is why the ntpq command doesn’t return, we believe
3.2. No data services started - until GPS LOCK ON
Since this thread is active again, I have a somewhat related question.
I have a physically attached GPS module that I have been able to read into the Raspberry Shake/PI via the I2C pins. Some information on how I am doing that is here.
The main problem is that I have to update the /etc/default/gpsd file every time I reboot the shake for my device to read in correctly (it seems to reset). Is this a known behavior (resetting the /etc/default/gpsd file)? Is there a way to prevent this?
This is what I want my /etc/default/gpsd to be (this is what works with my device):
yes, the Shake-OS auto-detects if there is a GPS module attached and sets this file accordingly. but in your case, since you’re GPS is attached to a different port than what the Shake-OS is expecting, it assumes there is no GPS attached and resets this file.
there are a couple of short-term solutions you can apply:
create a systemd service to set the contents of this file the way you’d like them, to run one-time only, after the service raspberryshake.service has completed, making sure to restart the GPS daemon as well
or
after you’ve created the correct version, for your use-case, of the file, change the file to be immutable, so that the Shake-OS is effectively denied from making any modifications to it; whatever version exists when you set this file attribute will persist forever into the future.
your favorite AI chat-bot will be very happy to provide all the gory details regarding implementation of either solution.
and, this has given me an idea: in a future release, the Shake-OS boot procedure will look for a user-defined version of this file, and when it exists, will copy this version to /etc/default to be used, instead of whatever it would do instead.
