gpsd-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GPSD doesn't report signal dropout


From: Tom Isaacson
Subject: Re: GPSD doesn't report signal dropout
Date: Wed, 7 Oct 2020 15:08:47 +1300

Built from source.

> I see no direct indication of antenna disconnect.  I don't think
> NMEA understands the concpet.  AFAIK that requires a binary protocol.

I'm just disconnecting the antenna to simulate losing signal which you
see in the messages. I wrote a small test app using minmea
(https://github.com/kosma/minmea) and it works fine so I'm not worried
the data from the source is wrong.

Client app is ours, but I wrote a small test app using the gpsd C++
example and it shows the same problem:
https://gpsd.gitlab.io/gpsd/client-howto.html#_c_examples_2

I'll try recording the data simultaneously with D5.


On Wed, Oct 7, 2020 at 2:54 PM Gary E. Miller <gem@rellim.com> wrote:
>
> Yo Tom!
>
> On Wed, 7 Oct 2020 14:24:23 +1300
> Tom Isaacson <tom.isaacson@teknique.com> wrote:
>
> > We are using gpsd 3.19
>
> gpsd 3.19 is a tad old.  3.20 fixes some bugs in 3.19.
>
> Built from source or from a distro package?
>
> > on a Quectel EC25 Mini PCIe
> > (https://www.quectel.com/product/eg25g.htm). GPS seems to work fine
> > until we lose the signal (e.g. go into a tunnel).
>
> I see no doc on what the part sends out.  Hard to support an undocumented
> part.
>
> > The NMEA0183 output shows when I disconnect/reconnect the antenna:
> > https://www.dropbox.com/s/4se0nluw8yh33fr/nmea-disconnect.txt?dl=0
>
> I see no direct indication of antenna disconnect.  I don't think
> NMEA understands the concpet.  AFAIK that requires a binary protocol.
>
> > See $GPRMC validity (http://aprs.gids.nl/nmea/#rmc) change from A (ok)
> > to V (invalid) and back again.
>
> Which may be caused by antenna disconnect, or by other things.
>
> > The GPSD log shows the same - you can see the lock disappear and
> > reappear:
> > https://www.dropbox.com/s/9fx48cohioepv06/gpsd-disconnect.txt?dl=0
>
> I don't see,it.  Way too short a data sample, at too low a -D level,
> with no timestamps to line up with the libgps output.  Maybe more
> obvious at -D5.
>
> The timestamps on the nmea-disconnect.txt do not line up wit the timestamps
> in gpsd-api-disconnect.txt so I can not coorelate them.
>
> I do see a warning about bad time:
>
> gpsd:WARN: merge_hhmmss(), malformed time
>
> But without the matching input I don't know why.
>
> I do see no TPV from 1:00:02 to 1:00:07
>
> > But the client app never sees the dropout:
>
> What client app?
>
> > https://www.dropbox.com/s/yu7mcfmz8dps01e/gpsd-api-disconnect.txt?dl=0
>
> 20 seconds is a bit short.
>
> whatI prefer is simultaineous capture if gpsd input and output.
>
> In separate terminals, run:
>         gpspipe -w > json.log
>         gpspipe -R > raw.log
>
> Send those files here.
>
> > Any suggestions? Is this a known bug, have we just compiled with the
> > wrong flags, what?
>
> Not a known bug.  Since you showed nothing of how you compiled I can not
> comment on that, but I doubt a build error.  Since you compiled it, try
> 3.20 or git head.
>
> If you have doc on the protocol, send that too.  As aa general rule gpsd
> can not support undocumented parts.
>
> RGDS
> GARY
> ---------------------------------------------------------------------------
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
>         gem@rellim.com  Tel:+1 541 382 8588
>
>             Veritas liberabit vos. -- Quid est veritas?
>     "If you can't measure it, you can't improve it." - Lord Kelvin



-- 

Tom Isaacson

6 Apollo Drive, Rosedale Auckland 0632


PO Box 300622, Albany

Auckland 0752

New Zealand

www.teknique.com

Principal Software Engineer

E

tom.isaacson@teknique.com

P

+64 9 282 3132

M

+64 21 362021



reply via email to

[Prev in Thread] Current Thread [Next in Thread]