[chirp_users] Another way Chirp can be tripped up by the OS

[Stephen Hersey]

On Thu, Mar 27, 2014 at 3:19 PM, Milton Hywatt <mhywattt at 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.


-- 
Steve Hersey N1XNX
n1xnxham at gmail.com
-----
Each of us has strengths and talents that others don't. Whether innate or
learned, these are gifts -- and a gift not shared is a sad and lonely
thing. Using our gifts for the benefit of all is an ethical obligation for
every intelligent being. (The magic only works if you pass it on!)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_users/attachments/20140327/15e87bcc/attachment.html