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

[John LaMartina]

Another Mystery of the UniV5Rse solved. :- )

John

 

 

From: chirp_users-bounces at intrepid.danplanet.com [mailto:chirp_users-bounces at intrepid.danplanet.com] On Behalf Of Stephen Hersey
Sent: Friday, March 28, 2014 9:37 AM
To: Discussion of CHIRP
Subject: Re: [chirp_users] Another way Chirp can be tripped up by the OS

 

Firstly, let me say a big THANK YOU to the chirp developers for building and giving away this excellent tool. It is greatly
appreciated, and your generosity and dedication make this corner of the world a better place.

Dan,

Thanks for your reply. I was about to take your advice to just select a non-TX channel and live with  the odd things being done to
the serial port state in the idle condition,  but I took one last stab at it and loaded the Prolific 3.2.0.0 driver from Miklor (who
deserve thanks as well), and the mystery PTT keying WENT AWAY. Victory is declared!

The moral of the story: Use the Prolific 3.2.0.0 driver in case of any doubt, even if the default driver used by Windows seems to
work properly in all other respects.

Don't we just live in age of marvels? Indeed, these radios and interface cables are el cheapo devices and we can't expect polish and
perfection from them. However, to be able to buy a decent-quality (if imperfect) radio for less than the price of dinner at a
restaurant is rather astounding.

Best regards,
Steve

 

On Thu, Mar 27, 2014 at 7:00 PM, Dan Smith <dsmith at danplanet.com> wrote:

> 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."

COM19 is perfectly valid, as is COM256.


> 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.

This is pretty much par for the course with these radios. It tends to be
DTR leakage into the PTT circuit, which means regular serial signaling
will occasionally cause the radio to transmit. This is, after all, a $20
device you paid $40 for...


> 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.

If I were you, I would not waste my time and set the radio to something
it can't transmit on before you go into clone mode.

--Dan




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_users/attachments/20140328/73b6bf9d/attachment.html