On Thu, Mar 27, 2014 at 3:19 PM, Milton Hywatt mhywattt@yahoo.com wrote:
Aren't COM ports virtual? If so it wouldn't matter what the number was as long as the software recognized ports equal to or higher than your port.
AFAIK, COM ports are indeed virtual, so this is a puzzle to me. I have seen other software in the past (some of it mine) that had a limited range of port numbering, but that was an artifact of a GUI design. Chirp listed (only) the COM ports that were physically present in the system (COM1 and COM19), so I'm not inclined to think that Chirp was at fault here; I think it's Windows weirdness. To paraphrase an earlier commenter, "Welcome to the world of high-quality Redmond operating systems."
As far as the radio keying up when the plug is inserted, shut the radio off before you insert the plug. If it does key up then there is a problem with the cable or plug. I've never read of anyone having their radio key up after the plug was inserted.
Here's an interesting bit of additional information on the PTT question: If I open the COM port using PuTTY (terminal emulator), then power on the radio with the plug inserted, the PTT does NOT key up. If I then close the PuTTY session, the PTT keys up a few seconds afterward. The trusty DVM indicates that the TX data line to the radio is held at 0V both before and after the PuTTY session, and is high during the PuTTY session (except when I'm sending serial data). When I run Chirp, the PTT keying only happens before the upload or download starts, and resumes a few seconds after it ends.
This suggests that I'm not seeing a bad adapter or cable, but that one or both of the following two things is happening: 1) The much-despised Prolific chip (the real thing, as far as I can tell, or else they did a great job forging the logo and marking) is setting the TXD line to a break state when there's no port session in progress, and/or 2) the Windows 7 64-bit Prolific com adapter driver (version 3.4.62.293) is commanding the adapter's TXD line to a break state when there's no session in progress.
I'll try this out on a 32-bit Win7 system using the canonical Prolific driver version, and see if the break-state shenanigans still happen there.
Also unless you have 19 COM ports in use, any of them could be invalid. I think previous devices remain in the registry after use and the port can be easily forced to use over by your new device.
Indeed, if I need to do that, it would surely be possible.