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

 
 

bug #52055: Missing TPV when there is no fix

Submitted by:  Piotr Figiel <pfigiel>
Submitted on:  Mon 18 Sep 2017 01:41:07 PM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: NoneStatus: None
Privacy: PublicAssigned to: None
Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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>
Project 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>
Project 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>
Project 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 File(s):
   
   
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
  • -unavailable- added by garyemiller (Posted a comment)
  • -unavailable- added by pfigiel (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 27 Oct 2017 08:38:36 PM UTCgaryemillerOpen/ClosedOpen=>Closed
    Mon 18 Sep 2017 01:41:07 PM UTCpfigielAttached 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.1-cleanup1