Marble does not show location with gpsd

ordealbyfire83 · 02-16-2015, 01:11 PM

I am trying to use Marble with a bluetooth gps receiver and gpsd.

This is all with Marble 4.13, gpsd 2.92, and GlobalSat BT-368.

First I bind the device using rfcomm:

Code:

hcitool scan
Scanning ...
        XX:XX:XX:XX:XX:XX       BT-GPS-39300D

Code:

sudo rfcomm connect 1 XX:XX:XX:XX:XX:XX
Connected /dev/rfcomm1 to XX:XX:XX:XX:XX:XX on channel 1
Press CTRL-C for hangup

Then start gpsd. I have not installed an init script for this because I don't plan on using it that often.

Code:

sudo /opt/kde-build/kde/sbin/gpsd -b -N -D 2 /dev/rfcomm1
gpsd: launching (Version 2.92)
gpsd: listening on port gpsd
gpsd: running with effective group ID 0
gpsd: running with effective user ID 0
gpsd: stashing device /dev/rfcomm1 at slot 0
gpsd: client 127.0.0.1 (0) connect on fd 5
gpsd: client(0) timed out before assignment request.
gpsd: detaching 127.0.0.1 (sub 0, fd 5) in detach_client

I'm not sure whether this output is appropriate. However if I run

Code:

sudo cat /dev/rfcomm1

I see my current location with data that looks like

$GPGSV
$GPRMC
$GPGGA

with valid location numbers. I haven't reproduced them here as they are rather uniquely identifiable.

If I now launch marble and try to find my location using gpsd, it only says "Waiting for current location information".

Any suggestions? I suspect I'm not using gpsd properly. Thanks in advance.

michaelk · 02-20-2015, 08:21 PM

Have you tried xgps or cgps to see if they work?

ordealbyfire83 · 02-20-2015, 11:39 PM

Yeah, I've tried them but they don't show anything. All of the fields are blank. How can I tell if xgps or cgps is actually reading from e.g. /dev/rfcommX?

michaelk · 02-22-2015, 02:46 PM

gpsmon is another utility that can verify the receiver and gpsd. It will display the raw data via the daemon. xgps and cgps query the gpsd server not the device itself. Might still be a problem with gpsd reading data from the gps.

Looks like you started and stopped an application that was accessing the gpsd server. The debug information looks reasonable for that level. Increase the debug level to see more information.

When you use the cat command is the data from the gps constantly updating?

ordealbyfire83 · 03-02-2015, 05:54 PM

Thanks for the suggestions. I didn't get much time to tinker with this last week. Strangely I am now sometimes able to get gpsmon, xgps, etc. working. I have done nothing different from the steps I outlined above. Sometimes though, cat /dev/rfcomm1 doesn't show anything and I have to turn off the gps, reset my computer's bluetooth, and try again. When it does work, the cat command does update constantly.

Right now I have gpsmon running and it appears to be working fine. The output line in xgps (which updates regularly) shows data such as the following. I have removed the latitude/longitude and some others though:

{"class":"TPV","tag":"RMC","device":"/dev/rfcomm1","time":1425340132.000,"ept":0.005,"lat":<xxx>,"lon":-<xxx>,"alt":<xxx>,"epx":<xxx>,"epy":<xxx>,"epv":<xxx>,"track":<xxx>,"speed":0.077,"climb":-0.100,"mode":3}

When it works, this seems like a pretty powerful tool. However Marble still says "Waiting for current location information." I am unsure though how best to "tear down" all of this - I have been revisiting the terminal tabs and pressing ctrl+c. However the next time I try to set this up, it never works.

Additionally, sometimes the first try with rfcomm does not work, and I have to do "release" the rfcomm1 assignment.

michaelk · 03-02-2015, 06:12 PM

I could not find any information on the inner workings of marble and GPS so not much help on that end.

ordealbyfire83 · 03-03-2015, 06:52 PM

Yes it does not seem to be documented well. I looked at some of the source files and found a section dealing with error handling. It looks like marble makes it through the "initializing" stage (in fact the program shows "Initializing current location service" for a brief second), but doesn't actually get to where the data is parsed; however it doesn't throw any of the listed errors, either.

sudo watch lsof -i (relevant output)

Code:

gpsd     20961  root    3u  IPv4 132366      0t0  TCP localhost:gpsd (LISTEN)
gpsd     20961  root    4u  IPv6 132367      0t0  TCP localhost:gpsd (LISTEN)
gpsd     20961  root    5u  IPv4 132376      0t0  TCP localhost:gpsd->localhost:44292 (ESTABLISHED)
gpsmon   20962  user    3u  IPv4 131829      0t0  TCP localhost:44292->localhost:gpsd (ESTABLISHED)
marble   21087  user   24u  IPv4 134143      0t0  TCP localhost:44467->localhost:gpsd (CLOSE_WAIT)
marble   21087  user   34u  IPv4 135245      0t0  TCP localhost:44471->localhost:gpsd (CLOSE_WAIT)

I may try recompiling marble against a newer version of gpsd. I'm mainly using v2.92 because it uses a sane and familiar method of compilation. I'm using BLFS here and have compiled a couple hundred packages for it, but Lord only knows how to compile new these new versions of gpsd.

ordealbyfire83 · 09-21-2017, 09:46 AM

I know this is quite old, but I have some updates. Recently I have compiled BLFS-7.9 (quite similar to Ubuntu 16.04 LTS) with KDE Frameworks 5.19 and Marble 15.12.3 and got this to work. gpsd is not in the BLFS book, and Ubuntu 16.04 uses gpsd version 3.15. This version of gpsd just does not work. It compiles fine but nothing ever goes into /dev/rfcomm1. Version 3.9 does output location data over /dev/rfcomm1 and the tools such as xgps show live data.

Compiling new versions of gpsd unfortunately requires "scons." I used scons version 2.4.1 - just follow the instructions in that tarball to compile the python setup file and it should be good to go.

To compile gpsd version 3.9 you also need a program called chrpath in /usr/bin - it needs to be there and just putting it in your $PATH is not good enough. (chrpath is a very simple program to compile - don't even bother running "make install" as you can just move the executable to /usr/bin and remove it after gpsd is compiled.) Compile gpsd using

Code:

scons prefix=/usr
sudo scons udev-install

which should do it. Also I tried something a little different to get the gps device up and running. As usual run

Code:

hcitool scan

to see if it is detected. As per this tutorial I put something like the following in /etc/bluetooth/rfcomm.conf

Code:

rfcomm0 {
	# Automatically bind the device at startup
	bind yes;

	# Bluetooth address of the device
	device XX:XX:XX:XX:XX:XX;

	# RFCOMM channel for the connection
	channel	1;

	# Description of the connection
	comment "Your GPS model here";
}

Note, this always gives this device /dev/rfcomm0, so if you want another number just change it here (in my above post I used /dev/rfcomm1). Now you can bind it using

Code:

sudo rfcomm bind rfcomm0

This is a bit more elegant as you can undo this setup just by

Code:

sudo rfcomm release rfcomm0

instead forcibly exiting with CTRL+C and the like. Now start gpsd as above, being mindful of the changed address

Code:

sudo /usr/sbin/gpsd -b -N -D 2 /dev/rfcomm0

This version will give a bit different output:

Code:

gpsd:INFO: launching (Version 3.9)
gpsd:INFO: listening on port gpsd
gpsd:INFO: NTPD ntpd_link_activate: 1
gpsd:INFO: stashing device /dev/rfcomm0 at slot 0
gpsd:INFO: running with effective group ID 10
gpsd:INFO: running with effective user ID 99
gpsd:INFO: startup at 2017-09-21T14:12:07.000Z (1506003127)
gpsd:INFO: opening read-only GPS data source type 4 and at '/dev/rfcomm0'
gpsd:INFO: speed 9600, 8N1
gpsd:INFO: speed 9600, 8O1
gpsd:INFO: speed 9600, 8N1
gpsd:INFO: gpsd_activate(): activated GPS (fd 6)
gpsd:INFO: /dev/rfcomm0 identified as type Generic NMEA (0.232178 sec @ 9600bps)
gpsd:WARN: can't use GGA time until after ZDA or RMC has supplied a year.
gpsd:INFO: detaching <unknown> (sub 0, fd 5) in detach_client
gpsd:INFO: detaching <unknown> (sub 0, fd 5) in detach_client
gpsd:INFO: closing GPS=/dev/rfcomm0 (6)

Now check xgps. If the data is there and updating, then start marble. Change the location to gpsd and it should work! (Note the position of the map does not automatically take you to your location unless you have that box ticked.)

I will try this version of gpsd with BLFS 7.5 + KDE 4.13 as above and see if that changes anything (i.e. whether this is a problem with gpsd or marble).

ordealbyfire83 · 09-27-2017, 01:19 PM

Tested and Working with Marble 4.13.3 (last update from that release) recompiled against gpsd 3.9.