|Subject:||Re: [gpsd-dev] ubxtool and remote gpsd|
|Date:||Mon, 1 Jul 2019 07:35:27 -0600|
|User-agent:||Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1|
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!
> 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
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']
connect: ('192.168.0.134', '2947')
and then when I ran:
connect: ('192.168.0.134', '2947')
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.
Sounds worthy of holding off for. That and the sconsclean thing. RGDS GARY ---------------------------------------------------------------------------
|[Prev in Thread]||Current Thread||[Next in Thread]|