How can one test a USB-GPS module (aka GPS Mouse Receiver) used as a clock source, in situations without network connectivity?
Using the ‘ntpq -p’ command always returns a list with 'SHM()’ entries, whether a GPS is plugged or not.
Is there a way to explicitly select the GPS module as clock source, in order to see wether the deliberately altered system time could be resolved (without NTP)?
Thanks for your support.
hello IceShake,
first, make sure that the GPS module was successfully detected and installed. you can see this in the output file /opt/log/gpsd-mgr.log.
then, using the ntpq -p command, you should see all the NTP clock sources where the SHM entries correspond to the GPS module, which i think you correctly understand. (and, if you are seeing the two SHM() entries in the ntpq output, i will infer that the GPS module was previously successfully installed.)
whether the unit is connected to the internet or not will have no bearing on how NTP uses the GPS time source if it is available: it will always prefer the stratum that is available with the lowest number, where GPS is stratum 0 (column 3 in the ntpq output). the nptq entry with ‘*’ displayed left-most is the current time source being used by the local NTP daemon.
to test without network connectivity, then, (where i assume you can’t log in to the Pi itself?), you should first confirm NTP is correctly using the GPS SHM() time source when it is connected to the internet, with you logged in.
then reboot and unplug the ethernet connection. wait some time, plug the network connection back in, log in to the Pi and confirm in /opt/log/postboot.log that there were no complaints about the NTP service being unable to start. and, of course, again the output of ntpq -p should confirm that the preferred time source being used is the PPS entry.
cheers, please let me know if you have any more questions,
richard
Thank a lot for your extensive feedback, Richard!
It seems that I’m failing with the first step - The log file reports no success.
I rebooted several times with the Original (u-Blox) module, as well as our Emlid Reach M+:
========== TEST BEGIN ==========
2019 126 07:57:43
No device named /dev/ttyUSB* found, dongle appears to be not plugged in.
========== TEST END ==========
best, Diego
hi,
this implies, then, that the data coming off the USB port is not recognized as valid GPS module data.
please run the following command on a command line, let it run for 5 seconds, then send the output file back:
> cat /dev/ttyUSB0 >/tmp/usb-port.txt
In my case, I can see in the /opt/log/gpsd-mgr.log that an install was done for the GPS Antenna after it was plugged in the first time.
And there are some messages coming in from /dev/ttyUSB0. Here is some output
$GPRMC,V,N53
$GPVTG,N30
$GPGGA,0,00,99.99,48
$GPGSA,A,1,99.99,99.99,99.9930
$GPGLL,V,N64
$GPTXT,01,01,01,NMEA unknown msg58
$GPTXT,01,01,01,NMEA unknown msg58
$GPTXT,01,01,01,NMEA unknown msg58
$GPTXT,01,01,01,NMEA unknown msg58
$GPTXT,01,01,01,NMEA unknown msg58
However, there is no SHM device in the ntpq -p listing
remote refid st t when poll reach delay offset jitter
+192.95.27.155 3.83.151.234 2 u 36 64 377 78.612 0.699 3.970
+ns1.switch.ca 213.251.128.249 2 u 33 64 377 78.778 -3.031 6.557
*comet.spiderspa 213.251.128.249 2 u 20 64 377 78.796 1.501 1.116
I can also see a message in the postboot.log file “GPS Dongle detected, turning on GPS daemon and friends”, followed shortly by “We have NTP services” (the shake is hooked up to the internet).
Any thoughts on why the SHM device isn’t showing up, even though the unit seems to think the GPS is active?
The best way to start on this is to see if a USB device is being connected.
Unplug the USB device, run dmesg --w at the console, then plug on the USB device. If it is a working USB device you will get a number of messages telling the device type, manufacturer etc and where it has been mounted. At this point you could try a known USB device such as a memory stick to see what should happen at insertion. If there are no messages then read on…
I recently had a problem with a USB/GPS device purchased from Ebay which was a complete dud. It was actually a GPS antenna. Cutting of the USB plug revealed a coax cable only. So, if you get nothing from dmesg, then it may be faulty or one like I bought.
I’ll test the USB Connect/Disconnect this evening. It is receiving some packets /dev/ttyUSB0, so something is connected. The GPS Antenna does not currently have reception (it is inside), but I thought the SHM device should still load and appear in the ntp tables, whether it saw the sky or not. I will do some more tests this evening.
I hope it isn’t a dud, it is a GPS Antenna purchased with the Raspberry Shake.
hi,
there are a couple of things to check to confirm everything is up and running as it should be:
-
test if GPS output coming off the USB port is recognized as valid:
> sudo gpsd-mgr -t -
reboot the unit to guarantee NTP daemon is started after GPS daemon, since order is important:
> sudo systemctl reboot -
if still no SHM() records listed from
ntpq, query the status of both NTP and GPS daemons:
> sudo systemctl status ntpdate
> sudo systemctl status ntpd
> sudo systemctl status gpsd
and please provide the log file /opt/log/gpsd-mgr.log to this call.
cheers,
richard
regarding no SHM() entries in ntpq output when no access to sky, it’s entirely possible that no SHM() entires will get created until the GPS module is providing actual PPS signals to its daemon.
please test with the GPS module exposed to the sky; otherwise, it’s not entirely clear what’s being tested.
richard
If you do a cat /dev/tty/USB0 then yo should see the EMEA statements coming from the GPS. If you are getting gobbledygook then the serial port speed may be the problem although the application usually handles it ok.
Something else that is often required is to make your user a member of the “dialout” group. This allows you access to the serial port without having to be root ie sudo not required. You can see if this is required by doing ls -l /dev/tty/USB0 and checking attributes. It should look something like: “crw-rw----T 1 root dialout…”
If you need to add yourself to the dialout group then the command is: sudo usermod -a -G dialout your username .
If you bought the GPS at the shop then I doubt it is a dud. It was a very unexpected “bug” in my case!
I hope some of this helps.
Hi,
I’ve put the GPS antenna where it now has a look to the sky. I’ve also done a number of reboots to see if an SHM entry appears, and it never does. Below are the results of the various tests.
DMESG Tests on USB Antenna Connect.
[32590.477744] usb 1-1.2: new full-speed USB device number 5 using dwc_otg
[32590.610031] usb 1-1.2: New USB device found, idVendor=067b, idProduct=2303
[32590.610047] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[32590.610057] usb 1-1.2: Product: USB-Serial Controller D
[32590.610065] usb 1-1.2: Manufacturer: Prolific Technology Inc.
[32590.611160] pl2303 1-1.2:1.0: pl2303 converter detected
[32590.615498] usb 1-1.2: pl2303 converter now attached to ttyUSB0
[32591.447842] Under-voltage detected! (0x00050005)
[32591.449649] ttyS ttyS0: 1 input overrun(s)
[32595.607898] Voltage normalised (0x00000000)
The Undervoltage detected is a strange error, but it seems that it was corrected? Not sure how to interpret these results.
Here is a snippet from /dev/ttyUSB0:
$GPRMC,####.##,A,####.#####,N,#####.#####,W,0.030,,090519,,,A*69
$GPVTG,,T,,M,0.030,N,0.056,K,A*23
$GPGGA,######.##,####.#####,N,#####.#####,W,1,08,1.02,56.4,M,-18.4,M,,*5E
$GPGSA,A,3,09,07,30,08,27,05,23,28,,,,,1.96,1.02,1.67*01
$GPGSV,3,1,11,04,73,173,30,05,27,296,37,07,80,030,31,08,34,104,35*76
$GPGSV,3,2,11,09,54,155,40,13,03,309,21,16,10,044,18,23,20,142,27*73
$GPGSV,3,3,11,27,29,063,23,28,23,212,25,30,58,280,37*4E
$GPGLL,####.#####,N,####.#####,W,#######.##,A,A*77
$GPTXT,01,01,01,NMEA unknown msg*58
$GPTXT,01,01,01,NMEA unknown msg*58
$GPTXT,01,01,01,NMEA unknown msg*58
$GPTXT,01,01,01,NMEA unknown msg*58
$GPTXT,01,01,01,NMEA unknown msg*58
$GPTXT,01,01,01,NMEA unknown msg*58
$GPTXT,01,01,01,NMEA unknown msg*58
$GPTXT,01,01,01,NMEA unknown msg*58
$GPTXT,01,01,01,NMEA unknown msg*58
$GPTXT,01,01,01,NMEA unknown msg*58
$GPTXT,01,01,01,NMEA unknown msg*58
$GPTXT,01,01,01,NMEA unknown msg*58
$GPTXT,01,01,01,NMEA unknown msg*58
$GPTXT,01,01,01,NMEA unknown msg*58
$GPTXT,01,01,01,NMEA unknown msg*58
$GPTXT,01,01,01,NMEA unknown msg*58
$GPTXT,01,01,01,NMEA unknown msg*58
$GPTXT,01,01,01,NMEA unknown msg*58
$GPTXT,01,01,01,NMEA unknown msg*58
$GPTXT,01,01,01,NMEA unknown msg*58
This keeps repeating. Note that the values “#” were actual numbers. The Lat/Lon coordinates were correctly showing my current location.
The output from > sudo gpsd-mgr -t is:
"Test Successful"
The output from > sudo systemctl status ntpdate
● ntpdate.service - Network Time Service
Loaded: loaded (/lib/systemd/system/ntpdate.service; enabled; vendor preset: enabled)
Active: active (exited) since Thu 2019-05-09 06:40:59 UTC; 12h ago
Process: 955 ExecStart=/usr/sbin/ntpd -u ntp:ntp -q -g -x -t 5 (code=exited, status=0/SUCCESS)
CPU: 0
CGroup: /system.slice/ntpdate.service
May 09 06:40:50 raspberryshake ntpd[955]: Listen normally on 5 docker0 169.254.132.107:123
May 09 06:40:50 raspberryshake ntpd[955]: Listen normally on 6 vetha98b9f0 169.254.3.124:123
May 09 06:40:50 raspberryshake ntpd[955]: Listen normally on 7 lo [::1]:123
May 09 06:40:50 raspberryshake ntpd[955]: Listen normally on 8 eth0 [fe80::1648:b399:65d5:bdfe%2]:123
May 09 06:40:50 raspberryshake ntpd[955]: Listen normally on 9 docker0 [fe80::42:dfff:fe6d:c5f1%4]:123
May 09 06:40:50 raspberryshake ntpd[955]: Listen normally on 10 vetha98b9f0 [fe80::e8a1:fdff:fe80:25f3%6]:123
May 09 06:40:50 raspberryshake ntpd[955]: Listening on routing socket on fd #27 for interface updates
May 09 06:40:59 raspberryshake ntpd[955]: 9 May 06:40:59 ntpd[955]: ntpd: time slew +8.821500 s
May 09 06:40:59 raspberryshake ntpd[955]: ntpd: time slew +8.821500s
May 09 06:40:59 raspberryshake systemd[1]: Started Network Time Service.
The output from > sudo systemctl status ntpd
● ntpd.service - Network Time Service
Loaded: loaded (/lib/systemd/system/ntpd.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2019-05-09 06:40:59 UTC; 12h ago
Process: 970 ExecStart=/usr/sbin/ntpd -u ntp:ntp -f /etc/ntp.conf -p /run/ntpd.pid (code=exited, status=0/SUCCESS)
Main PID: 972 (ntpd)
CPU: 7.459s
CGroup: /system.slice/ntpd.service
└─972 /usr/sbin/ntpd -u ntp:ntp -f /etc/ntp.conf -p /run/ntpd.pid
May 09 06:40:59 raspberryshake ntpd[972]: Listening on routing socket on fd #27 for interface updates
May 09 06:41:15 raspberryshake ntpd[972]: receive: Unexpected origin timestamp 0xe07e4a02.d87061b9 does not match aorg 0
May 09 06:41:15 raspberryshake ntpd[972]: receive: Unexpected origin timestamp 0xe07e4a02.d871be25 does not match aorg 0
May 09 06:41:22 raspberryshake ntpd[972]: bind(30) AF_INET6 fe80::10f4:beff:fef1:9520%8#123 flags 0x11 failed: Cannot as
May 09 06:41:22 raspberryshake ntpd[972]: unable to create socket on veth85a6c4c (11) for fe80::10f4:beff:fef1:9520%8#12
May 09 06:41:22 raspberryshake ntpd[972]: failed to init interface for address fe80::10f4:beff:fef1:9520%8
May 09 06:41:24 raspberryshake ntpd[972]: Listen normally on 12 veth85a6c4c [fe80::10f4:beff:fef1:9520%8]:123
May 09 06:41:28 raspberryshake ntpd[972]: Listen normally on 13 vethf03cfbd [fe80::d495:ccff:fe6c:7530%10]:123
May 09 06:41:33 raspberryshake ntpd[972]: Listen normally on 14 veth85a6c4c 169.254.204.82:123
May 09 06:41:39 raspberryshake ntpd[972]: Listen normally on 15 vethf03cfbd 169.254.1.161:1234:
The output from > sudo systemctl status gpsd
● gpsd.service - GPS (Global Positioning System) Daemon
Loaded: loaded (/lib/systemd/system/gpsd.service; indirect; vendor preset: enabled)
Active: active (running) since Thu 2019-05-09 16:18:22 UTC; 2h 51min ago
Main PID: 8143 (gpsd)
CPU: 23ms
CGroup: /system.slice/gpsd.service
└─8143 /usr/sbin/gpsd -N
May 09 16:18:22 raspberryshake systemd[1]: Started GPS (Global Positioning System) Daemon.
The system will not let me upload my gpsd-mgr.log file. However, in the beginning it contains a number of entries of:
========== TEST BEGIN ==========
2019 095 16:33:01
No device named /dev/ttyUSB* found, dongle appears to be not plugged in.
========== TEST END ==========
After a few of these, it is followed by a few:
========== TEST BEGIN ==========
2019 128 04:13:28
========== TEST END ==========
These are then followed by an Install Begin section. There is an update followed by dependency buils, then the following packages are installed:
fontconfig fontconfig-config fonts-dejavu-core gnome-icon-theme gpsd
gpsd-clients gtk-update-icon-cache hicolor-icon-theme libatk1.0-0
libatk1.0-data libavahi-client3 libblas-common libblas3 libbluetooth3
libcairo2 libcroco3 libcups2 libdatrie1 libfontconfig1 libfreetype6
libgail-common libgail18 libgdk-pixbuf2.0-0 libgdk-pixbuf2.0-common
libgfortran3 libgps22 libgraphite2-3 libgtk2.0-0 libgtk2.0-bin
libgtk2.0-common libharfbuzz0b libjbig0 liblapack3 libpango-1.0-0
libpangocairo-1.0-0 libpangoft2-1.0-0 libpixman-1-0 librsvg2-2
librsvg2-common libthai-data libthai0 libtiff5 libxcb-render0 libxcb-shm0
libxcomposite1 libxcursor1 libxdamage1 libxfixes3 libxi6 libxinerama1
libxrandr2 libxrender1 pps-tools python-cairo python-gobject-2 python-gps
python-gtk2 python-numpy
After downloading these packages, there are the following debconf warnings:
debconf: unable to initialize frontend: Dialog
debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Readline
debconf: (This frontend requires a controlling tty.)
debconf: falling back to frontend: Teletype
dpkg-preconfigure: unable to re-open stdin
It then proceeds to unpack the listed packages.
Subsequent tests appear as:
========== TEST BEGIN ==========
2019 129 06:30:34
Stopping gpsd service
========== TEST END ==========
Restarting gpsd service
Any further suggestions desperately welcome…
Still no SHM has appeared in ntpq -p output…
*cake.aseriesoft .PPS. 1 u 740 1024 377 68.420 1.144 4.128
+207.34.49.172 ( 206.108.0.131 2 u 482 1024 377 30.190 -2.340 0.456
+h199-182-204-19 23.252.63.82 2 u 561 1024 177 14.309 0.093 0.490
Best Regards,
Andrew
1 Like
Hi Andrew,
I’ve modified your permissions so you should be able to post your logs now. Sorry for the confusion.
Ian
Hi Ian,
Thanks.
Attached is the gpsd-mgr.log file. Not much additional info in there apart from what I posted.
cheers,
Andrewgpsd-mgr.log (21.6 KB)
And here is the complete dmesg output. There does appear to be an error in there, though it appears long before the GPS antenna is connected.
Andrewdmesg.log (22.7 KB)
Finally, the postboot.log file.
postboot.log (1.3 KB)
Thanks,
Andrew
hi gscShake,
everything looks fine, so why you are still not getting your SHM() entries is a mystery.
(i had thought from the manufacturer’s name that this wasn’t the model we sell, looking deeper there is a bit of confusion about the names, but in fact, we now know you did buy this from the Shake Shop directly.)
let me get back to you on what next steps should be to analyze this further. this is the first time we have seen this so need to have a think about next steps to analyze.
thanks,
richard
Hi Richard,
Thank you. I do have another RS I can try the same USB antenna on, to determine if it is a problem with the GPS Antenna itself, or whether it may be the shake. If I have anything further from that sort of test, I’ll report back.
Cheers,
Andrew
Ok, a long update on my end.
Short story, I’ve got it working now, thanks everyone for help.
I took my RS1D, running 0.15, which never had a GPS antenna installed, and tried the process from scratch again. I watched the /opt/log/gspd-mgr.log file closely after plugging in the Antenna. It didn’t seem to run the check itself after 10-12 minutes, so I instead manually used gpsd-mgr to check if the software was installed. As it wasn’t, I ran gpsd-mgr -i. This ran for a while, downloaded packages, and installed. As soon as this was installed, immediately /dev/ttyUSB0 was no longer available, and instead was listed as busy. Good sign. But, ntpq -p still didn’t show a SHM device listed. At this point, I rebooted the RS1D, and low and behold on reboot, there was an SHM entry (two actually), with the .PPS. one selected as active (marked by a star). Probably it would have been enough to reload the ntp daemon rather than reboot, but oh well.
So, I started up the RS4D (which was the shake I couldn’t get working, above). I ran gspd-mgr -ic, which showed as already installed. To be sure, I ran the install again (gpsd-mgr -i). This did provide some interesting output in the /opt/log/gspd-mgr.log file (I attach it here for reference). Specifically, it looks like something broke or didn’t complete during the install. I ran dpkg --configure -a, which installed a number of packages. Then I ran gpsd-mgr -i again, which continued the install from where it must have broken the first time it tried to install. This completed successfully.
Low and behold, /dev/ttyUSB0 is now busy. So I rebooted, and voila, SHM .PPS. is now the selected entry in the ntpq -p list.
So now it is working. Thanks for the help.
I’m happy to provide log files as needed if there is anything you want to check about why the install seemed to fail partway.
Thanks,
Andrew
1 Like
GREAT work Andrew!
I will add a note to the manual making it clear that the antenna must be plugged in before the Raspberry Shake boots up.
http://manual.raspberryshake.org/gpsTiming.html
Yours,
Branden
hi andrew,
if you could please provide the log files, all of them as downloaded from the home page of the front-end interface, i would appreciate it. i will look to detect GPS program install failures to see if this can be automatically recovered from.
glad it’s working for you now,
richard
Hi Ivor,
Do you want the logs posted/attached here?
Also, for the manual, perhaps it would be useful to explicitly state that gpsd-mgr can be used not only to test, but also force the install of the GPS Antenna.
Best,
Andrew