[Elecraft] KX3 sluggish keyer

[Sven Ladegast]

Hello Wayne,

Many thanks for your answer! This sounds exactly like my problem.

Since I am using the KX3 with different antennas it could be that the ATU used old parameters found from one of my other antennas and sent these values to the relays when I start to transmit though I had a perfect match some kHz away before. This at least explains why the ATU starts a tuning and ends up with a bad SWR occassionally plus having a little lag before transmission starts.. Until now I did not utilize the memory clear function for the ATU but I think that clearing memories after using a new antenna would solve this problem completely for me.

I am using iambic mode B with the keyer and if I have some kind of little pause between the dits and dahs during keying the MCU could recognize this as the first word pause and update L/C-data to the tuner which results in an interrupted first character.

Setting the ATU to bypass should also prevent the above problem and should make keying as responsive as normal.

Additionally I will try to sand the contact screws to a convex contact shape as well as adding 2 wires from the GND pad to the each lever's spring holder screw to improve contact reliability.

Many thanks for your explanation Wayne! It just felt the way that the MCU was missing keyer input. Thats why my idea with the interrupts...

Being an engineer is not that easy...you'll always find new problems to already available solutions! Hi

73!

Sven, DJ2AT

Wayne Burdick <n6kr at elecraft.com> schrieb:

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