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.
>> 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.
It also is often convenient to access the same receiver from multiple
processes using different ports.
In essence, I'd simply like to be able to use any or all of /dev/ttyACM*
to talk to the device.
>> [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.
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?
cheers,
ben
--
Ben Adler
Universität Hamburg
MIN-Fakultät
FB Informatik, AB TAMS
Vogt-Kölln-Strasse 30
22527 Hamburg
Tel +49 40 42883 2504
Fax +49 40 42883 2397
Mob +49 160 858 0660
--
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
