Date   

Re: Should we adopt the KD8CEC firmware?

Jack, W8TEE
 

I agree with Ron, here. Tim's statement:

    It's important to have a *standard* to write to.

would be nice, but as we all know, there is a difference between coding style and functionality. Cut-and-paste code is also nice to have, but any code may be useful if you can read and understand it. To me, the litmus test of good code is code that can be read and understood easily. When that's true, it becomes much easier to adapt it to your needs. Simple things like using #define's instead of "magic numbers" make it easier to read and adapt code. (If the IDE had a symbolic debugger, I might use constants, although symbolic constants are typeless and that can be a huge benefit in writing reusable code.) Writing "clever" code is rarely a benefit. Which would you rather read:

   a = b >> 1;

or

   averageVoltage = baseVoltage / 2;   // Voltage divider derives average voltage that's applied to pin AVERAGEVOLTAGE

Perhaps the only real reason the first version might make sense is to cause some speed gain in the executed code, or perhaps save some memory. Even that, however, often makes no sense because the Gnu compiler is quite good at optimizations. Indeed, my guess is that the two forms above generate exactly the same code. You can examine the *.lst file to get a feel for the final answer.

The final step before making it available to the public is to ask yourself: What can I do to make it easier to read and understand this code? If you cannot find changes that enhance readability, it's read for prime time. Even then, readers will have difference preferences on the way they would write the code...that's to be expected. However, the fact they have preferences means they can read, understand, and hopefully use the code.

For reasons most can guess, I have not read Ian's code recently, but I'm sure it's readable. The fact that Farhan has even suggested using it as the standard means he's happy with it. If it's possible to conditionally compile the code (e.g., why have a keyer if you know you'll never use CW, leaving some room for additions you know you want), it seems to me to be a moot question.

And to those who argue: "But conditional compiles means the users have to be able to change the code!" Yeah, so what? If you can't change the code, you still have several options: 1) accept the radio "as is", 2) learn enough programming to make the changes you want, or 3) pay a programmer to implement the changes you want. Trying to get a boo-hoo from me for people who don't want to invest a weekend in learning how to make such changes is pretty much going to fall on a deaf set of ears. Besides, this kind of programming is going to get more important down the road, not less. May as well bite the bullet and jump on board...you may even find you like it!

Jack, W8TEE



On Monday, May 14, 2018, 11:53:47 PM EDT, W2CTX <w2ctx@...> wrote:


Tim


   When I write software I don't have reuse as part of my mindset.  I try to make something work that is

broken or develop something new that does not exist.  Once it is tested it is given to the community to

use.


 So if I don't care if others use my code how does that advance the radio?  Well one case comes to mind in that

my keyer code had iambic A/B working correctly.  After I published the firmware I believe Ian looked at it.  Now

he could not cut-n-paste my code into his firmware because he used different timing and different hardware pins.

As he stated in his description of his keyer routine, he looked at my logic and  adapted my code into his.

And as all good programmers do gave me acknowledgement in his header of his keyer module.


So you don't have to create code that can be cut-n-paste to be useful.


rOn

On May 14, 2018 at 10:32 PM Tim Gorman wrote:


John,

If I am writing a function that others might want to use, how do I know
which analog input to look at for a trigger by the CW key?

Does my function need to look at both A3 and A6 just in case? Or do I
use one or the other and let the user worry about fiddling with my code
to make it work?

It's important to have a *standard* to write to.

tim ab0wr



On Mon, 14 May 2018 13:54:44 -0700
"John" wrote:
I disagree that the original software is a good starting point for
building on as its tuning and keying section need work.

I think the uBitx should be shipped with a software that best
promotes it's capabilities. That way the user can enjoy it fully
without having to go through an upgrade process that he may not be
willing to go through.

Making room for later software changes is easy if, as said above, the
software is segmented and shows the "memory cost" of each option.

As an example below is the start of the my ubitx_20.ino file, based
on Ian's 1.061 version.

It is easy to make room by commenting out options to insert one's own
code if desired, or simply enable "extra features".
//================== Compile options for adding/removing features and
saving memory =====================
//When there are no hardware modifications (i.e. wired as per the
HfSignals web-site) // If UNdefined, or commented OUT, assumes that
the CW key is connected to the PTT input (A3) to free-up A6 for //
the handsfree option here. (note that A6 could also be used for SWR
or supply voltage monitoring). No memory impact.


Groups.io Links:

You receive all messages sent to this group.

View/Reply Online (#49147): https://groups.io/g/BITX20/message/49147
View All Messages In Topic (64): https://groups.io/g/BITX20/topic/19183012
Mute This Topic: https://groups.io/mt/19183012/141851
New Topic: https://groups.io/g/BITX20/post
-=-=-
http://www.phonestack.com/farhan/bitx.html The original BITX
http://www.hfsignals.com/index.php/bitx40/ BITX40 by HFSignals
http://www.hfsignals.com/index.php/ubitx/ uBITX by HFSignals
https://amateurradiokits.in/store/ BITX Store by Sunil
http://ubitx.net/ BITX Web Site of Mike ZL1AXG
https://groups.io/g/BITX20/wiki/home Wiki
-=-=-
Change Your Subscription: https://groups.io/g/BITX20/editsub/141851
Group Home: https://groups.io/g/BITX20
Contact Group Owner: BITX20+owner@groups.io
Terms of Service: https://groups.io/static/tos
Unsubscribe:
https://groups.io/g/BITX20/leave/defanged<hr
style="height: 0; border: 0; border-top: 1px solid #aaa; margin: 8px 0;">


Re: Are the uBITX receivers ripe for improvement? -- And some other miscellaneous thoughts.

k4dsb
 

the Bitx40 was also reviewed in QST Labs...back a couple years ago..same circuit as the Bitx20A ( Hendricks )  except 40 meter operation. the specifications were impressive...

I can run it along side my IC756 Pro III and it is amazing how well it does perform.. especially sensitivity.. could it be those complaining have bad construction, alignments?  


K4DSB




From: BITX20@groups.io <BITX20@groups.io> on behalf of Ashhar Farhan <farhanbox@...>
Sent: Sunday, May 13, 2018 1:06 AM
To: BITX20@groups.io
Subject: Re: [BITX20] Are the uBITX receivers ripe for improvement? -- And some other miscellaneous thoughts.
 
The QTC, the sweden's ham radio magazine has put the ubitx+rtl_sdr on par with some top rated ICOM dsp radio. You might want to see how that author did it. 

- f

On Sun, May 13, 2018 at 10:18 AM, Zbigniew L <zlipecki@...> wrote:
On Sat, May 12, 2018 at 08:10 pm, Tom, wb6b wrote:

I see a lot of good conversations here about improving the uBITX transmitter output. However, I see very little about how good the receiver is. My question is, have many people done comparisons of the uBITX receiver vs their other radios; particularly on SSB?

 

In my case I have noticed that my SDR using a cheap dongle seems to outperform the uBITX receiver substantially. Even though I don’t consider the SDR dongles to be the pinnacle of RF design, I guess throwing brute force real time math at the receiver side makes up for some of it.

 

Are the uBITX receivers ripe for improvement?

 

Additional miscellaneous thoughts:

 

Rather than cutting up the uBITX or trying to cram more software into the one Arduino Nano on the uBITX I was pondering running multiple Nano’s communing on the I2C bus. They are only about $3.50 apiece. (The 3.3v bus [albeit barely] is in spec for the Nano.) 

 

But, rather than cutting up the radio I think I’d rather simply treat the uBITX as a peripheral to a Raspberry Pi. I’d place the Pi (and USB audio adaptors) in a metal box packaged in the same case as the uBITX.

 

What I’d do with the Pi is:

 

  1. Process and level the microphone audio for transmitting.
  2. Process, level and noise filter the receive audio, as well use a DSP library to add bandpass and notch filters.
  3. Use one of the digital mode libraries for digital mode communication. 
  4. Maybe get rid of the T/R audio pop while processing the receive audio. 
  5. Control other gizmos I may add to the transceiver.
  6. Put a fancy touch screen display on the whole thing.

Additionally, I’m doing a literature search to see what work has been done on training Neural Nets to decode Morse Code. It would seem that a technology that can identify people, dogs and cats from low resolution photos (although there was a study that found AI could mistake pictures of muffins for chihuahuas), could finally realize an adaptable, reliable CW decoder. (This would run on the Pi, also).

 

I’m sure others must be working on the same things. Anyone know about such projects. That would save time over starting from scratch.

Tom, wb6b

Next time just click on the 3 bars completely to the right, it will show the advance toolbar...

 Zbigniew L...73


 



Testing my antenna #ubitx

John Bignell
 

I built the uBitx and have set up on the 20 metres. Can hear CW and lots of chatter, but have been unable to make a first contact. I tested the PTT mic and the antenna lines seem to be working fine. But it seems like people can not hear me. Any suggestions on troubleshooting my radio's and making my first contact. As a new Ham I have really been at a loss as to what is wrong with my rig?

I am open to any suggestions or tests I can run to make this rig work.


Re: Bitx40 turning clicks #bitx40

 

Try making a RC filter to the power in of the raduino board, after doing this on mine the clicks were all but gone. its two 1200uH caps and a 12ohm resistor. I wish I could give you a schem but my googling is coming up short...knew I should have saved it, but its just a basic rc filter. 

Another suggestion is found here near the top of the post under "Clicks during tuning"
--
David

 N8DAH
Kit-Projects.com


Re: UBITX Assembly Wiki Page #ubitx

MAX <max@...>
 

I don’t know if I did that right or not.  I didn’t see the text I typed come up after I clicked on Save Page.

 

Regards.

 

Max K 4 O D S.

 

I've Never Lost the Wonder.

 

Antique Electronics Site: http://www.angelfire.com/electronic/funwithtubes/

 

 

From: BITX20@groups.io [mailto:BITX20@groups.io] On Behalf Of W7PEA
Sent: Monday, May 14, 2018 10:46 PM
To: BITX20@groups.io
Subject: Re: [BITX20] UBITX Assembly Wiki Page #ubitx

 

Hey Max... care to add some comments to describe this circuit for newer folks.
Do so here... 
https://groups.io/g/BITX20/wiki/uBITX-Reverse-Polarity-Protection


Re: UBITX Assembly Wiki Page #ubitx

MAX <max@...>
 

The idea was not original with me but since you ask I will comment on it.

 

Regards.

 

Max K 4 O D S.

 

I've Never Lost the Wonder.

 

Antique Electronics Site: http://www.angelfire.com/electronic/funwithtubes/

 

 

From: BITX20@groups.io [mailto:BITX20@groups.io] On Behalf Of W7PEA
Sent: Monday, May 14, 2018 10:46 PM
To: BITX20@groups.io
Subject: Re: [BITX20] UBITX Assembly Wiki Page #ubitx

 

Hey Max... care to add some comments to describe this circuit for newer folks.
Do so here... 
https://groups.io/g/BITX20/wiki/uBITX-Reverse-Polarity-Protection


Re: UBITX Assemly Wiki Page #ubitx

Lee
 

For reverse polarity protection I put a 5 amp rectifier in series  from the positive of the power jack and then to both fuses.   No relay or extra parts needed.  Sure I have a .7 volt drop but I do not think the loss would be noticed to the ear on the receiving end.  There is a lot more loss in just changing bands.
--
      Lee - N9LO

    
"I Void Warranties"


Re: UBITX Assembly Wiki Page #ubitx

MAX <max@...>
 

Thank you.

 

Regards.

 

Max K 4 O D S.

 

I've Never Lost the Wonder.

 

Antique Electronics Site: http://www.angelfire.com/electronic/funwithtubes/

 

 

From: BITX20@groups.io [mailto:BITX20@groups.io] On Behalf Of K9HZ
Sent: Monday, May 14, 2018 12:24 PM
To: BITX20@groups.io
Subject: Re: [BITX20] UBITX Assembly Wiki Page #ubitx

 

The diagram was a whole lot better than what i did on my phone though!

 

Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ

 

Owner - Operator

Big Signal Ranch – K9ZC

Staunton, Illinois

 

Owner – Operator

Villa Grand Piton - J68HZ

Soufriere, St. Lucia W.I.

Rent it: www.VillaGrandPiton.com

 

email:  bill@...

 


On May 14, 2018, at 11:59 AM, MAX <max@...> wrote:

Minor details.  Always minor details.  Grin.

 

Regards.

 

Max K 4 O D S.

 

I've Never Lost the Wonder.

 

Antique Electronics Site: http://www.angelfire.com/electronic/funwithtubes/

 

 

From: BITX20@groups.io [mailto:BITX20@groups.io] On Behalf Of K9HZ
Sent: Monday, May 14, 2018 8:15 AM
To: BITX20@groups.io
Subject: Re: [BITX20] UBITX Assembly Wiki Page #ubitx

 

Except you forgot the switch!

 

Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ

 

Owner - Operator

Big Signal Ranch – K9ZC

Staunton, Illinois

 

Owner – Operator

Villa Grand Piton - J68HZ

Soufriere, St. Lucia W.I.

Rent it: www.VillaGrandPiton.com

 

email:  bill@...

 


On May 14, 2018, at 7:22 AM, MAX <max@...> wrote:

Someone asked for a better schematic.  Ask and ye shall receive.

 

I don’t know how to insert an attachment directly into the text body of the email.  You will have to click on it to open it.

 

Regards.

 

Max K 4 O D S.

 

I've Never Lost the Wonder.

 

Antique Electronics Site: http://www.angelfire.com/electronic/funwithtubes/

 

 

From: BITX20@groups.io [mailto:BITX20@groups.io] On Behalf Of MAX
Sent: Monday, May 14, 2018 6:59 AM
To: BITX20@groups.io
Subject: Re: [BITX20] UBITX Assemly Wiki Page #ubitx

 

That’s the best one yet.

 

Regards.

 

Max K 4 O D S.

 

I've Never Lost the Wonder.

 

Antique Electronics Site: http://www.angelfire.com/electronic/funwithtubes/

 

 

From: BITX20@groups.io [mailto:BITX20@groups.io] On Behalf Of K9HZ
Sent: Sunday, May 13, 2018 10:39 PM
To: BITX20@groups.io
Subject: Re: [BITX20] UBITX Assemly Wiki Page #ubitx

 

There is a really trivial solution to this reversing diode-fuse thing.  My drawing is awful but you get the idea…  You just need a 50 cent 10A 12V relay. 

 

<image002.jpg>

 

 

Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ

 

Owner - Operator

Big Signal Ranch – K9ZC

Staunton, Illinois

 

Owner – Operator

Villa Grand Piton – J68HZ

Soufriere, St. Lucia W.I.

Rent it: www.VillaGrandPiton.com

Like us on Facebook! <image003.png>

 

Moderator – North American QRO Group at Groups.IO.

 

email:  bill@...

 

 

From: BITX20@groups.io [mailto:BITX20@groups.io] On Behalf Of Jerry Gaffke via Groups.Io
Sent: Sunday, May 13, 2018 10:08 PM
To: BITX20@groups.io
Subject: Re: [BITX20] UBITX Assemly Wiki Page #ubitx

 

A search for 'reverse polarity" in this forum shows dozens of hits since the uBitx was released in early Dec.
Here's a few of mine:
  https://groups.io/g/BITX20/message/35353
  https://groups.io/g/BITX20/message/39877

  https://groups.io/g/BITX20/message/44499

I've given up trying to right that particular absurdity.

Unfortunately, we have hundreds of new hams with no fuse (or too big of one)
assuming they are protected when they are not.  
And some of them are bound to be a bit too careless as a result.
 
Jerry


On Sun, May 13, 2018 at 07:23 pm, ajparent1/KB1GMX wrote:

One small point. 

If your using diode for reverse polarity protection it is better to place the
fuses BEFORE the diode as then the fuse blows and the diode is less
likely to be fried and also down stream circuits.


Allison

<uBITX Reverse Polarity Protect.gif>


Re: UBITX Assemly Wiki Page #ubitx

Paul Galburt - K2AYZ
 

Very nice documentation.

Does raise a sort loosely related question. If the switch bridging the PA power to the general power is opened, how does the user control PA power. Does it matter if PA power is on all of the time?

The PA power could be controlled by using a 2-pole switch, which has other advantages.

Thanks,

Paul - K2AYZ


Re: ND6T AGC implementation for uBIT-X

Paul Galburt - K2AYZ
 

Please post the files,

Thanks,

Paul-K2AYZ


Re: Variable IF

Alejandro Weber
 

Hi all, Nice work Tom!, I wonder If this mod to the filter does at some point an impedance mismatch? 
There is a way to change center frequency from 200hz to 750hz? 

73! De LU1MAW


Re: No mic audio

 

Tom,

Just tug your defective meters probe wires holding the probes and do the same at the meter end.
These wires fray and probably that why you got low readings.

Raj

At 15-05-18, you wrote:
PROBLEM SOLVED!

Well, actually two problems... initial problem was with voltmeter... it was providing erroneous readings. Once I swapped to newer voltmeter I was getting better measurements. Second problem was bad solder joint at electret mic end... it seems to be working now....

Thank you for your assistance.

Tom NU9R


Re: No mic audio

t.h.mills@...
 

PROBLEM SOLVED!

Well, actually two problems... initial problem was with voltmeter...  it was providing erroneous readings.  Once I swapped to newer voltmeter I was getting better measurements.   Second problem was bad solder joint at electret mic end...   it seems to be working now....

Thank you for your assistance.

Tom NU9R


Re: No mic audio

 

The Q6 is fine.

Now that you have 12.5 on the R66 mic preamp side, you should also get that coltage on one side of R60
as they are connected together.

I suspect a bad solder or a cut track between R60/R66. Check again.

R66 @ 12V end is directly connected to R60 so you should get same voltage.

Raj

At 15-05-18, you wrote:
During PTT I get 1.6V on the emitter, 2.2V on the base and 11V on the collector. I'm getting supply voltage(13VDC) on one side of R66 and 12.5VDC on the side with C64.


Re: ND6T AGC implementation for uBIT-X

Don Stewart
 

I would also like to order an AGC and a click kit. 
Don.  KI7TTX 


On May 14, 2018, at 8:31 PM, Nick VK4PLN <nickpullen@...> wrote:

Hi Kees, 2 of each as well please.
73 Nick VK4PLN


Re: Should we adopt the KD8CEC firmware?

K9HZ <bill@...>
 

Support? You think the uBITx is supported?

This is right off the HFSignals webside as indicates the limit of support: " This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE." And..." If you are interested or building any of the HF Signals’ kits, you can join the BITX20 group by visiting https://groups.io/g/bitx20. That’s the only support we provide. The level of collective wisdom and experience on the Forum is enough to sort out almost any technical problem or question you may have. You will also meet some really great builders on the Forum."

Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ

Owner - Operator
Big Signal Ranch – K9ZC
Staunton, Illinois

Owner – Operator
Villa Grand Piton – J68HZ
Soufriere, St. Lucia W.I.
Rent it: www.VillaGrandPiton.com
Like us on Facebook!

Moderator – North American QRO Group at Groups.IO.

email: bill@wjschmidt.com

-----Original Message-----
From: BITX20@groups.io [mailto:BITX20@groups.io] On Behalf Of W2CTX
Sent: Monday, May 14, 2018 11:22 PM
To: BITX20@groups.io
Subject: Re: [BITX20] Should we adopt the KD8CEC firmware?

If CEC firmware is selected to be the delivered "base" then you must think about the following two implications:

1. Is Ian willing to support the "base" in the future w.r.t. uBITX production hardware changes?
As well as answering all the "newbie" questions about all the options everyone is eluding to?

2. If Ian does not support the "base", then customers will be confused by having CEC as "base" and IAN still supplying CEC firmware that is different.

rOn

On May 14, 2018 at 11:09 PM K9HZ <bill@wjschmidt.com> wrote:


Tim... I think that's where we are today...with the base level, bare bones code shipped from the factory. An increasing number of people are gravitating to the CEC firmware and that gives you an idea of what is desirable in a base-level firmware for the radio. If you really want data on this issue, Arv can set up a poll...and we can vote to see which firmware is being used.


Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ
PJ2/K9HZ

Owner - Operator
Big Signal Ranch – K9ZC
Staunton, Illinois

Owner – Operator
Villa Grand Piton – J68HZ
Soufriere, St. Lucia W.I.
Rent it: www.VillaGrandPiton.com
Like us on Facebook!

Moderator – North American QRO Group at Groups.IO.

email: bill@wjschmidt.com



-----Original Message-----
From: BITX20@groups.io [mailto:BITX20@groups.io] On Behalf Of Tim
Gorman
Sent: Monday, May 14, 2018 4:42 PM
To: BITX20@groups.io
Subject: Re: [BITX20] Should we adopt the KD8CEC firmware?

Think of it this way.

I want to add a Tune item to the menu. The item will send a CW signal and monitor an i2c peripheral for reverse power indication while the CW key is held down.

Do I duplicate the CW transmit functionality in my code in case someone wants to use my code to add the Tune functionality to their program? If I don't do that then it won't work for someone who doesn't operate CW and has deleted the CW function from the software. And the code gets bloated from two different menu items duplicating the same functionality for those that do operate CW.

Or do I wind up having to maintain two versions, one for software that has CW functionality and one for software that doesn't?

It's my opinion that we *need* a base load with a set of common functionality that experimenters can build on. The current software that Ashar provides seems to fit that bill.

If someone wants to load other software then it is up to them to manage all the complexity.

tim ab0wr



On Mon, 14 May 2018 16:38:39 +0000 (UTC) "Jack Purdum via Groups.Io" <jjpurdum=yahoo.com@groups.io> wrote:

I think it could be done without too much confusion by using
preprocessor directives. That way, you don't actually mess with the
code; you only change the symbolic constants you wish to affect. For
example, if you don't use CW or CAT, then

#define CWINTERFACE false // Set this to true if you
want to use CW #define CATINTERFACE false // Set this
to true if you wish to use a CAT interface

and so on. The burden of getting everything right then falls on the
programmer, not the user. The user would, however, be responsible
for their own code additions/deletions.

As to how much space this saves will depend upon the programs
kept/deleted and what you mean by "very much program space". For
some users, 50 bytes might be enough to add something they want at
the cost of deleting some existing feature. The answer to that's
really a try-it-and-see answer.

Jack, W8TEE





---
This email has been checked for viruses by AVG.
https://www.avg.com




Re: Should we adopt the KD8CEC firmware?

Jerry Gaffke
 

I haven't looked at Ian's code yet.
But suspect it is plenty readable.
And if it's readable, there's a bunch of people here that could support it.
And I doubt Farhan would ship with it unless he was confident he understood it
and could make his own mods and fixes.

Farhan would be shipping something that is hopefully stable.
And if Ian is so inclined, he will continue adjusting the code to suit his whims.
Now I'm confused, was there somehow a problem with this? 

Generally, a few hundred lines of C code is fairly easy to figure out.
Though there are exceptions:
    https://www.ioccc.org/2018/algmyr/prog.c
    https://www.ioccc.org/years.html#2018

Jerry, KE7ER


On Mon, May 14, 2018 at 09:24 pm, W2CTX wrote:
If CEC firmware is selected to be the delivered "base" then you must think about the following two implications:

1. Is Ian willing to support the "base" in the future w.r.t. uBITX production hardware changes?
As well as answering all the "newbie" questions about all the options everyone is eluding to?

2. If Ian does not support the "base", then customers will be confused by having CEC as "base" and IAN still supplying CEC firmware that is different.


Re: UBITX Assembly Wiki Page #ubitx

W7PEA
 

OK, I _think_ I improve the image a bit. I put the CAD file and the image on the site as well. Accessible from the assembly page.

W7PEA


Re: No mic audio

t.h.mills@...
 

During PTT I get 1.6V on the emitter, 2.2V on the base and 11V on the collector.  I'm getting supply voltage(13VDC) on one side of R66 and 12.5VDC on the side with C64.


Re: No mic audio

 

On TX there should be large voltage on both side of R66 if not then maybe a relay fault or faulty Q6.
Check all the voltages around Q6.

Raj

At 15-05-18, you wrote:
Yes... the microphone case is ground... blue wire is going to ground and continuity checks good to ground everywhere as best I can tell. Even the metal part of the microphone shows dead short to ground. The purple lead is going to the mic side.

I measure 31 mV on both sides of R60. I get 3 mV on one side of C60 and 31 mV on the other side of C60. The side closest to the connector is 31 mV. Having the mic plugged or not makes no difference. I've measured R60 in the circuit (I know... not always reliable)... it measures 4.68 K Ohms.

There are two mods I've made but shouldn't have any effect. I've installed a DPDT switch for 12VDC input. And, I've installed 40mm fan on the back to keep the heat sync cool. Should have no impact on mic audio at all.

Earlier I was getting 3 mV at the mic element. Suspect bad meter... so, I put a different meter and I'm getting 30 mV. Just for grins I checked the other pins on the mic... I'm getting 5VDC to the ring (PTT). I also checked for AC just in case... no AC on any of the mic pins.