Guy,
Don't forget that KEY OUT is driven directly by the 7R signal in the K3 - that signal reaches and controls all the circuits that are turned on for receive. So it cannot be accomplished entirely in firmware without an accompanying hardware change. Any internal hardware change would require a firmware change - I don't think there are explicit signals in the K3 at the moment to create the necessary gating, although they may be combined with other functions in the firmware. 73, Don W3FPR On 3/13/2011 4:12 PM, Guy Olinger K2AV wrote: > I am not so sure that this cannot be accomplished in firmware. > > And I completely get what this causes if one has a complex pre-K3 setup > switching tower-top preamps, etc., whose primary state-change signal comes > from > > Only the CPU knows that VOX is on or off. There is no "VOX lead". "Band > down" and "VOX" share the same physical switch using "tap" and "hold". The > paddle states are interpreted in the CPU, there is no separate physical > keyer circuitry. Follow the /DASH or /DOT leads in the schematic and you > will see it goes straight to the CPU. Also there is no physical monitor > oscillator which is keyed by 7T. > > This gives me the firm gut estimate that firmware CAN clean this up. > 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 |
In reply to this post by Guy, K2AV
If you look at sheet 1 of the RF Board schematic, you will see that Key Out is controlled by 7R, not 7T. I'm pretty sure 7T is not the complement of 7R, as there are separate MCU outputs for them, T5 and R5. This, no doubt, has to do with timing issues. 7R controls numerous switching diodes, so it just can't be disabled in PTT mode, or the monitor wouldn't even work. AND, the MCU does not have a spare pin which could be used to gate Key Out. So there is clearly no way a firmware change, even with a minor hardware change, can disable Key Out without also disabling the monitor, etc. What firmware COULD do is completely disable transmit mode in PTT mode when the PTT switch is open. That might be a useful option, but it wouldn't allow hearing the internal keyer in rx mode.
That's just the way it is. 73, Scott K9MA On Mar 13, 2011, at 3:12 PM, Guy Olinger K2AV wrote: > I am not so sure that this cannot be accomplished in firmware. > > And I completely get what this causes if one has a complex pre-K3 setup > switching tower-top preamps, etc., whose primary state-change signal comes > from > > Only the CPU knows that VOX is on or off. There is no "VOX lead". "Band > down" and "VOX" share the same physical switch using "tap" and "hold". The > paddle states are interpreted in the CPU, there is no separate physical > keyer circuitry. Follow the /DASH or /DOT leads in the schematic and you > will see it goes straight to the CPU. Also there is no physical monitor > oscillator which is keyed by 7T. > > This gives me the firm gut estimate that firmware CAN clean this up. > > HOWEVER... And a BIG HOWEVER... > > The same gut gestimates that the code that is touched is all over the place, > would require a lot of testing because of everything that is involved, and > therefore it goes on the priority list just like everything else, and > weighted as "extensive". And we want the big E to stay in business, so > other development must go on. Wayne might want to state whether this is on > the list somewhere. Then future queries can be answered: "It's on the > list," and some day a firmware release will fix it. > > BEYOND THAT, HOWEVER NUMBER TWO... > > If the clanking relay while phantom sending is an issue, isn't the clanking > relay in normal sending also an issue? Don't blame the danging clanging > relay on the K3. Fix the $%&*(@!!@ AMP. I modified all my amps with fast > vacuum relays that are sound isolated by putting them on a blob of RTV. End > of the )()*(^%$##&*))!! clanging. For casual operating, I like to work > without headphones, so the clanging is super-irritating. The diversity is > really pretty good through stereo speakers, even if not quite as "spread" as > using headphones. > > Since 99.999% of my operating is regular operation, the danging clanging > (which I hate) is the AMP's problem. Not the K3's. For me that's a deal > killer for some of the Alpha's. > > 73, Guy. > > > > On Sun, Mar 13, 2011 at 1:27 PM, Jim McCook <[hidden email]> wrote: > >> Ralph, VE7XF, took the words right from my own mouth. This situation is >> unique, extremely annoying, and I have not been able to get used to this >> anomaly after several years. Using my spare FT-1000D is a big relief in >> that particular area. I have asked for a solution to this for years, >> but to no avail. >> >> 73, Jim >> W6YA >> >> >> ______________________________________________________________ >> 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 >> > ______________________________________________________________ > 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 Scott Ellington Madison, Wisconsin USA ______________________________________________________________ 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 |
You don't have to disable anything. Follow all the leads and you will see
that: 1) VOX is a firmware state only from tap vs. hold on a button shared with "band down". 2) PTT IN is routed to the CPU via an import path only without exporting any effect around the CPU directly to the physical post CPU circuitry. 3) PADDLE is routed to the CPU via an import path only without exporting any effect around the CPU directly to the physical post CPU circuitry. 4) KEY IN is routed to the CPU via an import path only without exporting any effect around the CPU directly to the physical post CPU circuitry. 5) Mon audio is added to number streams that are sent to audio DAC's creating phone, speaker and line out monitor outputs. 6) 7R and 7T are leads which drive just about everything physical in RF/IF path mainboard circuitry, but are driven ONLY from the CPU, and are not involved in audio output. Therefore, completely in firmware, if VOX program state is NOT set, PTT IN program state is NOT set, and PADDLE or KEY IN program state IS set, following any processing for PADDLE, if the "or" of processed PADDLE program stat and KEY IN program state IS asserted, then add numeric stream for CW audio to phone, speaker and line out as appropriate, without asserting firmware program state changes for transmitter keying which drive 7R and 7T. This solves the complaint and also allows "keying" the monitor audio without breaking RX as the K3 does now. "Keying" monitor audio, like other "intuitive" concepts floated here, is our attempt to describe K3 functioning with familiar analog words. While "keying" fits from an on/off point of view, whether a given input signal has actual wire connection all the way just depends on tracing through the schematic at the brutal detail level. 73, Guy. On Mon, Mar 14, 2011 at 10:05 AM, Scott Ellington < [hidden email]> wrote: > If you look at sheet 1 of the RF Board schematic, you will see that Key Out > is controlled by 7R, not 7T. I'm pretty sure 7T is not the complement of > 7R, as there are separate MCU outputs for them, T5 and R5. This, no doubt, > has to do with timing issues. 7R controls numerous switching diodes, so it > just can't be disabled in PTT mode, or the monitor wouldn't even work. AND, > the MCU does not have a spare pin which could be used to gate Key Out. So > there is clearly no way a firmware change, even with a minor hardware > change, can disable Key Out without also disabling the monitor, etc. What > firmware COULD do is completely disable transmit mode in PTT mode when the > PTT switch is open. That might be a useful option, but it wouldn't allow > hearing the internal keyer in rx mode. > > That's just the way it is. > > 73, > > Scott K9MA > > > On Mar 13, 2011, at 3:12 PM, Guy Olinger K2AV wrote: > > > I am not so sure that this cannot be accomplished in firmware. > > > > And I completely get what this causes if one has a complex pre-K3 setup > > switching tower-top preamps, etc., whose primary state-change signal > comes > > from > > > > Only the CPU knows that VOX is on or off. There is no "VOX lead". "Band > > down" and "VOX" share the same physical switch using "tap" and "hold". > The > > paddle states are interpreted in the CPU, there is no separate physical > > keyer circuitry. Follow the /DASH or /DOT leads in the schematic and you > > will see it goes straight to the CPU. Also there is no physical monitor > > oscillator which is keyed by 7T. > > > > This gives me the firm gut estimate that firmware CAN clean this up. > > > > HOWEVER... And a BIG HOWEVER... > > > > The same gut gestimates that the code that is touched is all over the > place, > > would require a lot of testing because of everything that is involved, > and > > therefore it goes on the priority list just like everything else, and > > weighted as "extensive". And we want the big E to stay in business, so > > other development must go on. Wayne might want to state whether this is > on > > the list somewhere. Then future queries can be answered: "It's on the > > list," and some day a firmware release will fix it. > > > > BEYOND THAT, HOWEVER NUMBER TWO... > > > > If the clanking relay while phantom sending is an issue, isn't the > clanking > > relay in normal sending also an issue? Don't blame the danging clanging > > relay on the K3. Fix the $%&*(@!!@ AMP. I modified all my amps with > fast > > vacuum relays that are sound isolated by putting them on a blob of RTV. > End > > of the )()*(^%$##&*))!! clanging. For casual operating, I like to work > > without headphones, so the clanging is super-irritating. The diversity > is > > really pretty good through stereo speakers, even if not quite as "spread" > as > > using headphones. > > > > Since 99.999% of my operating is regular operation, the danging clanging > > (which I hate) is the AMP's problem. Not the K3's. For me that's a deal > > killer for some of the Alpha's. > > > > 73, Guy. > > > > > > > > On Sun, Mar 13, 2011 at 1:27 PM, Jim McCook <[hidden email]> wrote: > > > >> Ralph, VE7XF, took the words right from my own mouth. This situation is > >> unique, extremely annoying, and I have not been able to get used to this > >> anomaly after several years. Using my spare FT-1000D is a big relief in > >> that particular area. I have asked for a solution to this for years, > >> but to no avail. > >> > >> 73, Jim > >> W6YA > >> > >> > >> ______________________________________________________________ > >> 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 > >> > > ______________________________________________________________ > > 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 > > Scott Ellington > Madison, Wisconsin > USA > > > > ______________________________________________________________ > 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 > 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 |
No. 7R - which drives Key Out - is used to control receive functions. You *CAN NOT* disable that, as would be required to disable Key Out, without leaving receive functions *ON* which would defeat other functions (like muting) when operating the key. Will this subject please die? This is the way Wayne designed the radio. If you don't like it, get a YaeComWood and stop fussing about an inherent design decision (feature) of the Elecraft rigs. The simple solution is turn off your amplifier or place it in standby if you don't want it keyed. 73, ... Joe, W4TV On 3/14/2011 11:12 AM, Guy Olinger K2AV wrote: > You don't have to disable anything. Follow all the leads and you will see > that: > > 1) VOX is a firmware state only from tap vs. hold on a button shared with > "band down". > > 2) PTT IN is routed to the CPU via an import path only without exporting > any effect around the CPU directly to the physical post CPU circuitry. > > 3) PADDLE is routed to the CPU via an import path only without exporting > any effect around the CPU directly to the physical post CPU circuitry. > > 4) KEY IN is routed to the CPU via an import path only without exporting > any effect around the CPU directly to the physical post CPU circuitry. > > 5) Mon audio is added to number streams that are sent to audio DAC's > creating phone, speaker and line out monitor outputs. > > 6) 7R and 7T are leads which drive just about everything physical in RF/IF > path mainboard circuitry, but are driven ONLY from the CPU, and are not > involved in audio output. > > Therefore, completely in firmware, if VOX program state is NOT set, PTT IN > program state is NOT set, and PADDLE or KEY IN program state IS set, > following any processing for PADDLE, if the "or" of processed PADDLE program > stat and KEY IN program state IS asserted, then add numeric stream for CW > audio to phone, speaker and line out as appropriate, without asserting > firmware program state changes for transmitter keying which drive 7R and 7T. > > This solves the complaint and also allows "keying" the monitor audio without > breaking RX as the K3 does now. > > "Keying" monitor audio, like other "intuitive" concepts floated here, is our > attempt to describe K3 functioning with familiar analog words. While > "keying" fits from an on/off point of view, whether a given input signal has > actual wire connection all the way just depends on tracing through the > schematic at the brutal detail level. > > 73, Guy. > > On Mon, Mar 14, 2011 at 10:05 AM, Scott Ellington< > [hidden email]> wrote: > >> If you look at sheet 1 of the RF Board schematic, you will see that Key Out >> is controlled by 7R, not 7T. I'm pretty sure 7T is not the complement of >> 7R, as there are separate MCU outputs for them, T5 and R5. This, no doubt, >> has to do with timing issues. 7R controls numerous switching diodes, so it >> just can't be disabled in PTT mode, or the monitor wouldn't even work. AND, >> the MCU does not have a spare pin which could be used to gate Key Out. So >> there is clearly no way a firmware change, even with a minor hardware >> change, can disable Key Out without also disabling the monitor, etc. What >> firmware COULD do is completely disable transmit mode in PTT mode when the >> PTT switch is open. That might be a useful option, but it wouldn't allow >> hearing the internal keyer in rx mode. >> >> That's just the way it is. >> >> 73, >> >> Scott K9MA >> >> >> On Mar 13, 2011, at 3:12 PM, Guy Olinger K2AV wrote: >> >>> I am not so sure that this cannot be accomplished in firmware. >>> >>> And I completely get what this causes if one has a complex pre-K3 setup >>> switching tower-top preamps, etc., whose primary state-change signal >> comes >>> from >>> >>> Only the CPU knows that VOX is on or off. There is no "VOX lead". "Band >>> down" and "VOX" share the same physical switch using "tap" and "hold". >> The >>> paddle states are interpreted in the CPU, there is no separate physical >>> keyer circuitry. Follow the /DASH or /DOT leads in the schematic and you >>> will see it goes straight to the CPU. Also there is no physical monitor >>> oscillator which is keyed by 7T. >>> >>> This gives me the firm gut estimate that firmware CAN clean this up. >>> >>> HOWEVER... And a BIG HOWEVER... >>> >>> The same gut gestimates that the code that is touched is all over the >> place, >>> would require a lot of testing because of everything that is involved, >> and >>> therefore it goes on the priority list just like everything else, and >>> weighted as "extensive". And we want the big E to stay in business, so >>> other development must go on. Wayne might want to state whether this is >> on >>> the list somewhere. Then future queries can be answered: "It's on the >>> list," and some day a firmware release will fix it. >>> >>> BEYOND THAT, HOWEVER NUMBER TWO... >>> >>> If the clanking relay while phantom sending is an issue, isn't the >> clanking >>> relay in normal sending also an issue? Don't blame the danging clanging >>> relay on the K3. Fix the $%&*(@!!@ AMP. I modified all my amps with >> fast >>> vacuum relays that are sound isolated by putting them on a blob of RTV. >> End >>> of the )()*(^%$##&*))!! clanging. For casual operating, I like to work >>> without headphones, so the clanging is super-irritating. The diversity >> is >>> really pretty good through stereo speakers, even if not quite as "spread" >> as >>> using headphones. >>> >>> Since 99.999% of my operating is regular operation, the danging clanging >>> (which I hate) is the AMP's problem. Not the K3's. For me that's a deal >>> killer for some of the Alpha's. >>> >>> 73, Guy. >>> >>> >>> >>> On Sun, Mar 13, 2011 at 1:27 PM, Jim McCook<[hidden email]> wrote: >>> >>>> Ralph, VE7XF, took the words right from my own mouth. This situation is >>>> unique, extremely annoying, and I have not been able to get used to this >>>> anomaly after several years. Using my spare FT-1000D is a big relief in >>>> that particular area. I have asked for a solution to this for years, >>>> but to no avail. >>>> >>>> 73, Jim >>>> W6YA >>>> >>>> >>>> ______________________________________________________________ >>>> 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 >>>> >>> ______________________________________________________________ >>> 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 >> >> Scott Ellington >> Madison, Wisconsin >> USA >> >> >> >> ______________________________________________________________ >> 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 >> > ______________________________________________________________ > 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 > 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 |
In reply to this post by Sy Botan
Joe > This is the way Wayne designed the J oe > radio. Fine, if this cannot be corrected, some explanation need to be given in owners manual or specs, so people know what to expect. As it is stated now, it is not clear. Joe >Â If you don't like it, get a YaeComWood and stop fussing Joe > about an inherent design decision (feature) of the Elecraft rigs. Not a good marketing strategy, IMHO. I hope Elecraft is not adopting it. That would be a shame. 73, Â Â Â Â Igor, N1YX ______________________________________________________________ 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 |
In reply to this post by Joe Subich, W4TV-4
Hello Joe et al
>Will this subject please die? This is the way Wayne designed the >radio. If you don't like it, get a YaeComWood and stop fussing >about an inherent design decision (feature) of the Elecraft rigs. The reason this subject will not die is because this design 'feature' is illogical and annoying ... to those K3 users who want to use CW PTT which is not implemented properly in the K3 (or the K2) How did this get past the field testers ? 73 Chris GM3WOJ / ZL1CT |
In reply to this post by k.igor
> Fine, if this cannot be corrected, some explanation need to be > given in owners manual or specs, so people know what to expect. > As it is stated now, it is not clear. What's not clear? Key Out is the logical or of the key input (straight key, internal keyer, PTT and VOX). A low on any of those inputs/internally generated signals reflect as a low on the Key Out whether the K3 is actually generating RF or not (e.g. Test mode or CW in PTT mode with no external PTT). It seems quite simple ... if you don't want your sequencer or amplifier activating when you press the paddles/key put it in "Standby" or turn it off. 73, ... Joe, W4TV On 3/14/2011 12:50 PM, [hidden email] wrote: > > > Joe> This is the way Wayne designed the > J oe> radio. > > > > Fine, if this cannot be corrected, some explanation need to be given in owners manual or specs, so people know what to expect. As it is stated now, it is not clear. > > > > Joe> If you don't like it, get a YaeComWood and stop fussing > Joe> about an inherent design decision (feature) of the Elecraft rigs. > > Not a good marketing strategy, IMHO. I hope Elecraft is not adopting it. That would be a shame. > > > > 73, > > Igor, N1YX > 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 |
In reply to this post by Sy Botan
Joe> What's not clear? Â Key Out is the logical or of the key input Joe> (straight key, internal keyer, PTT and VOX). Â A low on any of Joe> those inputs/internally generated signals reflect as a low on Joe> the Key Out whether the K3 is actually generating RF or not Joe> (e.g. Test mode or CW in PTT mode with no external PTT). Joe, If it would be so clear, this issue would not pop up every month on this list. Something along the lines in your quote above (after the question mark) in the manual under Key Out description probably c ould be sufficient. 73, Igor, N1YX ______________________________________________________________ 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 |
In reply to this post by Joe Subich, W4TV-4
On Mon, Mar 14, 2011 at 3:01 PM, Joe Subich, W4TV <[hidden email]> wrote:
Key Out is the logical or of the key input > (straight key, internal keyer, PTT and VOX). > WRONG. To use your terms and convention, as currently coded in firmware... KEY OUT in CW mode is the logical or of straight key, internal keyer and PTT. Turning on VOX neither asserts nor gates KEY OUT To prove that, place in CW mode, and hit the key or the paddle with VOX off and PTT not asserted. If your amp is connected, out of standby, and uses KEY OUT, it will change state with the CW. This *IS* a FIRMWARE directed behavior. It is not implicit in physical circuitry anywhere. The requested behavior change does not require a hardware change, even though the KEY OUT jack is a hard conversion of 7R from zero state to high voltage short at KEY OUT. When in CW mode, with neither VOX nor PTT asserted, leave the K3 in receive mode, use straight or internal keyer assertion to place monitor audio on the three RX audio DAC's only. This is entirely a firmware change, though possibly an ugly one. 73, Guy. ______________________________________________________________ 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 |
> KEY OUT in CW mode is the logical or of straight key, internal > keyer and PTT. Turning on VOX neither asserts nor gates KEY OUT No, when any of the (input) signals I named - straight key, internal keyer CW, PTT or VOX (note VOX is an input *not* a control state) - is active, Key Out is closed (low impedance to common). That is a logical-or (more specifically logical-NOR since it is a low going signal). It would properly be written: NOT (Straight Key OR Internal Keyer OR PTT OR VOX) What you want is for PTT (input), VOX (input) or QSK (control state) to gate the Key and Keyer. In other words, written as: NOT (((Straight Key OR Internal Keyer) AND (PTT OR VOX)) OR (PTT OR VOX OR QSK)) 73, ... Joe, W4TV On 3/14/2011 3:59 PM, Guy Olinger K2AV wrote: > On Mon, Mar 14, 2011 at 3:01 PM, Joe Subich, W4TV<[hidden email]> wrote: > > Key Out is the logical or of the key input >> (straight key, internal keyer, PTT and VOX). >> > > WRONG. To use your terms and convention, as currently coded in firmware... > > KEY OUT in CW mode is the logical or of straight key, internal keyer and > PTT. Turning on VOX neither asserts nor gates KEY OUT > > To prove that, place in CW mode, and hit the key or the paddle with VOX off > and PTT not asserted. If your amp is connected, out of standby, and uses KEY > OUT, it will change state with the CW. > > This *IS* a FIRMWARE directed behavior. It is not implicit in physical > circuitry anywhere. The requested behavior change does not require a > hardware change, even though the KEY OUT jack is a hard conversion of 7R > from zero state to high voltage short at KEY OUT. > > When in CW mode, with neither VOX nor PTT asserted, leave the K3 in receive > mode, use straight or internal keyer assertion to place monitor audio on the > three RX audio DAC's only. This is entirely a firmware change, though > possibly an ugly one. > > 73, Guy. > 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 |
Joe, I do not understand what you mean by VOX in your assertion below.
There is no VOX steady state input from anywhere. There is no VOX jack or ACC pin named VOX. There is a steady state VOX segment in the LCD display, but that is driven from the CPU across the LCDSCL LCDDI LCDCE LCDMODE multiplex lines. There is no VOX trace on the boards. The VOX input on the BAND- button is momentary. The CPU has to retain the steady state which means "the-operator-wants-VOX operation". You can call it anything you want, but the steady state, as evidenced by the lit VOX segment on the display, only exists in the CPU and somewhere inside the LCD display. Set your K3 to CW mode. Do not assert PTT IN at any time in the procedure below. Turn on VOX, key the rig via PADDLE or KEY, You get both keyed power out and "closure" on KEY OUT with the usual TR switching. The TX led lights roughly following the CW. Turn off VOX, key the rig via paddle or Key. You do not get power out, but you get closure on KEY OUT, and (with the hard connection to 7'r) the rig drops RX with the keying. The TX led does NOT light, even though the radio has done a 7R/7T flip. Whether you call VOX an input, a state, an imperative, or a glizzywichit, VOX on or off has no bearing on whether KEY OUT together with 7R is flipped by KEY or the results of PADDLE. Are you arguing that the behavior just described does not occur? 73, Guy On Mon, Mar 14, 2011 at 4:15 PM, Joe Subich, W4TV <[hidden email]> wrote: > > > KEY OUT in CW mode is the logical or of straight key, internal > > keyer and PTT. Turning on VOX neither asserts nor gates KEY OUT > > No, when any of the (input) signals I named - straight key, internal > keyer CW, PTT or VOX (note VOX is an input *not* a control state) - > is active, Key Out is closed (low impedance to common). That is a > logical-or (more specifically logical-NOR since it is a low going > signal). It would properly be written: > NOT (Straight Key OR Internal Keyer OR PTT OR VOX) > > What you want is for PTT (input), VOX (input) or QSK (control state) > to gate the Key and Keyer. In other words, written as: > NOT (((Straight Key OR Internal Keyer) AND (PTT OR VOX)) OR > (PTT OR VOX OR QSK)) > > 73, > > ... Joe, W4TV > > > On 3/14/2011 3:59 PM, Guy Olinger K2AV wrote: > >> On Mon, Mar 14, 2011 at 3:01 PM, Joe Subich, W4TV<[hidden email]> >> wrote: >> >> Key Out is the logical or of the key input >> >>> (straight key, internal keyer, PTT and VOX). >>> >>> >> WRONG. To use your terms and convention, as currently coded in firmware... >> >> KEY OUT in CW mode is the logical or of straight key, internal keyer and >> PTT. Turning on VOX neither asserts nor gates KEY OUT >> >> To prove that, place in CW mode, and hit the key or the paddle with VOX >> off >> and PTT not asserted. If your amp is connected, out of standby, and uses >> KEY >> OUT, it will change state with the CW. >> >> This *IS* a FIRMWARE directed behavior. It is not implicit in physical >> circuitry anywhere. The requested behavior change does not require a >> hardware change, even though the KEY OUT jack is a hard conversion of 7R >> from zero state to high voltage short at KEY OUT. >> >> When in CW mode, with neither VOX nor PTT asserted, leave the K3 in >> receive >> mode, use straight or internal keyer assertion to place monitor audio on >> the >> three RX audio DAC's only. This is entirely a firmware change, though >> possibly an ugly one. >> >> 73, Guy. >> >> 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 |
Guy,
I think whatever you say makes sense. The only action when paddles are touched in receive mode with VOX off should be keyer side tone, right? Since the sound is software controlled without involvement of 7R signal (I assume this is correct), the rig should remain in receive mode and there is no reason for 7R line to drop down at all. What happens though that all transceiver except final stage goes to transmit. Even P3 freezes for a duration of the tone, sensing that K3 is in transmit. Oh, the TX LED is not activated. Maybe we should use TX LED signal to key amplifier? Kidding, just kidding... By the way, I think the KPA3 is not activated either by the paddles in receive without VOX. Both 7R and 7T are brought to the KPA3 and they are both used to correctly switch the T/R mode of the amplifier. Looking at the whole thing from other perspective. It may or may not be easy to fix, Elecraft chose not to fix and I am not going to jump off the roof because of this. I wish this would be my biggest problem in life. Maybe it is time to follow Joe's advice and "stop fussing about it". Maybe some day I will think about hardware mod to fix it, maybe not. As for now I will not pursue this anymore. 73, Igor, N1YX -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Guy Olinger K2AV Sent: Monday, March 14, 2011 5:52 PM To: Joe Subich, W4TV Cc: Elecraft Reflector Subject: Re: [Elecraft] K3 transmit/amplifier relay Joe, I do not understand what you mean by VOX in your assertion below. There is no VOX steady state input from anywhere. There is no VOX jack or ACC pin named VOX. There is a steady state VOX segment in the LCD display, but that is driven from the CPU across the LCDSCL LCDDI LCDCE LCDMODE multiplex lines. There is no VOX trace on the boards. The VOX input on the BAND- button is momentary. The CPU has to retain the steady state which means "the-operator-wants-VOX operation". You can call it anything you want, but the steady state, as evidenced by the lit VOX segment on the display, only exists in the CPU and somewhere inside the LCD display. Set your K3 to CW mode. Do not assert PTT IN at any time in the procedure below. Turn on VOX, key the rig via PADDLE or KEY, You get both keyed power out and "closure" on KEY OUT with the usual TR switching. The TX led lights roughly following the CW. Turn off VOX, key the rig via paddle or Key. You do not get power out, but you get closure on KEY OUT, and (with the hard connection to 7'r) the rig drops RX with the keying. The TX led does NOT light, even though the radio has done a 7R/7T flip. Whether you call VOX an input, a state, an imperative, or a glizzywichit, VOX on or off has no bearing on whether KEY OUT together with 7R is flipped by KEY or the results of PADDLE. Are you arguing that the behavior just described does not occur? 73, Guy On Mon, Mar 14, 2011 at 4:15 PM, Joe Subich, W4TV <[hidden email]> wrote: > > > KEY OUT in CW mode is the logical or of straight key, internal > > keyer and PTT. Turning on VOX neither asserts nor gates KEY OUT > > No, when any of the (input) signals I named - straight key, internal > keyer CW, PTT or VOX (note VOX is an input *not* a control state) - > is active, Key Out is closed (low impedance to common). That is a > logical-or (more specifically logical-NOR since it is a low going > signal). It would properly be written: > NOT (Straight Key OR Internal Keyer OR PTT OR VOX) > > What you want is for PTT (input), VOX (input) or QSK (control state) > to gate the Key and Keyer. In other words, written as: > NOT (((Straight Key OR Internal Keyer) AND (PTT OR VOX)) OR > (PTT OR VOX OR QSK)) > > 73, > > ... Joe, W4TV > > > On 3/14/2011 3:59 PM, Guy Olinger K2AV wrote: > >> On Mon, Mar 14, 2011 at 3:01 PM, Joe Subich, W4TV<[hidden email]> >> wrote: >> >> Key Out is the logical or of the key input >> >>> (straight key, internal keyer, PTT and VOX). >>> >>> >> WRONG. To use your terms and convention, as currently coded in >> >> KEY OUT in CW mode is the logical or of straight key, internal keyer and >> PTT. Turning on VOX neither asserts nor gates KEY OUT >> >> To prove that, place in CW mode, and hit the key or the paddle with VOX >> off >> and PTT not asserted. If your amp is connected, out of standby, and uses >> KEY >> OUT, it will change state with the CW. >> >> This *IS* a FIRMWARE directed behavior. It is not implicit in physical >> circuitry anywhere. The requested behavior change does not require a >> hardware change, even though the KEY OUT jack is a hard conversion of 7R >> from zero state to high voltage short at KEY OUT. >> >> When in CW mode, with neither VOX nor PTT asserted, leave the K3 in >> receive >> mode, use straight or internal keyer assertion to place monitor audio on >> the >> three RX audio DAC's only. This is entirely a firmware change, though >> possibly an ugly one. >> >> 73, Guy. >> >> 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 ______________________________________________________________ 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 |
In reply to this post by Guy, K2AV
*Hi,
I have been following this thread for a while now and maybe I have misplaced the issue. What is there to fix Igor? I ask this so that I can better understand your concern and application as I don't recall anyone else chiming in on a 'fix' if something is indeed wrong. Always willing to learn. 73's Gary * On 15 March 2011 12:13, Igor Kosvin <[hidden email]> wrote: > Guy, > > I think whatever you say makes sense. The only action when paddles are > touched in receive mode with VOX off should be keyer side tone, right? > Since > the sound is software controlled without involvement of 7R signal (I assume > this is correct), the rig should remain in receive mode and there is no > reason for 7R line to drop down at all. What happens though that all > transceiver except final stage goes to transmit. Even P3 freezes for a > duration of the tone, sensing that K3 is in transmit. Oh, the TX LED is not > activated. Maybe we should use TX LED signal to key amplifier? Kidding, > just > kidding... > By the way, I think the KPA3 is not activated either by the paddles in > receive without VOX. Both 7R and 7T are brought to the KPA3 and they are > both used to correctly switch the T/R mode of the amplifier. > Looking at the whole thing from other perspective. It may or may not be > easy > to fix, Elecraft chose not to fix and I am not going to jump off the roof > because of this. I wish this would be my biggest problem in life. Maybe it > is time to follow Joe's advice and "stop fussing about it". Maybe some day > I > will think about hardware mod to fix it, maybe not. As for now I will not > pursue this anymore. > > 73, > > Igor, N1YX > > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On Behalf Of Guy Olinger K2AV > Sent: Monday, March 14, 2011 5:52 PM > To: Joe Subich, W4TV > Cc: Elecraft Reflector > Subject: Re: [Elecraft] K3 transmit/amplifier relay > > Joe, I do not understand what you mean by VOX in your assertion below. > > There is no VOX steady state input from anywhere. There is no VOX jack or > ACC pin named VOX. There is a steady state VOX segment in the LCD display, > but that is driven from the CPU across the LCDSCL LCDDI LCDCE LCDMODE > multiplex lines. There is no VOX trace on the boards. > > The VOX input on the BAND- button is momentary. The CPU has to retain the > steady state which means "the-operator-wants-VOX operation". You can call > it anything you want, but the steady state, as evidenced by the lit VOX > segment on the display, only exists in the CPU and somewhere inside the LCD > display. > > Set your K3 to CW mode. Do not assert PTT IN at any time in the procedure > below. > > Turn on VOX, key the rig via PADDLE or KEY, You get both keyed power out > and "closure" on KEY OUT with the usual TR switching. The TX led lights > roughly following the CW. > > Turn off VOX, key the rig via paddle or Key. You do not get power out, but > you get closure on KEY OUT, and (with the hard connection to 7'r) the rig > drops RX with the keying. The TX led does NOT light, even though the radio > has done a 7R/7T flip. > > Whether you call VOX an input, a state, an imperative, or a glizzywichit, > VOX on or off has no bearing on whether KEY OUT together with 7R is flipped > by KEY or the results of PADDLE. > > Are you arguing that the behavior just described does not occur? > > 73, Guy > > > On Mon, Mar 14, 2011 at 4:15 PM, Joe Subich, W4TV <[hidden email]> > wrote: > > > > > > KEY OUT in CW mode is the logical or of straight key, internal > > > keyer and PTT. Turning on VOX neither asserts nor gates KEY OUT > > > > No, when any of the (input) signals I named - straight key, internal > > keyer CW, PTT or VOX (note VOX is an input *not* a control state) - > > is active, Key Out is closed (low impedance to common). That is a > > logical-or (more specifically logical-NOR since it is a low going > > signal). It would properly be written: > > NOT (Straight Key OR Internal Keyer OR PTT OR VOX) > > > > What you want is for PTT (input), VOX (input) or QSK (control state) > > to gate the Key and Keyer. In other words, written as: > > NOT (((Straight Key OR Internal Keyer) AND (PTT OR VOX)) OR > > (PTT OR VOX OR QSK)) > > > > 73, > > > > ... Joe, W4TV > > > > > > On 3/14/2011 3:59 PM, Guy Olinger K2AV wrote: > > > >> On Mon, Mar 14, 2011 at 3:01 PM, Joe Subich, W4TV<[hidden email]> > >> wrote: > >> > >> Key Out is the logical or of the key input > >> > >>> (straight key, internal keyer, PTT and VOX). > >>> > >>> > >> WRONG. To use your terms and convention, as currently coded in > firmware... > >> > >> KEY OUT in CW mode is the logical or of straight key, internal keyer and > >> PTT. Turning on VOX neither asserts nor gates KEY OUT > >> > >> To prove that, place in CW mode, and hit the key or the paddle with VOX > >> off > >> and PTT not asserted. If your amp is connected, out of standby, and uses > >> KEY > >> OUT, it will change state with the CW. > >> > >> This *IS* a FIRMWARE directed behavior. It is not implicit in physical > >> circuitry anywhere. The requested behavior change does not require a > >> hardware change, even though the KEY OUT jack is a hard conversion of 7R > >> from zero state to high voltage short at KEY OUT. > >> > >> When in CW mode, with neither VOX nor PTT asserted, leave the K3 in > >> receive > >> mode, use straight or internal keyer assertion to place monitor audio on > >> the > >> three RX audio DAC's only. This is entirely a firmware change, though > >> possibly an ugly one. > >> > >> 73, Guy. > >> > >> > ______________________________________________________________ > 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 > > ______________________________________________________________ > 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 > -- *VK4FD - Motorhome Mobile Elecraft Equipment K3 #679, KPA-500 #018 Living the dream!!!* ______________________________________________________________ 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 |
Free forum by Nabble | Edit this page |