KX3 sluggish keyer
Locked
 
|
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:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] |
|
|
Hi Sven,
Please contact Elecraft Customer Support to confirm the address. They are arranging to send you a replacement KXPD3. Cheers, David Elecraft Customer Support |
|
Administrator
|
In reply to this post by Sven Ladegast
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 <[hidden email]> 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:[hidden email] > > This list hosted by: http://www.qsl.net > Please help support this email list: http://www.qsl.net/donate.html > Message delivered to [hidden email] ______________________________________________________________ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] |
|
|
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" <[hidden email]> To: "Sven Ladegast" <[hidden email]> Cc: <[hidden email]> 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 <[hidden email]> 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:[hidden email] >> >> This list hosted by: http://www.qsl.net >> Please help support this email list: http://www.qsl.net/donate.html >> Message delivered to [hidden email] > > ______________________________________________________________ > Elecraft mailing list > Home: http://mailman.qth.net/mailman/listinfo/elecraft > Help: http://mailman.qth.net/mmfaq.htm > Post: mailto:[hidden email] > > This list hosted by: http://www.qsl.net > Please help support this email list: http://www.qsl.net/donate.html > Message delivered to [hidden email] > ______________________________________________________________ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] |
|
|
In reply to this post by Sven Ladegast
Hello David, I think I used the wrong word... "Sluggish" may not be tge correct term to describe the problem. The KXPD3 is mechanically perfect for its size. The touch feel is good and can be adjusted with the different springs to my needs. I meant the "feel" of the keyer, not the key itself. So I do not think a swap of the key makes a difference. But anyway many thanks for offering this swap! 73! Sven, DJ2AT David Shoaf <[hidden email]> schrieb: >Hi Sven, > >Please contact Elecraft Customer Support to confirm the address. They are >arranging to send you a replacement KXPD3. > >Cheers, > >David >Elecraft Customer Support > > > >-- >View this message in context: http://elecraft.365791.n2.nabble.com/KX3-sluggish-keyer-tp7590116p7590121.html >Sent from the Elecraft mailing list archive at Nabble.com. >______________________________________________________________ >Elecraft mailing list >Home: http://mailman.qth.net/mailman/listinfo/elecraft >Help: http://mailman.qth.net/mmfaq.htm >Post: mailto:[hidden email] > >This list hosted by: http://www.qsl.net >Please help support this email list: http://www.qsl.net/donate.html >Message delivered to [hidden email] Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] |
|
Administrator
|
In reply to this post by Igor Sokolov-2
We'll put this on the wish-list. Yes, it would affect both the KXAT3 and the KXAT100.
73, Wayne N6KR On Jun 9, 2014, at 12:52 PM, "Igor Sokolov" <[hidden email]> wrote: > 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. ______________________________________________________________ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] |
|
|
In reply to this post by 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 <[hidden email]> 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 <[hidden email]> 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:[hidden email] >> >> This list hosted by: http://www.qsl.net >> Please help support this email list: http://www.qsl.net/donate.html >> Message delivered to [hidden email] > Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] |
|
|
In reply to this post by Sven Ladegast
Retuning to preset frequencies is a plus when operating with same antennas.
It is a problem with portable antennas. If a portable antenna has a bandwidth of 300KHz, why should it require a retune every 20 KHz? I would vote for a menu choice to select either presets or tuning on demand as in K2. Ignacy, NO9E |
|
|
In reply to this post by Sven Ladegast
In reply to Sven Ladegast, Wayne said...
. . . 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. . . . Hi. I'd certainly like that option in the future if it were to become available. To me, it makes more sense, especially if you've actually taken the trouble to "train" the ATU for the antenna in use. (Now.. If it were also possible to backup and restore ATU "training data", that'd be a nice feature too.) The odd relay click during tuning is not an issue for me, but I guess for some it could be regarded as an extra unwanted power drain if running on internal cells, so yes, a menu selected option would be ideal for all I think. Best Regards. Dave G0WBX. ______________________________________________________________ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] |
|
|
In reply to this post by wayne burdick
Hello Wayne,
I used the ATU clear method to clear any L/C combinations before using a new antenna and allow the tuner to tune up the antenna before transmission. This solved the problem with ATU updates between the words. The missing dots/dahs problem could be solved by a small modification to the KXPD3: I put two small soldering eyelets on each of the outer side of the paddle arms under the countersunk screw that holds the spring in place. I soldered very light isolated bus wire to these eyelets and directly cabled them to the GND pin of the KXPD3 connector plus I used the "firm" spring supplied with the paddle kit. - Problem solved! The contacts at my paddle also has the convex shape and the contact rolls are mode of stainless steel which seems to be the improved version. I cleaned the contacts using 100% alcohol. So far I am happy with that solution and it does not really disturb the optical appearance of the KXPD3 but improves keying reliability a lot. vy 73! Sven, DJ2AT ______________________________________________________________ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] |
|
In reply to this post by Sven Ladegast
The problem, according to my own experience, is that the ground in intermittent. Each paddle arm is the ground that makes contact with each standoff. Without a good grounding, the contact action between the set screw and the standoff is sometimes hit or miss. The reason the ground is occasionally weak is because the contact with ground by each keying paddle is designed to be via the pivot pins of each paddle arm. They are independent and sometimes intermittent grounding occurs. This results is missed dots or dashes (dits/dahs) being keyed. There are some solutions outlined on the web whereby one does a little soldering of two small wires to ground and then screw down the opposite ends of said wire under the heads of each countersunk screw head on each respective paddle arm. (These screw heads are the spring retainer screws.) I developed another reliable solution whereby no soldering is required. (I am good at soldering but the miniaturization of the solder pads here are very delicate. I feel sure warranty issues come to mind as well. ) A great alternative is to provide backup grounding. To do so, 1. Disassemble as if changing springs. 2. The spring is coated for durability and anti-corrosion. So, on each end, place the spring opening (each end alternatively) on a micro file (or very fine emory board) and remove just the coating on the ends that contact the arms. 3. Delicately, use a small screwdriver or tool to remove the paint where the spring contacts each arm. Take your time. The paint is durable. Just remove an amount about the size of a lock washer. This will, in effect connect each paddle arm together. 4. When disassembling the key, you removed three allen screws. The heads of these screws fit into a recessed hole. At the bottom of that recess, you will need to remove the paint there as well. You need only do one but I did all three to be sure. 5. Reassemble the keyer. This mod resulted in 100% keying. The original reliability was dependent on the pivot arms of each paddle independently. This mod increases the reliability by transferring a good ground (via the spring) over to the arm that may be intermittently ungrounded. This method is still statistically less than 100% over time, but whereas I was getting keying errors regularly, they have completely disappeared. Happy keying. 73, Bill, AA4BQ 73, Bill - AA4BQ Jupiter, FL. |
|
|
Hello Bill,
> The problem, according to my own experience, is that the ground in > intermittent. Each paddle arm is the ground that makes contact with each > standoff. Well I recognized this problem too and ended up putting an soldering eyelet under each spring retainer screw. I soldered small bus wire to the eyelets and soldered the other ends directly to the GND pad of the 4-pin connector. This seems to work very good whereas clearing the ATU memories prevents the keyer from interrupting your transmission when the ATU is recalling old memory settings and you have used another antenna before. Anyway...I did a lot of QSOs with this modification and still have problems here and there. It seems like the key doesn't like me! :) Some days I need to correct every few words and other days the key is working fine. I have no such problems when using my old Ten Tec model 604 key with built-in keyer. So it should not be my keying itself... Anyhow...I am living with that issue at the moment. Maybe I will upgrade to a Begali Adventure but at the moment the modified stock key is not bothering me too much to pay another $350 for a new key. Anyhow, the KXPD3 is still great bang for the buck and fits nicely to the rig. vy 73! Sven, DJ2AT ______________________________________________________________ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] |
|
|
One of the problems with the paddle is that the arms can move up and down to much. Sometimes my contacts don't touch correctly unless I force the dit arm down. A better job of drilling and machineing of the holes that the arms pivit in would fix the problem. My dit arm has over 150 thousense of an inch of up and down movement.
Sent from my iPhone this time > On Jul 6, 2014, at 2:26 PM, Sven Ladegast <[hidden email]> wrote: > > Hello Bill, > >> The problem, according to my own experience, is that the ground in >> intermittent. Each paddle arm is the ground that makes contact with each >> standoff. > > Well I recognized this problem too and ended up putting an soldering eyelet under each spring retainer screw. I soldered small bus wire to the eyelets and soldered the other ends directly to the GND pad of the 4-pin connector. > > This seems to work very good whereas clearing the ATU memories prevents the keyer from interrupting your transmission when the ATU is recalling old memory settings and you have used another antenna before. > > Anyway...I did a lot of QSOs with this modification and still have problems here and there. It seems like the key doesn't like me! :) Some days I need to correct every few words and other days the key is working fine. > > I have no such problems when using my old Ten Tec model 604 key with built-in keyer. So it should not be my keying itself... > > Anyhow...I am living with that issue at the moment. Maybe I will upgrade to a Begali Adventure but at the moment the modified stock key is not bothering me too much to pay another $350 for a new key. > > Anyhow, the KXPD3 is still great bang for the buck and fits nicely to the rig. > > vy 73! > > Sven, DJ2AT > ______________________________________________________________ > Elecraft mailing list > Home: http://mailman.qth.net/mailman/listinfo/elecraft > Help: http://mailman.qth.net/mmfaq.htm > Post: mailto:[hidden email] > > This list hosted by: http://www.qsl.net > Please help support this email list: http://www.qsl.net/donate.html > Message delivered to [hidden email] Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] |
|
|
I think the ends of the pins are different. Make sure both are pointed in same direction.
Sent from my iPhone ...nr4c. bill > On Jul 7, 2014, at 7:23 AM, Gerry leary <[hidden email]> wrote: > > One of the problems with the paddle is that the arms can move up and down to much. Sometimes my contacts don't touch correctly unless I force the dit arm down. A better job of drilling and machineing of the holes that the arms pivit in would fix the problem. My dit arm has over 150 thousense of an inch of up and down movement. > > Sent from my iPhone this time > >> On Jul 6, 2014, at 2:26 PM, Sven Ladegast <[hidden email]> wrote: >> >> Hello Bill, >> >>> The problem, according to my own experience, is that the ground in >>> intermittent. Each paddle arm is the ground that makes contact with each >>> standoff. >> >> Well I recognized this problem too and ended up putting an soldering eyelet under each spring retainer screw. I soldered small bus wire to the eyelets and soldered the other ends directly to the GND pad of the 4-pin connector. >> >> This seems to work very good whereas clearing the ATU memories prevents the keyer from interrupting your transmission when the ATU is recalling old memory settings and you have used another antenna before. >> >> Anyway...I did a lot of QSOs with this modification and still have problems here and there. It seems like the key doesn't like me! :) Some days I need to correct every few words and other days the key is working fine. >> >> I have no such problems when using my old Ten Tec model 604 key with built-in keyer. So it should not be my keying itself... >> >> Anyhow...I am living with that issue at the moment. Maybe I will upgrade to a Begali Adventure but at the moment the modified stock key is not bothering me too much to pay another $350 for a new key. >> >> Anyhow, the KXPD3 is still great bang for the buck and fits nicely to the rig. >> >> vy 73! >> >> Sven, DJ2AT >> ______________________________________________________________ >> Elecraft mailing list >> Home: http://mailman.qth.net/mailman/listinfo/elecraft >> Help: http://mailman.qth.net/mmfaq.htm >> Post: mailto:[hidden email] >> >> This list hosted by: http://www.qsl.net >> Please help support this email list: http://www.qsl.net/donate.html >> Message delivered to [hidden email] > ______________________________________________________________ > Elecraft mailing list > Home: http://mailman.qth.net/mailman/listinfo/elecraft > Help: http://mailman.qth.net/mmfaq.htm Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] |
|
|
I'll check that out sometime. I only took it partially apart so that I could understand it. I only have trouble with dits once in a while, and I am not using C.W. a lot. I do really appreciate the paddle and the thought that has gone into it. Mine has been very forgiving and durible. I like that there are no wires involved to use it.
Sent from my iPhone this time > On Jul 7, 2014, at 8:00 AM, Nr4c <[hidden email]> wrote: > > I think the ends of the pins are different. Make sure both are pointed in same direction. > > Sent from my iPhone > ...nr4c. bill > > >> On Jul 7, 2014, at 7:23 AM, Gerry leary <[hidden email]> wrote: >> >> One of the problems with the paddle is that the arms can move up and down to much. Sometimes my contacts don't touch correctly unless I force the dit arm down. A better job of drilling and machineing of the holes that the arms pivit in would fix the problem. My dit arm has over 150 thousense of an inch of up and down movement. >> >> Sent from my iPhone this time >> >>> On Jul 6, 2014, at 2:26 PM, Sven Ladegast <[hidden email]> wrote: >>> >>> Hello Bill, >>> >>>> The problem, according to my own experience, is that the ground in >>>> intermittent. Each paddle arm is the ground that makes contact with each >>>> standoff. >>> >>> Well I recognized this problem too and ended up putting an soldering eyelet under each spring retainer screw. I soldered small bus wire to the eyelets and soldered the other ends directly to the GND pad of the 4-pin connector. >>> >>> This seems to work very good whereas clearing the ATU memories prevents the keyer from interrupting your transmission when the ATU is recalling old memory settings and you have used another antenna before. >>> >>> Anyway...I did a lot of QSOs with this modification and still have problems here and there. It seems like the key doesn't like me! :) Some days I need to correct every few words and other days the key is working fine. >>> >>> I have no such problems when using my old Ten Tec model 604 key with built-in keyer. So it should not be my keying itself... >>> >>> Anyhow...I am living with that issue at the moment. Maybe I will upgrade to a Begali Adventure but at the moment the modified stock key is not bothering me too much to pay another $350 for a new key. >>> >>> Anyhow, the KXPD3 is still great bang for the buck and fits nicely to the rig. >>> >>> vy 73! >>> >>> Sven, DJ2AT >>> ______________________________________________________________ >>> Elecraft mailing list >>> Home: http://mailman.qth.net/mailman/listinfo/elecraft >>> Help: http://mailman.qth.net/mmfaq.htm >>> Post: mailto:[hidden email] >>> >>> This list hosted by: http://www.qsl.net >>> Please help support this email list: http://www.qsl.net/donate.html >>> Message delivered to [hidden email] >> ______________________________________________________________ >> Elecraft mailing list >> Home: http://mailman.qth.net/mailman/listinfo/elecraft >> Help: http://mailman.qth.net/mmfaq.htm Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] |
«
Return to Elecraft
|
1 view|%1 views
| Free forum by Nabble | Edit this page |