Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
- BITX20
- Messages
Search
uBitx
toggle quoted message
Show quoted text
|
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.? ?;-)
toggle quoted message
Show quoted text
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: 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 allThat 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 |
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. |
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 |
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: |
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.
toggle quoted message
Show quoted text
Vince. On 05/15/2018 10:28 AM, Tim Gorman wrote:
Jerry, --
Michigan VHF Corp. |
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 |
to navigate to use esc to dismiss