GNSS time synchro


I have several RS3D outdoor with the GNSS patch antenna. When I look at the time synchro with ntpq -p command not any RS3D seems to use the GNSS timing but always the remote ntp one…quite strange for me. Is there any modification to be done in the ntp.conf file to force the RS3D to use the GNSS when it is avaliable.
Here an exemple of one of the RS3D “ntpq -p” result :

myshake@raspberryshake:/opt $ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
 SHM(0)          .GPS.            0 l    -   16    0    0.000    0.000   0.000
 SHM(1)          .PPS.            0 l    -   16    0    0.000    0.000   0.000
*dedibox.demonge   2 u  200 1024  377   37.509   -3.193   4.699
+     3 u 1056 1024  377   37.963   -1.795  13.623
+ntp.univ-angers   2 u   68 1024  377   41.975   -1.061   5.199

Thanks for your help.

Have a good day

Hello Mickael,

When needed, yes, it is possible to set up NTP servers by SSHing into the Shake and then editing the /etc/ntp.conf file. You will find all the details here: NTP and GPS timing details — Instructions on Setting Up Your Raspberry Shake

In this file, you will have to supply the IP address of the computer where the GNSS antenna is connected. Could you also provide a basic schematic of your system, as I could be able to offer a more precise solution?

Thank you.


The RS3D I am using are ONLINE through 4G connection. As outdoor models, all have the GNSS USB patch antenna bought at OSOP. But How can I check that the GPS is really used ? From the ntpq -p command it seems that the RS3D only consider the remote NTP.
When I look at the gpsd-mgr.log I read messages :“Required output from command 'cat /dev/ttyUSB[0-9] not found…” ???
And there are not any ttyUSB attached in /dev/…looks like the GPS USB is not detected or something is wrongly configurate in the shakes…
That s a pity as I bought the antenna from your compagnie.


Hello Mickael,

Thank you for the additional feedback and details. There could be something else that is missing so I need a bit more data.

After rebooting the Shake with the GPS connected to one of the USB ports, could you please also provide the following?

  1. the contents of /etc/ntp.conf file
  2. the logs of Shake (downloadable via rs.local/ or by zipping the entire /opt/log folder)
  3. the new output of ntpq -p

This additional information should help us in defining your current situation better. Thank you for your collaboration.

Sorry for the late reply, I thought I have send the informations already but don’t see my answer in the system.
Here are the log file, the ntpq -p output and the content of the ntp.conf file.
Thx for your help.


> ntpq -p
>      remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
>  SHM(0)          .GPS.            0 l    -   16    0    0.000    0.000   0.000
>  SHM(1)          .PPS.            0 l    -   16    0    0.000    0.000   0.000
> *dedibox.demonge   2 u   66 1024  377   41.473   -2.513  15.391
> +    3 u  979 1024  377   47.514    0.809  18.949
> +ntp.univ-angers   2 u  232 1024  377   51.302    3.531  49.536
> more /etc/ntp.conf
> tinker panic 0
> # /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help
> driftfile /var/lib/ntp/ntp.drift
> # Enable this if you want statistics to be logged.
> #statsdir /var/log/ntpstats/
> statistics loopstats peerstats clockstats
> filegen loopstats file loopstats type day enable
> filegen peerstats file peerstats type day enable
> filegen clockstats file clockstats type day enable
> # You do need to talk to an NTP server or two (or three).
> #server ntp.your-provider.example
> # maps to about 1000 low-stratum NTP servers.  Your server will
> # pick a different set every time it starts up.  Please consider joining the
> # pool: <>
> server iburst
> server iburst
> server iburst
> # Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
> # details.  The web page <>
> # might also be helpful.
> #
> # Note that "restrict" applies to both servers and clients, so a configuration
> # that might be intended to block requests from certain clients could also end
> # up blocking replies from your own upstream servers.
> # By default, exchange time with everybody, but don't allow configuration.
> restrict -4 default kod notrap nomodify nopeer noquery
> restrict -6 default kod notrap nomodify nopeer noquery
> # Local users may interrogate the ntp server more closely.
> restrict
> restrict ::1
> # Clients from this (example!) subnet have unlimited access, but only if
> # cryptographically authenticated.
> #restrict mask notrust
> # If you want to provide time to your local subnet, change the next line.
> # (Again, the address is an example only.)
> #broadcast
> # If you want to listen to time broadcasts on your local subnet, de-comment the
> # next lines.  Please do this only if you trust everybody on the network!
> #disable auth
> #broadcastclient
>     # GPS Serial data reference                          
>     server minpoll 4 maxpoll 4 noselect     
>     fudge time1 0.500 refid GPS             
>     #                                                    
>     # GPS PPS reference                                  
>     server minpoll 4 maxpoll 4 prefer       
>     fudge refid PPS

RSH.RA7A9.2023-03-22T13 35 09.logs.tar (5.9 MB)

Hello Mickael, no problem at all.

Thank you for all the data you have provided and the new logs. It is an unusual situation, so I would like to see what is detected with a clean system by resetting the Shake OS to default after a microSD re-burn. I will leave the burning instructions here for your convenience:

Once done, the Shake should be able to use the GPS antenna with no issues. If not, please provide all the command outputs and the new logs again after the re-burn.

Thank you again for your collaboration!


I have done some test on a RPYSHAKE that I have in the lab. It is not the RA7A9 but the RE367 but with the same GNSS reception issue.
I have followed your procedure, reburn the SD. Unfortunately the issue seems to be persistant. The USB GNSS antenna is not detected while it is powered (red led into the antenna).
It seems that the antenna is not detected (no /dev/ttyUSB…).

Here are the log file of that RPY post reburn, and also a file containing the outputs of ntpq -d and ntptime commands and also the content of the gpsd-mgr.log file.

Hope it will help to solve the issue…

RE367.cmd.txt (1.3 KB)
RSH.RE367.2022-10-27T10 37 11.logs.tar (225 KB)

Hello Mickael,

Thank you for the further testing and output files/logs. I can see the same, that is, the Shake OS does not see the GPS, and this is likely the main reason it was not connecting to it during your field installation time.

Could I please ask you to try to connect the GPS directly to the USB ports on the Shake (by opening the outdoor enclosure again, disconnecting the enclosure USB cable, and connecting the GPS to any of the available USB ports) and see if, in this way, the Shake sees the GPS as connected after a reboot?

This will allow us to determine if the enclosure USB cable could be responsible for the issue you are experiencing. When doing this, please make sure you are using proper ESD (ElectroStatic Discharge) protection (such as gloves, etc.) so that the Shake is protected from any discharge.

Also, I understand that you bought both the outdoor RS3Ds and the GPS antennas from us; is this correct? Just to confirm for documentation purposes.

Thank you.


I have done the test. It works !

The RPY takes the pps.

There is something wrong on the cable extension/connector or inside the box.

What’s next ?



1 Like

Hello Mickaël,

Thank you for the test, and that’s great to hear! Indeed, now we know that the issue has to be with the connecting cables between the GPS and the Pi.

If you can confirm that the email you used to order the Shake is the same one you are using here on the forum, I will take care of everything else and ask our management to send you a replacement cable.


Yes for the quotation it was my email.


Hello Mickael,

That’s perfect; you should receive my email soon.

You’re more than welcome.

Sorry for may really late reply. I did received the antenna and it solves my issue !!


Hello Mickael,

No problem at all, and thanks for getting back to us. Glad to hear that your problems were solved with what you have received!

Happy to have been of help.