Re: [gpsd-dev] ubxtool and remote gpsd

[Ken McGuire]

Hi Gary,

Yo Ken!

On Sun, 30 Jun 2019 11:52:26 -0600
Ken McGuire <address@hidden> wrote:

> Just subscribed to this list, but I've been reading the archives for 
> several months.

Welcome!

Thanks.

> I have several test setups using u-blox F9P/T devices as well as some 
> older M8Ns.

Nice.  Any feed back on those welcomoe.

The F9x series is a game changer for the low cost high precision arena.

I've been working with Clive on several different board designs using those parts, for a while. I signed up for the ArduSimple Kickstarter, but at the time had no assurance that they would succeed, so I went ahead and designed my own board. I built several for myself & Clive, then did a rev of the layout to support the F9T and do a few things that Clive had requested. You got one of the F9T boards. I have since done another variant that mates with a PocketBeagle to form a very compact and capable module. I've had one of the original design running 24/7 as a base station since October.

> However when I try connect
> remotely with ubxtool (ubxtool 192.168.0.134) I get the following
> error:
> 
> ubxtool: failed to connect to gpsd [Errno 111] Connection refused.

Works for me.  But there were some fixes there last week.  Can
you confirm this with git head?

The system is complicated by the fact that there are 2 different architecture devices running 2 different OSs, I originally thought the problem was with the OPi0 which runs gpsd. But after the nmap and nc tests showed that port 2947 was open I started looking at ubxtool and its support code on my desktop.

Here is what I've done since you replied, I'm not done testing, and won't have time to co much more today:

1 cloned the gitlab gpsd repo to gpsd-test on my desktop

2 ran scons to rebuild the code ( I do not have gpsd "installed" on my desktop )

3 ssh'd into my remote OPi0 box and ran:  ./gpsd -D 2 -G -N -n /dev/ttyACM0 (I don't have gpsd "installed" on that platform either) This code was built yesterday from after a git pull from the gpsd GitLab repo.

4 ran ./cgps 192.168.0.134 on my desktop and it ran as expected.

5 ran ./ubxtool 192.168.0.134 on my desktop and got: ubxtool: failed to connect to gpsd [Errno 111] Connection refused

6 at line 47 of client.py added:         print ('connect:', (host, port))

7 ran:

./ubxtool 192.168.0.134
connect: ('127.0.0.1', '2947')
ubxtool: failed to connect to gpsd [Errno 111] Connection refused

and then:

./ubxtool 192.168.0.134:1234
connect: ('127.0.0.1', '2947')
ubxtool: failed to connect to gpsd [Errno 111] Connection refused

8 This leads me to believe that something is amuck with how ubxtool was dealing with the server:port parameter it is passed.

> At about line 6626 in ubxtool I change:
> 
>                  self.ser = gps.gpscommon(host=None)
> 
> to:
> 
>                  self.ser =
> gps.gpscommon(host=opts['target']['server'])

Notice the next two lines which set the target:

                self.ser = gps.gpscommon(host=None)
                self.ser.connect(opts['target']['server'],
                                 opts['target']['port'])

Your patch loses the port number.

9 I noticed that, but when I changed the "host=None" to "host=opts['target']['server']

and ran:

./ubxtool 192.168.0.134:1234

I got:

connect: ('192.168.0.134', '2947')
connect: ('192.168.0.134', '1234')
ubxtool: failed to connect to gpsd [Errno 111] Connection refused

and then when I ran:

./ubxtool 192.168.0.134

I got:

connect: ('192.168.0.134', '2947')
connect: ('192.168.0.134', '2947')
UBX-RXM-RAWX:
 rcvTow 134868.994 week 2060 leapS 18 numMeas 17 recStat 0x1 version 1
 reserved1[2] 0x28 0xc5
  recStat (leapSec)
  prmes 19899575.355 cpMes 104572974.082 doMes 749.914307
   gnssId 0 svId 28 sigId 0 freqId 0 locktime 0 cno 22
   prStdev 10 cpStdev 15 doStdev 12 trkStat 1
  prmes 20696143.613 cpMes 108758951.762 doMes -4022.361816
   gnssId 0 svId 9 sigId 0 freqId 0 locktime 64500 cno 26
   prStdev 6 cpStdev 9 doStdev 8 trkStat 7
  prmes 23830814.438 cpMes 124093277.618 doMes -3552.841797
   gnssId 3 svId 21 sigId 0 freqId 0 locktime 64500 cno 28
........

And so forth...

> I am not a programmer but a hardware guy, so my solution may be all
> wet.

A good bug report is valuable.  I'll look at it seriously on Monday
to see why our results differ.

> Hopefully you can get this fix or a more correct/complete/better
> one.... in before the 3.19 release.

Thanks much.

   ...ken...

Sounds worthy of holding off for.  That and the sconsclean thing.

RGDS
GARY
---------------------------------------------------------------------------