It sure looks like the Vesper is in /dev/ttyUSB0. Is there any way you can verify that it is pushing out NMEA data? Does it have it;s own WiFi connection that you can connect to.
So far you have kplex running but not spitting out any data, Vesper attached, perhaps not putting out any data for kplex to retransmit (?).
I realize that it’s been a long while since this discussion about setting up Soft Float Hub on a Raspberry Pi, but it seems that I am having similar issues with no actual data being received by sfh. Did the problem get resolved?
My situation is running sfh on an old Raspberry Pi 2B attempting to use kplex to stream from a usb Ublox gps. The Python version is 3.#, although I did try running it with “python2” with similar results - so I don’t believe that is the issue.
Kplex has been installed per the instructions and the kplex.conf file set to relay from serial /dev/ttyACM0 - which is what the USB gps has been assigned. The Kplex output server has been set to standard TCP port etc.
When running sfh with kplex running I can see the continual connection cycling as if there is no actual data being relayed from kplex.
This seems to be the exact same problem that this thread discovered.
Earlier, I did discover a conflict with gpsd which required sudo killall gpsd to enable kplex to run without error messages.
I also tried using gpsd instead of kplex as the server, and in this case the result was the same connection cycling with no real data apparently being sent to sfh.
Separately, I was however able to write a modified test program to read the gps from serial directly and then send to the float hub server using extracts from sfh. This worked but was not stable or ready for prime time.
Any suggestions or advice would be much appreciated.
Cheers
Rich
Are you using a FloatHub ID beginning QMm? If yes, we do so show some data reception, but that may be from when you had your own (non “prime time”) code running.
Can you please cut and paste:
- The command line you are using to run sfh (x-out your FloatHub ID and Security Key of course)
- A few seconds of sfh output when running with verbose on (adding the -v flag).
- A copy of your /etc/kplex.conf configuration file
- A few seconds of kplex running with “-d 9” turned on
That should help diagnose things.
Thanks for the quick response.
Kplex.conf file:
[serial]
filename=/dev/ttyACM0
direction=in
baud=38400
[tcp]
mode=server
port=10110
direction=both
Terminal dmesg info:
[ 256.592893] usb 1-1.2: New USB device found, idVendor=1546, idProduct=01a7, bcdDevice= 1.00
[ 256.592957] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 256.592986] usb 1-1.2: Product: u-blox 7 - GPS/GNSS Receiver
[ 256.593007] usb 1-1.2: Manufacturer: u-blox AG - www.u-blox.com
[ 256.777414] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device
[ 256.779656] usbcore: registered new interface driver cdc_acm
[ 256.779691] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[ 259.304408] pps_ldisc: PPS line discipline registered
[ 259.311263] pps pps0: new PPS source acm0
[ 259.311376] pps pps0: source “/dev/ttyACM0” added
rest to follow
Initial response to starting kplex:
lazydays@raspberrypi:~ $ kplex -d 9
kplex DEBUG: Using config file /etc/kplex.conf
kplex DEBUG: kplex starting, config file /etc/kplex.conf
Failed to open /dev/ttyACM0: Device or resource busy
Failed to initialize Interface _serial-id1
Second try after killing gpsd:
lazydays@raspberrypi:~ $ sudo killall gpsd
lazydays@raspberrypi:~ $ kplex -d 9
kplex DEBUG: Using config file /etc/kplex.conf
kplex DEBUG: kplex starting, config file /etc/kplex.conf
kplex DEBUG: _serial-id1: opened serial device /dev/ttyACM0 for input
kplex DEBUG: _tcp-id2: initialised
starting sfh - needed to use “python” prefix to avoid error “no such file or directory”
python ./sfh/sfh -v -i QM… -k 79…
sfh then runs - screenshots next:
It looks like sfh and kplex are cycling connections, which suggests something may be up at the kplex end.
What if we just cut sfh out of the picture and you do a:
telnet localhost 10110
You may need to install telnet on your Pi for that to work (i.e. something like “sudo apt-get install telnet”). That should show you exactly what kplex is putting out on TCP port 10110.
ok, keeping kplex and sfh running, here is telnet’s output:
lazydays@raspberrypi:~ $ telnet localhost 10110
Trying ::1…
Trying 127.0.0.1…
Connected to localhost.
Escape character is ‘^]’.
it seems a little thin
Thin indeed 
Best to kill off sfh and try again to triple check, but it sure looks like kplex is not actually outputing anything at all. That would explain why sfh keeps trying to kill off and re-establish the connection.
First thing to try might be to comment out “direction=both” in your kplex config. Not sure that’s the issue, but just not something we are familiar with.
Also, unless you are using it for some other reason, might be good idea to disable gpsd. This should stop it:
sudo systemctl stop gpsd.socket
And this should disable it:
sudo systemctl disable gpsd.socket
Probably good to do a reboot after that and then once back up make sure there is no hint of gpsd running, ie:
ps ax | grep gps
should not show anything. Then try telnet to kplex (without sfh running at all).
ok, I stopped and disabled gpsd per your instructions, then did a reboot and entered the check for gpsd.
looks like it is still alive:
lazydays@raspberrypi:/ $ ps ax | grep gps
505 ? S<sl 0:00 /usr/sbin/gpsd -n /dev/ttyAMC0
1364 pts/0 S+ 0:00 grep --color=auto gps
so I tried again:
lazydays@raspberrypi:/ $ sudo systemctl stop gpsd.socket
lazydays@raspberrypi:/ $ sudo systemctl disable gpsd.socket
lazydays@raspberrypi:/ $ ps ax | grep gps
2754 pts/0 S+ 0:00 grep --color=auto gps
seems to have stopped gpsd finally.
However, trying to start kplex shows some conflict:
lazydays@raspberrypi:/ $ kplex -d 9
kplex DEBUG: Using config file /etc/kplex.conf
kplex DEBUG: kplex starting, config file /etc/kplex.conf
kplex DEBUG: _serial-id1: opened serial device /dev/ttyACM0 for input
Failed to open tcp server for (null)/10110: Address already in use
Failed to initialize Interface _tcp-id2
kplex DEBUG: Cleaning up data for exiting input interface _serial-id1 id 10000
So it looks like a module of kplex was running after the reboot, so I killed kplex and re started it.
Now I have the same empty output on 10110 as before (as seen through telnet).
none the wiser
OK, let’s peel back one more layer of the onion and see if the GPS device at /dev/ttyAMC0 is actually outputting anything over it’s serial connectiion. If you stop kplex (and double check that gpsd is still not running), what happens if you just do a:
screen /dev/ttyAMC0 38400
You may have to install screen first, with something like
sudo apt-get install screen
If that does not produce obvious NMEA output, you might try a couple of other BAUD rates, eg.
screen /dev/ttyACM0 115200
screen /dev/ttyACM0 9600
screen /dev/ttyACM0 4800
If that still doesn’t produce anything, try unplugging and re-plugging the GPS. When you do so, check dmesg to see which device name it got when you re-plugged it (it might be /dev/ttyAMC1) and also check to see if gpsd is being started somehow whenever you insert the unit. It could well be that there’s a rule somewhere that is invoking gpsd on any gps insertion and then gpsd is setting a baud rate and/or putting the device into binary mode (rather than normal NMEA serial output mode).
I tried screen with varying baud rates after killing gpsd and kplex. In all cases the first few lines were GPSTXT then a stream of unrecognizable characters.
Are we expecting to see NMEA sentences here? I think I am likely seeing some form of binary stream, so your idea that something is setting the gps in a non nmea mode makes sense.
I also removed and re-inserted the usb gps and it keeps coming back to /dev/ttyACM0 in my setup.
Yup, you should see nice clean NMEA sentences something like this:
Maybe more numerous and faster, but definitely like that. Each time you plug the device back in, are you seeing gpsd starting up somehow and are you having to kill it off?
May have to get gpsd completely (apt) uninstalled to make it stop (?). Also, do you know the exact make and model of your NEO-7 device? We could then research how to make sure it is in normal NMEA/Serial mode. The most likely baud rate is probably 9600.
Ok thanks. My device is a usb U-Blox 7
I will uninstall gpsd and reboot to see if I can fix it. that way.
Edit:
That worked - with gpsd apt removed - screen now shows gps NMEA sentences.
My plan is to reboot and get kplex and sfh running and see if we can upload to the server.
Fingers crossed!
ok, small issue - now port 10110 seems to be in use which is causing kplex to fail:
lazydays@raspberrypi:~ $ sudo kplex -d 9
kplex DEBUG: Using config file /etc/kplex.conf
kplex DEBUG: kplex starting, config file /etc/kplex.conf
kplex DEBUG: _serial-id1: opened serial device /dev/ttyACM0 for input
Failed to open tcp server for (null)/10110: Address already in use
Failed to initialize Interface _tcp-id2
kplex DEBUG: Cleaning up data for exiting input interface _serial-id1 id 10000
You don’t want kplex running at all at this point. Not sfh, not gpsd, and not kplex. Just screen to talk directly to the serial device at /dev/ttyACM0
Ok got it - thanks.
I managed to get a good stream of NMEA from the screen command.
All good now with the gps. It was indeed gpsd taking control somehow after boot. That was fixed by the apt remove steps.
Now I have kplex running successfully along with sfh. I just put the unit outside to get good gps signal and FloatHub just messaged me that the boat position (anchor alarm) had moved. All good - we are fully up and running.
Thanks for the rapid responses and your patience in getting my issue resolved!
Much appreciated
Cheers
Rich
All’s well that ends well
Glad this is here on the forums so that other users with similar issues will have access to the debugging steps.
Almost hesitate to mention it, but there is probably a way to have gpsd and kplex talk nicely with each other. Essentially you let gpsd talk to the gps hardware over serial (generally in binary format), and then have kplex talk only to gpsd (not directly to the gps serial device). The only reason you would want to do this is if there is some feature of gpsd you want access to use that kplex does not provide.