Hello Nigel.

Long time no speak etc.   Sorry for the delay, I've been working away from base for the last week, trying to keep up using a mobile device.

From your dmesg snip, I suspect you have other issues, relating to the

GPU that is flooding the message buffer..  Goodness knows what though.

Anyhow...   Based on the other recommendations, try something like this.

dmesg | grep tty

You could see something like this.

~ $ dmesg | grep tty [    0.000000] console [tty0] enabled [   23.331221] cdc_acm 2-1.6:1.1: ttyACM0: USB ACM device [   23.332685] cdc_acm 2-1.6:1.3: ttyACM1: USB ACM device [   23.349212] cdc_acm 2-1.6:1.9: ttyACM2: USB ACM device [ 6363.098904] usb 2-1.2.1: pl2303 converter now attached to ttyUSB0 [ 6363.101275] usb 2-1.2.2: pl2303 converter now attached to ttyUSB1 [ 6363.103361] usb 2-1.2.3: pl2303 converter now attached to ttyUSB2 [ 6363.105035] usb 2-1.2.4: pl2303 converter now attached to ttyUSB3 ~ $

That shows the the console tty "device" enabled at boot, three ttyACM instances that (I think) are a GSM modem that is built into this laptop, and the four Prolific chipset devices that are used in the shack here, that I plugged in just before issuing that command..

I didnt use grep ttyUSB, as that would have only shown USB serial devices, there are cases on some machines and other 'nix versions where such things show up with other variations of "tty".   (Especially BSD & Mac systems.)

Also as said, doing...

ls /dev/tty*     Is another command line tool.

On the same machine as above, that results in.

~ $ ls /dev/tty* /dev/tty    /dev/tty18  /dev/tty28  /dev/tty38  /dev/tty48  /dev/tty58    /dev/ttyACM1    /dev/ttyS16  /dev/ttyS26  /dev/ttyS8 /dev/tty0   /dev/tty19  /dev/tty29  /dev/tty39  /dev/tty49  /dev/tty59    /dev/ttyACM2    /dev/ttyS17  /dev/ttyS27  /dev/ttyS9 /dev/tty1   /dev/tty2   /dev/tty3   /dev/tty4   /dev/tty5   /dev/tty6     /dev/ttyprintk  /dev/ttyS18  /dev/ttyS28  /dev/ttyUSB0 /dev/tty10  /dev/tty20  /dev/tty30  /dev/tty40  /dev/tty50  /dev/tty60    /dev/ttyS0      /dev/ttyS19  /dev/ttyS29  /dev/ttyUSB1 /dev/tty11  /dev/tty21  /dev/tty31  /dev/tty41  /dev/tty51  /dev/tty61    /dev/ttyS1      /dev/ttyS2   /dev/ttyS3   /dev/ttyUSB2 /dev/tty12  /dev/tty22  /dev/tty32  /dev/tty42  /dev/tty52  /dev/tty62    /dev/ttyS10     /dev/ttyS20  /dev/ttyS30  /dev/ttyUSB3 /dev/tty13  /dev/tty23  /dev/tty33  /dev/tty43  /dev/tty53  /dev/tty63    /dev/ttyS11     /dev/ttyS21  /dev/ttyS31 /dev/tty14  /dev/tty24  /dev/tty34  /dev/tty44  /dev/tty54  /dev/tty7     /dev/ttyS12     /dev/ttyS22  /dev/ttyS4 /dev/tty15  /dev/tty25  /dev/tty35  /dev/tty45  /dev/tty55  /dev/tty8     /dev/ttyS13     /dev/ttyS23  /dev/ttyS5 /dev/tty16  /dev/tty26  /dev/tty36  /dev/tty46  /dev/tty56  /dev/tty9     /dev/ttyS14     /dev/ttyS24  /dev/ttyS6 /dev/tty17  /dev/tty27  /dev/tty37  /dev/tty47  /dev/tty57  /dev/ttyACM0  /dev/ttyS15     /dev/ttyS25  /dev/ttyS7 ~ $

That's a lot to scan through, but on the right side you can see the USB instances, so...

ls /dev/ttyU*        (Note the * wild-card character used.)

Will result in...

~ $ ls /dev/ttyU* /dev/ttyUSB0  /dev/ttyUSB1  /dev/ttyUSB2  /dev/ttyUSB3 ~ $

Much more usable.

(Note, that Linux is case sensitive regarding naming files and devices, so ttyu* is not the same as ttyU*.)

Just about all the "main stream" Linux's have drivers built into the Kernel for FTDI, Prolific, SiLabs and others, by default.

For example, this Mint 17.2 box identifies an old mobile phone adapter lead thus...

usb 3-1: SPCP8x5 converter now attached to ttyUSB4

And it works well, when I short out the Tip & Ring of the 2.5mm jack it has.  I have no idea what chipset it is, no current Windows machine will use it.   (According to Google, SPCP8x5 is a Sunplus device. So now I know, but I digress.)

So, those are the methods I use when initially trying to debug Linux serial port issues, at least, how to find out what device name is assigned to something that is connected, if the Kernel recognises it.

Hope something above helps Linux users of Chirp, get linked to their radios.

73.

Dave B.

On 24/10/17 19:29, Nigel A. Gunn G8IFF/W8IFF wrote:

Mine shows:

-HP-Pavilion-Notebook:~$ dmesg | tail -20 [141952.984577] amdgpu: [powerplay] min_core_set_clock not set [141952.985883] amdgpu: [powerplay] min_core_set_clock not set [141952.986564] amdgpu: [powerplay] min_core_set_clock not set [141952.987559] amdgpu: [powerplay] min_core_set_clock not set [141952.988580] amdgpu: [powerplay] min_core_set_clock not set [141952.989695] amdgpu: [powerplay] min_core_set_clock not set [141952.990562] amdgpu: [powerplay] min_core_set_clock not set [141952.991565] amdgpu: [powerplay] min_core_set_clock not set [141952.992589] amdgpu: [powerplay] min_core_set_clock not set [141952.993569] amdgpu: [powerplay] min_core_set_clock not set [141952.994570] amdgpu: [powerplay] min_core_set_clock not set [161875.141546] amdgpu: [powerplay] min_core_set_clock not set [161875.383230] amdgpu: [powerplay] min_core_set_clock not set [161876.144722] amdgpu: [powerplay] min_core_set_clock not set [161876.384676] amdgpu: [powerplay] min_core_set_clock not set [161876.385424] amdgpu: [powerplay] min_core_set_clock not set [161876.399925] amdgpu: [powerplay] min_core_set_clock not set [161876.413122] amdgpu: [powerplay] min_core_set_clock not set [161876.414780] amdgpu: [powerplay] min_core_set_clock not set [161876.415479] amdgpu: [powerplay] min_core_set_clock not set

...

On 24 October 2017 at 12:44 Dave B g8kbv@uku.co.uk wrote:

On 23/10/17 20:00, chirp_users-request@intrepid.danplanet.com mailto:chirp_users-request@intrepid.danplanet.com wrote:

...

Message: 1 Date: Mon, 23 Oct 2017 04:48:38 +0000 (UTC) From: Rick Begeman bitbungler@yahoo.com mailto:bitbungler@yahoo.com Subject: [chirp_users] Connecting to a FT2DR

What cable is being used for a FT2DR and Linux?The factory cable does not create a ttyUSB port when connected to the Linux box.Will an FTDI cable with a mini USB work with this radio?