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 <[email protected]> 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 <[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]
