Navilock NL 302U does not work about gps-share HOT 20 OPEN

To summarise two issues here:

• The assumed baudrate of 38400 isn't correct for device in question.
• For some reason the data from the port is consistently invalid UTF-8 and we assume the data to be UTF-8.

@nineff Could you kindly also check what you get on minicom (or some other terminal handler)?

from gps-share.

Sure. I'm getting pretty garbeled stuff:

Willkommen zu minicom 2.7.1

Optionen: I18n 
Übersetzt am Apr 20 2017, 07:07:53.
Port /dev/ttyUSB1, 15:32:21

Drücken Sie CTRL-A  Z für Hilfe zu speziellen Tasten
������)������-�ݗ����            y�`��а��������-�k����N�ݪ�����󹰳��4��Q��Q��Q��Q��Q

And so on.

But the device is working with GPSD, so it's not a faulty connection etc. just some encoding problem

from gps-share.

Thanks. If you made sure the terminal settings (baudrate, stop bits etc) are correctly set?

from gps-share.

I set the baudrate to 4800 but I can't find stopbits in the "documentation" so i left them as default

from gps-share.

Is there a way to log the communication between the service and the device? the data might be helpfull, as will be analyzing the commands sent by GPSD.

from gps-share.

After some googling I found quite a few similar issues with the used prolific serial adapter inside the NL302U, so I followed all suggestions including testing all baud-rates even if the manual specifies otherwise, with now success.
The output does however vary with baud-rate.
I'll try analyzing the raw packets using an oscilloscope to find out which speed GPSD uses. This might be hidden somewhere in a config file or google-able, but actually measuring it seems more fun.

from gps-share.

Interesing! Any luck so far? Does it give ASCII at any baudrate/setting?

from gps-share.

Unfortunately no luck so far, I can't get my logic analyzer to work and my oscilloscope can't decode USB, but if I was reeeeally bored, I could look at every single bit sent...

from gps-share.

If you manage to make it work with gpsd, getting a verbose output will likely yield that elusive information.

from gps-share.

well it's definitively the manufacture specified 4800 baud:

sudo gpsctl /dev/ttyUSB0 -f
/dev/ttyUSB0 identified as a SiRF at 4800 baud.

But I don't know why I'm getting garbled strings in just about any terminal (I tried minicom, telnet, screen and putty) while GPSd can handle it

from gps-share.

At a guess, gps-share doesn't support SiRF, which is a binary protocol. Not NMEA.

Looks like this one on Amazon.de also uses the protocol.
https://www.amazon.de/Navilock-NL-442U-USB-Empf%C3%A4nger-SiRFstarIV/dp/B00AU0G838/

Zeeshan, add this to your wishlist ;)

from gps-share.

Haha, URL to amazon.DE was very thoughtful. Thanks. 😊

from gps-share.

@nineff, the chipseet supports NMEA but it may not be the default mode depending on your OEM. The output you show indicate it’s using a proprietary driver. You can most likely switch the output mode to NMEA from the Windows management software. This may be useful: http://www.varioskin.de/ComPort-Baudrate_fur_Gopal_3_anpassen.pdf (instructions may vary for your specific device, but these seem like the same as for my u-blox8m chipset.) Remember to save the configuration to nvram on the device and not just change the runtime configuration.

Don’t ask me how you can switch output mode from Linux. I couldn’t figure it out for my own u-blox8m based device either and had to resolve to using the Windows management tool to configure it.

from gps-share.

Thanks for the tip! I was sent down quite a rabbit-hole to find old Sirf software since the company has been acquired by Qualcomm.

However I found the SiRFDemo software here:
http://gps.0xdc.ru/static/sirf/soft/win32/sirflive/

And the ReferenceManuals here:
https://www.sparkfun.com/datasheets/GPS/NMEA%20Reference%20Manual-Rev2.1-Dec07.pdf
http://usglobalsat.com/downloads/SiRF_Binary_Protocol.pdf

It specifically addresses switching the protocols around in section 100—SetSerialPort. So I thing it should be doable under Linux as well, however I have not looked into it.

Also quit interestingly, the bitrate seems to be changeable and not limited to 4800 baud. In fact, the Software has a "sync protocoll and baudrate" option, which results in 57600 baud.

from gps-share.

I had a look at the spec and if I understood correctly, it allows you to switch to NMEA mode and I've that on my to-do. I also have the device so it'll hopefully happen at some point.

from gps-share.

At the Berlin Rust Hack & Learn event yesterday, I looked into this a bit. My first issue was finding the baudrate and I'm still not sure what's the default. But I didn't spend much time on that one. I spent more time checking why gps-share can't read from the port at all at any baudrate. The issue is that currently gps-share expects to always read string lines from the device and hence it blocks waiting so i've a WIP patch to solve that in wip/sirf branch now. I'll see when I can find time again to work on this..

from gps-share.

I stumbled upon this issue and see it's still unresolved. Just some notes from trying to get it working somehow:

• gpsd has implemeted a way to switch from SiRF to NMEA mode; you can switch with gpsctl -n /dev/ttyUSB0 while gpsd is running (tested)
• I found some documentation about switching from SiRF to NMEA here: NAVMAN SiRF Binary Protocol Reference Manual
• There's a proof-of-concept implementation in Python available: Mister Muffin Blog - sirf/nmea protocol switch
• To change to NMEA mode, you need to set the speed to 9600 Baud
• For reading the NMEA data, I had to set the speed to 4800 Baud
• After switching to NMEA mode and setting the speed to 4800 (stty -F /dev/ttyUSB0 ispeed 4800), I could read valid NMEA data from /dev/ttyUSB0 f.ex. via tail -f /dev/ttyUSB0 as well as via gps-share -b 4800 /dev/ttyUSB0

EDIT: Sometimes the output is prepended by some unreadable output - in this case, gps-share throws a "Failed to read from serial port: stream did not contain valid UTF-8". Example:

❯ tail -f /dev/ttyUSB0
��Ά6&��F��&66��cvF��&�F�Vc�F�6�V�&fF�F��cFv���c��Vk
$GPGSA,...

from gps-share.

@Kareema0 Thanks so much for the info. Not sure when I'll get to this (if at all). :)

from gps-share.

@zeenix The Navilock NL 302U is a rather old hardware, so it's probably not that much in use any more. I just had it at my disposal for testing and wanted to document here, what I found out. This is partly for myself as a reference, if I should find the time to take a look at your wip/sirf branch :-)

from gps-share.

I experience the same issue with a USB GBS based on the more recent ublox 7, which is still on sale in many outlets.

$ udevadm info /dev/gps0
P: /devices/pci0000:00/0000:00:15.0/usb1/1-2/1-2:1.0/tty/ttyACM0
N: ttyACM0
L: 0
S: gps0
S: serial/by-path/pci-0000:00:15.0-usb-0:2:1.0
S: serial/by-id/usb-u-blox_AG_-_www.u-blox.com_u-blox_7_-_GPS_GNSS_Receiver-if00
E: DEVPATH=/devices/pci0000:00/0000:00:15.0/usb1/1-2/1-2:1.0/tty/ttyACM0
E: DEVNAME=/dev/ttyACM0
E: MAJOR=166
E: MINOR=0
E: SUBSYSTEM=tty
E: USEC_INITIALIZED=8205816
E: [email protected]
E: ID_BUS=usb
E: ID_VENDOR_ID=1546
E: ID_MODEL_ID=01a7
E: ID_PCI_CLASS_FROM_DATABASE=Serial bus controller
E: ID_PCI_SUBCLASS_FROM_DATABASE=USB controller
E: ID_PCI_INTERFACE_FROM_DATABASE=XHCI
E: ID_VENDOR_FROM_DATABASE=U-Blox AG
E: ID_MODEL_FROM_DATABASE=[u-blox 7]
E: ID_VENDOR=u-blox_AG_-_www.u-blox.com
E: ID_VENDOR_ENC=u-blox\x20AG\x20-\x20www.u-blox.com
E: ID_MODEL=u-blox_7_-_GPS_GNSS_Receiver
E: ID_MODEL_ENC=u-blox\x207\x20-\x20GPS\x2fGNSS\x20Receiver
E: ID_REVISION=0100
E: ID_SERIAL=u-blox_AG_-_www.u-blox.com_u-blox_7_-_GPS_GNSS_Receiver
E: ID_TYPE=generic
E: ID_USB_INTERFACES=:020201:0a00ff:
E: ID_USB_INTERFACE_NUM=00
E: ID_USB_DRIVER=cdc_acm
E: ID_USB_CLASS_FROM_DATABASE=Communications
E: ID_PATH=pci-0000:00:15.0-usb-0:2:1.0
E: ID_PATH_TAG=pci-0000_00_15_0-usb-0_2_1_0
E: ID_MM_CANDIDATE=1
E: ID_FOR_SEAT=tty-pci-0000_00_15_0-usb-0_2_1_0
E: ID_MM_DEVICE_IGNORE=1
E: DEVLINKS=/dev/gps0 /dev/serial/by-path/pci-0000:00:15.0-usb-0:2:1.0 /dev/serial/by-id/usb-u-blox_AG_-_www.u-blox.com_u-blox_7_-_GPS_GNSS_Receiver-if00
E: TAGS=:seat:uaccess:systemd:
E: CURRENT_TAGS=:seat:uaccess:systemd:

However, running gpsd and setting the GPS to NMEA output with gpsctl -n /dev/gps0 did the trick for me. Remember to stop the default gpsd service after setting this using sudo systemctl stop gpsd. I also had to briefly unplug the GPS to get a reset.

Anyhow, it is crazy what one has to do to get a simple USB GPS working with geoclue. It is obvious that geoclue was commissioned by mobile phone manufacturers. One better gets a system with a 4G modem GPS onboard...

from gps-share.