search

zeenix / gps-share

Utility to share your GPS device on local network
GNU General Public License v2.0
69 stars 9 forks source link

Navilock NL 302U does not work #3

Open nineff opened 7 years ago

nineff commented 7 years ago

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 commented 7 years ago

To summarise two issues here:

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

nineff commented 7 years ago

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ݪ����󹰳��4QQQQQ

And so on.

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

zeenix commented 7 years ago

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

nineff commented 7 years ago

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

nineff commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

nineff commented 7 years ago

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 commented 7 years ago

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

nineff commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

da2x commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 3 years ago

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

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 commented 3 years ago

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

Kareema0 commented 3 years ago

@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 commented 2 years ago

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

diodelass commented 1 month ago

@stroobandt I just ran into this issue today with a U-Blox Neo M8N, and the issue seems to have been that it was shooting both NMEA and UBX (U-Blox's proprietary protocol) into the port at once. UBX uses terse binary message formatting, which would be why it's causing invalid-UTF-8 issues.

From a fresh factory reset, my module seems to only output NMEA, and everything works, but as soon as I change anything (mainly enabling Galileo support, which is off by default), this issue consistently pops up. What fixed it was using the configuration tool to turn off UBX output. I'm using PyGPSClient, which has a convenient preset macro command to enable NMEA and disable UBX.

I'm curious if there's a straightforward way to separate NMEA sentences from other, non-textual data coming from the serial port, which would allow gps-share to avoid this issue without requiring the user to change their device configuration. I'm not very familiar with NMEA at all, but it does appear that gpsd is able to sort it out, since I've never had it complain about the NMEA stream being full of junk.