USB GPS Receiver - Mobile Action i-gotU GT-120

melodic

melodic

Hi All,

I have a USB GPS data logger which when plugged in can be used as a GPS receiver via a USB serial interface. I've tested this on linux and the kernel there automatically recognises the device and ends up creating /dev/ttyUSB0 which I can then use gpsd to view the data.

This is the relevant output from dmesg on linux for the receiver
Code: 
[  120.332920] usb 1-1.2: new full-speed USB device number 6 using dwc_otg
[  120.468484] usb 1-1.2: New USB device found, idVendor=0df7, idProduct=0900
[  120.468512] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  120.468522] usb 1-1.2: Product: i-gotU
[  120.468532] usb 1-1.2: Manufacturer: Mobile Action
[  120.600987] usbcore: registered new interface driver usbserial
[  120.601125] usbcore: registered new interface driver usbserial_generic
[  120.601251] usbserial: USB Serial support registered for generic
[  120.613620] usbcore: registered new interface driver navman
[  120.613709] usbserial: USB Serial support registered for navman
[  120.613796] navman 1-1.2:1.0: navman converter detected
[  120.620031] usb 1-1.2: navman converter now attached to ttyUSB0

This is what I was getting on FreeBSD 12-RELEASE
Code: 
ugen0.5: <Mobile Action i-gotU> at usbus0

I found some mention of patching the uplcom.ko in my reasarch so I took the output of
Code: 
usbconfig -d 0.5 dump_all_desc
and patched uplcom.ko

Code: 
ugen0.5: <Mobile Action i-gotU> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA)

  bLength = 0x0012
  bDescriptorType = 0x0001
  bcdUSB = 0x0101
  bDeviceClass = 0x0000  <Probed by interface class>
  bDeviceSubClass = 0x0000
  bDeviceProtocol = 0x0000
  bMaxPacketSize0 = 0x0008
  idVendor = 0x0df7
  idProduct = 0x0900
  bcdDevice = 0x0000
  iManufacturer = 0x0001  <Mobile Action>
  iProduct = 0x0002  <i-gotU>
  iSerialNumber = 0x0000  <no string>
  bNumConfigurations = 0x0001

Configuration index 0

    bLength = 0x0009
    bDescriptorType = 0x0002
    wTotalLength = 0x0019
    bNumInterfaces = 0x0001
    bConfigurationValue = 0x0001
    iConfiguration = 0x0003  <0000000>
    bmAttributes = 0x00a0
    bMaxPower = 0x0032

    Interface 0
      bLength = 0x0009
      bDescriptorType = 0x0004
      bInterfaceNumber = 0x0000
      bAlternateSetting = 0x0000
      bNumEndpoints = 0x0001
      bInterfaceClass = 0x00ff  <Vendor specific>
      bInterfaceSubClass = 0x0000
      bInterfaceProtocol = 0x0000
      iInterface = 0x0000  <no string>

     Endpoint 0
        bLength = 0x0007
        bDescriptorType = 0x0005
        bEndpointAddress = 0x0081  <IN>
        bmAttributes = 0x0003  <INTERRUPT>
        wMaxPacketSize = 0x0010
        bInterval = 0x0001
        bRefresh = 0x0000
        bSynchAddress = 0x0000

I've then recompiled the uplcom.ko module adding the following lines to:

/usr/src/sys/dev/usb/serial/uplcom.c
Code: 
UPLCOM_DEV(MOBILEACTION, GT120),        /* Mobile Action GT120 GPS Receiver*/

/usr/src/sys/dev/usb/usbdevs
Code: 
product MOBILEACTION GT120                0x0900  GT120 GPS Receiver

loading this newly patched module into my kernel still doesn't give me any joy but dmesg has a little more information now:

Code: 
ugen0.5: <Mobile Action i-gotU> at usbus0
uplcom0 on uhub1
uplcom0: <Mobile Action i-gotU, class 0/0, rev 1.01/0.00, addr 5> on usbus0
device_attach: uplcom0 attach returned 6

Any clues where I should look next to try and get this device supported? I've searched for 'navman' for FreeBSD but I can't find any references to this in the source code or anywhere when searching. Not sure if it matters but this is running on a Raspberry Pi 3 (arm64).

Any help is greatly appreciated thanks,

melodic
 
Try loading ucom(4), you may not need to edit anything if it's a "standard" USB serial interface.
 
I knew I had forgotten something in my post! The other modules I had loaded to test! I had already loaded ucom and unfortunately the behaviour doesn't change.
 
Do you have any idea what they used for USB->Serial? There are several different (hardware) implementations, hence the quotes around "standard". Another common USB->serial chipset is FTDI; uftdi(4).
 
Unfortunately I don't, no. I've just tried the FTDI module and there's no difference in the behaviour of the receiver getting detected. I wonder if it's worth looking through the linux kernel code for the references to this device. Would that be beneficial to my quest for FreeBSD support?
 
Looking at the Linux driver might give an idea which USB-to-serial chipset they may have used. As I said, there are several different chipsets that could be used. Our FreeBSD driver might still not recognize that particular device but at least we'll know which driver we would need to fix.
 
Right so have gone simple and cracked the receiver open to view the chips inside and read their data sheets and I can see two on one side of the board:

Sonix SN8P2213 - http://www.kodec.com/sn8p_tool/datasheet/SN8P2213_V1.3_EN.pdf
MX 25L1605DM2I - https://pdf1.alldatasheet.com/datasheet-pdf/view/267910/MCNIX/MX25L1605DM2I-12G.html - Looks to be the Flash Memory

I think the Sonix chip is the one performing the serial/usb connection but I'm unable to see what kind of serial it uses in the data sheet.

Thank you for all your help so far SirDice :)

edit: I'm not a developer but looking at how linux is doing this I believe they have a specific driver in their kernel just for this device and one other;

github.com

linux/drivers/usb/serial/navman.c at master · torvalds/linux

Linux kernel source tree. Contribute to torvalds/linux development by creating an account on GitHub.
github.com github.com

Code: 
static const struct usb_device_id id_table[] = {
    { USB_DEVICE(0x0a99, 0x0001) },    /* Talon Technology device */
    { USB_DEVICE(0x0df7, 0x0900) },    /* Mobile Action i-gotU */
    { },
};

The second device matches my device ID's exactly.

I'm not sure how to proceed now :(
 
melodic said:
I think the Sonix chip is the one performing the serial/usb connection but I'm unable to see what kind of serial it uses in the data sheet.
Click to expand...
It's a small 8 bit microcontroller. These things can be programmed to do just about anything. And it looks like it has its own USB connections (Chapter 9 of the datasheet). It looks like it's not presenting itself as a serial device but as a generic USB HID device. That would also explain why Linux has specific drivers for the device.
 
You must log in or register to reply here.
Back
Top