[Elecraft] KX3 sluggish keyer

Mon Jun 9 15:52:52 EDT 2014

Wayne,
It would be indeed very good feature if ATU is updated during RX rather then
the way it works now. Will you do that for KXPA100 with its ATU as well?  I
would very much like that.
BTW is Elecraft going to be presented at WRTC 2014?  Half of transceivers 
(52 out of 104) at WRTC 2010 in Moscow where of Elecraft breed. This time 
there will be 59 teams from all over the world and I expect that Elecraft 
rigs will again be well presented. Hopefully Elecraft will not miss such a 
big international gathering.

73, Igor UA9CDC
----- Original Message ----- 
From: "Wayne Burdick" <n6kr at elecraft.com>
To: "Sven Ladegast" <sven at ladegast.info>
Cc: <elecraft at mailman.qth.net>
Sent: Tuesday, June 10, 2014 1:05 AM
Subject: Re: [Elecraft] KX3 sluggish keyer

> Sven,
>
> This has nothing to do with interrupt routines, etc.
>
> When you transmit, the KX3 first checks to see if you have moved the VFO
> to a new "band segment" for ATU purposes. This is typically every 20 kHz,
> but may be a smaller or larger increment depending on the band and on
> whether you have "trained" the KX3 at multiple points within a band.
>
> If the KX3 finds that new L/C data is available for the segment you're now
> transmitting in, it must retrieve that data and send it to the KXAT3
> module. The KXAT3 has latching relays, so it takes a significant fraction
> of a second (up to about 200 ms) to do all of the relay updates.
>
> In non-CW modes, this L/C update is done immediately, since a one-time
> delay of this length is usually of no concern.
>
> However, in CW mode, a 200-ms delay can interrupt keying. So we had to
> choose between two options:
>
> 1. interrupt the first character sent
>
> 2. attempt to insert the L/C update between words
>
> We chose the latter. As soon as there appears to be a word-space-length
> pause in transmission by the operator, the KX3 will send the new ATU data
> to the KXAT3 and flash the "ATU" icon a couple of times.
>
> In practice this works well most of the time. You may be noticing the
> effect of leaving a word-lengh space, but starting to key the radio just
> before it has completed ATU update, which of course holds off
> transmission.
>
> In a future firmware release we may allow the operator to select automatic
> L/C updates during VFO tuning. The sound of relays updating occasionally
> as the VFO is tuned would be objectionable to many, which is why we didn't
> do it this way initially. If we add this feature, you'll need to select it
> with a menu entry.
>
> 73,
> Wayne
> N6KR
>
>
>
> On Jun 9, 2014, at 9:57 AM, Sven Ladegast <sven at ladegast.info> wrote:
>
>> Hello folks,
>>
>> I am experiencing from time to time that the KX3 internal keyer is kinda
>> "sluggish" and misses here and there a dot or the timing is weird. This
>> mostly happens at the beginning of transmissions.
>>
>> I have tried another key (Kent double paddle) with my KX3 and I can
>> exclude it is the stock paddle which has contact problems. The key is
>> working fine on another external keyer.
>>
>> It is extremely irritating and on some transmissions the ATU starts a new
>> tuning cycle (maybe critical tuning on antenna) and exactly in these
>> moments the keyer misses dots or dashes, often more than one.
>>
>> It seems whenever the MCU has too much to do (tuning cycle of ATU, some
>> other task) the interrupts for the keyer input get lost and the actual
>> character is malformed.
>>
>> It happens with MCU firmware 1.87 and 1.94beta.
>>
>> This is an extremely annoying "feature" which I really would like to go
>> away in one of the next firmware releases.
>>
>> From an embedded developer's point of view I would say that there is too
>> much code executed in interrupt service routines that block the MCU from
>> executing the keyer timing correctly.
>>
>> I have found that parts of the stock paddle have been swapped out to
>> reduce the problem but in my opinion this will not cure the problem.
>> Since contact problems are contributing to the problem one might
>> experience a better keyer timing with exchanged or filed contacts at the
>> paddle but the "sluggish" feeling is still there.
>>
>> I know that this is hard to find in the MCU firmware but there is one
>> directive a firmware developer should follow:
>>
>> When entering an interrupt service routine interrupts must be disabled.
>> *No* code should be executed within an interrupt service routine, instead
>> flags should be set which enables the main loop to execute code depending
>> to that interrupt. The interrupt service routine itself should be left as
>> fast as possible and interupts should be re-enabled as fast as possible.
>>
>> It could also be a problem with some software debouncing algorithm that
>> is used on the keyer input lines. Without seeing any source it is hard to
>> tell where the problem is.
>>
>> I hope that I gave a hint to the developers to look for?
>>
>> vy 73!
>>
>> Sven
>>
>> PS: Feel free to contact me if further information is needed.
>> ______________________________________________________________
>> 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
>
> ______________________________________________________________
> 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 ua9cdc at gmail.com
>