[Elecraft] Mic gain goes to zero using N1MM

Mike Reublin NF4L nf4l at comcast.net
Wed Sep 9 18:42:51 EDT 2015


Well said!

73, Mike NF4L


> On Sep 9, 2015, at 5:32 PM, Guy Olinger K2AV <k2av.guy at gmail.com> wrote:
> 
> On Wed, Sep 9, 2015 at 11:29 AM, K8TE <billamader at gmail.com> wrote:
>> 
>> In my case, the Mic gain is normally set to 8-9 (CM500 headset).  The anomaly decreases the Mic Gain to zero.  I manually reset it to 8-9 which restores SSB power output to normal.  I haven’t tried any other actions to restore the Mic gain.  All indications I have this is a Mic Gain problem.
>> 
> 
> Since the mic gain, displayed in a digit format, is reported as
> literally going to the digit zero, we must remember that everything
> inside a dotted line within the K3 is entirely SDR. We must carefully
> avoid our decades-ground-in tendency to think of troubles in our
> familiar and comfortable analog fashion. I do include myself in this
> habit and sometimes catch myself going retrograde, having to do a
> brainwave CTL-ALT-DEL, and start over from the beginning.
> 
> This trouble is presenting inside the K3's SDR dotted line. Of the
> eight "pots" on six shaft centers on the left side K3 front panel, all
> those rotational functions *advise* the CPU of their state via
> multiplexed one and zero state data lines. There is no gain
> potentiometer inserted anywhere in the various audio paths, nor is
> there a steady state control voltage from a potentiometer controlling
> a linear pass transistor in the audio string anywhere, thank your
> lucky stars. Remember "scratchy" audio? Just another of the analog
> bugaboos happily banned forever by the K3's mostly SDR hybrid scheme.
> 
> The MIC control function uses a *shared* encoder assigned three
> separate unrelated settings. If the encoder or its physical data
> connection to the CPU was a problem, it would affect all three
> functions MIC, SPEED and DELAY on the front panel. I have heard of the
> encoder going bad and needing to be replaced. If the encoder is
> miscellaneously sending a string of "decrease" encoder signals, it
> should also happen in SPEED or DELAY mode. All the encoder can do is
> send increase or decrease signals. You would have your CW and VOX
> delays going to nothing, or your CW speed going to the 8 WPM minimum.
> 
> The CPU knows what function is currently "on the knob" and the static
> values in force for the three lower left encoder functions. Exactly
> one function at a time is currently assigned to the knob, and the CPU
> interprets a "decrease signal" accordingly. The decrease signal
> travels to the CPU over a multiplexed data line which is either there
> and properly working for many diverse functions or is not for all
> those functions.
> 
> Doesn't this really start to smell like a program issue? That gets you
> to the next thing -- if it is a firmware bug, then the trouble is
> present for ALL K3 users running the affected firmware version(s). And
> we should have lots of reports because every single user of the
> firmware could be experiencing the same problem intermittently.
> 
> The only program code that could isolate the trouble to a *few* users
> would have to be external to the K3. Is it possible for an external
> program to set the MIC gain? This of course is impossible in an analog
> radio priced for ham customers, so analog thinking would not suggest
> that. The trouble would have to be IN an analog radio. But since the
> K3 is digital, we note that page 1 of the K3 programmer's guide has
> "MG * Mic gain" cell in the command table cheet sheet. That just might
> be an "Aha" moment.
> 
> If an external program intermittently sent an MG 000 command to the
> K3, you would inconveniently find the MIC gain set to zero,
> intermittently. Not a K3 intermittent physical problem, but a K3
> *commanded* to set MIC gain at zero, a command which the K3 mindlessly
> obeys, as yet unable to read a contrary indication from the mind of
> the operator. Let me know when the mind-reading K7 shows up. I want
> one. Get rid of a lot of cables and input devices.
> 
> I, myself, with my terribly soft and mumbly radio voice, with
> extensive trials managed to get a good setting for K3 SSB MIC gain,
> compression and TX EQ settings. I was directed to those settings, and
> had those settings confirmed as clear, punchy and understandable over
> the air, by the PVRC contest guru crowd. Predictably I haven't myself
> touched those settings in maybe three or four YEARS now. They are
> still where I put them. They better stay there, too. People don't hear
> me nearly as well when I'm non-K3-processed. It's like turning off the
> amplifier.
> 
> Repeating myself, if it's a third party program on someone's
> particularly configured PC, or with a particular parallel combination
> of running third party programs, then the mic gain to zero problem
> would be scattered and rare. If it's in K3 firmware, it probably would
> have been caught in alpha or beta testing. If if got to the general
> field in a production release, Big E would have been buried in
> complaints.
> 
> Myself, I would suspect something incoming on the control serial line
> like "MIC 010" losing ASCII digits and arriving as "MIC 0", or mangled
> to "MIC 000" or something like that. Does the K3 process a "MIC 0"
> command or consider that an invalid command? I don't know. But poor
> physical connections for external serial lines, or overloading USB
> hubs have resulted in mangled command strings, or two programs
> fighting for exclusive use of the serial line, and those kinds of
> problems far beyond Elecraft's control, are as common as nails. And by
> my reading of this reflector those troubles are frequently first
> blamed on the K3, even if the true chances of that actually being
> correct are worse than hitting the lottery.
> 
> Do follow the support advice to disconnect all the external programs
> and see what happens.
> 
> The complete list of all possible combinations of third party programs
> that can drive a K3 over a serial connection is an absolute witches
> brew of widely scattered quality, from the sublime to the simply
> awful, sometimes implemented in a hamshack with grotesque physical
> arrangements. There are programs in distribution that have known
> problems that the coder has no intention of ever fixing, for any
> number of reasons, and some have publicly stated such. What you got is
> all you are ever going to get with these. Meaning that your particular
> problem could have been reported to the author a thousand times
> without effect. That in a programming world that swiftly keeps moving
> on. And of course this is without mentioning the ubiquitous
> fallibility in PC Bios programs and operating systems.
> 
> Elecraft is your friend. Respect the Elecraft.
> 
> 73, Guy K2AV
> ______________________________________________________________
> Elecraft mailing list
> Home: http://mailman.qth.net/mailman/listinfo/elecraft
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:Elecraft at mailman.qth.net
> 
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
> Message delivered to nf4l at comcast.net



More information about the Elecraft mailing list