[Elecraft] [K1] CW Paddle Contact Bounce
David Brown
dbbrown624 at gmail.com
Tue Feb 24 16:40:16 EST 2015
I have owned a K1 for almost 15 years and have always used it with either a
straight key or an external keyer. I have never had a keying problem with
the K1 other than operator errors. Last year I purchased a single lever
paddle to use with the K1's internal keyer. Much to my surprise,
significant keying errors occurred when this new paddle was used with the
k1's internal keyer. With the K1's internal keyer set for 20 WPM, I could
not complete sending the entire alphabet without at least one keying error.
I discovered that sending the Morse letter “A” multiple times, the K1 would
occasionally transmit the letter “N”. Steve, N8WL, used his much newer K1
with my new paddle for this experiment. Sure enough, Steve had about the
same error rate as I had with my K1. I should mention that my K1 has been
updated with the latest updates, including the MCU firmware which matched
that in Steve's K1. So just what is the problem here?
Paddle contact bounce was the prime suspect in these keying errors at this
point. I decided to investigate what contact bounce may exist and how the
K1 deals with it before doing any paddle adjustment or contact cleaning. I
instrumented my K1 with two oscilloscope probes connected to the K1's MCU
that, in addition to performing K1 control functions, controls transmitter
keying and the Iambic mode keyer implementation. One probe was connected to
the MCU keying input and the other to the keying line output that keys the
transmitter. A fairly lengthy investigation can be summarized with the
following observations. First, paddle contact bounce was very prevalent.
For example, the dot contact bounce typically ranged between 3 and 6
milliseconds, but had some occurrences as high as 8 milliseconds. It
appears that in the presence of contact bounce, a false detection of a
contact closure can occur when the MCU keying input voltage must transition
through a region that represents a valid but unintended contact closure. In
the Morse “A” experiment, the MCU keying voltage will initially switch from
6.1 volts down to 1.9 volts with the dot contact closure. In doing this,
the voltage will drop through the vicinity of 3.8 volts which represents a
dash contact closure. The MCU A/D conversion and firmware that monitors
this voltage sometimes mistakenly recognizes this transition as a valid
dash contact closure that is followed by a dot contact closure. When this
happens, the dash contact closure used in sending “A” appears to be ignored
while “N” is being transmitted by the K1.
The K1's paddle contacts are connected to the MCU keying input via a
resistor network that adjusts the MCU input voltage to the values used in
identifying specific paddle contact closures. Capacitor C6 (.01 uF) at the
MCU keying input provides some RC filtering to this keying voltage. Varying
the size of C6 had a very strong influence on the percentage of keying
errors. Larger values of capacitance increased the error rate while smaller
values decreased it. This makes sense in that with a larger C6, the voltage
transition through that "dash contact closure" region is increased in the
"A" experiment, thus increasing the probability of a false contact closure
detection. It is a difficult problem to design a real time A/D conversion
and voltage detection system that meets acceptable A/D charge holding times
in the presence of significant contact bounce. I wound up changing C6 from
the stock .01uF to 100 pF which in turn significantly reduced false paddle
contact closures. In addition to this, paddle adjustments were made to
further eliminate this problem. The contact bounce error rate is not zero,
but it has been reduced to a low background level that is well below my own
paddle use errors. All of the data recorded in this investigation is
presented in a short article in the January 2015 issue of the QRP Quarterly
(http://www.qrparci.org/). I would be interested in hearing from others
that have dealt with contact bounce issues involving the K1.
73, Dave K8AX
More information about the Elecraft
mailing list