On Thu, May 30, 2013 at 04:00:17PM +0200, Ben Adler wrote: > Hello list! > > I'm using a > http://www.septentrio.com/products/receivers/asterx2i-oem INS/GNSS > receiver. When connected via USB to a windows-host, there's two (or > even three, don't remember exactly) virtual serial ports to talk to > it. Why do you want to talk to the other ports? What is on those connections? > When connected to a 3.8.0-19-generic #30-Ubuntu SMP i686 GNU/Linux > system, I only see /dev/ttyACM0. I'd really like to get access to > the second virtual com port, so I tried setting Why? > options usbserial vendor=0x152a product=0x8230 Ick, no, don't do that. It's an acm device, use the correct driver for it. > usbserial_generic 3-2:1.0: Generic device with no bulk out, not > allowed. > > > usbserial_generic: probe of 3-2:1.0 failed with error -5 Exactly, it's not a "normal" generic usb serial device :) > usb 3-2: generic converter now attached to ttyUSB0 > > ttyUSB0 does work for communicating with the device, but there's no > second port (this trick did work with some NovAtel receivers). > > Is there a way to make the other virtual COM port appear? > > # lsusb -d 152a:8230 -v > > Bus 003 Device 002: ID 152a:8230 > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 1.10 > bDeviceClass 2 Communications > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 8 > idVendor 0x152a > idProduct 0x8230 > bcdDevice 1.10 > iManufacturer 1 Septentrio > iProduct 2 Septentrio USB Device > iSerial 0 > bNumConfigurations 2 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 91 > bNumInterfaces 4 > bConfigurationValue 2 > iConfiguration 0 > bmAttributes 0xc0 > Self Powered > MaxPower 2mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 0 > bAlternateSetting 0 > bNumEndpoints 0 > bInterfaceClass 2 Communications > bInterfaceSubClass 2 Abstract (modem) > bInterfaceProtocol 255 Vendor Specific (MSFT RNDIS?) > iInterface 0 > CDC Header: > bcdCDC 1.01 > CDC ACM: > bmCapabilities 0x0e > connection notifications > sends break > line coding and serial state > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 1 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 10 CDC Data > bInterfaceSubClass 0 Unused > bInterfaceProtocol 255 Vendor specific > iInterface 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x01 EP 1 OUT > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0040 1x 64 bytes > bInterval 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x82 EP 2 IN > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0040 1x 64 bytes > bInterval 0 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 2 > bAlternateSetting 0 > bNumEndpoints 0 > bInterfaceClass 2 Communications > bInterfaceSubClass 2 Abstract (modem) > bInterfaceProtocol 255 Vendor Specific (MSFT RNDIS?) > iInterface 0 > CDC Header: > bcdCDC 1.01 > CDC ACM: > bmCapabilities 0x0e > connection notifications > sends break > line coding and serial state > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 3 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 10 CDC Data > bInterfaceSubClass 0 Unused > bInterfaceProtocol 255 Vendor specific > iInterface 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x04 EP 4 OUT > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0040 1x 64 bytes > bInterval 1 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x85 EP 5 IN > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0040 1x 64 bytes > bInterval 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 62 > bNumInterfaces 2 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0xc0 > Self Powered > MaxPower 2mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 0 > bAlternateSetting 0 > bNumEndpoints 1 > bInterfaceClass 2 Communications > bInterfaceSubClass 2 Abstract (modem) > bInterfaceProtocol 1 AT-commands (v.25ter) > iInterface 0 > CDC Union: > bMasterInterface 0 > bSlaveInterface 1 > CDC Header: > bcdCDC 1.01 > CDC ACM: > bmCapabilities 0x0e > connection notifications > sends break > line coding and serial state > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x83 EP 3 IN > bmAttributes 3 > Transfer Type Interrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0040 1x 64 bytes > bInterval 1 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 1 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 10 CDC Data > bInterfaceSubClass 0 Unused > bInterfaceProtocol 0 > iInterface 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x01 EP 1 OUT > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0040 1x 64 bytes > bInterval 1 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x82 EP 2 IN > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0040 1x 64 bytes > bInterval 1 > Device Status: 0x0001 > Self Powered > > Even though I don't really understand the interfaces and endpoints, > I get the impression there's multiple CDC-Data interfaces. Yes, there are, but the cdc-acm driver binds to them all (you can see this by running 'usbdevices' from the usbutils package. > How can I use them? The network should connect to the device just fine through the single port, right? > Also, is there a way to influence the latency? As I'm using the > receiver's data for flight control, I'd prefer to achieve low > latency in data transfer from receiver->host on at least one port. I > see the Transfer Type for most endpoints is bulk, not interrupt, but > maybe there's a few tricks to make bulk-transfers faster? Right now > I'm seeing latencies between 5 and 70ms. There is no difference in "speed" or "latency" between the bulk and interrupt endpoints, it just is how the data is transferred from the USB device (they really are the same, just that interrupt is smaller packets more often, and bulk is larger packets whenever there is some data.) USB devices are well known for having latency issues, that's due to the cheap chip in them, plus the usb protocol overhead, plus whatever is on the other side of the USB device sending data. It almost never is the host OS issue here. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
