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<
> sdell...@facstaff.wisc.edu> 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<w...@cox.net> 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:Elecraft@mailman.qth.net
>>>>
>>>> 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:Elecraft@mailman.qth.net
>>>
>>> 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:Elecraft@mailman.qth.net
>>
>> 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:Elecraft@mailman.qth.net
>
> 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:Elecraft@mailman.qth.net
This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
