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

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.

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

On May 14, 2018 at 11:09 PM K9HZ <bill@...> 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@...



-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Tim
Gorman
Sent: Monday, May 14, 2018 4:42 PM
To: [email protected]
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@...> 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.

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.

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.

On May 14, 2018 at 11:09 PM K9HZ <bill@...> 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@...



-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Tim Gorman
Sent: Monday, May 14, 2018 4:42 PM
To: [email protected]
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@...> 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.

On May 14, 2018 at 11:13 PM John <vk2eta@...> wrote:

Hello Tim,

The keyer input is also defined so your program only need make reference to the defined label (ANALOG_KEYER here), not the hardware pin per say:

From the code:

#define ANALOG_KEYER? ? (A3)

73, John (VK2ETA)

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): /g/BITX20/message/49147
View All Messages In Topic (64): /g/BITX20/topic/19183012
Mute This Topic: /mt/19183012/141851
New Topic: /g/BITX20/post
-=-=-
The original BITX
BITX40 by HFSignals
uBITX by HFSignals
BITX Store by Sunil
BITX Web Site of Mike ZL1AXG
/g/BITX20/wiki/home Wiki
-=-=-
Change Your Subscription: /g/BITX20/editsub/141851
Group Home: /g/BITX20
Contact Group Owner: [email protected]
Terms of Service: /static/tos
Unsubscribe:

---

/g/BITX20/leave/defanged<hr style="height: 0; border: 0; border-top: 1px solid #aaa; margin: 8px 0;">

So, I double checked all my wiring and everything on the ubitx is correct. Orange wire from digital connector to center / ring on mic jack. Blue from audio connector to ground. And the purple wire from audio connector was to the tip of the mic jack. I tried the home brew electret mic that came with the kit and also a Comet electret mic. Still no mic audio output during transmit.