Elecraft

OT: Somewhat Interesting Ebay Item--K2

Classic

List

Threaded

27 messages Options

w7aqk

OT: Somewhat Interesting Ebay Item--K2

I stumbled across a K2 for sale on Ebay that I thought was rather
"interesting". It's one of those situations where you have no idea what you
are really getting!

The K2 is actually described as a "CB radio"! Wow! Makes you wonder.
Also, it is later described as a "K2/100", but that has to be wrong since it
has no heat sink! At least they do say "As IS for parts/repair".

Now, there probably is some value here, and maybe some good value, but how
can you possibly tell? Right now the bidding is up to $280, with a couple
of days to go. I'm just curious how much this thing will sell for. If
anyone else is curious, it is item # 162388838126.

Dave W7AQK

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]

Elecraft mailing list

Re: OT: Somewhat Interesting Ebay Item--K2

I saw it but if you look close it appears that it was not built well
Long leads on caps and transistors, sloppy winding on toroids etc.

From: w7aqk <[hidden email]>
To: Elecraft Reflector <[hidden email]>
Sent: Monday, February 13, 2017 5:08 PM
Subject: [Elecraft] OT: Somewhat Interesting Ebay Item--K2

I stumbled across a K2 for sale on Ebay that I thought was rather
"interesting". It's one of those situations where you have no idea what you
are really getting!

The K2 is actually described as a "CB radio"! Wow! Makes you wonder.
Also, it is later described as a "K2/100", but that has to be wrong since it
has no heat sink! At least they do say "As IS for parts/repair".

Now, there probably is some value here, and maybe some good value, but how
can you possibly tell? Right now the bidding is up to $280, with a couple
of days to go. I'm just curious how much this thing will sell for. If
anyone else is curious, it is item # 162388838126.

Dave W7AQK

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]

donovanf

Feature Request: improved internal keyer and CW PTT behavior

In reply to this post by w7aqk

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:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]

Igor Sokolov-2

Re: Feature Request: improved internal keyer and CW PTT behavior

May be Elecraft can also look at the 8 msec PTT delay which cannot be
made longer without distorting CW. Some of the apmplifiers are not that
quick.

73, Igor UA9CDC

14.02.2017 10:52, [hidden email] пишет:

> 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:[hidden email]
>
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
> Message delivered to [hidden email]
>

Vic Rosenthal

Re: Feature Request: improved internal keyer and CW PTT behavior

If Wayne will be tearing up the code in this area, it might not be hard
to fix the problem that the internal keyer weighting is much heavier in
PTT mode than in QSK or semi-QSK VOX.

73,
Vic, 4X6GP
Rehovot, Israel
Formerly K2VCO
http://www.qsl.net/k2vco/

On 14 Feb 2017 12:50, Igor Sokolov wrote:

> May be Elecraft can also look at the 8 msec PTT delay which cannot be
> made longer without distorting CW. Some of the apmplifiers are not that
> quick.
>
>
> 73, Igor UA9CDC
>
>
> 14.02.2017 10:52, [hidden email] пишет:
>> 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:[hidden email]
>>
>> This list hosted by: http://www.qsl.net
>> Please help support this email list: http://www.qsl.net/donate.html
>> Message delivered to [hidden email]
>>
>
> ______________________________________________________________
> Elecraft mailing list
> Home: http://mailman.qth.net/mailman/listinfo/elecraft
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:[hidden email]
>
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
> Message delivered to [hidden email]

briancom

Re: Feature Request: improved internal keyer and CW PTT behavior

In reply to this post by donovanf

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, [hidden email] 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:[hidden email]
>
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
> Message delivered to [hidden email]

donovanf

Re: Feature Request: improved internal keyer and CW PTT behavior

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" <[hidden email]>
To: [hidden email]
Cc: "Elecraft Reflector" <[hidden email]>
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

wayne burdick

Re: Feature Request: improved internal keyer and CW PTT behavior

Administrator

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

Wayne
N6KR

On Feb 14, 2017, at 7:39 AM, [hidden email] 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" <[hidden email]>
> To: [hidden email]
> Cc: "Elecraft Reflector" <[hidden email]>
> 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, [hidden email] 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:[hidden email]
>>
>> This list hosted by: http://www.qsl.net
>> Please help support this email list: http://www.qsl.net/donate.html
>> Message delivered to [hidden email]
>
>
> ______________________________________________________________
> Elecraft mailing list
> Home: http://mailman.qth.net/mailman/listinfo/elecraft
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:[hidden email]
>
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
> Message delivered to [hidden email]

Chester Alderman

Re: Feature Request: improved internal keyer and CW PTT behavior

In reply to this post by donovanf

First, I admit to not understanding the problem! I do run QSK and VOX during
contest and during regular QRQ QSO's. With my K3/Alpha 9500 setup, I can run
full QSK CW up to 100 wpm and I have no PTT delay issues? I do not run with
PTT asserted and therefore I do not witness the issues other contesters
have.. As for N1MM's "poorly designed internal K3 keyer logic", I certainly
have to disagree with that comment. During 'normal' contest I operate from
28 to 40 wpm, full QSK and would go nuts if there were any perturbations
with my K3's keying.

A so called 'solution' to CW stuttering is to purchase and use the K1EL
keyer. The real problem is with Windows op system wherein the CPU is often
interrupted to do 'internal chores'; and when this happens, all I/O ports
are shut down, which causes the CW stutter. Simply turning off the Windows
generated sound, eliminates the stutter issue and the 'requirement' to
purchase the K1EL keyer.

73,
Tom - W4BQF

-----Original Message-----
From: Elecraft [mailto:[hidden email]] On Behalf Of
[hidden email]
Sent: Tuesday, February 14, 2017 12:53 AM
To: Elecraft Reflector
Subject: [Elecraft] Feature Request: improved internal keyer and CW PTT
behavior

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:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]

donovanf

Re: Feature Request: improved internal keyer and CW PTT behavior

In reply to this post by wayne burdick

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" <[hidden email]>
To: [hidden email]
Cc: "Elecraft Reflector" <[hidden email]>
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, [hidden email] wrote:

wayne burdick

Re: Feature Request: improved internal keyer and CW PTT behavior

Administrator

In reply to this post by donovanf

Is a workaround to simply set the QSK delay to 0 in CW mode even when using PTT?

On Feb 14, 2017, at 7:39 AM, [hidden email] wrote:

donovanf

Re: Feature Request: improved internal keyer and CW PTT behavior

In reply to this post by Chester Alderman

Hi Tom,

The problems I described are unique to the K3's CW PTT mode,
you wouldn't be aware of them if you use QSK.

My CW keying is both from Win-Test via the USB port (it works
perfectly) and into the K3 key and PTT connectors from the K1EL
Winkeyer (the Winkeyer works perfectly for manual keying from a
paddle except for the unwanted long VOX delay that the K3 applies
to the external PTT input).

When are you coming back to a W3LPL multi-multi DX contest to
show us how to work hundreds of 80 meter JAs again? :) I'll
never forget that weekend on 80 meters, its never happened to
nearly that degree again, and certainly not on both mornings! We're
still using the same 2 element quad at 170 feet,, but we now have
a much better receiving antenna, a W8JI/W5ZN 8-circle receiving
array.

73
Frank
W3LPL

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

From: "Chester Alderman" <[hidden email]>
To: [hidden email], "Elecraft Reflector" <[hidden email]>
Sent: Tuesday, February 14, 2017 3:53:30 PM
Subject: RE: [Elecraft] Feature Request: improved internal keyer and CW PTT behavior

First, I admit to not understanding the problem! I do run QSK and VOX during
contest and during regular QRQ QSO's. With my K3/Alpha 9500 setup, I can run
full QSK CW up to 100 wpm and I have no PTT delay issues? I do not run with
PTT asserted and therefore I do not witness the issues other contesters
have.. As for N1MM's "poorly designed internal K3 keyer logic", I certainly
have to disagree with that comment. During 'normal' contest I operate from
28 to 40 wpm, full QSK and would go nuts if there were any perturbations
with my K3's keying.

A so called 'solution' to CW stuttering is to purchase and use the K1EL
keyer. The real problem is with Windows op system wherein the CPU is often
interrupted to do 'internal chores'; and when this happens, all I/O ports
are shut down, which causes the CW stutter. Simply turning off the Windows
generated sound, eliminates the stutter issue and the 'requirement' to
purchase the K1EL keyer.

73,
Tom - W4BQF

-----Original Message-----
From: Elecraft [mailto:[hidden email]] On Behalf Of
[hidden email]
Sent: Tuesday, February 14, 2017 12:53 AM
To: Elecraft Reflector
Subject: [Elecraft] Feature Request: improved internal keyer and CW PTT
behavior

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:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]

donovanf

Re: Feature Request: improved internal keyer and CW PTT behavior

In reply to this post by wayne burdick

Hi Wayne,

I made an error in my original email. PTT releases immediately
in CW PTT mode regardless of VOX delay.

Its only in VOX mode that PTT release is delayed by VOX delay,
which makes no logical sense to me.

tks

73
Frank
W3LPL

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

From: "Wayne Burdick" <[hidden email]>
To: [hidden email]
Cc: "Elecraft Reflector" <[hidden email]>
Sent: Tuesday, February 14, 2017 6:04:09 PM
Subject: Re: [Elecraft] Feature Request: improved internal keyer and CW PTT behavior

Is a workaround to simply set the QSK delay to 0 in CW mode even when using PTT?

On Feb 14, 2017, at 7:39 AM, [hidden email] wrote:

k6dgw

Re: Feature Request: improved internal keyer and CW PTT behavior

I'm really confused now [a not uncommon state for me]. I have "mature"
K3 S/N 642. The VOX delay is adjustable by holding the SPEED/MIC knob.
There is a separate delay for CW and SSB. I normally run QSK, but I
just tried semi-breakin now and the two modes have two different
adjustable delays. I use a Winkey-3. I used to use the internal K3
keyer, and I don't remember any problems then either. Before I got the
KPA500, my amp wouldn't do full QSK so I ran semi-breakin all the time.

The subject of the original email doesn't note the Elecraft product, if
it's not a K3 [or K3S I guess] disregard this.

73,

Fred ["Skip"] K6DGW
Sparks NV DM09dn
Washoe County

On 2/14/2017 3:57 PM, [hidden email] wrote:

> Hi Wayne,
>
>
> I made an error in my original email. PTT releases immediately
> in CW PTT mode regardless of VOX delay.
>
>
> Its only in VOX mode that PTT release is delayed by VOX delay,
> which makes no logical sense to me.
>
>
> tks
>
>
> 73
> Frank
> W3LPL
>
> ----- Original Message -----
>
> From: "Wayne Burdick" <[hidden email]>
> To: [hidden email]
> Cc: "Elecraft Reflector" <[hidden email]>
> Sent: Tuesday, February 14, 2017 6:04:09 PM
> Subject: Re: [Elecraft] Feature Request: improved internal keyer and CW PTT behavior
>
> Is a workaround to simply set the QSK delay to 0 in CW mode even when using PTT?
>
>
> On Feb 14, 2017, at 7:39 AM, [hidden email] 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" <[hidden email]>
>> To: [hidden email]
>> Cc: "Elecraft Reflector" <[hidden email]>
>> 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, [hidden email] 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:[hidden email]
>>>
>>> This list hosted by: http://www.qsl.net
>>> Please help support this email list: http://www.qsl.net/donate.html
>>> Message delivered to [hidden email]
>>
>> ______________________________________________________________
>> Elecraft mailing list
>> Home: http://mailman.qth.net/mailman/listinfo/elecraft
>> Help: http://mailman.qth.net/mmfaq.htm
>> Post: mailto:[hidden email]
>>
>> This list hosted by: http://www.qsl.net
>> Please help support this email list: http://www.qsl.net/donate.html
>> Message delivered to [hidden email]
>
> ______________________________________________________________
> Elecraft mailing list
> Home: http://mailman.qth.net/mailman/listinfo/elecraft
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:[hidden email]
>
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
> Message delivered to [hidden email]
>

donovanf

Re: Feature Request: improved internal keyer and CW PTT behavior

Hi Fred,

I never operate QSK, my amp relays aren't fast enough and they
make too much noise. Like many K3 users, I always use either
CW VOX or CW PTT.

The K3 works fine in CW VOX mode, except for the odd behavior
that after PTT is released the VOX delay continues to keep the
transmitter active until the delay set by the Delay pot times out.

Its a different story in CW PTT mode (not QSK). PTT is very
responsive (the transmitter always releases immediately after PTT
is released regardless of delay pot setting). The problem is that if
you use the internal K3 keyer in CW PTT mode, the radio actually
transmits in QSK mode risking damage to slow amplifier relays.

Like many K3 users, I solved the internal keyer problem by using a
K1EL Winkeyer connected to the K3 Key and PTT inputs. That
solution works exactly the way the K3 should work if the logic for
the K3 internal keyer worked as it should.

73
Frank
W3LPL

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

From: "Fred Jensen" <[hidden email]>
To: [hidden email]
Sent: Wednesday, February 15, 2017 12:33:09 AM
Subject: Re: [Elecraft] Feature Request: improved internal keyer and CW PTT behavior

I'm really confused now [a not uncommon state for me]. I have "mature"
K3 S/N 642. The VOX delay is adjustable by holding the SPEED/MIC knob.
There is a separate delay for CW and SSB. I normally run QSK, but I
just tried semi-breakin now and the two modes have two different
adjustable delays. I use a Winkey-3. I used to use the internal K3
keyer, and I don't remember any problems then either. Before I got the
KPA500, my amp wouldn't do full QSK so I ran semi-breakin all the time.

The subject of the original email doesn't note the Elecraft product, if
it's not a K3 [or K3S I guess] disregard this.

73,

Fred ["Skip"] K6DGW
Sparks NV DM09dn
Washoe County

On 2/14/2017 3:57 PM, [hidden email] wrote:

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]

KENT TRIMBLE

Re: Feature Request: improved internal keyer and CW PTT behavior

The solution for operating full QSK with a non-QSK amp is the QSK-2500 (http://qsk2500.myfreesites.net/).

See QST Product Review in September 2016 issue.

73,

Kent K9ZTV

> On Feb 14, 2017, at 7:19 PM, [hidden email] wrote:
>
> I never operate QSK, my amp relays aren't fast enough and they
> make too much noise.
______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]

k6dgw

Re: Feature Request: improved internal keyer and CW PTT behavior

In reply to this post by donovanf

Hmmm ... explain what "CW PTT" mode means, that may be the cause of my
lack of understanding. With VOX enabled, QSK off, and using the
internal keyer, my K3 reverts to receive on the delay time I have set
for CW. I tried it with a minimum delay [whatever 0.00 sets] and it
drops immediately, between letters and sometimes even between code
elements if I get a bit sloppy with the paddle.

Obviously, I'm doing this different than you are.

73,

Fred ["Skip"] K6DGW
Sparks NV DM09dn
Washoe County

On 2/14/2017 5:19 PM, [hidden email] wrote:

> Hi Fred,
>
> I never operate QSK, my amp relays aren't fast enough and they
> make too much noise. Like many K3 users, I always use either
> CW VOX or CW PTT.
>
> The K3 works fine in CW VOX mode, except for the odd behavior
> that after PTT is released the VOX delay continues to keep the
> transmitter active until the delay set by the Delay pot times out.
>
> Its a different story in CW PTT mode (not QSK). PTT is very
> responsive (the transmitter always releases immediately after PTT
> is released regardless of delay pot setting). The problem is that if
> you use the internal K3 keyer in CW PTT mode, the radio actually
> transmits in QSK mode risking damage to slow amplifier relays.
>
> Like many K3 users, I solved the internal keyer problem by using a
> K1EL Winkeyer connected to the K3 Key and PTT inputs. That
> solution works exactly the way the K3 should work if the logic for
> the K3 internal keyer worked as it should.
>
> 73
> Frank
> W3LPL
>
>
>
> ------------------------------------------------------------------------
> *From: *"Fred Jensen" <[hidden email]>
> *To: *[hidden email]
> *Sent: *Wednesday, February 15, 2017 12:33:09 AM
> *Subject: *Re: [Elecraft] Feature Request: improved internal keyer and
> CW PTT behavior
>
> I'm really confused now [a not uncommon state for me]. I have "mature"
> K3 S/N 642. The VOX delay is adjustable by holding the SPEED/MIC knob.
> There is a separate delay for CW and SSB. I normally run QSK, but I
> just tried semi-breakin now and the two modes have two different
> adjustable delays. I use a Winkey-3. I used to use the internal K3
> keyer, and I don't remember any problems then either. Before I got the
> KPA500, my amp wouldn't do full QSK so I ran semi-breakin all the time.
>
> The subject of the original email doesn't note the Elecraft product, if
> it's not a K3 [or K3S I guess] disregard this.
>
> 73,
>
> Fred ["Skip"] K6DGW
> Sparks NV DM09dn
> Washoe County
>
> On 2/14/2017 3:57 PM, [hidden email] wrote:
> > Hi Wayne,
> >
> >
> > I made an error in my original email. PTT releases immediately
> > in CW PTT mode regardless of VOX delay.
> >
> >
> > Its only in VOX mode that PTT release is delayed by VOX delay,
> > which makes no logical sense to me.
> >
> >
> > tks
> >
> >
> > 73
> > Frank
> > W3LPL
> >
> > ----- Original Message -----
> >
> > From: "Wayne Burdick" <[hidden email]>
> > To: [hidden email]
> > Cc: "Elecraft Reflector" <[hidden email]>
> > Sent: Tuesday, February 14, 2017 6:04:09 PM
> > Subject: Re: [Elecraft] Feature Request: improved internal keyer and
> CW PTT behavior
> >
> > Is a workaround to simply set the QSK delay to 0 in CW mode even
> when using PTT?
> >
> >
> > On Feb 14, 2017, at 7:39 AM, [hidden email] 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" <[hidden email]>
> >> To: [hidden email]
> >> Cc: "Elecraft Reflector" <[hidden email]>
> >> 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, [hidden email] 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:[hidden email]
> >>>
> >>> This list hosted by: http://www.qsl.net
> >>> Please help support this email list: http://www.qsl.net/donate.html
> >>> Message delivered to [hidden email]
> >>
> >> ______________________________________________________________
> >> Elecraft mailing list
> >> Home: http://mailman.qth.net/mailman/listinfo/elecraft
> >> Help: http://mailman.qth.net/mmfaq.htm
> >> Post: mailto:[hidden email]
> >>
> >> This list hosted by: http://www.qsl.net
> >> Please help support this email list: http://www.qsl.net/donate.html
> >> Message delivered to [hidden email]
> >
> > ______________________________________________________________
> > Elecraft mailing list
> > Home: http://mailman.qth.net/mailman/listinfo/elecraft
> > Help: http://mailman.qth.net/mmfaq.htm
> > Post: mailto:[hidden email]
> >
> > This list hosted by: http://www.qsl.net
> > Please help support this email list: http://www.qsl.net/donate.html
> > Message delivered to [hidden email]
> >
>
> ______________________________________________________________
> Elecraft mailing list
> Home: http://mailman.qth.net/mailman/listinfo/elecraft
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:[hidden email]
>
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
> Message delivered to [hidden email]
>

Vic Rosenthal

Re: Feature Request: improved internal keyer and CW PTT behavior

In reply to this post by donovanf

In other words, you are saying that the AMP KEY output follows keying and not PTT?

W3LPL wrote: The problem is that if
you use the internal K3 keyer in CW PTT mode, the radio actually
transmits in QSK mode risking damage to slow amplifier relays.
--
Vic 4X6GP
______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]

donovanf

Re: Feature Request: improved internal keyer and CW PTT behavior

In reply to this post by k6dgw

Hi Fred,

CW PTT is the K3 CW operating mode when VOX is off and
QSK is disabled.

Two distinct categories of messages are sent during CW contests:

-- prerecorded messages (CQ, exchange and end of QSO messages)
They're usually stored in an external computer so that they can
be instantly started and prematurely stopped by the contest
logging program if necessary.

-- real time operator originated messages, keyboard or paddle sent

For pre-recorded messages its important that the transceiver
switch from transmit to receive in less than the timing for
one Morse inter-character space (three Morse elements). At
35 WPM an inter-character space is approximately 100 milliseconds.

Transmit-to-receive switchover longer than 100 milliseconds will
frequently result in the receiver not being active when the other
station is sending the first Morse element of his callsign,
resulting in a mis-copied callsign or a request for a repeat.

In order for a K3 to meet the 100 millisecond transmit-receive
switchover requirement for pre-recorded messages, the K3 can be
operated in QSK mode, CW PTT mode, or CW VOX mode with
front panel VOX delay set to near zero.

For real time operator sent messages (e.g., requests for repeats
or brief text messages) the transmit-to-receive changeover timing
isn't as critical and a 200 millisecond VOX delay is usually acceptable.

Many contest operators prefer to use a paddle to send real time
messages, some use a computer keyboard. If the internal keyer
in the K3 is used to send real time messages, only QSK can be
used with the current K3 implementation of its internal keyer.

If CW PTT is selected by the operator, unfortunately the K3
actually sends the message in QSK mode. If the operator selects
CW VOX mode, a very short VOX delay will result in VOX
dropouts between every character and word. If the operator
increases the VOX delay to at least 250 milliseconds to avoid
inter-character and inter-word dropouts, the 100 millisecond
transmit-receive switchover for real time messages cannot be
achieved because unfortunately the K3 adds a VOX delay to
the end of the computer generated PTT when the K3 is in VOX
mode.

One solution is to operate the K3 only in QSK mode, but many
operators prefer not to use QSK.

A very effective solution is to use an external K1EL Winkeyer
and not use the internal K3 keyer because of its unacceptable
behavior for contest operation.

Perhaps the most desirable solution is to correct the shortcomings
of the current K3 internal keyer and eliminate the unwanted
VOX PTT delay so that K3 behavior is similar to the Winkeyer.

73
Frank
W3LPL

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

From: "Fred Jensen" <[hidden email]>
To: [hidden email]
Sent: Wednesday, February 15, 2017 2:42:35 AM
Subject: Re: [Elecraft] Feature Request: improved internal keyer and CW PTT behavior

Hmmm ... explain what "CW PTT" mode means, that may be the cause of my
lack of understanding. With VOX enabled, QSK off, and using the
internal keyer, my K3 reverts to receive on the delay time I have set
for CW. I tried it with a minimum delay [whatever 0.00 sets] and it
drops immediately, between letters and sometimes even between code
elements if I get a bit sloppy with the paddle.

Obviously, I'm doing this different than you are.

73,

Fred ["Skip"] K6DGW
Sparks NV DM09dn
Washoe County

On 2/14/2017 5:19 PM, [hidden email] wrote:

donovanf

Re: Feature Request: improved internal keyer and CW PTT behavior

In reply to this post by Vic Rosenthal

Hi Vic,

Yes, if you place your K3 in CW mode with VOX off and QSK off,
the amplifier key output turns on and off during every Morse element.

73
Frank
W3LPL

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

From: "Vic Rosenthal" <[hidden email]>
To: [hidden email], [hidden email]
Sent: Wednesday, February 15, 2017 6:12:56 AM
Subject: Re: [Elecraft] Feature Request: improved internal keyer and CW PTT behavior

In other words, you are saying that the AMP KEY output follows keying and not PTT?

W3LPL wrote: The problem is that if
you use the internal K3 keyer in CW PTT mode, the radio actually
transmits in QSK mode risking damage to slow amplifier relays.
--
Vic 4X6GP

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]