¿ªÔÆÌåÓý

  1. BITX20
  2. Messages
Expanded Topics Messages Polls
Date
MAX9812

[email protected]
 

Have any of you folks used one of these and if so, how did it work out?
Re: Variable IF

 

Good question, which I will leave for someone else to answer because I don't know. ?My guess is yes.

One error in the schematic I sent. ?The 12K resisitor in the TX voltage divider should be 15K in order to have the best audio on SSB with the filter at full bandwidth.
uBitx

 

¿ªÔÆÌåÓý




Begin forwarded message:

From: allen west <kb4ra67@...>
Date: May 15, 2018 at 9:08:35 AM EDT
To: [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
Re: Should we adopt the KD8CEC firmware?

 

Apologies to Ashhar for misspelling his name in my previous post.

73, John (VK2ETA)?
Re: Should we adopt the KD8CEC firmware?

 

Hello Tim,

We have to look at this from different perspectives:

1. From Ashar's perspective, it is important to provide a unit that is attractive to the whole range of users from appliance users to experimenters, and the current software does, in my opinion, fall short in some areas: functionally as you said it needs upgrading and from a kit builder's perspective I believe it should have more basic built-in diagnostics.

2. From the new experimenter's perspective I am convinced that it would be much easier if I wanted to add say an SWR function to change a one line define statement and connect the described hardware that having to get into the intricacies of even the current factory software to implement the code.

How do I know this? Because I had to go through it, and I would have been very happy to start from a base with existing code rather than start from scratch.

3. For the more savvy experimenter the beauty of the conditional compile is that by following the ifdef enclosed blocks I can immediately get to the core of the code in question and can if I so desire modify it.

From that point, by the way, I consider that the responsibility form fixing any software problem is 100% mine. I break it, I fix it, simple. I can get help, but the responsibility is mine.

As far a regression testing it has to be taken in context: a] the rate of release is not like in a daily software release so how often do they expect to have to perform it, probably once only and b] It is not mission critical and c] There is help at hand here.?

Now as to a comparison with a commercial rig I don't think that is the point since my FT-817 does *not* have a built-in tuner, a low battery alarm, a digital VOX or the option to plug a handsfree ear piece as a microphone to name a few. It does have a lot of other features I don't care about and that are clogging the user interface from my perspective.?

One of the thrills of kit building is the possibility to customize it as per your own needs.

73, John (VK2ETA)
Re: Should we adopt the KD8CEC firmware?

 

Maybe this thread has wandered a bit off topic.? Instead of the merits of a basic firmware versus a feature rich one as the stock firmware shipped with the units, it seems to have turned into a pissing contest on software methods and practices.

Individual and experienced developers are more than free to develop outside the stock offerings, and share, or not share as they see fit.? The question is what would be best for inexperienced or new hams as a starting point.

uBITX should be targeted at new hams, not new coders.? New hams already have enough to be confused about.
Re: Should we adopt the KD8CEC firmware?

 

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.
Re: Core for Output Transformer

 

My plan is the longer version of the BN43-6802 (or use two BN43-302 end to end).

Amidon has the 6802, Diz/Kitsandparts has the 302.

I? have to order some MPSH10s for driver mods.

Allison
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.?
67741 - 67760 of 116950