GPSD not getting a good fix

Question

I have a GPS module connected to a Raspberry Pi via USB.

For some reason I can't seem to get a fix using:

cgps

it doesn't seem to get a fix and terminates.

I've also tried:

sudo killall gpsd

sudo gpsd /dev/ttyUSB0 -F /var/run/gpsd.sock

and then tried cgps again, but that doesn't seem to work either.

I even tried:

sudo nano /etc/default/gpsd

and changed the line:

GPSD_OPTIONS=""

to:

GPSD_OPTIONS="/dev/ttyACM0"

which apparently worked for others around the web, but after a reboot, that didn't work either.

But for some reason when I do:

gpsmon /dev/ttyUSB0

I get a full readout of data; lat, lon, Sats, altitude, ext.

Is there a way to output gpsmon /dev/ttyUSB0 sentences to a text file?

Also, why can't I obtain a fix using cgps or something similar?

Answer 1

gpsd is a beautiful application to simplify gps use, but it can be a little confusing.

If you're using a Rasbian, or some apt based package system it is best to configure it with sudo dpkg-reconfigure gpsd to avoid complications (tyqos), but isn't necessary. We have preferences for, but you may not,

• autostart,
• -n Don't wait for a client
• -G to listen on all addresses,
• -b Broken-device-safety mode, and
• autofind

The resultant configuration file looks like

# Default settings for gpsd.
# Please do not edit this file directly - use `dpkg-reconfigure gpsd'  to
# change the options.
START_DAEMON="true"
GPSD_OPTIONS="-n -G -b"
DEVICES=""
USBAUTO="true"
GPSD_SOCKET="/var/run/gpsd.sock"

The primary stumbling block with this approach while gpsd is running in this fashion is it will grab the gps before you can. Attempts to independently and directly access the device /dev/whatever will fail as busy.

If you wish to go that route, for whatever reason, before doing anything else, make sure gpsd is not running.

sudo killall gpsd

and remove any sockets gpsd might have left behind,

sudo rm /var/run/gpsd.sock

Check the location of your gps by attaching it and tracking where it went with dmesg | tail. It will look something like

[67338.935645] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[67338.935650] usb 1-1.2: Product: USB-Serial Controller
[67338.935653] usb 1-1.2: Manufacturer: Prolific Technology Inc.
[67338.936154] pl2303 1-1.2:1.0: pl2303 converter detected
[67338.937953] usb 1-1.2: pl2303 converter now attached to ttyUSB1
[67339.806917] pl2303 ttyUSB1: usb_serial_generic_read_bulk_callback - urb stopped: -32
[67339.807306] pl2303 ttyUSB1: usb_serial_generic_read_bulk_callback - urb stopped: -32
[67340.018016] pps_ldisc: PPS line discipline registered
[67340.018321] pps pps0: new PPS source usbserial1
[67340.018330] pps pps0: source "/dev/ttyUSB1" added

Then you can check for output with sudo cat /dev/ttyUSB1...or whatever, but you could do that with gpsd running. (You can also pump this into a text file sudo cat /dev/ttyUSB1 > gps_dump.txt, or your gpsmon /dev/ttyUSB0 >gps_dump.txt, but there are more elegant solutions.)

The flip side of the confusion is no gps output from the gpsd because it isn't running or configured 'properly'. (either turned off, not started, or pointing to the wrong device). A few application will tell you it's not running, many just sit in silence without any data. I know of none that will tell you gpsd has been manually set to the wrong device.

If you have killed gpsd, or do not have it automagically start, ensure that it is running with sudo /etc/init.d/gpsd restart

Unless you're doing something odd with odd hardware most cases will spit back data with gpsd in these settings, sparing the need for diagnostic settings.

However, bear in mind cgps will timeout if there is no fix. Check your skyview, and Time To First Fix. xgps, on the other hand, is more resilient for failures and provides clues for the absence, or quality of data. If you have an X server, xgps is actually my preferred test for "is it working". If you don't, but have your Pi on a network (xgps 192.168.0.6, or whatever, because the other machine has gpsd-client installed). Another option is to ssh -X [email protected] and then execute xgps)

Telneting into gpsd, while interesting, is another tier diagnostic, as are others.

And finally, a shameless plug for a Python client for gpsd (gps3.py) as means to access the data from a gpsd. It still is alpha, but it doesn't import historical cruft.