Hi Johan, I apologize for the extreme delay in replying to your latest message. I was considering approaching this an entirely different way and have since returned to submitting the request directly to you. As such, I will now address each of your questions. -- Q1. Do your products support other serial interfaces as well (e.g. UART or i2c)? -- Our USB interface offers 3 virtual UARTs that can be used a serial ports. All of our products also can be interfaced to using RS232 and many offer Ethernet, Wifi and CAN support. But all that I think is relevant for adding support to the kernel is the USB virtual serial ports. -- Q2. As Oliver mentioned it would be useful to know what USB-serial converter chip you use in the device, if any, or of this is a custom implementation. -- As far as I am aware, this is our own implementation. Our Windows driver's have a mention in their configuration about a 16550 compatible UART, however I'm not certain if that is relevant. For your purposes. -- Q3. Since 4.19 we actually have GNSS subsystem in the kernel, which if we implement a driver for your devices would show up as /dev/gnssN with an associated attribute describing the GNSS type (reflecting the supported protocol, e.g. NMEA, UBX or SiRF). What protocols do your devices use (besides NMEA)? Do use any common GNSS receivers chips, or do you have your own? -- That's very interesting! The GNSS chips used are our own. Out of the box our receivers communicate using our own protocol. Users can send proprietary binary or ASCII messages, which are our own standard format that has been used for decades. This "NOVATEL" protocol is well-documented online. Our serial communication ports can be reconfigured to comply with various other formats, the list is quite long. You can see the full set of supported protocols at the following page under the title "Serial Port Interface Modes": https://docs.novatel.com/OEM7/Content/Commands/INTERFACEMODE.htm? -- Q4. What are the three ports used for, or is that configurable? -- Our ports are highly configurable by the user. Some users will only ever use one port. While others will configure some ports to specific dedicated uses such as for configuration or logging different formats of GNSS, Timing, and INS type data records. -- Q5. Depending a bit on your answers to the above questions, we could also add your VID/PID to a USB-serial driver, which would give you ttyUSBN devices without any need to mess with modprobe. -- This is all I was hoping we could get done here. So, "yes please!". Here's a tiny bit more context for you - When our Linux users ask us how to configure their Linux machines to recognize our receivers over USB, we typically ask them to the following: 1. Create the file /etc/udev/rules.d/z90_novatel.rules 2. Paste in these lines: SUBSYSTEM=="usb", SYSFS{idProduct}=="0100", SYSFS{idVendor}=="09d7", PROGRAM="/sbin/modprobe usbserial vendor=0x09d7 product=0x0100" BUS=="usb", SYSFS{idProduct}=="0100", SYSFS{idVendor}=="09d7", SYSFS{product}=="NovAtel GPS Receiver", SYSFS{manufacturer}=="NovAtel Inc.", SYMLINK+="gps%n" This doesn't work for every distro, but most. Another approach that can work is to simply enter this in to the shell: echo '09d7 0100' > /sys/bus/usb-serial/drivers/generic/new_id Does this satisfy your questions? Thank you very much. Best regards, James Snell -----Original Message----- From: Johan Hovold <jhovold@xxxxxxxxx> On Behalf Of Johan Hovold Sent: Monday, November 12, 2018 4:00 AM To: SNELL James <James.Snell@xxxxxxxxxxx> Cc: linux-usb@xxxxxxxxxxxxxxx Subject: Re: Adding NovAtel USB vendor & device ID to Kernel On Thu, Nov 08, 2018 at 01:07:47AM +0000, SNELL James wrote: > Hello, > We produce extremely high-end GNSS (GPS, etc) receivers that are often > used for a very wide range of applications. Our receivers can be > connected to via USB, which will provide 3 USB-to-serial ports that > can be used to issue commands and get receiver data. Do your products support other serial interfaces as well (e.g. UART or i2c)? > We typically get Linux users to create a udev file so their systems > attach the USB serial ports to /dev. > > I just noticed that when my receiver enumerates, dmesg outputs: > [ 414.374523] usb 1-1.1.3: new full-speed USB device number 8 using > dwc_otg [ 414.508473] usb 1-1.1.3: New USB device found, > idVendor=09d7, idProduct=0100 [ 414.508488] usb 1-1.1.3: New USB > device strings: Mfr=1, Product=2, SerialNumber=3 [ 414.508497] usb > 1-1.1.3: Product: NovAtel GPS Receiver [ 414.508505] usb 1-1.1.3: Manufacturer: NovAtel Inc. > [ 414.508514] usb 1-1.1.3: SerialNumber: DMGW18050122R [ 414.511608] > usbserial_generic 1-1.1.3:1.0: The "generic" usb-serial driver is only for testing and one-off prototypes. > [ 414.511624] usbserial_generic 1-1.1.3:1.0: Tell mailto:linux-usb@xxxxxxxxxxxxxxx to add your device to a proper driver. > [ 414.511636] usbserial_generic 1-1.1.3:1.0: generic converter > detected [ 414.512004] usb 1-1.1.3: generic converter now attached to > ttyUSB0 [ 414.512352] usb 1-1.1.3: generic converter now attached to > ttyUSB1 [ 414.512805] usb 1-1.1.3: generic converter now attached to > ttyUSB2 > # lsusb -s 001:008 -v > I think it would be "nice" if our receiver's USB-delivered serial > ports attached to /dev as /dev/novatel0, .. /dev/novatelN or > (/dev/gnss0 .. /dev/gnssN). Though if they continued to appear as > /dev/ttyUSB0 .. /dev/ttyUSBN, that'd also be great. As Oliver mentioned it would be useful to know what USB-serial converter chip you use in the device, if any, or of this is a custom implementation. Since 4.19 we actually have GNSS subsystem in the kernel, which if we implement a driver for your devices would show up as /dev/gnssN with an associated attribute describing the GNSS type (reflecting the supported protocol, e.g. NMEA, UBX or SiRF). What protocols do your devices use (besides NMEA)? Do use any common GNSS receivers chips, or do you have your own? What are the three ports used for, or is that configurable? > I'm not entirely sure if the dmesg output that's directed me here is > really intended for this sort of request. If not, I'm willing to make > my own git merge request, though I've not toyed much with the Linux > Kernel, so tips would be extremely appreciated. > > Can we please get our Vendor ID (0x09d7) and Product ID (0x0100) added > to the Kernel in a sensical manner? Depending a bit on your answers to the above questions, we could also add your VID/PID to a USB-serial driver, which would give you ttyUSBN devices without any need to mess with modprobe. > The information contained in this e-mail may contain confidential or > privileged material and is intended only for the stated addressee(s). > If you are not a valid addressee, the use, disclosure, copying or > distribution of this information is prohibited and may be unlawful. > If you have received this message in error, please notify the sender > immediately and delete all copies of the message from your computer. > Notwithstanding any applicable legislation which may provide for > contracts to be formed from electronic communication, this email does > not create, form part of, or vary any contract, nor is it otherwise > intended to bind any Hexagon group company. You need to remove this footer when dealing with the mailing lists, though. Thanks, Johan
