[Elecraft] Feature Request: improved internal keyer and CW PTT behavior

Tue Feb 14 10:56:00 EST 2017

Hi Wayne, 

As Brian pointed out, one of the design issues is that in some 
situations -- foot switch usage comes to mind -- the external PTT 
will be inadvertently un-asserted before the operator stops keying 
or stops speaking in the SSB case. The design must properly 
handle premature external PTT de-assertion. 

I recommend taking a look at the behavior of the K1EL Winkeyer. 
Its user community helped its firmware developer achieve highly 
optimized CW keying and CW PTT behavior. 

73 
Frank 
W3LPL 

----- Original Message -----

From: "Wayne Burdick" <n6kr at elecraft.com> 
To: donovanf at starpower.net 
Cc: "Elecraft Reflector" <elecraft at mailman.qth.net> 
Sent: Tuesday, February 14, 2017 3:44:29 PM 
Subject: Re: [Elecraft] Feature Request: improved internal keyer and CW PTT behavior 

This is now at the top of our firmware task list. 

Wayne 
N6KR 

On Feb 14, 2017, at 7:39 AM, donovanf at starpower.net wrote: 

> Hi Brian, 
> 
> 
> The PTT problem I described is that the K3 adds a long delay (the 
> VOX delay, much longer than 5-10 milliseconds) after the external 
> PTT is dropped. I can't explain any rationale for adding VOX delay 
> after PTT is dropped except for a firmware design error. VOX 
> delay is applied to PTT in every operating mode, even in SSB 
> VOX mode. 
> 
> 
> Fortunately VOX delay is not applied when using computer keying 
> via the USB port. 
> 
> 
> 73 
> Frank 
> W3LPL 
> 
> 
> ----- Original Message ----- 
> 
> From: "briancom" <alsopb at comcast.net> 
> To: donovanf at starpower.net 
> Cc: "Elecraft Reflector" <elecraft at mailman.qth.net> 
> Sent: Tuesday, February 14, 2017 2:21:48 PM 
> Subject: Re: [Elecraft] Feature Request: improved internal keyer and CW PTT behavior 
> 
> Frank, 
> Pardon my ignorance on this issue if the below is off target. 
> The asynchronous nature of an external ptt appears to be a problem. 
> Suppose the K3 is in the middle of a long 100 watt dash and the external ptt signal is dropped. It clearly takes some time for the RF tail to drop to zero. One would seem to need to add some delay time for this to happen. To avoid clicks one wants a shaped tail. I dont see how the K3 can immediately go to RX. 
> How fast a turn off and go to RX action do you want? Is the normal 5 ms tail fast enough? 
> 
> Of course if Winkey logic is programmed within the K3 the asynchronous problem goes away. 
> 
> The adjustable TXDELAY issue where the CW gets QSD with a setting more than 8 ms is an issue that has existed from day one. People started complaining about it on day 2. Elecraft has know about it for a long, long time. From what I am able to glean about the problem is that it may be really difficult to fix. Apparently the timing has to be fixed in many places in the code to produce good CW at all values of TXDELAY. If the fix were a simple one, it would have been fixed years ago. 
> 73 de Brian K3KO 
> 
>> On Feb 14, 2017, at 12:52 AM, donovanf at starpower.net wrote: 
>> 
>> Okay, lets take Eric's lead and open an interesting thread directly 
>> related to an excellent Elecraft product. 
>> 
>> 
>> 
>> For years many of us have suffered with the odd behavior of the K3 
>> in CW PTT mode. There are at least two inexplicble aspects of K3 
>> CW PTT behavior that have forced many of us to use external 
>> Winkeyers rather than the poorly designed internal K3 keyer logic 
>> when the K3 is in CW PTT mode. 
>> 
>> 
>> For CW contesters, its necessary to operate the K3 in PTT mode 
>> to avoid unwanted VOX delay. But for some strange reason the 
>> K3 always applies VOX delay after external PTT is unasserted. 
>> I can think of no logical reason why VOX delay should be applied 
>> at the end of the external PTT input when the K3 is PTT mode or 
>> any other mode. When PTT is unasserted, the K3 should always 
>> immediately return to receive mode, no exceptions. 
>> 
>> 
>> When using the internal K3 keyer when in PTT mode, for some 
>> inexplicable reason the K3 behaves like its in QSK mode. The 
>> only way to avoid this is to use VOX rather than PTT mode or 
>> to use a foot switch when in PTT mode. Both alternatives 
>> are unacceptable. 
>> 
>> 
>> The band aid solution many contesters use with excellent results 
>> is to avoid using the internal K3 keyer and to use an external 
>> K1EL Winkeyer that generates both a key output and a PTT 
>> signal generated according to well designed Winkeyer CW PTT 
>> logic. 
>> 
>> 
>> Why can't the K3 implement logic similar to the Winkeyer to 
>> generate the equivalent of "Winkeyer PTT" when using the K3 
>> internal keyer when the K3 is in PTT mode? 
>> 
>> 
>> 73 
>> Frank 
>> W3LPL 
>> ______________________________________________________________ 
>> Elecraft mailing list 
>> Home: http://mailman.qth.net/mailman/listinfo/elecraft 
>> Help: http://mailman.qth.net/mmfaq.htm 
>> Post: mailto:Elecraft at mailman.qth.net 
>> 
>> This list hosted by: http://www.qsl.net 
>> Please help support this email list: http://www.qsl.net/donate.html 
>> Message delivered to alsopb at comcast.net 
> 
> 
> ______________________________________________________________ 
> Elecraft mailing list 
> Home: http://mailman.qth.net/mailman/listinfo/elecraft 
> Help: http://mailman.qth.net/mmfaq.htm 
> Post: mailto:Elecraft at mailman.qth.net 
> 
> This list hosted by: http://www.qsl.net 
> Please help support this email list: http://www.qsl.net/donate.html 
> Message delivered to n6kr at elecraft.com 