I am currently running TWO raspberry pi's, lets call them WORKING PI and non working pi.
WORKING PI:
- Model B Rev 2
- Jessie 4.1.19+ #858
- gpsd revision 3.11-3+deb8ul
- This unit was upgraded from the original Wheezy distro to this version of Jessie. Use to have a working TL-WN725N wireless connection under Wheezy, but this was rendered inoperable after the Jessie upgrade.
non working pi
- Model B Rev 2+
- Jessie 4.1.7+ #817
- gpsd revision 3.11-3
- This is the original distro, but have updated to the latest version.
- This unit has a working TL-WN725N wireless connection.
What both pi's have in common:
- RPI GPS Add On hat both running U-Blox 6 gps chipsets.
- when commanded with gpsmon /dev/ttyAMA0, both pi's regurgitate the expected gps NMEA strings
- Can load the gpsmon command with the u-blox driver and switch between NMEA and U-Blox formatted gps data.
The Problem The ultimate goal is to have gps data logged by both pi's using python. To do that, it appears (as far as I can glean) there must be a gpsd socket running. This can be verified using cgps -s. This is functional in the WORKING PI, but fails in the non working pi.
I have started the gpsd service with the following command in both pi's
sudo gpsd /dev/ttyAMA0 -b -N -D 3 -n -F /var/run/gpsd.sock
In the WORKING PI, this command is accepted and cgps -s runs correctly. Furthermore, the following information is provided:
$ sudo netstat -ltnp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN 498/ser2net
tcp 0 0 0.0.0.0:2000 0.0.0.0:* LISTEN 498/ser2net
tcp 0 0 0.0.0.0:2001 0.0.0.0:* LISTEN 498/ser2net
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 452/sshd
tcp 0 0 0.0.0.0:23 0.0.0.0:* LISTEN 369/inetd
tcp 0 0 0.0.0.0:3000 0.0.0.0:* LISTEN 498/ser2net
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 769/exim4
tcp 0 0 0.0.0.0:3001 0.0.0.0:* LISTEN 498/ser2net
tcp 0 0 127.0.0.1:6010 0.0.0.0:* LISTEN 814/0
tcp 0 0 127.0.0.1:6011 0.0.0.0:* LISTEN 20461/2
tcp 0 0 127.0.0.1:6012 0.0.0.0:* LISTEN 6177/5
tcp 0 0 127.0.0.1:6013 0.0.0.0:* LISTEN 6236/7
tcp 0 0 127.0.0.1:2947 0.0.0.0:* LISTEN 8609/gpsd
tcp6 0 0 :::22 :::* LISTEN 452/sshd
tcp6 0 0 ::1:25 :::* LISTEN 769/exim4
tcp6 0 0 ::1:6010 :::* LISTEN 814/0
tcp6 0 0 ::1:6011 :::* LISTEN 20461/2
tcp6 0 0 ::1:6012 :::* LISTEN 6177/5
tcp6 0 0 ::1:6013 :::* LISTEN 6236/7
tcp6 0 0 ::1:2947 :::* LISTEN 8609/gpsd
This is what I expect: both IPv4 and IPv6 2947 sockets are being used by the gpsd service.
Now, with the non working pi:
$ sudo gpsd /dev/ttyAMA0 -b -N D 3 -n -F /var/run/gpsd.sock
gpsd:ERROR: can't bind to IPv4 port gpsd, Address already in use
gpsd:ERROR: maybe gpsd is already running!
gpsd:ERROR: can't bind to IPv6 port gpsd, Address already in use
gpsd:ERROR: maybe gpsd is already running!
In response to the netstat command:
$ sudo netstat -ltnp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:2947 0.0.0.0:* LISTEN 1/init
tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN 564/ser2net
tcp 0 0 0.0.0.0:2000 0.0.0.0:* LISTEN 564/ser2net
tcp 0 0 0.0.0.0:2001 0.0.0.0:* LISTEN 564/ser2net
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 477/sshd
tcp 0 0 0.0.0.0:3000 0.0.0.0:* LISTEN 564/ser2net
tcp 0 0 0.0.0.0:3001 0.0.0.0:* LISTEN 564/ser2net
tcp 0 0 127.0.0.1:6010 0.0.0.0:* LISTEN 882/0
tcp6 0 0 ::1:2947 :::* LISTEN 1/init
tcp6 0 0 :::22 :::* LISTEN 477/sshd
tcp6 0 0 ::1:6010 :::* LISTEN 882/0
Clearly, both IPv4 and IPv6 2947 sockets are being used by the init service (I'm a RF hardware guy, not a software guy, but this sounds like the operating system is controlling the port.
I have compared the following files between the two pi's and found them to be identical:
/lib/systemd/system/gpsd.socket
/lib/systemd/system/gpsd.service
/etc/default/gpsd
I have spent the last 2 weeks combing this site and others and tried the solutions presented there (to no avail). It appears that this in not an uncommon problem. I welcome any help, but my 3 main questions are:
- Why does init not capture port 2947 at boot in the WORKING PI, whereas the non working pi does capture it, even though both pi's are running Jessie 4.1 (though I admit different rev's). Clearly the reason the non working pi cannot mount a gpsd socket is because the port it wants is already taken.
- Is there a way to tell the non working pi NOT to capture port 2947, or is there a way for me to make init relinquish that port from the command line?
- Is it possible, the wireless on the non working pi is using these ports and that's why gpsd can grab the port on the WORKING PI (which does not have wireless) and can't on the non working pi (which has a working wireless).
I'm out of ideas.
I'm not quite sure if I'm supposed to ADD COMMENT, EDIT THE POST or ANSWER THE QUESTION. In response to LARSKS first answer:
I'll chronicle each pi separately.
non working pi
Upon rebooting the pi:
$ systemctl is-enabled gpsd.socket
enabled
$ systemctl is-enabled gpsd.service
static
cgps -s or cgps still does not work (it times out)
Though, it appears the socket and service are present. So, I tried telneting in to port 2947:
$ sudo telnet localhost 2947
Trying ::1...
Connected to localhost.
Escape character is '^]'.
{"class":"VERSION","release":"3.11","rev":"3.11-3","proto_major":3,"proto_minor":9}
?WATCH={"enable":true, "json"}
{"class":"DEVICES","devices":[]}
{"class":"WATCH","enable":true,"json":false,"nmea":false,"raw":0,"scaled":false,"timing":false,"split24":false,"pps":false}
^]
telnet> quit
Connection closed.
The connection just hangs.
gpsmon /dev/ttyAMA0 still functions properly.
WORKING PI
$ systemctl is-enabled gpsd.socket
disabled
$ systemctl is-enabled gpsd.service
static
This is what I expected, so I attempted to start the service as I did before:
$ sudo gpsd /dev/ttyAMA0 -b -N D 3 -n -F /var/run/gpsd.sock
gpsd:ERROR: device open failed: No such file or directory - retrying read-only
gpsd:ERROR: read-only device open failed: No such file or directory
gpsd:ERROR: initial GPS device D open failed
gpsd:ERROR: device open failed: No such file or directory - retrying read-only
gpsd:ERROR: read-only device open failed: No such file or directory
gpsd:ERROR: initial GPS device 3 open failed
gpsd:ERROR: device open failed: No such file or directory - retrying read-only
gpsd:ERROR: read-only device open failed: No such file or directory
gpsd:ERROR: D: device activation failed.
gpsd:ERROR: device open failed: No such file or directory - retrying read-only
gpsd:ERROR: read-only device open failed: No such file or directory
gpsd:ERROR: 3: device activation failed.
gpsd:ERROR: device open failed: No such file or directory - retrying read-only
gpsd:ERROR: read-only device open failed: No such file or directory
gpsd:ERROR: D: device activation failed.
gpsd:ERROR: device open failed: No such file or directory - retrying read-only
gpsd:ERROR: read-only device open failed: No such file or directory
gpsd:ERROR: 3: device activation failed.
^Z
[1]+ Stopped sudo gpsd /dev/ttyAMA0 -b -N D 3 -n -F /var/run/gpsd.sock
This is now different. In fact, when I attempt to run cgps, I just get a blank screen. Previously I would get an empty table, but now, nothing.
When I attempt to run gpsmon /dev/ttyAMA0, I get:
$ gpsmon /dev/ttyAMA0
gpsmon:ERROR: device open failed: Device or resource busy - retrying read-only
gpsmon:ERROR: read-only device open failed: Device or resource busy
gpsmon: activation of device /dev/ttyAMA0 failed, errno=16 (Device or resource busy)
But, if I reboot, gpsmon /dev/ttyAMA0 returns to normal operation.
As a footnote:
$ systemctl enable --now gpsd.socket
systemctl: unrecognized option '--now'
As a general observation, the gpsmon /dev/ttyAMA0 command works because I am just streaming NMEA msgs via the serial port, to my screen.
the cgps (or python code) does not work, because the socket and or service is not working.
