Re: Glitching GPS feed

[Nick Taylor]

Hi Gary and others here - many thanks for suggestions...

On 19/10/2023 00:10, Gary E. Miller wrote:
> Yo Nick!
>
> On Wed, 18 Oct 2023 09:55:08 +0100
> Nick Taylor <nicktaylor@dataskill.uk> wrote:
>
> > - we don't have exact details of how they are doing this behind the
> > scenes but it sounds like there are a couple of devices in between us
> > and the actual GPS receiver.
> Yeah, from the gpspipe -r:
>
> "device":"gpsd://10.253.154.161:2947#tcp://10.253.132.170:7000"
>
> Their .170 is sending NMEa to their .161, that you are reading from.
> What would possibly go wrong?
Quite a lot it seems :D
> As Mike Tubby already pointed out:
>
> $GNTXT,01,01,00,txbuf alloc*61
>
> That means the conenction from the gps receiver is too slow, and data
> is being lost.  Nothing you can do about that, they have to fix the
> configuration of their receiver.
Thanks - have passed this info to customer IT team
> > We can pickup feed using gpsd:// source, however when using this feed
> > cgps seems to glitch, keeps resetting and never seems to get a fix.
> The JSON in the gpspipe -r looks good to me, no idea why cgps would burp.
> Snice I can't duplicate, could Iget port 2947 access to your gpsd instance?
Not easily I'm afraid - the devices are tucked away on firewalled LAN on 
a customer site
> > I'm attaching dumps of the received feed (one is gpspipe -r and the
> > other gpspipe -R). These show feed seems to contain multiple GNTXT
> > messages which may or may not be causing the issue.
> The gpspipe -R seems to show a good solid 3D fix:
>
> {"class":"TPV","device":"gpsd://10.253.154.161:2947#tcp://10.253.132.170:7000","status":2,"mode":3,"time":"2023-10-17T09:25:06.000Z","ept":0.005,"lat":57.314024000,"lon":-111.763671167,"alt":222.000,"epx":1.928,"epy":1.660,"epv":4.715,"track":128.3500,"speed":15.788,"eps":3.86}
>
> Can't image why that would glitch, except the obious "txbuf alloc" problem
> they have.
Let's see whether they can fix this up first?

All the best

Nick