[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-dev] Urgent: Need a fix for this weird GPSD behaviour...
From: |
Eric S. Raymond |
Subject: |
Re: [gpsd-dev] Urgent: Need a fix for this weird GPSD behaviour... |
Date: |
Tue, 21 Jul 2015 15:30:29 -0400 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
address@hidden <address@hidden>:
> IMPORTANT: We need to find some fix for this problem as our software
> to be used for a business presentation that should occur tomorrow! …
> If we cannot solve this issue we will not be able to demonstrate our
> RF product prototype and we will lose a major business opportunity.
I'm sorry but I have no fix for this. I do have a guess about the bug.
> 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.)
OK, so we know it's not actually gpsd having a problem here. There's either
a client-library issue or something wrong with your application. I think
I might know what that is.
> Both CGPS and XGPS reported the correct locations. In the case of our
> application, each value produced by gpsmm::read() was the one the other two
> applications reported 1 to 2 minutes prior. At the end of the exercise, all
> the coordinates are being correctly produced but we needed them in real
> time... With a 1 to 3 minutes offset the whole thing becomes useless for our
> application and makes us look very bad !
>
> It’s as if “read()” takes the values out of a FIFO that our code would not
> “unstack” fast enough.
There is no FIFO in the client library. You can verify this for
yourself by looking at the code. There *is* an implicit FIFO deeper
in the system, which is the buffers in your socket layer.
You are reporting the behavior I would expect to see if the main loop
of your application were not calling gpsmm::read() often enough (that
is, less frequently than once a second).
I think your application needs fixing. You can check this by logging
the timing of the read calls. A smoking gun would be a sleep call in
your code with an argument of 1 second or greater.
> Again, I need to remind you that I installed GPSD following
> <http://www.instantsupportsite.com/self-help/raspberry-pi/raspberry-globalsat-353s4-install/>
> this tutorial and that following the step of editing the file
> “/lib/udev/gpsd.hotplug”, 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.
Probably not, though it's worth investigation in itself.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Re: [gpsd-dev] Urgent: Need a fix for this weird GPSD behaviour..., Gary E. Miller, 2015/07/21