¿ªÔÆÌåÓý

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

 

It isn't an issue of how easy or hard it is to change the software
load. Using defines to do this seems to be a simple and effective way
to do it. John has proved that with his options.

What happens though when User A has deleted the keyer function from his
software and then tries to add the "Tune" function provided by my
software. It won't work. How many users will spend countless hours
trying to figure out why?

That standard code need not be exhaustively tested for all
permutations of the build. Just that the standard build works well
enough to be usable.
That may be true for you. How true will it be for all those rank
novices at software who are trying to become experimenters using the
ubitx platform?

In complicated software like Ian's regression testing is a requirement.
I can't tell you how many times I heard from budget managers that we
didn't need to do regression testing on a new central office switch
software because Western Electric had already tested it and it was a
waste of manpower and budget money. And it eventually *always* came
back to bite us in the backside when we let their view take hold.

What we really have here is an argument over whether the ubitx should
remain simple enough for new experimenters or if we should move to a
model making it competitive with other retail transceivers.

I vote for keeping it simple. If someone wants a software load
providing the functionality of an FT-817 then they can download the
software and install it.

tim ab0wr

On Tue, 15 May 2018 07:55:44 -0700
"Jerry Gaffke via Groups.Io" <jgaffke@...> wrote:

Tim

I disagree.

For example, if the standard code has an iambic keyer but I have run
out of flash trying to implement an SWR indicator, then it would be
handy to free up the flash used by the keyer by changing a #define
from true to false with something like this: #define? IAMBIC_KEYER? ?0

That standard code need not be exhaustively tested for all
permutations of the build. Just that the standard build works well
enough to be usable.

The #define's for conditional compilation may or may not work, if
they don't work they are at least a good indication of the original
programmer's understanding of how he thought it should work.

And if I adjust the standard code through a modification of the
#define's or some other hack to better suit my needs and it does not
work for me, then that is clearly my problem to debug.

Jerry

On Tue, May 15, 2018 at 07:28 am, Tim Gorman wrote:


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.
Re: Should we adopt the KD8CEC firmware?

 

Really? Even if I'm not the one that integrated the software into the
load the operator is using?

If it works with *my* software load and I offer for others to use then
*I* am responsible for making it work with *their* software load?

I don't think so.

This goes back to the original question I asked on this subject. Do I
have to include *all* functionality that might be needed in my software
so it won't be dependent on any other functionality? Do I have to
include code to implement the CW transmit functionality and keyer
functionality in *my* code?

If so then won't this contribute a huge amount of memory bloat in the
final compile?

To me, its the main reason that a simple, stable, functional software
load is of prime importance.

Otherwise software bloat is ensured and experimentation is curtailed as
it gets harder and harder to integrate new ideas that maintain
functionality across all kinds of different loads in a complicated
software environment.

tim ab0wr

On Tue, 15 May 2018 07:29:26 -0700
"Jerry Gaffke via Groups.Io" <jgaffke@...> wrote:

That's an easy one.
If it's your software then *you* are charged with doing the
troubleshooting.

On Tue, May 15, 2018 at 07:16 am, Tim Gorman wrote:


But what happens if the CW option is defined out of the software as
has been suggested to save program space?

Then the defined label won't exist. If my software assumes it *does*
exist then it won't function correctly for some users that try to
integrate it in their load.

Who gets charged with doing the troubleshooting as to why it doesn't
work?
Re: Should we adopt the KD8CEC firmware?

 

We aren't talking about what load *I* want to use.

We are talking about what load should come as standard with a new
ubitx.

If you want to make it harder for a beginning experimenter to make
changes while maximizing the number of functions available for
advanced operators then Ian's code is the way to go for a base load.

If you want to make it simpler and easier for an experimenter to make
changes then a simple, stable load like the current one is the way to
go.

Please note that experimenters range from the brand new software coder
just beginning to learn how to code to the professional coder like Jack.

The more complicated you make the standard load the harder you make it
for the beginning experimenter and/or the beginning amateur to
understand the software -- which is who I thought was the main target
audience for this unit.

I totally understand this. I am a rank amateur when it comes to coding
today. Most of my experience was in machine language and Perl, not
in C, and that experience was more years ago than I like to admit. I
didn't even know what an Arduino was! I spent several nights just
learning how the simple Arduino IDE worked and how to download software
to the NANO. If I had to begin trying to figure out Ian's software to
add in even the most basic, simple functionality I probably would have
given up right at the beginning.

If the majority opinion is that we want to make the ubitx into a
competitor for Yaesu/Elecraft in functionality then I'll be quiet. If
the majority opinion is that we want to continue the ubitx as a platform
for experimentation, both hardware and software, even for the beginning
experimenter then I'll argue till I'm blue in the face that the current
software load is the way to go, even if it does need some minor fixing.

tim ab0wr

On Tue, 15 May 2018 12:38:19 -0400
"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.


Re: Should we adopt the KD8CEC firmware?

 

I have found that the wd2cec code works pretty well for me.? Really like the CAT control With the low power that these units have digital mode seems to make sense. I built mine with a computer fan blowing across the heat sinks and board.?

Ian some constructive suggestions:
I wouldn't mind another switch or knob to vary the rate of tuning.

Have the unit go to USB when in digital and have the unit go into lower sb on the lower frequencies.?

Work on the S meter settings. to make them more comparable. I have tried the various options and the built in smeter action seems random to me. Maybe it is just me.

Without having any other HF multiband radio the micro bitx seems very good.?
Core for Output Transformer

 

In the posts on boosting and/or leveling output power I often see pictures of a binocular core being used as the output transformer?in place of the toroid that comes with the uBitx board. What size is that binocular core? I'm getting ready to order some toroids and would like to throw a couple of those on the order so I will have?one for my scratch build.?Thanks and 73
Jerry - W0PWE
Re: Should we adopt the KD8CEC firmware?

 

ARE YOU KIDDING ME -- IT FITS !


That is what this whole discussion is about - it doesn't fit.


rOn

On May 15, 2018 at 11:12 AM Vince Loschiavo <vince320@...> wrote:

Ashhar,
I think it should be the standard.? It fits, and no issues installing.
more Plus than Minus.
1.? Download and run the Memory manager.? Provides user a different look at what is getting written to memory.
2.? All the added features not to mention CAT control at the bare minimum which might be attractive
3.? options for displays
4.? WSPR?
on an on...
de
N2AIE
Vince
Re: Should we adopt the KD8CEC firmware?

Vince Vielhaber
 

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.

Re: Voltage Regulator

 

The LM78L09 and LM7809 have very different pinouts and if it smoked on power up it was wired wrong.

I cannot imagine a case where the VFO used more power than a 78L09 could handle.

Allison
Re: Should we adopt the KD8CEC firmware?

 

The nano is the atmega168 or 328P(more often these days) what you get.
Its the middle child of the set:
? 32k of program space
? 2k of ram space
? 1k eeprom space.

Compared to cpus of my day that is a vast amount of space.
We got the full 5 pounds in the bag with a lot less.

The largest of the atmega family?the atmega2650 aka the arduino Mega2650:?
? ?256K of program space
? ?8k of ram space
? ?4k eprom space
? ?Small chip is the 64pin large is 100 pin? either has far more IO than the 328P.

That would be big enough.
If it can't do it then maybe revisiting system design is in order.? For an analog radio that
would cover a lot of ground and allow a very elaborate user interface.

This does not include refactoring the software for space.? It can be made smaller without giving up things.

I'm currently using a Arduino Pro Mini (328p cpu) with display and 5351 to test firmware ideas,

Allison
?
Re: Looking for a single row 16pin ribbon cable source #parts

 

Hi Vince,

All you need is two 6-lead ribbon cables. 4 pins are not used, just check the schematics.

73, Frank
PA7F
Re: Looking for a single row 16pin ribbon cable source #parts

 

¿ªÔÆÌåÓý

Two 8-pin molex will work but you have to shave just a tiny bit of plastic off to make them fit end-to-end.? See attached using CAT5.?

73, Pat AA4PG



http://www.cahabatechnology.com/aa4pg.html

From: [email protected] <[email protected]> on behalf of Vince Loschiavo <vince320@...>
Sent: Tuesday, May 15, 2018 9:13:24 AM
To: [email protected]
Subject: [BITX20] Looking for a single row 16pin ribbon cable source #parts
?
Anyone have a link to a single row 16pin connector for make it yourself Ribbon cable?

Vince
n2aie

UBITXOPEN.jpeg

Re: Voltage Regulator

 

Thank you for your reply..

I finally decided to change the LM78L09 with LM7809.. I think it was because the LM78L09 couldn't take the high current.?
Re: Variable IF

Lawrence Macionski
 

Would the BFO frequency shift the filter peak into the 750HZ? range?
I have an audio spectrum analyzer app on my android that uses the mic. sure would be something to investigate.
I have a source of inexpensive 12.000 Mhz crystals. (5 for? $1.00)? Perhaps a parallel filter network with the low slope variable would solve it..
Looking for a single row 16pin ribbon cable source #parts

 

Anyone have a link to a single row 16pin connector for make it yourself Ribbon cable?

Vince
n2aie
Re: Should we adopt the KD8CEC firmware?

 

Ashhar,
I think it should be the standard.? It fits, and no issues installing.
more Plus than Minus.
1.? Download and run the Memory manager.? Provides user a different look at what is getting written to memory.
2.? All the added features not to mention CAT control at the bare minimum which might be attractive
3.? options for displays
4.? WSPR?
on an on...
de
N2AIE
Vince
Re: using the BITX on RTTY

 

Good morning,

Though not specifically uBitx related, the RTTY timing issues has been discussed ad naseum on the RTTY group which has recently rehomed to (RTTY) groups.io and IIRC the issues with timing are based largely in windows as it is not a real time OS. If you are like me, these discussions are, IMHO, very interesting and can be a time sink.

Arduino can and does a very nice job of handling RTTY with Andy, K0SM work creating TinyFSK, see??which incidentally also functions as a CW keyer ala hat tip to Anthony, K3NG and his wonderful arduino CW keyer. Anthony maintains a group (radioartisan) on groups.io. I do use David, G3YYD wonderful 2Tone software which has implementations for tinyFSK as your transmit source built in; see ?In a nutshell, I could not live without 2Tone when I play RTTY as it is truly fantastic and I routinely run several 2Tone receive windows along side Alex, VE3NEA Gritty software (print only - no xmit); see?

The key is ensuring you grab the correct timing packages from Paul over at PJRC (Teensy), see?

All my very best,

Mike N4EEV
Re: UBITX Assemly Wiki Page #ubitx

R. E. Klaus
 

Back in the 70's, some CB radio manufacturers used a diode in series with the power and it worked well. A couple brands used a bridge rectifier setup in the input power that way it didn't matter which way you connected to power.
Roxie -- K1AUS
Re: Should we adopt the KD8CEC firmware?

 

Tim

I disagree.

For example, if the standard code has an iambic keyer but I have run out of flash
trying to implement an SWR indicator, then it would be handy to free up the flash
used by the keyer by changing a #define from true to false with something like this:
#define? IAMBIC_KEYER? ?0

That standard code need not be exhaustively tested for all permutations of the build.
Just that the standard build works well enough to be usable.

The #define's for conditional compilation may or may not work, if they don't work
they are at least a good indication of the original programmer's understanding of
how he thought it should work.

And if I adjust the standard code through a modification of the #define's or?
some other hack to better suit my needs and it does not work for me,
then that is clearly my problem to debug.

Jerry


On Tue, May 15, 2018 at 07:28 am, Tim Gorman wrote:
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.

Re: Should we adopt the KD8CEC firmware?

 

With all respect, do you understand Ian's code well enough to add
functionality to it? Or is it just better from an operational
standpoint?

tim ab0wr

On Tue, 15 May 2018 07:23:14 -0700
docame12@... wrote:

As a newcomer to Arduino, I really appreciate of the benefits of Dr.
Lee's implementation versus the stock standard currently shipping.

Thanks,
DaveWS1ETI
Re: a new application of morse code #off_topic

Lawrence Macionski
 

It was 1967-68.. Detroit when I started college, President of K8EEH Henry Ford College ARC.. Somewhere in Detroit there was a Marine, that had been hit while on the Korean DMZ and was paralyzed- lost the ability to speak. He had the ability to send CW with only his thumb. Hams in Detroit built a CW to RTTY converter and supplied a Teletype in his bedroom so his mother, his care giver (and others), would not have to learn morse code.

CW was extensively used in Alcatraz as depicted in the Movie "Birdman of Alcatraz"? I just saw an article out of NERDS (New England Radio Discussion Society) about the Navy using shipboard flasher signaling lights with an automated Text to CW flash converter. No need to learn CW.
67921 - 67940 of 116965