ttyUSB0 vs. ttyUSB1

[bgrattan]

This might be more of a linux question than wview but I thought I'd
throw it out since there has been some recent discussion about RS232
to USB converters.

From someone's earlier post, I purchased a couple ($12.45 each) of
Sewell SW-1301 RS232 to USB converters to use with my VP2 wireless
station and wview. They work great, are inexpensive, and are
recognized by the linux kernel. I'm running ubuntu 9.10 on a MSI Wind-
PC (also picked up from a post here). It all runs very well and
consumes very little power.

I have tried running xastir (a ham radio application) on the same box
using the second SW-1301 to connect to my TNC device. VP2 is ttyUSB0
and the TNC is ttyUSB1. All is well until I reboot for some reason or
another. At the reboot, it's a tossup as to which device becomes 0
and which 1. I'm not a linux whiz and have consulted with several who
are more familiar with the OS than I; and I have not been able to find
a solution to this random device assignment.

The work-around has been to first plug in the VP2, which becomes
ttyUSB0, followed by the TNC which then falls into the correct place.
This process eliminates the possibility of a remote reboot which I
would like to be able to use from time to time.

Just curious if anyone has run into the same problem? Any suggestions
for a solution, other than making the VP2 the only device on the linux
box?

Thanks. BG

[Mark S. Teel]

I think udev rules is a way to "alias" a device regardless of what
device name it comes up as. A quick Google yielded:
http://www.reactivated.net/writing_udev_rules.html

Maybe that will get you started.

Mark

> --
>
> You received this message because you are subscribed to the Google Groups "wview" group.
> To post to this group, send email to wv...@googlegroups.com.
> To unsubscribe from this group, send email to wview+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/wview?hl=en.
>
>
>

[jfiddler]

That's right. Device naming is kind of a crap-shoot, unless you make
it explicit, which you can do by using udev rules. Those rules allow
for considerable flexibility in how devices are named, created,
permissioned, etc., but they're quite easy to set up. The tutorial
that Mark pointed you towards is quite good, but it's rather old. In
particular, it relies on an older tool called udevinfo which no longer
exists on most systems. Use udevadm to accomplish exactly the same
tasks.

If you need help with this, send me a private message and I'll do what
I can. It's probably too far off-base for this board.

[Mark S. Teel]

I actually think that once you guys come up with a solution, a Google
groups page describing how it was done would be nice. I think other
folks will run into this too.

Mark

[Jim]

I've been doing something similar for quite a while. I like the
PL2302-based adapters, and I have two of them on my system. Since
they're identical and they don't have a serial number embedded in
them, I need to address it via some other means. What I chose to do
it on is the physical USB port its plugged into.

Here's the "cookbook" method I used:

1) plug in an adapter
2) run: dmesg |grep USB
You should see something like:
usb 1-1.2: new full speed USB device using orion-ehci and address 6
usb 1-1.2: pl2303 converter now attached to ttyUSB0
Note the part after usb (in this case, 1-1.2). In this example, I've
plugged it into a usb hub on a sheeva, so usb 1-1 is the first
physical port on the system, and .2 represents the second port on the
hub. In any case, this is the physical port you plugged into. Note
that if you move your USB hub into another USB port on your system
(assuming you have one; sheeva's don't), then that WILL change the
addressing. So, in this example, I'm running my serial adapter on usb
port 1-1.2.
3) go to /etc/udev/rules.d and edit a new file. I call mine 91-serial-
aliasees.rules
4) add a single like like this:
KERNEL=="ttyUSB*", ID=="1-1.2", SYSFS{product}=="USB-Serial
Controller", SYMLINK+="ttyUSB-weather"
This tells udev to add a symlink for ttyUSB-weather pointing to any
device created that is a ttyUSB and is on physical port 1-1.2 and is a
serial controller.
5) either reboot or tell udev to reload (udevadm control --reload-
rules).
6) insert your usb adapters in any order. The one that matches the ID
line above will always have the ttyUSB-weather symlink. Of course,
you can add more rules like that to the alias files for your other usb
adapters.

Note that this method will still result in the ttyUSB0 / ttyUSB1
assignments being somewhat arbitrary, but the symlinks will always
point to the right one (try it...unplug both adapters, then plug them
in the opposite order).

I've been using this successfully for about a year now, and it has
really helped. I would recommend labling the physical ports,
though....This method does require that the adapters always get
plugged into the respective ports.

--Jim

[Deborah]

I, too, use udev to give the USB serial device a fixed name.

My station is a Vantage Pro2 with USB datalogger. This datalogger
includes a Silicon Labs USB-to-UART chip.

I created the file /etc/udev/rules.d/45-vpro.rules on my Debian 5.0
system:

# Start file
# Vantage Pro USB (CP2101 UART)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60",
ATTRS{bcdDevice}=="0100", symlink+="vpro", OWNER="weather"
# End file

Now I can access the serial device at /dev/vpro. I've also set the
device to be owned by a weather user, because I run wview as that
user.

(I think that Davis is a bit cheap not changing the Vendor and Product
fields from the generic Silicon Labs ones. Also it's annoying that
they haven't assigned a serial number that I can match with a udev
rule. If I ever want to connect two USB dataloggers to the same
machine, they won't be distinguishable unless I use Jim's method of
matching individual ports.)

[Chris]

I don't know if this helps but I had similar issues with combinations
of USB>Serial adapters from various vendors and each being initialized
in a seemingly random order. I know udev is mentioned further in this
thread and this is probably the correct solution but I never pursued
it.

Instead I noted on Ubuntu 9.04/9.10 that the devices were always
uniquely identified in /dev/serial/by-id, e.g.

root@thepbx2:/usr/src/wview-5.10.3/rapidFirePatch1# ls -l /dev/serial/
by-id
total 0
lrwxrwxrwx 1 root root 13 2010-01-03 11:05 usb-9710_7720-if00-port0 -
> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 2010-01-03 11:05 usb-9710_7720-if00-port1 -
> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 2010-01-02 11:09 usb-
FTDI_FT232R_USB_UART_A4001mrb-if00-port0 -> ../../ttyUSB2
lrwxrwxrwx 1 root root 13 2010-01-02 11:09 usb-
Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 -> ../../
ttyUSB3
lrwxrwxrwx 1 root root 13 2010-01-02 11:09 usb-
Prolific_Technology_Inc._USB-Serial_Controller-if00_D-port0 -> ../../
ttyUSB4

The last 2 are identical pl2303s. So being lazy I configure my
applications (heyu & wview) to reference the /dev/serial/by-id/....
path and have never had an issue.

Cheers,
Chris

[Deborah]

Hi Chris,

On Jan 7, 10:29 am, Chris <ch...@winslow-bucks.net> wrote:
> I know udev is mentioned further in this
> thread and this is probably the correct solution but I never pursued
> it.
> Instead I noted on Ubuntu 9.04/9.10 that the devices were always
> uniquely identified in /dev/serial/by-id, e.g.

[...]

> So being lazy I configure my
> applications (heyu & wview) to reference the /dev/serial/by-id/....
> path and have never had an issue.

Nothing lazy about that. It's probably a better solution, one that
doesn't occur to us old-school people who still expect /dev to be a
flat directory on Unix machines. For what it's worth, the files in /
dev/serial/by-id are still created by udev. They are just the result
of default rules rather than the custom rules that I was talking
about.

If I may go off on a tangent for the sake of people searching this
thread in the future, these sorts of tricks aren't generally needed on
Mac OS X, as I found when I moved my weather station from the Debian
box to a Mac OS X box last week. USB serial devices, on the whole,
seem to get unique and predictable names in /dev without any
intervention.

[ccroom]

Strange event occurred yesterday that may or may not be related. I
upgraded to version 5.10.3 yesterday at about 2pm EDT. At 7pm EDT the
computer and VantagePro stopped communicating on ttyUSB0 and the
computer changed the connection to the VantagePro to ttyUSB1 for no
known reason. Obviously no data was pulled from the VantagePro. I
stopped wview, unplugged and plugged the usb cable and it acquired
ttyUSB0 as normal. I will watch it to see if that occurs again. I am
running Ubuntu 8.04 on Dell Mini 9. Any suggestions?

Jan 7 05:33:45 clay-mini wvpmond[27027]: <1262860413165> : wvpmond:
recv signal 15: exiting!
Jan 7 05:33:45 clay-mini wvpmond[27027]: <1262860413165> : exiting
normally...
Jan 7 05:33:45 clay-mini wvhttpd[27014]: <1262860413171> : wvhttpd:
recv signal 15: exiting now!
Jan 7 05:33:45 clay-mini htmlgend[26999]: <1262860413185> : htmlgend:
recv signal 15: exiting!
Jan 7 05:33:45 clay-mini htmlgend[26999]: <1262860413185> : exiting
normally...
Jan 7 05:33:45 clay-mini wviewd[26993]: <1262860413201> : wviewd:
recv sig 15: exiting!
Jan 7 05:33:45 clay-mini wviewd[26993]: <1262860413201> : exiting
normally...
Jan 7 05:33:45 clay-mini kernel: [3228257.172196] cp2101 ttyUSB0:
cp2101_set_config - Unable to send request, request=0x0 size=2
result=-19
Jan 7 05:33:45 clay-mini radmrouted[26989]: <1262860414218> :
radmrouted: recv sig 15: exiting!
Jan 7 05:33:45 clay-mini kernel: [3228257.174368] cp2101 ttyUSB0:
cp2101 converter now disconnected from ttyUSB0
Jan 7 05:33:45 clay-mini radmrouted[26989]: <1262860425404> : exiting
normally...
Jan 7 05:37:35 clay-mini kernel: [3228498.875564] usb 4-2: USB
disconnect, address 4
Jan 7 05:37:35 clay-mini kernel: [3228498.876703] cp2101 ttyUSB1:
cp2101 converter now disconnected from ttyUSB1
Jan 7 05:37:35 clay-mini kernel: [3228498.876790] cp2101 4-2:1.0:
device disconnected
Jan 7 05:37:42 clay-mini kernel: [3228505.864951] usb 4-2: new full
speed USB device using uhci_hcd and address 5
Jan 7 05:37:42 clay-mini kernel: [3228506.031233] usb 4-2:
configuration #1 chosen from 1 choice
Jan 7 05:37:42 clay-mini kernel: [3228506.034205] cp2101 4-2:1.0:
cp2101 converter detected
Jan 7 05:37:42 clay-mini kernel: [3228506.144660] usb 4-2: reset full
speed USB device using uhci_hcd and address 5
Jan 7 05:37:42 clay-mini kernel: [3228506.291037] usb 4-2: cp2101

[Tagman9]

I think I'm having a similar issue. I noticed this morning that wview
wasn't updating (running 5.11).

I'm running ubuntu 9.10 and looking at the logs it stated that cp2101
reset itself at 5:48am and changed itself from ttyUSB0 to ttyUSB1
(thanks to Mark for pointing that out)..

Jan 11 05:48:57 server kernel: [145476.472127] usb 2-2: USB
disconnect, address 3
Jan 11 05:48:57 server kernel: [145476.472409] cp210x ttyUSB0: cp210x

converter now disconnected from ttyUSB0

Jan 11 05:48:57 server kernel: [145476.472449] cp210x 2-2:1.0: device
disconnected
Jan 11 05:48:57 server kernel: [145476.712527] usb 2-2: new full speed
USB device using uhci_hcd and address 4
Jan 11 05:48:57 server kernel: [145476.880751] usb 2-2: configuration

#1 chosen from 1 choice

Jan 11 05:48:57 server kernel: [145476.887673] cp210x 2-2:1.0: cp210x
converter detected
Jan 11 05:48:57 server kernel: [145477.000053] usb 2-2: reset full
speed USB device using uhci_hcd and address 4
Jan 11 05:48:57 server kernel: [145477.147765] usb 2-2: cp210x
converter now attached to ttyUSB1

So after reading this thread and reading the message from Chris, I
changed wview to look at /dev/serial/by-id/
Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0

This worked, however when testing (by unplugging the usb connection
and then back in) weview gave me the same set of errors and spiked to
100% cpu.. The symbolic link /dev/serial/by-id/
Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
correctly changed to point to /dev/ttyUSB1 as the port changed. I
could also restart wview manually this time.

However I have 2 questions:

1) What the heck could be causing the cp2101 to reset itself? Is this
an ubuntu thing, has anyone else seen this??

2) What does Wviewd_vpro do when it encounters this? Does it attempt
to close and re-open the device? It seems that after it errors out
with:
Jan 11 09:12:49 server wviewd[4572]: <1263219169808> : wakeupConsole:
Write ERROR!
Jan 11 09:12:49 server wviewd[4572]: <1263219169808> :
wviewd:vproErrorState: received stimulus 5
it just hangs...

[Chris Stone]

I've not seen anything quite as severe as that. I've had a few issues with
USB serial since I 'upgraded' from Jaunty to Karmic but that seems to have
settled down now. The symptoms I was seeing were with wx200d just being
incredibly slow.

I suppose conceivably if wview is not expecting the handle on the serial
port to get closed it could go spinning trying to read from a non-existent
file descriptor? Not really sure, I'm a hacker, not a programmer sadly.

Certainly whether you access is via /devv/ttyUSB... or any other link
shouldn't really make a difference.

Did you upgrade to 9.10 or was it a clean install? I've had a mare of a time
to be honest, mainly around issues with upstart and networking but that's a
story for another time.

C.

[Tagman9]

I did a clean install of 9.10.. I don't think this USB reset is
happening every day, but I think it may be the culprit of my wview
having issues over time. I suspect I had this issue with 8.10 as well
because it would stop updating every few days.. I would just reboot...
(kinda like running windows...)

I'm running cp210x: v0.09:Silicon Labs CP210x RS232 serial adaptor
driver

I see there is a 3.0 driver on Silicon Labs web site, not sure if this
is worth looking at..

Below is a lsusb:

Bus 002 Device 004: ID 10c4:ea60 Cygnal Integrated Products, Inc.
CP210x Composite Device
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x10c4 Cygnal Integrated Products, Inc.
idProduct 0xea60 CP210x Composite Device
bcdDevice 1.00
iManufacturer 1 Silicon Labs
iProduct 2 CP2102 USB to UART Bridge Controller
iSerial 3 0001
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 2 CP2102 USB to UART Bridge Controller
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
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 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0000
(Bus Powered)

[Chris Stone]

I'm not sure about that particular device but here's what I have:

lrwxrwxrwx 1 root root 13 2010-01-08 01:22 usb-9710_7720-if00-port0 ->
../../ttyUSB2
lrwxrwxrwx 1 root root 13 2010-01-08 01:22 usb-9710_7720-if00-port1 ->
../../ttyUSB3
lrwxrwxrwx 1 root root 13 2010-01-08 01:22
usb-FTDI_FT232R_USB_UART_A4001mrb-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 2010-01-08 01:22
usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 -> ../../ttyU

The first two are a dual serial port device from Bafo (actually from Maplin
here in the UK) - http://www.bafo.com/products_bf-816_F.asp. I'd actually
bought it for my Windows machine but there was no way it was going to work
with Windows 7 - I was quite surprised when I plugged it into my Ubuntu
machine and it just worked!

The 3rd one is an X10 RF receiver with built in USB->Serial and finally we
have the trusty old Prolific.

All seems to be working fine just now but I did recently update the kernel
(to 2.6.31-17) which has had some changes around USB serial. I've also
chosen the PAE kernel (for no particular reason) - I did seem to have more
issues with the non-PAE version before I upgraded, but I've no idea why that
should be.

[Tagman9]

I think I fixed it... I put my CP2101 on a powered USB hub and have
not seen any resets since.. Keeping my fingers crossed...