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" <[email protected]>
To: "Sven Ladegast" <[email protected]>
Cc: <[email protected]>
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 <[email protected]> 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:[email protected]
This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [email protected]
______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[email protected]
This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [email protected]
______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[email protected]
This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [email protected]
