GPS logger / field data collection

[Jim Morris]

Neil Brown wrote:
> On Monday August 18, ml at e4net.com wrote:
>> I was kind of surprised that gpsd didn't give me a simple way to just get the current location, I 
>> had to capture 5 sentences to do that simple thing, but what I really wanted was to simply get the 
>> last known lat and long I was at. With the data logger I can presumably do that by getting the last 
>> entry of the log.
> 
>  from the man page for gpsd
> 
>  p
>            Returns the current position in the form "P=%f %f"; numbers are in
>            degrees, latitude first.
> 
> 

That doesn't work if you connect, get a fix and disconnect. From the FAQ...

Why does my single-shot query fail to return fix data?

This is closely related to the previous item.

The old-style query commands such as P and A are are safe to use with J=1 if you're polling 
repeatedly, but they're a dicey way to go if you're opening a channel to gpsd, doing a single-shot 
query, and then hanging up. Even repeating the query a few times won't necessarily work.

The problem is that your queries are in a race with the daemon's logic for assigning and 
initializing a GPS. It won't try to assign a GPS to your channel until the first command that 
demands actual device information.

Then the race begins. The daemon will be interleaving reads of whatever packet fragments the GPS is 
shipping with reads from your client socket. It is entirely possible that the rest of your commands 
will get processed before the daemon reads and processes enough GPS sentences to get a fix — 
especially if the serial device is slow and the GPS has a long initialization sequence.

(A similar race existed in gpsd versions before multi-device support was added in 2.21; if you 
issued a query too soon after device open it would fail in exactly this way.)

The right way to code your client is to set watcher mode and read a couple of O responses before 
trying to parse one. That way the daemon paces the action, actually telling the client when it 
receives packets.

To be certain of having full fix data, you'd need to wait for as many O responses as there are 
sentences that set fix data in the device's normal cycle. For SiRFs, one read will do because 
normally only one sentence in the cycle ships fix data. For NMEA devices you don't have a full fix 
before five reads, enough for an entire GPRMC/GPGGA/GPVTG/GPGLL/GPGSV cycle in whatever permutation 
the device ships it.

In practice, three O reads will always be enough to get you some fix information — worst case is 
your first O came from a GPGSA and all you get is a mode, and then you get GPVTG, but you'll always 
get lat/lon on the next O.

Clients that poll P or A repleatedly won't have a problem; the race effects will show up but be 
limited to noise in the first few seconds of samples.


-- 
Jim Morris, http://blog.wolfman.com