On Mon, Jun 10, 2013 at 06:56:30PM +0200, Ben Adler wrote: > Hello Greg, > > thanks for getting back to me! > > >>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? > > They're all serial ports, used to issue commands to the receiver (in > binary or ascii form) and receive data at different intervals > (again, binary or ascii). Which messages exactly are accepted or > sent on which (virtual) port at which interval can be configured. That's not what the USB device descriptors you provided below show. They look like a "normal" cdc-acm device, so we are (according to the USB-IF specification), supposed to export to userspace a single device that can be used to communicate with it. > >> 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? > > These receivers are rather complex systems and use of multiple > (virtual) serial ports is often necessary. For example, to use a > very precise positioning mode like differential GPS or even RTK > (Real-Time-Kinematic GPS), differential correction data has to be > streamed to the receiver (from another, stationary GNSS receiver). > This MUST be done on a separate port, because otherwise the receiver > is unable to discriminate command input from differential correction > input. Odd, that's not what a cdc-acm device is supposed to be for, but oh well :) But, again, the device isn't exposing multiple devices to the operating system at all, that must be something Windows is doing with a custom driver for the device. > It also is often convenient to access the same receiver from > multiple processes using different ports. Multiple processes can access the same device port just fine, that's how they should always work (although if you are doing command/response type things, it can get messy with multiple applications.) > In essence, I'd simply like to be able to use any or all of > /dev/ttyACM* to talk to the device. You are getting the "one" port to talk to the device properly already, but it seems it is lying to the OS about what it really is :( > >> [lsusb output] > >>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. > > T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 > D: Ver= 1.10 Cls=02(commc) Sub=00 Prot=00 MxPS= 8 #Cfgs= 2 > P: Vendor=152a ProdID=8230 Rev=01.10 > S: Manufacturer=Septentrio > S: Product=Septentrio USB Device > C: #Ifs= 2 Cfg#= 1 Atr=c0 MxPwr=2mA > I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=02 Prot=01 Driver=cdc_acm > I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_acm > > I can confirm :) How can this be changed? > > >>How can I use them? > > > >The network should connect to the device just fine through the single > >port, right? > > I don't understand, which network are you referring to? There is no > network connection for this device. Ok, my mistake, I thought this was a network device. You're going to have to possibly unbind the cdc-acm driver from the device, and either talk directly to it using libusb, or write a custom kernel driver to expose the different "ports" properly. I would suggest contacting the company to get the specs on how to talk to the device in order to be able to do this. > >>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. > > Thanks for the explanation! Meanwhile I've also realized that 95% of > the packets I receive are exactly 60 bytes in length, and sometimes > (not always) I see latencies similar to this (in milliseconds): > > 34 6 44 5 51 8 20 7 > > So I could also imagine that there is a buffer (probably of > 61<size<119 bytes) that only gets flushed once its full. Is there, > by any chance, a 64 byte buffer in the cdc_acm module or linux USB > code? Not that I can see, odds are the buffering is in the device itself, that's quite common for USB devices (very low processor speeds / logic). Sorry, 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
