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

[sauclair]

Hello Gary,

Thanks for replying...

The code was in the email itself !

And I don't understand what you mean by "... Don't try to rewrite the gpsd 
library..."... our application is client of gpsd... not the other way around !
Anyway so "gpsmm.waiting()" MUST be used ?... Not using this call is right now 
the only difference between our code and the C++ samples provided here: 
http://www.catb.org/gpsd/client-howto.html#_c_examples_2

Would using .data() or some other function do the trick ?... If we have to use 
"gpsmm.waiting()" then the code would freeze the UI and RF communication loops 
so I would need to isolate the GPSD related functions in a separated thread... 
I might not have enough time to make this modifications before our 
presentation....Can you explain to me why we're having this weird offset 
behaviour and XGPS or CGPS doesn't ?

Is there a buffer involved in the read() function I would not manage on 
consider properly ?
When I call read(), I expect the "current" location, not the one where I was 5 
minutes ago !

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

-----Original Message-----
From: Gary E. Miller [mailto:address@hidden 
Sent: July 21, 2015 3:12 PM
To: address@hidden
Cc: 'Sanjeev Gupta'; 'gpsd-dev'
Subject: Re: [gpsd-dev] Urgent: Need a fix for this weird GPSD behaviour...

Yo address@hidden

On Tue, 21 Jul 2015 14:55:42 -0400
<address@hidden> wrote:

> Didn’t get any response to my last email…

Well, you tend to get what you pay for.

> As we drove along, we compared the values of our C++ code which uses 
> libgpsmm.h with the values displayed using both CGPS and XGPS  on 
> Raspbian Raspberry Pi B+. (All three applications were running at the 
> same time on the same unit using the same GPS receiver.)

If cgps is showing you good results then clearly your program C++ code is bad

> It’s as if “read()” takes the values out of a FIFO that our code would 
> not “unstack” fast enough.

Not much we can say without seeing your code.

> Again, I need to remind you that I installed GPSD following 
> <http://www.instantsupportsite.com/self-help/raspberry-pi/raspberry-gl
> obalsat-353s4-install/> this tutorial and that following the step of 
> editing the file “/lib/udev/gpsd.hotplug”,

We can only support our own RasPi howto.

A quick look at the page shows they fail to use the absolutely essential '-n' 
option to gpsd.  I hope you added that already.

Unrelated to your problem, but the 353-s4 has pretty bad sensitivity, you 
should instead use a SiRF 3 or ublox if you can.


> the dates that the GPS outputs through CGPS, XGPS and our own 
> application is no longer 2015…. But 1995… !!!
> Don’t know if this could be connected to our issue.

You will not get a good fix until the date is good.  If you see 1995 then you 
have lost your ephmeris and almanac and you need to wait
30 minutes until it is reacquired.

> We had to make this editing of the file “/lib/udev/gpsd.hotplug”
> because without this, gpsd was starting as a service but it was 
> failing at connecting to the socket...

I'm not sure why you feel you need the socket at all.

> We were forced to killall the
> gpsd process and restart it manually.

Yes, the RasPis daemon setup is known bad.

> Only then were the XGPS and
> CGPS applications able to work properly and the dates were the current 
> 2015 ones. Now gpsd starts as a service at boot time but the date is 
> 1995.

The RasPi service config for gpsd is known bad, dont use it.

Does your GPS have a battery in it?  Many RasPi GPS do not, thus they lose the 
ephemeris and almanac on a power cycle.  Requiring up to 30 mins to reacquire.

> See previous email below for a clear description of our code. (Note 
> that we do not use the wait function provided by libgpsmm.h… we rather 
> use a QTimer instance which is part of the QT UI lib we need to use 
> for our application.)

Well, that would also be a problem. Don't try to rewrite the gpsd library until 
you know how it works.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1(541)382-8588