Navilock NL 302U does not work

[nineff]

The device: http://www.navilock.de/produkte/F_778_GPS_61422/merkmale.html?setLanguage=en

The Udev Output:

udevadm info /dev/ttyUSB0 
P: /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/ttyUSB0/tty/ttyUSB0
N: ttyUSB0
S: gps0
S: serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0
S: serial/by-path/pci-0000:00:1a.0-usb-0:1.2:1.0-port0
E: DEVLINKS=/dev/gps0 /dev/serial/by-path/pci-0000:00:1a.0-usb-0:1.2:1.0-port0 /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0
E: DEVNAME=/dev/ttyUSB0
E: DEVPATH=/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/ttyUSB0/tty/ttyUSB0
E: ID_BUS=usb
E: ID_MM_CANDIDATE=1
E: ID_MODEL=USB-Serial_Controller
E: ID_MODEL_ENC=USB-Serial\x20Controller
E: ID_MODEL_FROM_DATABASE=PL2303 Serial Port
E: ID_MODEL_ID=2303
E: ID_PATH=pci-0000:00:1a.0-usb-0:1.2:1.0
E: ID_PATH_TAG=pci-0000_00_1a_0-usb-0_1_2_1_0
E: ID_PCI_CLASS_FROM_DATABASE=Serial bus controller
E: ID_PCI_INTERFACE_FROM_DATABASE=EHCI
E: ID_PCI_SUBCLASS_FROM_DATABASE=USB controller
E: ID_REVISION=0300
E: ID_SERIAL=Prolific_Technology_Inc._USB-Serial_Controller
E: ID_TYPE=generic
E: ID_USB_DRIVER=pl2303
E: ID_USB_INTERFACES=:ff0000:
E: ID_USB_INTERFACE_NUM=00
E: ID_VENDOR=Prolific_Technology_Inc.
E: ID_VENDOR_ENC=Prolific\x20Technology\x20Inc.
E: ID_VENDOR_FROM_DATABASE=Prolific Technology, Inc.
E: ID_VENDOR_ID=067b
E: MAJOR=188
E: MINOR=0
E: SUBSYSTEM=tty
E: SYSTEMD_WANTS=gpsdctl@ttyUSB0.service
E: TAGS=:systemd:
E: USEC_INITIALIZED=520043777

lsusb:

Bus 001 Device 006: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port

Terminal Output:

# ./gps-share -b 4800
Attempting to autodetect GPS device...
/dev/ttyUSB0 seems interesting
Needs verification
Reading from port..
Failed to read from serial port
Reading from port..
Failed to read from serial port
Not verified
Failed to autodetect GPS device

Specifying device and connecting via telnet:

# ./gps-share /dev/ttyUSB0 -b 4800
TCP server bound on all interfaces
Port: 37391
group: /Client2/EntryGroup1
Connection from 127.0.0.1
Failed to read from serial port: stream did not contain valid UTF-8
Failed to read from serial port: stream did not contain valid UTF-8
Failed to read from serial port: stream did not contain valid UTF-8 ...

[zeenix]

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)?

[nineff]

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
QQQQQ

And so on.

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

[zeenix]

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

[nineff]

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

[nineff]

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.

[nineff]

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.

[zeenix]

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

[nineff]

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...

[hadess]

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

[nineff]

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

[hadess]

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 ;)

[zeenix]

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

[da2x]

@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.

[nineff]

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.

[zeenix]

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.

[zeenix]

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..

[Kareema0]

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,...

[zeenix]

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

[Kareema0]

@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 :-)

[stroobandt]

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: SYSTEMD_WANTS=gpsdctl@ttyACM0.service
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...