Re: [gpsd-dev] Urgent: Need a fix for this weird GPSD behaviour...

[sauclair]

Ok then I'll just call read() every 500msecs it should fix the problem.

BTW adding -N to the daemon starting script makes the date back to
2015-etc... I tested many times to make sure I was not being misled by
something else...

Systematically... not using -N makes gpsd output 1995 and using it makes it
output the proper date !

Just so you know !

Thanks for your help... We'll  conduct a new series of tests tonight and I
am sure it will now work perfectly.




Sébastien Auclair
Retia Technologies
(581) 305-2574

-----Original Message-----
From: Eric S. Raymond [mailto:address@hidden 
Sent: July 21, 2015 4:39 PM
To: address@hidden
Subject: Re: [gpsd-dev] Urgent: Need a fix for this weird GPSD behaviour...

address@hidden <address@hidden>:
> Thanks Eric,
> 
> As I said in one of my previous message, the call to read() occurs every 5
seconds... Of course the problem has to do with our code... We just don't
know where the look and we lack the time and resources to investigate...
> 
> As a user of the gpsd lib without knowledge of its internals, I would
expect the current location each time I call read()..... I do not expect to
receive outdated locations !.... At least that's how i thought it should
logically work.
> 
> Now what is the proper frequency to use to call read() ?

You have to poll at least once per cycle time of the device - normally once
per second.  If need be, spawn a worker thread to do this and mutex-lock the
gps_data_t.

If you don't do this, data will pile up in the socket buffers, because gpsd
is shipping data once per second.  If you read only at 5-second intervals
you'll typically fall behind by 4 seconds on each poll.

The Client HOWTO mentions this but I guess I didn't emphasize the problem
enough.  I'll fix that.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>