PDA

View Full Version : [SOLVED] serial port


volbollo
26th July 2010, 01:55 PM
Hi,
I'm new in this forum and i'm sorry for my english...i come from Italy but i do what i can!

So, I use fc13 and for business reason (I'm doing an application porting from Win to Linux ) i need to open my pc serial port.

To tell the truth I don't have any serial port on my machine but I want to use a USB-to Serial cable to do this.

[malakian@munf ~]$ lsusb
Bus 002 Device 003: ID 064e:a127 Suyin Corp.
Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


So, my machine see it and I've read that my kernel support this cable and has its driver (kernel 2.6.33.6-147.fc13.i686.PAE)

I show you some output from my shell

$ dmesg|tail
usb 1-1.1: Manufacturer: Prolific Technology Inc.
usbcore: registered new interface driver usbserial
USB Serial support registered for generic
usbcore: registered new interface driver usbserial_generic
usbserial: USB Serial Driver core
USB Serial support registered for pl2303
pl2303 1-1.1:1.0: pl2303 converter detected
usb 1-1.1: pl2303 converter now attached to ttyUSB0
usbcore: registered new interface driver pl2303
pl2303: Prolific PL2303 USB to serial adaptor driver

Besides without cable I can read

[malakian@munf ~]$ ll /dev/tty*

.
.
.
crw-rw----. 1 root dialout 4, 64 26 lug 09:19 /dev/ttyS0
crw-rw----. 1 root dialout 4, 65 26 lug 09:19 /dev/ttyS1
crw-rw----. 1 root dialout 4, 66 26 lug 09:19 /dev/ttyS2
crw-rw----. 1 root dialout 4, 67 26 lug 09:19 /dev/ttyS3


while hooking up the cable

[malakian@munf ~]$ ll /dev/tty*

.
.
.
crw-rw----. 1 root dialout 4, 64 26 lug 09:19 /dev/ttyS0
crw-rw----. 1 root dialout 4, 65 26 lug 09:19 /dev/ttyS1
crw-rw----. 1 root dialout 4, 66 26 lug 09:19 /dev/ttyS2
crw-rw----. 1 root dialout 4, 67 26 lug 09:19 /dev/ttyS3
crw-rw----. 1 root dialout 188, 0 26 lug 14:45 /dev/ttyUSB0


It seems all right but typing by root


setserial /dev/ttyUSB0


I obtain


Cannot get serial info: Invalid argument
[/CODE]

..i cannot open the door... Can someone help me?

PabloTwo
26th July 2010, 03:00 PM
I use F12 32 bit and have a USB>Serial adaptor. I don't know why your setserial command is not working for you as it does for me.
BASH:~/-> lsusb
Bus 002 Device 005: ID 1608:0240 Inside Out Networks [hex] Edgeport/1
Bus 002 Device 004: ID 03f0:6004 Hewlett-Packard DeskJet 5550
Bus 002 Device 002: ID 045e:00f0 Microsoft Corp.
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
BASH:~/-> lsmod | grep serial
usbserial 27143 1 io_ti
BASH:~/-> setserial -G /dev/ttyUSB0
/dev/ttyUSB0 uart 16550A port 0x0000 irq 0 baud_base 9600 spd_normal skip_test auto_irq
BASH:~/-> sudo ls /proc/tty/driver/
serial usbserial
BASH:~/-> cat /proc/tty/drivers
/dev/tty /dev/tty 5 0 system:/dev/tty
/dev/console /dev/console 5 1 system:console
/dev/ptmx /dev/ptmx 5 2 system
/dev/vc/0 /dev/vc/0 4 0 system:vtmaster
usbserial /dev/ttyUSB 188 0-253 serial
serial /dev/ttyS 4 64-95 serial
pty_slave /dev/pts 136 0-1048575 pty:slave
pty_master /dev/ptm 128 0-1048575 pty:master
unknown /dev/tty 4 1-63 console

volbollo
26th July 2010, 03:25 PM
me too have quite similar output (exept for the third)

# lsusb
Bus 002 Device 003: ID 064e:a127 Suyin Corp.
Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 005: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

$ lsmod | grep serial
usbserial 26445 1 pl2303

# setserial -G /dev/ttyUSB0
Cannot get serial info: Invalid argument

# ls /proc/tty/driver/
serial usbserial


# cat /proc/tty/drivers
/dev/tty /dev/tty 5 0 system:/dev/tty
/dev/console /dev/console 5 1 system:console
/dev/ptmx /dev/ptmx 5 2 system
/dev/vc/0 /dev/vc/0 4 0 system:vtmaster
usbserial /dev/ttyUSB 188 0-253 serial
serial /dev/ttyS 4 64-95 serial
pty_slave /dev/pts 136 0-1048575 pty:slave
pty_master /dev/ptm 128 0-1048575 pty:master
unknown /dev/tty 4 1-63 console


I tryed to open that port in several ways but there is no way :D

I've tryed with 'Moserial Terminal' too...

it 'could not open /dev/ttyUSB0' port!!!!

trigpoint
26th July 2010, 03:32 PM
Have you added your user to group dialout?

PabloTwo
26th July 2010, 03:39 PM
In F12 I have setserial-2.17-24.fc12.i686 version of setserial. Checking at the koji build server, I see for F13 is setserial-2.17-26.fc13, so there does not appear to be any significant change(s) to the setserial program.

One thing that I have found that enables a regular user to have access to the /dev/ttyUSBx port/device is to add the user to the dialout group.
BASH:~/-> ll /dev/ttyUSB0
crw-rw----. 1 root dialout 188, 0 2010-07-26 08:50 /dev/ttyUSB0
..though as root user, access should not be a problem. I use the termianl program 'minicom' to set a parameter on the device that is connected to the USB>Seral adaptor as user without problem by adding myself to the dialout group. I don't know if this will help your situation.

volbollo
26th July 2010, 03:44 PM
...I do not think so...

and sincerely I don't know how to to it...can you help me?

---------- Post added at 06:44 AM CDT ---------- Previous post was at 06:41 AM CDT ----------

Sorry...I don't have seen the other post...I tryed also with minicom but without results...

PabloTwo
26th July 2010, 03:48 PM
You could use the graphical interface on your system (Users and Groups) to do that. You should be prompted for root password when you launch that from the menu. Or by command line:
su -c 'usermod -G -a dialout username'
To verify afterwards, do:
cat /etc/group | grep dialout
You should see your username added at the end (:username)

edit: forgot the ending single quotation mark that wraps the command

volbollo
26th July 2010, 03:51 PM
I've started minicom as root

than I choose 'serial port setup' , 'A' and I've modified '/dev/modem' -> '/dev/ttyUSB0' than 'return' and than I try to save the setup but it tells me that I couldn't!!

PabloTwo
26th July 2010, 03:56 PM
Minicom is a bit difficult to navigate at first. You will need to run minicom as root in order to be able to save the configuration settings. Once you have done so, it will be saved in a file /etc/minirc.dfl. The important parameters to set in minicom are the port (/dev/ttyUSB0 in this case) and the baud rate of the device connected to the USB>Serial adaptor. My device is jumper set to run at 19200b over it's serial port, and my minrc.dfl file looks like this.
BASH:~/-> cat /etc/minirc.dfl
# Machine-generated file - use "minicom -s" to change parameters.
pu port /dev/ttyUSB0
pu baudrate 19200
pu minit
pu mreset
pu mdialpre
pu mdialsuf
pu mdialpre2
pu mdialsuf2
pu mdialpre3
pu mdialsuf3
pu mhangup
pu mdialcan
pu logfname

volbollo
26th July 2010, 04:06 PM
I tryed to do as you tell me in post #7 but this is the output

[malakian@munf bin]$ su -c 'usermod -G -a dialout malakian'
Password:
usermod: group '-a' does not exist
[malakian@munf bin]$ cat /etc/group | grep dialout
dialout:x:18:


(malakian is my username)

PabloTwo
26th July 2010, 04:09 PM
Try,
su -c 'usermod -aG dialout malakian'
I just got the syntax a little wrong on that command.

volbollo
26th July 2010, 04:14 PM
ok!....it likes it now the output is

[malakian@munf bin]$ cat /etc/group | grep dialout
dialout:x:18:malakian


...but the port is already closed

[root@munf malakian]# setserial /dev/ttyUSB0
Cannot get serial info: Invalid argument


I've forgot something???

PabloTwo
26th July 2010, 04:25 PM
I still do now know or understand why the setserial command is failing for you. It may be a bug introduced in F13, or some sort of problem with the pl2303 kernel driver module. I am out of any further suggestions to try. You might try doing a search for 'pl2303' on the forum and look at the most recent threads that may be relevant to F13 and see if you can get any clues from those.

It's working for me as both normal user and as root,
BASH:~/-> su
Password:
BASH:paulm/-> setserial /dev/ttyUSB0
/dev/ttyUSB0, UART: 16550A, Port: 0x0000, IRQ: 0
BASH:paulm/-> exit
exit
BASH:~/-> setserial /dev/ttyUSB0
/dev/ttyUSB0, UART: 16550A, Port: 0x0000, IRQ: 0

volbollo
26th July 2010, 04:32 PM
I've just done both a search for pl2303 and 'f13 problem with serial port'...but nothing...

Nevertheless thank you very much for helping me...I'll try again to open that port and if ll do it I'll post it...


Obviously if someone could help me I would appreciate it... ;)

PabloTwo
26th July 2010, 04:39 PM
Perhaps I should add, the examples I've given with commands on my system in this thread is without the "device" (a tnc packet modem for ham radio) being connected to the USB>Serial adaptor, though I don't really think it would matter if it was. Are you using your USB>Serial adapter cable with something attatched to the other end and powered on/off, or just the cable itself plugged into a USB port?

Not sure if that would make any difference, but it's worth trying both ways.

trigpoint
26th July 2010, 04:46 PM
Is there any particular reason for using minicom? It has never been a particularly easy programme to use.

MayI suggest, as a simple way of checking the serial port is working, that you install putty? It is very self explanatory and doesn't need set serial. As root type 'yum install putty'.

HTH

PabloTwo
26th July 2010, 05:20 PM
One other thing did come to mind. You might check if there is a LOCK file for that device that hasn't been cleared.
ls /var/lock/
If you find a file named LCK..ttyUSB0, then you need to delete that file as root. When ever I use minicom, the tnc device is connected to my USB>Serial cable adapter, otherwise, minicom would have no communications device to "talk" to over that port. What you haven't said as yet, unless I somehow overlooked it, is what you are connecting to your USB>Serial adapter. What you connect will determine what software or tools to use to communicate over that usb>serial link.

Is it some kind of modem? Some sort of networking device?

Using putty to talk to a modem over a serial link? I'd like to know how that is done.

trigpoint
26th July 2010, 06:26 PM
Using putty to talk to a modem over a serial link? I'd like to know how that is done.

You can talk to a modem using the Hayes Command Set (http://en.wikipedia.org/wiki/AT_command). Actually it can be done with any dumb serial terminal.

Once you connect putty to the modem, most accept more or less any baud rate, you can use a series of AT Commands to check that the modem is working.
ATZ will return OK, its the reset command.
ATDT1471 will dial 1471 using touchtone dialing. In the UK 1471 will return the last number that called you.

There are extensions to the AT Command set used by mobile phones.

I have attached some screenshots of a simple putty seesion with my phone, configuring a modem (or at least finding the bits) will take some time. If I used a dialup with fedora it was core 1, certainly not core 2.

Config (http://www.trigpoint.me.uk/images/puttyconfig.png)
Session (http://www.trigpoint.me.uk/images/puttysession.png)

I had to put them in as links, insert image doesn't work for me. Any pitfalls here?

http://www.trigpoint.me.uk/images/puttyconfig.png

http://www.trigpoint.me.uk/images/puttysession.png
http://www.trigpoint.me.uk/images/puttyconfig.png

http://www.trigpoint.me.uk/images/puttysession.png

PabloTwo
26th July 2010, 06:40 PM
Well, before I saw your post above, I took a break (closed firefox) and yum installed putty to have a go at that. Like you said, it was pretty intuitive. I have used PuTTY in windows before, but never in Linux, and only to ssh into a remote Linux box. In Linux, I've just always used ssh at the command line in a terminal to do an ssh connect.

Once installed, and without ever doing 'man putty', I was connected to my TNC (Terminal Node Controller) using putty over the usb>serial port in mere seconds and giving it commands. It couldn't have been simpler.

Looks like I've 'found' a new tool to use in my aresenal

volbollo
27th July 2010, 11:19 AM
I've never hooked up a device to my pc...I need serial port for several reason but not to use a modem

I must 'comunicate' to a demo board, for istance that allow me serial comunication...

i don't know why I have that problem...I've not found any bugs in serial comunication concerning fc13 and it does not seems a driver problem...

It seems to me a configuration problem but i don't know where I have to put my hands..

trigpoint
27th July 2010, 12:45 PM
Getting a serial port to work, with nothing on the other end is not the easiest thing to do.

I would recommend that you install putty as I previously suggested and connect your demo board to your PC.

Forget setserial and minicom, they are hard work.

If you are initially having problems with permissions, open a terminal and su to root and run putty as root. Once that is working, then start solving the problems of connecting as a user such as group permissions.

HTH

volbollo
27th July 2010, 03:26 PM
SOLVEEEEEEED!!!

I was at least two weeks trying to solve it!!

To be clear: I've installed putty, setup the /dev/ttyUSB0 port and now also ttyS* goes well (I suppose virtually...)..

trigpoint
27th July 2010, 06:10 PM
Do you mean ttyS*? That is the on-board serial port, which will exist on the motherboard but hasn't been brought out.

Make sure that putty works with the serial port set to ttyUSB0.

Is your demo board pre-programmed, or are you writing the serial code for the board.

If the board is pre-programmed connect it up and make sure it works. If it is not pre-programmed then I would advise you to do a sanity check and connect the PC up to another one, or a 2nd USB serial adaptor connected to the same one and make sure you can echo characters back and forth between 2 putty sessions.

HTH

PabloTwo
27th July 2010, 09:33 PM
You have me a bit confused now. Your first post indicated that your computer has no serial ports, which may very well be true. My computer motherboard (desktop) has no external serial port jacks, but it does have one internal serial port header on the mb.

Whether you do or don't have any serial ports on your mb, Fedora Linux still will always report four (4) ttySx devices (serial ports). If one or more is real, fine. If some or all are not real, they are serial port ghosts. The easy way to tell which is which is with the setserial command, as it can query the serial port and discover and report what it finds. The key thing is whether it finds an actual UART, that's the chip that does the actual I/O work.

If setserial reports a UART as being something like 16550A, then the serial port is real. If it reports the UART as an unknown, then it's a non-existent ghost serial port.
BASH:~/-> sudo setserial -a /dev/ttyS0
/dev/ttyS0, Line 0, UART: 16550A, Port: 0xa000, IRQ: 16 <== This is a real serial port
Baud_base: 115200, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal skip_test

BASH:~/-> sudo setserial -a /dev/ttyS1
/dev/ttyS1, Line 1, UART: unknown, Port: 0x02f8, IRQ: 3 <== This is a ghost serial port
Baud_base: 115200, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal skip_test auto_irq

BASH:~/-> sudo setserial -a /dev/ttyS2
/dev/ttyS2, Line 2, UART: unknown, Port: 0x03e8, IRQ: 4 <== This is a ghost serial port
Baud_base: 115200, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal skip_test auto_irq

BASH:~/-> sudo setserial -a /dev/ttyS3
/dev/ttyS3, Line 3, UART: unknown, Port: 0x02e8, IRQ: 3 <== This is a ghost serial port
Baud_base: 115200, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal auto_irq

BASH:~/-> sudo setserial -a /dev/ttyUSB0
/dev/ttyUSB0, Line 0, UART: 16550A, Port: 0x0000, IRQ: 0 <== This is a real serial port
Baud_base: 9600, close_delay: 5000, divisor: 0
closing_wait: 4000
Flags: spd_normal skip_test auto_irq

My real onboard serial port is disabled in the bios as it won't pass any data through it, even though the bios, OS and programs thinks it's just fine. The ttyS0 shown here is actually my PCI slot 56k modem card.

Now, the good thing about setserial over putty is that it can do a detailed discover and query of a serial port even when there is nothing attached to it. putty can't do that. putty can only be used to communicate through a working serial port to an attached device, and if that works, then you know that serial port is working

My point here is that if you can't get setserial to report to you the parameters it finds, including a known type of UART, of your USB>Serial cable adaptor, then something clearly isn't working. The adapter may be bad. Did you buy it new or used? Have you tried using it on another computer, Linux or Windows?

For the most part, I've been using the setserial command as a user, which sometimes works (depending on the command options), and sometimes doesn't. It will always work when run as root. So, to make sure you're not getting tripped up by using the setserial command as a user, from now on do so as root.

As regular user:
BASH:~/-> setserial -a /dev/ttyS0
/dev/ttyS0: Device or resource busy
As root:
BASH:~/-> sudo setserial -a /dev/ttyS0
/dev/ttyS0, Line 0, UART: 16550A, Port: 0xa000, IRQ: 16
Baud_base: 115200, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal skip_test
I can use this command on /dev/ttyUSB0 as user and get full report back, but not on /dev/ttyS0. When you sav "SOLVEEEEEEED!!!", do you mean you were able to communicate with the demo board over the USB>Serial cable adapter? If so, just ignore this post.

volbollo
28th July 2010, 11:27 AM
Ok...thank you for having doubt in my solution... (it is understandable?????sorry for my english...)

I've done some check and the results are rather strange...

I'll try to explain to you...

I'm sure that USB-Serial works because I'm able to communicate with a serial device through it.

Talking about ttyS* I don't know if they exist physically or virtually because I don't know if, as you told me, the problem is just the absence of a serial jack ore that they are virtual.

The application GUI that I must test and then use now show me that ttyS* port are opened but offLine and the USB-Serial just when I hook up it.

I be able to set UART of ttyS* with set serial but I can't set ttyUSB* from it.

It type me "cannot get serial info: invalid argument!"

Setserial, moserial terminal, putty, minicom have different "opinion" about my serial connection and I don't know who have reason

I'm sure that I see results after putty installation (probably some dipendencies able my serial comunication )

PabloTwo
28th July 2010, 03:15 PM
I'll try to explain to you...

I'm sure that USB-Serial works because I'm able to communicate with a serial device through it.
OK... that explanation was missing from your post that declared it [SOLVED]
To set serial port parameters using the setserial command, the command syntax must be very specific. If you use the -G option of setserial to query a serial port it will return the current values in a form the same as you would use to set those values. From 'man setserial'
-G Print out the configuration information of the serial port in a form which can be fed back to set-
serial as command-line arguments.
BASH:~/-> setserial -G /dev/ttyUSB0
/dev/ttyUSB0 uart 16550A port 0x0000 irq 0 baud_base 9600 spd_normal skip_test auto_irq
BASH:~/-> sudo setserial -G /dev/ttyS0
/dev/ttyS0 uart 16550A port 0xa000 irq 16 baud_base 115200 spd_normal skip_test
I guess your pl2303 adapter just doesn't want to cooperate well with the setserial command :)
Glad to know it's working OK for you though. Thanks for explaining.

jims
9th January 2013, 03:50 AM
I realize that this thread is marked Solved, but after a day of trying to get a PL2303 USB<-->Serial cable up and running, I have discovered a conflict that was taking over the generated ttyUSB device in exclusive mode and not allowing me to use the ttyUSB device to talk with a Ham Radio PacComm TNC.

Some time ago, I had installed gpsd in anticipation of connecting one of my GPS devices to my box.

When I connected my newly purchased PL2303 USB<-->Serial cable to a USB port, gpsd grabbed it through the /etc/udev/rules.d/99-gpsd.rules.

I was experiencing very similar problems to the ones causing problems for volbollo. Example: inability to run setserial as a standard user in the dialout group, inability to use a F16 serial terminal to open the ttyUSB device.

The crazy thing was I was able to use a Ham Radio server suite (TNOS) (running under systemd as root) to open the ttyUSB device, but was unable to communicate through it to and from the PacComm TNC. gpsd opens the ttyUSB connected device in a proprietary communications protocol that allows gps clients to talk with gps devices.

Eventually after analysis, I went to the gpsd site at http://gpsd.berlios.de/faq.html#conflict and got the following:

Why does GPSD interfere with non-GPS USB devices?

Most USB devices have a defined device class - mass storage, video, hub, and human interface device are three of the more common ones. Using GPSD will never interfere with such devices, nor will they interfere with GPSD.

Unfortunately, there is no device class for USB GPSes. Nor is there a device class for USB-to-serial adapter chips. Both are assigned the catch-all class 0xFF, "Vendor Specific". Every USB GPS we've ever seen consists of a GPS module with TTL-level RS232 outputs connected to an RS232-to-USB adapter chip, and presents the class ID 0xFF to your USB subsystem.

When you install GPSD, it puts in place rules that watch for hotplug activation events from devices that might be GPSes. When such a hotplug event happens, a gpsd instance is started (if one is not already running) and puts a copy of the device path in an internal stash list. Later, if a client application requests GPS data, gpsd will try to read from the device, and discard it from the stash list if it is not emitting data that gpsd recognizes.

GPSD's notion of "might be a GPS" depends on the fact that all USB GPSes are made with one of a small number of USB-to-serial adapter chips, the most common of which is the Prolific Logic 2303. GPSD's hotplug rules expect that anything exhibiting the USB vendor : product ID pair of one of these chips will be a GPS.

A problem can arise if you have other devices connected to your system through one of these specific adaptor chips. When these activate, the GPSD hotplug rules will believe they are GPSes, and gpsd will try to read from them when a GPS-ware client application requests data. We've had reports of this happening with USB modems and various microcontroller kits. It's not a problem we can solve with clever programming, the devices simply don't yield enough information about themselves to avoid conflicts.

Under Linux, gpsd at 3.1 and later versions checks each serial and USB device after opening it to see if any other process has that device open; if so, it'd dropped. This should at least keep GPSD from usurping data sources belonging to other service daemons.

If this sort of conflict becomes a problem, you can work around it by disabling the GPSD hotplug rules. Unfortunately, this means you will have to start gpsd manually with a device-path argument when you want to use a GPS.

I followed the suggestion to disable the gpsd hotplug rules by renaming it to /etc/udev/rules.d/99-gpsd.rules_HOLDOFF (any rule in the folder that does not terminate with .rules is ignored). Success!

Another thing I did was to create a hotplug rule for the ttyUSB device creating a symlink that gets mapped to the ttyUSB device. This allows for persistent enumeration of the device as /dev/paccomm-tnc.

/etc/udev/rules.d/98-usb-serial.rules

#Device #1 - Generic 1-port USB to serial adapter (Prolific-based) for a PacComm TNC
SUBSYSTEM=="tty", ATTRS{idVendor}=="067b", ATTRS{idProduct}=="2303", SYMLINK+="paccomm-tnc"

After returning the PacComm TNC to kiss mode using gtkterm, entering the command MKISS and restarting my server software, communications are now flowing to and from the PacComm TNC.

Some considerations for anyone else trying to use a ttyUSB cable for simple connection to a non gps serial device while having gpsd installed with an active hotplug rule.

Cheers es 73

Jim
VE7JTS

PabloTwo
9th January 2013, 02:02 PM
Thank you for posting the above information. That was info was quite enlightening.

Paul
N4WKQ

jims
9th January 2013, 06:49 PM
An update to my post above ...

I re-enabled the gpsd rule by renaming /etc/udev/rules.d/99-gpsd.rules_HOLDOFF to /etc/udev/rules.d/99-gpsd.rules. Because the usb-serial rule /etc/udev/rules.d/98-usb-serial.rules runs before the the gpsd rule, the usb-serial rule grabs the the Prolific Technology, Inc. PL2303 ttyUSB device cable. When the gpsd rule is run, it notices that the device is in use and ignores it.

Net result, the USB<-->Serial cable is mapped to a /dev/ttyUSB* device and my persistent enumeration symlink is created.

Communications run freely to and from the PacComm TNC on the USB<-->Serial cable without interference.

The gpsd rule is returned to original condition and is available to detect and map a GPS device upon connection to the system (as long as it is not connected through another Prolific Technology, Inc. PL2303 ttyUSB device cable which would be grabbed by the /etc/udev/rules.d/98-usb-serial.rules).

If a GPS serial port device is either connected through a USB<-->Serial cable with a different combination of ATTRS{idVendor} and ATTRS{idProduct} other than ATTRS{idVendor}=="067b", ATTRS{idProduct}=="2303" (Prolific Technology, Inc. PL2303) in the /etc/udev/rules.d/99-gpsd.rules or is a GPS usb port device, all should be good.

Jim
VE7JTS