Vince - shame on you. You did not read the post. You were not to
submit your entry publicly to this reflector -- read the original post!
Because of that, this entry is hereby disqualified, sorry.

Come on people, follow the rules!

W0EB

Jack,

Respectfully, you missed my point. I probably wasn't clear. I didn't
mean a "coding" standard. I meant a standard software load with defined
functionality.

Trying to add functionality that others might want to use, in an
environment of multiple conditional compiles, becomes a true nightmare
of regression testing to insure the added functionality works with all
combinations of the conditional compiles.

Not doing such regression testing and throwing a software modification
out into the wild means many users are going to find that their
individual software load no longer works as intended if they try to use
the software modification.

For instance, your mention of deleting keyer code if you never use CW.
If I develop functionality like a "Tune" option that requires the CW
transmit module and some kind of a CW key to transmit a carrier, it
won't work with someone that has deleted the keyer code using their
conditional compile. If they add my functionality what's the first
thing they are going to see happen? It won't work. Who then gets to
figure out why and then who gets to fix it?

tim ab0wr

On Tue, 15 May 2018 13:25:23 +0000 (UTC)
"Jack Purdum via Groups.Io" <jjpurdum@...> wrote:

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.

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;">

I just need to see someone do it the first time (load in new code) with a step by step explanation and then the light might go on.

?

Whoops, a USB sound card gives you stereo sound output. Plugged into the mike connector for digital work it activates the PTT line with the audio!
The CAT interface works find for PTT and frequency control.
It took me forever to realize the orange PTT wire needs to be disconnected for digital work.

I made a bit of progress, getting a copyable RTTY signal with fldigi on my nearby rig. I couldn't get FT8 to copy. Experimenting with proper audio levels is driving me crazy but I'll figure it out.

The receiver surprised me, with me copying PA & NY on FT8 WHILE CONNECTED TO A DUMMY LOAD. I hope my transmitted signals didn't get out too.

I happened to have a 5v fan that fit the 3d printed panels I bought. I used a 7805 to drop the voltage down. Kinda noisy, going to drop it down to 3 volts. or so.

One awkwardness - the rig runs off of 12 volts which runs thru the power switch. However the usb interface activates the LCD whenever it is plugged in. How many times have I scratched my head with it when it wouldn't transmit even tho the display said it was, because the power switch was off. A solution would be to cut the +5v lead in a USB cable I guess.

In the meantime, a simple CW QSO is in order.
Bo W4GHV

Begin forwarded message:

*From:* allen west <kb4ra67@... <mailto:kb4ra67@...>>
*Date:* May 15, 2018 at 9:08:35 AM EDT
*To:* [email protected] <mailto:[email protected]>
*Subject:* *uBitx*

Just finished putting together uBitx in the Amateur radio kits case.
Turned it on and tuned, heard lots of squeals. After about two minutes
of looking for a signal with minimum antenna the audio quit and cannot
get a sound out of it at all. Any ideas? seems like the tuning and
setup still works.
Al, KB4RA

---

Links:

You receive all messages sent to this group.

View/Reply Online (#49229) | Reply To Group | Reply To Sender | Mute This Topic | New Topic

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
Group Home
Contact Group Owner
Terms Of Service
Unsubscribe From This Group

_._,_._,_

Or the other way around
Nobody is stuck with stock firmware, update to the KD8CEC firmware if
you choose :)

I would be fine with the units coming with latest stock firmware and a
not about KD8CEC possibilities.
Just my 2c

Laurence
KB1HKO

On Tue, May 15, 2018 at 12:38 PM, Vince Vielhaber <vev@...> wrote:

Simple solution. Download the original firmware, modify it and load it onto
your Raduino. Noone ever said you'd be stuck with the CEC firmware if it
came as stock.

Vince.




On 05/15/2018 10:28 AM, Tim Gorman wrote:

Jerry,

Ian's code may be easy for you to read and understand. That is most
definitely *not* the case for many of us.

Any code that can be changed on the fly by defining options to be
included or excluded probably can't be considered "stable". It becomes
a minefield for others trying to add their functionality. Regression
testing to insure the software still works as intended becomes a
nightmare of trying all the numerous options together in a multiplicity
of option combinations.

This is not meant as disparagement Ian's software. It has a lot of
functionality that many people have asked for. Many people are using
it. There is a good reason for that.

But that doesn't mean it is suitable as the base load for all future
ubitx units.

Does Ashar have the resources to do a full regression testing of Ian's
software as it stands today when changes are made to the ubitx hardware?

tim ab0wr

On Mon, 14 May 2018 22:42:01 -0700
"Jerry Gaffke via Groups.Io" <jgaffke@...> wrote:

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:



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.

--
Michigan VHF Corp.

Perhaps you could send this out for bid with Boeing and/or Lockheed.? ?;-)

Demanding regression testing of various convenience factors for us to hack the stock firmware of a $109 radio seems a bit over the top.? All I ask is that the stock firmware be usable.


On Tue, May 15, 2018 at 10:54 am, Tim Gorman wrote:

In complicated software like Ian's regression testing is a requirement.

Or the other way around
Nobody is stuck with stock firmware, update to the KD8CEC firmware if
you choose :)

I would be fine with the units coming with latest stock firmware and a
not about KD8CEC possibilities.
Just my 2c

Laurence
KB1HKO

On Tue, May 15, 2018 at 12:38 PM, Vince Vielhaber <vev@...> wrote:

Simple solution. Download the original firmware, modify it and load it onto
your Raduino. Noone ever said you'd be stuck with the CEC firmware if it
came as stock.

Vince.




On 05/15/2018 10:28 AM, Tim Gorman wrote:

Jerry,

Ian's code may be easy for you to read and understand. That is most
definitely *not* the case for many of us.

Any code that can be changed on the fly by defining options to be
included or excluded probably can't be considered "stable". It becomes
a minefield for others trying to add their functionality. Regression
testing to insure the software still works as intended becomes a
nightmare of trying all the numerous options together in a multiplicity
of option combinations.

This is not meant as disparagement Ian's software. It has a lot of
functionality that many people have asked for. Many people are using
it. There is a good reason for that.

But that doesn't mean it is suitable as the base load for all future
ubitx units.

Does Ashar have the resources to do a full regression testing of Ian's
software as it stands today when changes are made to the ubitx hardware?

tim ab0wr

On Mon, 14 May 2018 22:42:01 -0700
"Jerry Gaffke via Groups.Io" <jgaffke@...> wrote:

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:



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.

--
Michigan VHF Corp.

Simple solution. Download the original firmware, modify it and load it onto
your Raduino. Noone ever said you'd be stuck with the CEC firmware if it
came as stock.

Vince.




On 05/15/2018 10:28 AM, Tim Gorman wrote:

Jerry,

Ian's code may be easy for you to read and understand. That is most
definitely *not* the case for many of us.

Any code that can be changed on the fly by defining options to be
included or excluded probably can't be considered "stable". It becomes
a minefield for others trying to add their functionality. Regression
testing to insure the software still works as intended becomes a
nightmare of trying all the numerous options together in a multiplicity
of option combinations.

This is not meant as disparagement Ian's software. It has a lot of
functionality that many people have asked for. Many people are using
it. There is a good reason for that.

But that doesn't mean it is suitable as the base load for all future
ubitx units.

Does Ashar have the resources to do a full regression testing of Ian's
software as it stands today when changes are made to the ubitx hardware?

tim ab0wr

On Mon, 14 May 2018 22:42:01 -0700
"Jerry Gaffke via Groups.Io" <jgaffke@...> wrote:

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:



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.

--
Michigan VHF Corp.