CODEWITHSUNDEEP
raspberry-piraspbiangpsd
user173115
user173115

Reputation: 21

GPSD not seeing complete data

I'm trying to get a Raspberry Pi with a 4" touch screen setup to wardrive and capture some WiFi signals. The piece that is giving me issues is getting the GPS working.

I'm trying to use a module that came with Microsoft Streets & Trips I got a long time ago.

lsusb shows the device as "Bus 001 Device 007: ID 1546:01a5 U-Blox AG [u-blox 5]"

dmesg | grep tty shows: [ 8.276615] cdc_acm 1-1.1:1.0: ttyACM0: USB ACM device [ 344.931792] cdc_acm 1-1.1:1.0: ttyACM0: USB ACM device

I do see a data stream if I issue cat /dev/ttyACM0

sudo gpsd /dev/ttyACM0 -F /var/run/gpsd.sock and then gpsmon /dev/ttyACM0 gives the following:

gpsmon output

But then when I try cgps -s I get:

cgps output

I seem to be getting some data but no lat/long/time data.

Should I conclude that this GPS module is not supported?

Upvotes: 1

Views: 2104

Answers (1)

rmc
rmc

Reputation: 1178

Are you sure your receiver has a satellite fix? Also, you have a log of the GPS data stream? Do you know what specific model receiver you are using?

From your first screenshot it looks like you are definitely receiving data from the GPS, as it's recognizing several different NMEA sentences. On top of that, the first screenshot shows what seems to be a valid GPGLL sentence (I haven't confirmed the checksum):

$GPGLL,,,,,224538.00,V,N*40

My initial hunch would be that the GPS receiver does not have a satellite fix. This is based on

  • Empty GPGLL sentence. The only populated fields in the above sentence are the UTC time and Status fields. The Status value is V, which means the data is invalid.
  • Status NO FIX in the second screenshot.
  • The various boxes in the first screenshot give me the impression that GPSD is correctly parsing the various NMEA packets. For example, the GSV box lists various satellites in view.
  • The lsusb output reports the device as a u-blox receiver. U-blox receivers generally have solid support from GPSD, so I'd be surprised if this receiver isn't supported (but anything is possible). Without knowing the specific model it's hard to say anything definitive.

I've only worked with a couple different receivers, but my general experience is that when they don't have a fix on startup they'll send empty/partial packets. And the date/time data in those packets is probably due to a Real-time clock (RTC) on the receiver. RTCs are common on GPS receivers as they often drastically improve the Time To First Fix (TTFF). So it makes sense that you have a time, but it's marked as invalid.

Recommendations

The fact that your receiver is reporting satellites in view (though none are being used) and that the Status is NO FIX is especially strong evidence to me that your receiver probably just doesn't have a fix. Try moving it to somewhere with a better view of the sky. Also ensure that if it requires any kind of external antenna hardware that you connect that. Lastly, you might have to wait awhile to get a fix. If it's been awhile since you've used the device you could be looking at a cold start with a TTFF of upwards of 10-20 minutes.

Upvotes: 1

Related Questions