bugGPSD - Bugs: bug #52055, Missing TPV when there is no fix

 
 

bug #52055: Missing TPV when there is no fix

Submitter:  Piotr Figiel <pfigiel>
Submitted:  Mon 18 Sep 2017 01:41:07 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 31 Oct 2017 08:15:17 AM UTC, comment #5: 

Hi,
 thanks for looking at it, unfortunately I have no EC-10X for regression testing.
 As I mentioned in the original message the issue is reproducible with gpsfake running with the log file attached to the report. You can see that RMC contains information that the fix was lost but gpsd sends TPV reports only for RMC's which indicate that the fix is present. Expected behavior is that gpsd would send TPV with mode=1 when there is no fix as indicated by RMC with status='V'. gpsd attempts to detect this condition in the driver I modified but originally (without the patch) the handling doesn't result in TPV reports being sent with mode=1.

Piotr Figiel <pfigiel>
Tue 31 Oct 2017 03:25:37 AM UTC, comment #4: 

I did look at your patch, but it breaks the EC-10X.  You can't just take out those important if statements.

Gary E. Miller <garyemiller>
Group administrator
Tue 31 Oct 2017 03:22:34 AM UTC, comment #3: 


> Just for the record as I see the issue is already closed:


Easy to reopen if you can make a case.

> gpsd in this case receives data from GPS receiver, data 
>  received by gpsd indicate that there is no fix (e.g. on RMC
> but also in
> other messages), but I understand that it's your
> intention/design decision to ignore this.


No, not at all.  the case i thought we were talking about was where gpsd receives nothing, and thus has nothing to send.

So you need to supply more details.  What exactly are you getting from your GPS that gpsd is failing to send on?

> the issue is though that instead of getting information about
> the missing fix immediately when it happens I must wait for
> the timeout to expire.


Yes, I agree, IFF gpsd is dropping data that is bad.

If you have data that shows that, I'll reopen this bug.


> Also JSON interface description of gpsd seems misleading as
> mode=1 is a documented value expected to be sent when there is
> no fix,


Not exactly.  gpsd needs to be told by the GPS that there is no fix before sending a notification.

> i.e. timeout is not a documented way of finding out that there
> is no fix.


Documentation change requests will be happily reviewed.  especially as this subject keeps coming up regularly.

Gary E. Miller <garyemiller>
Group administrator
Mon 30 Oct 2017 08:18:47 AM UTC, comment #2: 

Just for the record as I see the issue is already closed:
gpsd in this case receives data from GPS receiver, data received by gpsd indicate that there is no fix (e.g. on RMC but also in other messages), but I understand that it's your intention/design decision to ignore this.
My client code handles the timeout, the issue is though that instead of getting information about the missing fix immediately when it happens I must wait for the timeout to expire.
Also JSON interface description of gpsd seems misleading as mode=1 is a documented value expected to be sent when there is no fix, i.e. timeout is not a documented way of finding out that there is no fix.

Piotr Figiel <pfigiel>
Fri 27 Oct 2017 08:38:36 PM UTC, comment #1: 

Its not a bug.  Its a feature.  gpsd only outputs when it has data.  If it has no input, it sends no output.  Your client needs to check for timeouts.

There are many reason not to be getting TPV, or other data, from gpsd.  No additions on the gpsd side can handle data being lost from gpsd to your client.  Your clients needs to have a timeout
and do what it needs to do on stale data.

gpsd has no way to know your client's data freshness needs.

Gary E. Miller <garyemiller>
Group administrator
Mon 18 Sep 2017 01:41:07 PM UTC, original submission:  

Hi,
 on recent gpsd [1] I stumbled on an issue similar to one reported already in the past [2] that TPV with mode = 1 (MODE_NO_FIX) is not being sent by the gpsd when the fix is lost. Instead no TPV at all was received by the clients by the time there was no fix. This affects use case when it's expected to detect fix loss on libgps client.

 On my receiver (Telit's SL869, but I also remember this appearing in the past on HE910) the scenario is easily reproducible with cgps:

 - wait for receiver to get fix,
 - run cgps,
 - disconnect antenna,
-> cgps still shows 3D fix despite the RMC sentences (as observed with gpspipe) show that fix was lost.

I isolated the issue so that it's reproducible with attached log file used with gpsfake (-c 1) - gpsfake simulates sequence: no fix -> fix -> no fix -> etc...

I introduced correction which now I'm testing and it resolves the issue. It's attached, can you please review and merge if applicable?

Best regards,
Piotr Figiel.

[1] confirmed on master, 3db781b747e03df8faa71a8d4281f9294e05084b but also in past versions
[2] https://lists.gnu.org/archive/html/gpsd-users/2016-11/msg00013.html

Piotr Figiel <pfigiel>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #41826:  RMC2.tmp.log added by pfigiel (1KiB - text/x-log)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by garyemiller (Posted a comment)
  • -email is unavailable- added by pfigiel (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-10-27 garyemiller Open/ClosedOpen Closed
    2017-09-18 pfigiel Attached File- Added 0001-nmea-0183-report-MODE_NO_FIX-when-there-is-no-fix.patch, #41825
        Attached File- Added RMC2.tmp.log, #41826

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code