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.
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 wrote:
Message: 1 Date: Mon, 23 Oct 2017 04:48:38 +0000 (UTC) From: Rick Begeman <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? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://intrepid.danplanet.com/pipermail/chirp_users/attachments/20171023/75db5aca/attachment-0001.html
What does :-
dmesg | tail -20
show, if entered immediately after the cable is plugged into the PC? (It might have to be connected to the radio, and the radio powered ON first.)
Also, what Linux distro'?
Regards.
Dave B.
_______________________________________________
chirp_users mailing list
chirp_users@intrepid.danplanet.com
http://intrepid.danplanet.com/mailman/listinfo/chirp_users
This message was sent to Nigel Gunn, W8IFF at nigel@ngunn.net
To unsubscribe, send an email to chirp_users-unsubscribe@intrepid.danplanet.com
Nigel A. Gunn, 1865 El Camino Drive, Xenia, OH 45385-1115, USA. tel +1 937 825 5032
Amateur Radio G8IFF W8IFF (was KC8NHF 9H3GN), e-mail nigel@ngunn.net www http://www.ngunn.net
Member of ARRL, QRPARCI #11644, SOC #548, Flying Pigs QRP Club International #385,
Dayton ARA #2128, AMSAT-NA LM-1691, GCARES, EAA382.