|Subject:||Re: [gpsd-dev] ubxtool and remote gpsd|
|Date:||Mon, 1 Jul 2019 19:42:51 -0600|
|User-agent:||Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1|
Glad to hear it...Yo Ken! On Mon, 1 Jul 2019 07:35:27 -0600 Ken McGuire <address@hidden> wrote: > > Nice. Any feed back on those welcomoe. > > The F9x series is a game changer for the low cost high precision > arena. Yup. I can easily get 1 cm accuracy with PPP. > I've been working with Clive on several different board designs using > those parts, for a while. Ah. Good. The sample F9T board I have from Clive works great for me.
> > 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. It always in the dark corners that the dust collects. So keep at it. > Here is what I've done since you replied, I'm not done testing, and > won't have time to co much more today: That all, except setp 5/6 looks good to me. > 5 ran ./ubxtool 192.168.0.134 on my desktop and got: ubxtool: failed > to connect to gpsd [Errno 111] Connection refused I can no duplicate this with git head. I can do both of these: ./ubxtool [ipv4] ./ubxtool [hostname] So either your git is slighlty older than mine, or something we need to find and fix.
That code was changed by: commit e00c2bd65d95bd8d71077fa9147cdfd6b07504fd Date: Thu Jun 27 19:51:59 2019 -0700 So any test earlier than Friday is stale data.
Interesting, I'll check the commit.
The latest commit I have is:
ae1711865cd36d6ab8ef1cc85ec2a9036d30c7e5 which is 6/28 at 18:52
> 6 at line 47 of client.py added: print ('connect:', (host, > port)) Which should be a NOP, except it breaks the port selection. > 7 ran: > > ./ubxtool 192.168.0.134 > connect: ('127.0.0.1', '2947') > ubxtool: failed to connect to gpsd [Errno 111] Connection refused Odd. I do not see how the before Friday code would have done that. > and then: > > ./ubxtool 192.168.0.134:1234 > connect: ('127.0.0.1', '2947') > ubxtool: failed to connect to gpsd [Errno 111] Connection refused Doubly odd. Can you confirm your UBXOPTS environment variable is empty?
This is definitely an ""Interesting"" issue.> 8 This leads me to believe that something is amuck with how ubxtool > was dealing with the server:port parameter it is passed. I agree, except I can't duplicate, nor do I see how the code before the recent fix could fail that way.
python --versionWhat is your Python version?
So, do you agree that this is an issue with ubxtool, and not something with gpsd itself? all of the above is related to the desktop (Linux Mint 17.3) The gpsd version on the remote system is at the same commit as on the desktop.RGDS GARY
On the OPi0:
But gpsd doesn't use python in it's normal operation.
|[Prev in Thread]||Current Thread||[Next in Thread]|