OT: Somewhat Interesting Ebay Item--K2

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

donovanf
Hi Richard,


The K3 and external K1EL Winkeyer is a great combination, it corrects
most of the deficiencies of the internal K3 keyer and PTT VOX delay.


Hopefully the next next upgrade of the K3 internal keyer will at least
make it better, if not perfect! The biggest faults are:
- VOX delay added to the tail of the PTT signal when in VOX mode
- inability to use the internal keyer in CW PTT mode, it always reverts to QSK


Thanks for your wise observations!


73
Frank
W3LPL

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

From: "Richard Ferch" <[hidden email]>
To: [hidden email]
Sent: Wednesday, February 15, 2017 3:30:16 PM
Subject: Re: [Elecraft] Feature Request: improved internal keyer and CW PTT behavior


Frank,


In a nutshell, what you would like is PTT control when the CW comes from the computer (via the straight key jack), and VOX when the paddles are used (via the paddle jack).


OK - but it may not be quite as simple as it seems. Not that it cannot be done, but it might not be quite so easy to program and debug.


First off, some users might want VOX from both inputs (in particular, someone using QSK probably would). So, this looks like a new configuration option - VOX from the paddle input only, but not from the straight key input, vs. the standard option with VOX enabled on both inputs. OK so far.


Suppose you are using the paddle and want to continue directly with a computer message. If you hit the function key before the VOX has dropped, the computer will assert PTT and the rig will stay in the transmit state, but you will want the VOX delay to be disabled for the duration of the computer message, i.e. the firmware has to remember not to impose the VOX delay, whereas it would have done so if you had not hit the function key. The state machine is getting a bit more complicated.



Now, what happens if the operator wants to interrupt a computer message by touching the paddle? Using a Winkey, touching the paddle aborts the computer-generated CW. If you want to be able to do this, then touching the paddle will have to turn the VOX delay on and temporarily disable the straight key CW input. Meanwhile, the computer has no way of knowing what has happened, so it has not dropped PTT. If the paddle input plus VOX delay ends before the original PC message is finished, the computer will still be asserting PTT and toggling the CW line. You will want the rig to continue to ignore the straight key input until the computer releases PTT - but in the meanwhile, do you also want the rig to be ignoring the hardware PTT from the computer and switching back to receive, even while the computer is still "transmitting"? This could get messy. Maybe the easier choice would be not to allow paddle input to interrupt the computer keying, so you have to hit the Esc key before usin
 g the paddle. Simpler to implement, but not nearly as convenient as using a Winkey.


Add to this the fact that the interaction between CW and PTT in the K3 has always been somewhat problematic (witness the CW problems when the TX Delay setting is changed from the default 8 ms); throw in the fact that somehow this has to work even when computer PTT is done via software commands rather than a hardware signal (this has historically been a significant problem area for the K3 that was addressed in F/W revision 5.46 after significant testing effort); and maybe programming and debugging this might just turn out to be harder than it looks.


Maybe the easiest solution is just to use a Winkey after all!


73,
Rich VE3KI




______________________________________________________________
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]
Reply | Threaded
Open this post in threaded view
|

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

k6dgw
In reply to this post by donovanf
This is getting harder to understand than organic chemistry was.   See
interspersed questions and results of trying to duplicate. Somehow,
keying an external amp has come into this, the issue I've been trying to
duplicate for you was excessive delay in going back to receive.

On 2/14/2017 10:22 PM, [hidden email] wrote:
> Hi Fred,
>
> CW PTT is the K3 CW operating mode when VOX is off and
> QSK is disabled.
With VOX and QSK off, I can step on the footswitch [or plug the Winkey
PTT output into the K3 PTT jack] and transmit.  When done, either
reverts to RX essentially instantly.  The Winkey may hang just a tiny
bit, very hard to tell.  I will fire up the WK3 Tools program and see if
there's a delay programmed in.
>
> 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
Yes, I operate a lot of CW contests and events, both manually with
pencil/paper logging [just to add some interest to what otherwise
becomes mechanical], and with N1MM+ [when I care about a score].  I'm
somewhat familiar with the protocol.

>
> 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.
I can't make this happen on my K3.  VOX off/QSK off, the K3 reverts to
receive as soon as I release PTT. I use the footswitch on SSB and I've
used the CW+SSB option occasionally.  Works exactly as advertised.
>
> 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.
Hmmm ... "unacceptable behavior for contest operation?"  There are
several thousand K3's out there, many in contests, and a number of
DXpeditions have used them.  That's a fairly broad assertion considering
how common they are and how long the K3 has been around.
>
> 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.
When keying the K3 using RTS/DTR from N1MM+, Windows will very
occasionally lapse into 90 WPM Klingon, almost always at exactly the
worst time, of course.  That's why I went to the WinkeyUSB.  I'm
left-handed but I normally send right. However I have a second paddle on
the internal K3 keyer on the left and I switch often in a contest
depending on which hand is free.  They seem to work exactly the same for me.

I thought I might be able to help but that does not seem to be the case
here.  I'll defer to others who understand what's going on better than I do.

73,

Fred ["Skip"] K6DGW
Sparks NV DM09dn
Washoe County
______________________________________________________________
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]
Reply | Threaded
Open this post in threaded view
|

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

donovanf
Hi Fred,


You can easily replicate the unwanted PTT delay as follows:


- Set the K3 to CW mode,
- Turn VOX on .
- Set the VOX delay to a fairly large delay so its to observe.
- Key the PTT line
- You will observe the unwanted VOX delay after you unkey the PTT line


You can easily replicate the unwanted K3 internal keyer behavior as follows:


- Set the K3 to CW mode
- Turn VOX off
- Plug a paddle into the K3
- Operate the paddle.
- The K3 will switch from transmit to receive and the external amplifier
key output will deactivate after each Morse element, just like it does in QSK mode


73
Frank
W3LPL







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

From: "Fred Jensen" <[hidden email]>
To: [hidden email]
Sent: Wednesday, February 15, 2017 7:07:25 PM
Subject: Re: [Elecraft] Feature Request: improved internal keyer and CW PTT behavior

This is getting harder to understand than organic chemistry was. See
interspersed questions and results of trying to duplicate. Somehow,
keying an external amp has come into this, the issue I've been trying to
duplicate for you was excessive delay in going back to receive.

On 2/14/2017 10:22 PM, [hidden email] wrote:
> Hi Fred,
>
> CW PTT is the K3 CW operating mode when VOX is off and
> QSK is disabled.
With VOX and QSK off, I can step on the footswitch [or plug the Winkey
PTT output into the K3 PTT jack] and transmit. When done, either
reverts to RX essentially instantly. The Winkey may hang just a tiny
bit, very hard to tell. I will fire up the WK3 Tools program and see if
there's a delay programmed in.
>
> 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
Yes, I operate a lot of CW contests and events, both manually with
pencil/paper logging [just to add some interest to what otherwise
becomes mechanical], and with N1MM+ [when I care about a score]. I'm
somewhat familiar with the protocol.

>
> 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.
I can't make this happen on my K3. VOX off/QSK off, the K3 reverts to
receive as soon as I release PTT. I use the footswitch on SSB and I've
used the CW+SSB option occasionally. Works exactly as advertised.
>
> 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.
Hmmm ... "unacceptable behavior for contest operation?" There are
several thousand K3's out there, many in contests, and a number of
DXpeditions have used them. That's a fairly broad assertion considering
how common they are and how long the K3 has been around.
>
> 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.
When keying the K3 using RTS/DTR from N1MM+, Windows will very
occasionally lapse into 90 WPM Klingon, almost always at exactly the
worst time, of course. That's why I went to the WinkeyUSB. I'm
left-handed but I normally send right. However I have a second paddle on
the internal K3 keyer on the left and I switch often in a contest
depending on which hand is free. They seem to work exactly the same for me.

I thought I might be able to help but that does not seem to be the case
here. I'll defer to others who understand what's going on better than I do.

73,

Fred ["Skip"] K6DGW
Sparks NV DM09dn
Washoe County
______________________________________________________________
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]
Reply | Threaded
Open this post in threaded view
|

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

kstover
In reply to this post by Chester Alderman
Using the Winkey is not a requirement. It's just a much better keyer
than the Elecraft keyer.
One chip and some extraneous parts...problem gone.


On 2/14/2017 9:53 AM, Chester Alderman wrote:

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

--
R. Kevin Stover
AC0H
ARRL
FISTS #11993
SKCC #215
NAQCC #3441


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

______________________________________________________________
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]
Reply | Threaded
Open this post in threaded view
|

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

KC6CNN
If it were only a chip change to add a winkeyer 3 inside my K3 I would do it in a heart beat.  


> On Feb 16, 2017, at 6:51 PM, Kevin <[hidden email]> wrote:
>
> Using the Winkey is not a requirement. It's just a much better keyer than the Elecraft keyer.
> One chip and some extraneous parts...problem gone.
>
>
>> On 2/14/2017 9:53 AM, Chester Alderman wrote:
>> 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]
>>
>
> --
> R. Kevin Stover
> AC0H
> ARRL
> FISTS #11993
> SKCC #215
> NAQCC #3441
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
> ______________________________________________________________
> 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]
KC6CNN - Gerald
K3 # 6294
KX3 # 757
Reply | Threaded
Open this post in threaded view
|

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

Bob Wilson, N6TV
In reply to this post by donovanf
donovanf wrote
Hi Richard, The K3 and external K1EL Winkeyer is a great combination, it corrects most of the deficiencies of the internal K3 keyer and PTT VOX delay. Hopefully the next next upgrade of the K3 internal keyer will at least make it better, if not perfect! The biggest faults are: - VOX delay added to the tail of the PTT signal when in VOX mode - inability to use the internal keyer in CW PTT mode, it always reverts to QSK
Hi Frank,

I haven't followed this entire thread, but I believe there is no need for any firmware changes, or a WinKey, to solve this problem.

The problem of unwanted PTT delay when using the internal keyer with VOX, and computer-generated CW/PTT, was already addressed by the improvements to the RX; command in K3 firmware 5.46 and later. Sending an RX; command at the end of all computer-generated CW messages will immediately open the PTT line no matter how long you set the VOX delay, so there will be no delay in receiving when the computer-generated message terminates. You will still get the programmed CW VOX delay when hand-sending, and the PTT will be held closed for the duration of all computer-generated messages, if you follow all of the steps outlined below.

This is easy to do in Win-Test, which is the contest software I think you are using. Other contest loggers have similar features.

This works best connecting paddles directly to the internal keyer of the K3 and avoiding the WinKey entirely.

First set CONFIG:RTS-DTR PTT-KEY

Disconnect the WinKey and disable its serial port.

Tell Win-Test to key CW on the K3 serial port DTR pin, and PTT on the RTS pin (under Options | Interface configuration). Win-Test sends great CW using either real serial ports or FTDI USB-to-Serial adapters. Or you may use legacy LPT port CW/PTT keying circuits if you prefer (set CONFIG:PTT-KEY OFF-OFF when using LPT keying).

Download K3scripts.zip from my Win-Test LUA script web site, https://bit.ly/wtscripts. This contains many useful K3 scripts, including PTTOff.wts, which does the following:

wtRadio:Send("RX;")
return -1

At the end of every CW message programmed in Win-Test, call this script, like this:

CQ $MYCALL $MYCALL~#PTTOFF
$LOGGEDCALL $RST $STATE~#PTTOFF
TU $MYCALL~$CR~#PTTOFF
$MYCALL~#PTTOFF
etc.

In Win-Test, the "~" character is a macro separator, like a blank, but it sends no "space" characters. The macro won't run until the final bit of CW is output.

Now you may put the K3 in semi-breakin mode, with VOX ON, and set the CW VOX delay to whatever works well with your paddling speed (0.21 works pretty well at contest speeds). This CW VOX delay will be overridden at the end of all computer-generated CW messages (except for Alt-K keyboard CW, but I think that's an acceptable exception).

As a final step, make the Escape key halt any CW in progress and immediately open the PTT line too. To do this, assign the following script (name it PlayHalt2.wts), to the Escape key, using the Win-Test Scripts Manager.

-- If Escape key already halted CW, and we were called back
if wtApp:IsPostKeyProcess() then
   wtRadio:Send("RX;")                 -- Send "Receive" command to K3 to open PTT line
   return -1			       -- No further keystroke processing
else				       -- Else, first time through
   return 1			       -- Request normal keystroke processing of Escape key, with
                                       -- callback requested.
end

Please let me know if this solves all the problems you care about regarding unwanted PTT hang delay, Win-Test, and the K3.

73,
Bob, N6TV

Reply | Threaded
Open this post in threaded view
|

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

donovanf
Hi Bob,  

The Win-Test PTTOff script corrects the unwanted K3  PTT VOX delay!

Hopefully Elecraft will eventually eliminate the unwanted PTT VOX delay too.

Thanks

73
Frank
W3LPL  


From: "Bob Wilson [via Elecraft]" <[hidden email]>
To: "donovanf" <[hidden email]>
Sent: Friday, February 17, 2017 10:12:16 AM
Subject: Re: Feature Request: improved internal keyer and CW PTT behavior

donovanf wrote
Hi Richard, The K3 and external K1EL Winkeyer is a great combination, it corrects most of the deficiencies of the internal K3 keyer and PTT VOX delay. Hopefully the next next upgrade of the K3 internal keyer will at least make it better, if not perfect! The biggest faults are: - VOX delay added to the tail of the PTT signal when in VOX mode - inability to use the internal keyer in CW PTT mode, it always reverts to QSK
Hi Frank,

I haven't followed this entire thread, but I believe there is no need for any firmware changes, or a WinKey, to solve this problem.

The problem of unwanted PTT delay when using the internal keyer with VOX, and computer-generated CW/PTT, was already addressed by the improvements to the RX; command in K3 firmware 5.46 and later. Sending an RX; command at the end of all computer-generated CW messages will immediately open the PTT line no matter how long you set the VOX delay, so there will be no delay in receiving when the computer-generated message terminates. You will still get the programmed CW VOX delay when hand-sending, and the PTT will be held closed for the duration of all computer-generated messages, if you follow all of the steps outlined below.

This is easy to do in Win-Test, which is the contest software I think you are using. Other contest loggers have similar features.

This works best connecting paddles directly to the internal keyer of the K3 and avoiding the WinKey entirely.

First set CONFIG:RTS-DTR PTT-KEY

Disconnect the WinKey and disable its serial port.

Tell Win-Test to key CW on the K3 serial port DTR pin, and PTT on the RTS pin (under Options | Interface configuration). Win-Test sends great CW using either real serial ports or FTDI USB-to-Serial adapters. Or you may use legacy LPT port CW/PTT keying circuits if you prefer (set CONFIG:PTT-KEY OFF-OFF when using LPT keying).

Download K3scripts.zip from my Win-Test LUA script web site, https://bit.ly/wtscripts. This contains many useful K3 scripts, including PTTOff.wts, which does the following:

wtRadio:Send("RX;")
return -1

At the end of every CW message programmed in Win-Test, call this script, like this:

CQ $MYCALL $MYCALL~#PTTOFF
$LOGGEDCALL $RST $STATE~#PTTOFF
TU $MYCALL~$CR~#PTTOFF
$MYCALL~#PTTOFF
etc.

In Win-Test, the "~" character is a macro separator, like a blank, but it sends no "space" characters. The macro won't run until the final bit of CW is output.

Now you may put the K3 in semi-breakin mode, with VOX ON, and set the CW VOX delay to whatever works well with your paddling speed (0.21 works pretty well at contest speeds). This CW VOX delay will be overridden at the end of all computer-generated CW messages (except for Alt-K keyboard CW, but I think that's an acceptable exception).

As a final step, make the Escape key halt any CW in progress and immediately open the PTT line too. To do this, assign the following script (name it PlayHalt2.wts), to the Escape key, using the Win-Test Scripts Manager.

-- If Escape key already halted CW, and we were called back
if wtApp:IsPostKeyProcess() then
   wtRadio:Send("RX;")                 -- Send "Receive" command to K3 to open PTT line
   return -1			       -- No further keystroke processing
else				       -- Else, first time through
   return 1			       -- Request normal keystroke processing of Escape key, with
                                       -- callback requested.
end

Please let me know if this solves all the problems you care about regarding unwanted PTT hang delay, Win-Test, and the K3.

73,
Bob, N6TV


If you reply to this email, your message will be added to the discussion below:
http://elecraft.365791.n2.nabble.com/OT-Somewhat-Interesting-Ebay-Item-K2-tp7626862p7627035.html
This email was sent by Bob Wilson (via Nabble)
To receive all replies by email, subscribe to this discussion

12