¿ªÔÆÌåÓý

  1. BITX20
  2. Messages
Expanded Topics Messages Polls
Date
Re: Should we adopt the KD8CEC firmware?

 

That is partially correct.? In my keyer code I use the spare pin too.? So converting my code to work with one

pin is not as simple as changing one #define.


rOn

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)
Re: No mic audio

[email protected]
 

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.
Re: uBitX in its new home

W7PEA
 

I love the red, can you send code faster with the red case? ;-)

W7PEA
Re: Should we adopt the KD8CEC firmware?

 

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): /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;">
Re: No mic audio

 

Check the mic polarity. One of the leads behind the capsule is connected to the body and that is ground

Check if there is 12v is on the mic transistor stage when you press ptt.

Raj

At 15-05-18, you wrote:

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.
Re: UBITX Assembly Wiki Page #ubitx

W7PEA
 

Hey Max... care to add some comments to describe this circuit for newer folks.
Do so here...?
/g/BITX20/wiki/uBITX-Reverse-Polarity-Protection
Re: ND6T AGC implementation for uBIT-X

 

Hi Kees, 2 of each as well please.
73 Nick VK4PLN
Re: ND6T AGC implementation for uBIT-X

John KC9H
 

Hi, I would like to order one AGC and one Click kit.
John kc9h.
Re: Should we adopt the KD8CEC firmware?

 

+1 about the poll, HFsignals need to know what their customers are really doing.

73, John (VK2ETA)
Re: adding to base load software

 

Ron,

If I want to add a "Tune" menu item which puts the rig into CW transmit
upon key closure and also measures a voltage indicating the amount of
reverse power just how do I set that menu item up so that others can
use it?

If you have a KD8CEC load where the user has dropped the CW
functionality, how do I get the ubitx into CW mode in order to adjust
the tuner for lowest reverse power?

With the base load from Ashar I have a fixed base to code to. I don't
have to worry about making the code fit all possible options in a
modifiable base software.

Even the menu coding is different between the Ashar base software and
the CEC software. If I code to the current Ashar base and someone tries
to use the code in the CEC software it won't work and what happens
then? Do I get a complaint that my software doesn't work?

It's my opinion that you can't have two different base loads. You can
have one base load and everything else is an option to that. If your
base load is infinitely variable then it isn't really a base load at
all.

Look at John's (vk2eta) message. Most of what he has listed are options
which add to a base functionality. One which isn't is the option to
change what pin is used for the CW key. That creates a problem for
someone writing software dependent on the CW key. It is a change to the
base functionality.

There is nothing wrong with the basic functions of Ashar's current
software. Some of the functions don't work well but that can be fixed.
The fixes become part of the base software. Everyone, both the
appliance operator and the experimenter (and everyone in between), gets
the same base load and when they come on here and ask questions about
how the rig is working (or not working) then everyone is working from
the same base in trying to help with troubleshooting. You don't need a
complete listing of their defines in order to tell what options they
might have or not have.

Maybe I'm too much of a KISS kind of guy. But I've already had enough
problems with my first ubitx that I was glad I had a standard setup
others could easily understand to give me troubleshooting tips.

tim ab0wr



On Mon, 14 May 2018 15:43:22 -0700
"Rod Davis" <km6sn@...> wrote:

Tim, I am a little confused by your post titled Re: [BITX20] Should
we adopt the KD8CEC firmware? You mention a feature you may want to
implement. To me, whether the 'base load' is hfsignals firmware, or
KD8CEC firmware, the problem seems to be the same. You can add or
delete features to/from either firmware. I quote your email: 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. --end
quote-- In your example, especially the second paragraph quoted
above, it seems to me that either 'base load' would suffice. Am I
missing something? Rod KM6SN
Re: Should we adopt the KD8CEC firmware?

 

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)
Re: ubitx raduino issue/AKA the radio doesn't receive

M Garza
 

Here is a link to the info:


Hope this helps,

Marco - KG5PRT?

On Mon, May 14, 2018, 10:07 PM M Garza <mgarza896@...> wrote:
John,
You will need to do the front end diode protection mod before you transmit near your bitx40 or you can blow the front end...? I will look for the info and will post it here.

Marco - KG5PRT?

On Mon, May 14, 2018, 10:01 PM John Knoper <knoperj@...> wrote:
thank you, I'll try to track all that info down.??

Re: Should we adopt the KD8CEC firmware?

 

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 ¨C K9ZC
Staunton, Illinois

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

Moderator ¨C 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.
Re: ubitx raduino issue/AKA the radio doesn't receive

M Garza
 

John,
You will need to do the front end diode protection mod before you transmit near your bitx40 or you can blow the front end...? I will look for the info and will post it here.

Marco - KG5PRT?

On Mon, May 14, 2018, 10:01 PM John Knoper <knoperj@...> wrote:
thank you, I'll try to track all that info down.??

Re: using the BITX on RTTY

 

Hello Tim,

At 45.45 baud and 170 Hz shift it would not be an issue to do it all by software to meet the frequency and timing accuracy requirements.

Writing the frequency for the next RTTY bit to be sent can be triggered by a single byte write over I2C in less than 1/10th of a milisecond as only the last register write activates the clock change.

The CW keyer function of KD8CEC's software could be re-cast for sending canned RTTY messages/beacons.

73, John (VK2ETA)
Re: ubitx raduino issue/AKA the radio doesn't receive

 

thank you, I'll try to track all that info down.??
Re: Should we adopt the KD8CEC firmware?

 

¿ªÔÆÌåÓý

I hope at least this sort of thing gives Ian ideas on how to better structure the firmware for different types of operators.? I could see myself redefining the radio (changing conditional compile variables, recompiling and reloading the firmware) many different ways and times for various operations.? Example:? Field day.? Just CW QRP radio.

?

?

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

?

Owner - Operator

Big Signal Ranch ¨C K9ZC

Staunton, Illinois

?

Owner ¨C Operator

Villa Grand Piton ¨C J68HZ

Soufriere, St. Lucia W.I.

Rent it:

Like us on Facebook!

?

Moderator ¨C North American QRO Group at Groups.IO.

?

email:? bill@...

?

?

From: [email protected] [mailto:[email protected]] On Behalf Of Jack Purdum via Groups.Io
Sent: Monday, May 14, 2018 11:39 AM
To: [email protected]
Subject: Re: [BITX20] Should we adopt the KD8CEC firmware?

?

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

?

?

On Monday, May 14, 2018, 12:10:53 PM EDT, Tim Gorman <tgorman2@...> wrote:

?

?

This is where problems will begin to occur.

?

Are you going to add in functionality to modify ubitx_menu.ino

on the fly? Or are you going to break up ubitx_menu.ino into a lot of

little pieces that can be included/excluded at compile time? How do you

tie including/excluding menu items to controlling the actual compile of

functions in the code?

?

If you just inhibit access to the alignment software after it is used it

doesn't lower the amount of memory used for the program unless you do

so with a recompile and reload. Is that really what we want the user to

have to do?

?

Does deleting a mode actually save very much program space? Most

functions are common between modes, you still have to transition

between receive and transmit, only some variables change value.

?

Does doing all this actually make it harder for the experimenter to

modify the code because it makes it more difficult to lay out all the

interactions between the code that might be affected? I know it's hard

enough for me already to trace through all the code when I want to

change something. Making it more difficult is not what I would want to

see.

?

tim ab0wr

?

On Mon, 14 May 2018 14:18:46 +0000 (UTC)

"Jack Purdum via Groups.Io" <jjpurdum=[email protected]> wrote:

?

> This is a good idea and might make it easier to peel off those

> features not desired. The source already lends itself to this

> approach. I have not studied it closely enough to know whether

> specific files (e.g., ubitx_keyer.ino, ubitx_cat.ino) can be taken

> out of the compile chain as it currently stands.

>

> Jack, W8TEE

>?

>

>? ? On Monday, May 14, 2018, 10:05:13 AM EDT, K9HZ

> <bill@...> wrote:

>?

> In fact, to expand on this¡­ I think Ian should consider block defines

> for sections of the code that people want or don¡¯t want.? He has

> already done this in selecting the type of display (2 line or 4

> line).? Some of the things to block define might be:

>

>? ?

>

> 1.?????? CAT

>

> 2.?????? WSPR

>

> 3.?????? Alignment ?(if you¡¯ve done it once, why do it again?)

>

> 4.?????? CW? (some people only use SSB)

>

> 5.?????? SSB? (some people only use CW).

>

>? ?

>

> I¡¯m sure there are others.? This way there is plenty of room if you

> want to experiment.? Just shut stuff off.? In fact, there could be an

> experiment define that turns on or shuts off your experiments too.

>

>? ?

>

> Just a thought¡­

>

>? ?

>

>? ?

>

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

> PJ2/K9HZ

>

>? ?

>

> Owner - Operator

>

> Big Signal Ranch ¨C K9ZC

>

> Staunton, Illinois

>

>? ?

>

> Owner ¨C Operator

>

> Villa Grand Piton ¨C J68HZ

>

> Soufriere, St. Lucia W.I.

>

> Rent it:

>

> Like us on Facebook!

>

>? ?

>

>?

?

?


Virus-free.

Re: Should we adopt the KD8CEC firmware?

 

This sort of answers my concerns about documentation and software engineering practices...sigh...
Brian K9WIS

---- Tim Gorman <tgorman2@...> 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" <vk2eta@...> 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.
Re: No mic audio

 

You should have more than three millivolts. There is about 5K of
resistance between the TX voltage and the positive lead going to the
microphone element. With no more current than an electret pulls you
should be seeing several volts between the positive lead on the
electret and the ground on the electret (which is usually the case). If
the mic is unhooked you should be seeing full voltage on the connector,
whatever you are feeding into the ubitx, probably somewhere between
11.5v and 14v.

Three millivolts isn't enough to get much output from the electret mic.

You need to check the voltage at the mainboard (use a piece of wire
poked down into the second connector pin if necessary). If you don't
see more voltage than 3mv there then measure at the junction of C60 and
R60 to see what voltage you have.

tim ab0wr

On Mon, 14 May 2018 15:05:32 -0700
t.h.mills@... wrote:

I get 3.0 mV to the connector with good continuity to the microphone.
Re: using the BITX on RTTY

 

A 45 baud FSK RTTY signal changes frequency each 22mS.? The shift for RTTY is 170Hz. From my limited experience (not consulting the datasheet) I expect the si5351 would handle this easily.? ?The trick would be getting the timing of the changes right.? ?A software timer such as the Arduino delay()? may not work as it is pretty inaccurate with small arguments.? ?A hardware timer that generates interrupts should do the trick.??It would be easy to try.?

73 Paul VK3HN.?
67481 - 67500 of 116426