Topics

Should we adopt the KD8CEC firmware?

Ashhar Farhan
 

Peeps,

Given that Dr.Lee's software is now pretty stable from 1.06 onwards, what do you all say about using this as the 'shipped' firmware? I have some personal quirks that make me modify it for my personal use (ex: I prefere general coverage when changing the bands rather than steps to and from ham bands) but do we consider it to be usable and stable for our needs? 

I resisted feature-ful software as the base because smaller code base makes it easier for people to get in and modify, there is space in the memory for modifications, etc. 

If there is a general consensus, then, we will customize it to the standard hardware, and start burning this into the next batch of ubitx.

Opinions, please.

- f


Ashhar Farhan
 

I just noticed that the sketch is too big to get into the nano with the factory alignment enabled. this is a mandatory in the shipped firmware. I don't want to fork out and grandfather the KD8CEC versions. Not sure what to do now...

- f

On Sat, May 12, 2018 at 11:38 AM, Ashhar Farhan <farhanbox@...> wrote:
Peeps,

Given that Dr.Lee's software is now pretty stable from 1.06 onwards, what do you all say about using this as the 'shipped' firmware? I have some personal quirks that make me modify it for my personal use (ex: I prefere general coverage when changing the bands rather than steps to and from ham bands) but do we consider it to be usable and stable for our needs? 

I resisted feature-ful software as the base because smaller code base makes it easier for people to get in and modify, there is space in the memory for modifications, etc. 

If there is a general consensus, then, we will customize it to the standard hardware, and start burning this into the next batch of ubitx.

Opinions, please.

- f



Mike Woods
 

Ashhar

You can configure the sketch so that the factory alignment is enabled and other functions are disabled.   I am sure that Ian would configure a version that would be the current version that always had factory alignment in place.

It makes a lot of sense to me to adopt the KD8CEC sketch due to the broad range of features that are added.

Mike ZL1AXG


On 12/05/18 6:20 PM, Ashhar Farhan wrote:
I just noticed that the sketch is too big to get into the nano with the factory alignment enabled. this is a mandatory in the shipped firmware. I don't want to fork out and grandfather the KD8CEC versions. Not sure what to do now...

- f

On Sat, May 12, 2018 at 11:38 AM, Ashhar Farhan <farhanbox@...> wrote:
Peeps,

Given that Dr.Lee's software is now pretty stable from 1.06 onwards, what do you all say about using this as the 'shipped' firmware? I have some personal quirks that make me modify it for my personal use (ex: I prefere general coverage when changing the bands rather than steps to and from ham bands) but do we consider it to be usable and stable for our needs? 

I resisted feature-ful software as the base because smaller code base makes it easier for people to get in and modify, there is space in the memory for modifications, etc. 

If there is a general consensus, then, we will customize it to the standard hardware, and start burning this into the next batch of ubitx.

Opinions, please.

- f




--
Mike Woods
mhwoods@...

marjannorm
 

Yes, Ashar, we should!   Seems good to me
norm Lee vk5gi (no relation!)

Frank PA7F
 

Ashhar,

KD8CEC f/w is really good.

After I got my uBITX working I immediately installed v1.061. Following Ian's suggestion I used a tool called Xloader to install the hex-file. You don't have to install and get to know the Arduino IDE. 

Frank PA7F

 

How much more space required ?


At 12-05-18, you wrote:
I just noticed that the sketch is too big to get into the nano with the factory alignment enabled. this is a mandatory in the shipped firmware. I don't want to fork out and grandfather the KD8CEC versions. Not sure what to do now...

- f

On Sat, May 12, 2018 at 11:38 AM, Ashhar Farhan <farhanbox@...> wrote:
Peeps,

Given that Dr.Lee's software is now pretty stable from 1.06 onwards, what do you all say about using this as the 'shipped' firmware? I have some personal quirks that make me modify it for my personal use (ex: I prefere general coverage when changing the bands rather than steps to and from ham bands) but do we consider it to be usable and stable for our needs?Â

I resisted feature-ful software as the base because smaller code base makes it easier for people to get in and modify, there is space in the memory for modifications, etc.Â

If there is a general consensus, then, we will customize it to the standard hardware, and start burning this into the next batch of ubitx.

Opinions, please.

- f

Dennis Zabawa
 

Stick to what you are doing.  IF anyone wants to upgrade their Raduino, they have that option with minimal effort.  I agree that the factory alignment software is vital.  TNX for all your efforts!

As of now, I have a BITX40 and two uBITX up and functioning well.  I applaud you for your efforts to bring employment to your fellow country persons (have to be politically correct here).

John (vk2eta)
 

 No disrespect to the default software of the uBitx, but from a "marketing" perspective and in my experience, Ian's software brings the rig to a more complete and enjoyable level.

So I support it to be the default software. 

There is a simple and easy fix to free some extra memory for the factory alignment routines and that is to use the SoftI2CMaster I2C library instead of the Wire library. I have done that in the portable variation I uploaded to the files section and it has been working without a fault for several weeks now with both an Arduino as slave and the Si5351 on the I2C bus.

This replacement library saves 1158 bytes of flash memory. 

I have passed the information to Ian Lee about this. Maybe he has plans to incorporate it in a future version as he has also worked on freeing up memory for extra features.

The second option is to have options in the source (like I did in the same uploaded software in the ubitx_20.ino file) with features like WSPR disabled by default and the factory alignment enabled by default. These can then be swapped with a simple addition/removal of comments ("//") in the source. This should be pretty easy to document.

All the best,

73, John (VK2ETA)

Doug W
 

I don't have a real strong opinion either way but I do have one concern.  If you start shipping a CAT enabled rig you are basically giving your blessing to use digital modes on the stock radio and all the issues that come with excessive heat and the finals.  At the very least I would include a very strong warning to the user about upgrading the thermal management before going digital.  The easier you make it to do something the less likely many users are to implement proper procedures.  I am thrilled with my µBITX and appreciate your design everyday.  I would hate to see it get a bad reputation because a bunch of unqualified new users cook the finals.
--
www.bitxmap.com

Jack, W8TEE
 

All:

Right now, I am not running Ian's software, but I know there are a lot of people who are. Given the alignment software that Farhan needs to be included, the switch seems to be a moot question for now unless Farhan wishes to modify the display to use fewer I/O lines. That seems like a lot of work for marginal benefit. Ian has a lot of nice features in the software and has done an amazing job getting it all packed into a very small address space. People have been successful in moving to Ian's project, so I would argue for not changing it. The documentation seems to make the switch a fairly "cookbook-like" process and painless.

Also, I would like to argue for not using multiple *.ino files in any project that we use in conjunction with the µBITX. To assess the impact, take either code project, change all the *.ino files except ubitx_20.ino to *.cpp (C++) file (ubitx_20.ino holds the setup() and loop() functions needed by the IDE and must remain a *.ino file) and then compile it. You will see numerous warnings on the compile. True, they are not errors, but warnings. By using multiple *.ino files, type checking is turned off and those warnings are hidden...their cause is still in the code, it's just that you don't know about them. Most of the time, those warnings will not cause problems, but when they do, it can be very difficult to find the bug.

There may be another advantage, too. I have not checked this, but when *.cpp files are used, it appears that the IDE (Gnu) compiler can do "incremental compiles." That is, if you have not changed a given *.cpp file since the last compile, certain parts of the compile process (e.g., syntax checking) can be bypassed, resulting in slightly faster compiles. Like I said, I have not timed this yet, but I know when I start working with my project in the morning with a "fresh start", my 10,000 line project takes a fairly long time to perform that first compile. If I only change 1 file and then recompile, it is a much faster compile. I have a pretty fast PC, but I would guess that I save over 30 seconds per compile. Not a big deal unless you're doing a hundred compiles each day. In that case, it saves me almost an hour a day. To me, changing to *.cpp files and correcting the code so the warnings disappear is worth the effort. The fact that subsequent compiles may be quicker is just a dab of icing on the cake.

Jack, W8TEE




On Saturday, May 12, 2018, 7:20:28 AM EDT, Raj vu2zap <rajendrakumargg@...> wrote:


How much more space required ?

At 12-05-18, you wrote:
I just noticed that the sketch is too big to get into the nano with the factory alignment enabled. this is a mandatory in the shipped firmware. I don't want to fork out and grandfather the KD8CEC versions. Not sure what to do now...

- f

On Sat, May 12, 2018 at 11:38 AM, Ashhar Farhan <farhanbox@...> wrote:
Peeps,

Given that Dr.Lee's software is now pretty stable from 1.06 onwards, what do you all say about using this as the 'shipped' firmware? I have some personal quirks that make me modify it for my personal use (ex: I prefere general coverage when changing the bands rather than steps to and from ham bands) but do we consider it to be usable and stable for our needs?Â

I resisted feature-ful software as the base because smaller code base makes it easier for people to get in and modify, there is space in the memory for modifications, etc.Â

If there is a general consensus, then, we will customize it to the standard hardware, and start burning this into the next batch of ubitx.

Opinions, please.

- f

Bo Barry <bobarr@...>
 

I'm so 'conflicted' or excited I plan to order a second unit!
One to use and one to experiment with!

Maybe offer a discount if we by two units at once and offer both firmwares😂

Great project for our hobby. We really appreciate it.

73 Bo W4GHV since '54

bill richardson
 

Yes, this would be a great thing to do.   I’m all for it. Now that I have 3 ubitx’s I certainly can see the advantage of doing this. 


On May 12, 2018, at 8:46 AM, Bo Barry <bobarr@...> wrote:

I'm so 'conflicted' or excited I plan to order a second unit!
One to use and one to experiment with!

Maybe offer a discount if we by two units at once and offer both firmwares😂

Great project for our hobby. We really appreciate it.

73 Bo W4GHV since '54

Jerry Gaffke
 

Opinions vary, no obvious winner among the options.
    https://groups.io/g/BITX20/topic/7715019

Jack's recommendation is closer to what normal C programmers do,
and allows the compiler to do a good job of error checking.
But if there are *.c files in addition to that *.ino file, then we also have a new header file
that must be kept current, which new programmers will find to be a burden.

It seems ArduinoLand is structured to best support one big fat ino file.
Also allows the good error checking.  Not all that big if we're coding for a Nano.

Multiple *.ino files is a compromise for those that aren't comfortable with their text editor.
Some error checking is defeated.
Does make it easy to substitute a new keyer or CAT protocol and the like.

It's a choice to be made by whoever puts it together.
Those with other opinions can create their own distribution, see if it gains traction.

Jerry


On Sat, May 12, 2018 at 06:30 am, Jack Purdum wrote:
Also, I would like to argue for not using multiple *.ino files in any project that we use in conjunction with the µBITX.

Jack, W8TEE
 

Jerry's right, a new header file is necessary so all of the now-independent files know about global variables and functions that might be shared across different files. For example, suppose you have a global variable named whichMenu and suppose ubitx_20.ino and ubitx_menu.cpp both need access to it. This is where most programmers get really sloppy: the terms "define" and "declare" are NOT the same. When you define a variable, you allocate memory space for it. When you declare a variable, you are simply creating a list of the variable's attributes that let's the compiler use it during the compile process. You can declare a variable a bazillion times in a program, but you can only define it once. So, how can I let ubitx_menu.cpp know what and where whichMenu is so the compiler can use it in that file without defining it. Simple:

FILE:                           ubitx_20.ino                               ubitx_menu.cpp
line # 1                         int whichMenu;                          extern int whichMenu;

The extern keyword in the menu file says to the compiler: "OK, whichMenu is not defined here (i.e., not allocated a place in memory in this file), but you can use it in this file as an int data type." So think of the compiler leaving two question marks "??" for the actually memory address that will eventually be given to whichMenu. Now, a program pass called the "linker" comes along and sees the two question marks in ubitx_menu.cpp associated with whichMenu. The linker then looks in its symbol table and says: "Oh, yeah, I assigned whichMenu to memory location 1500 back when I compiled ubitx_20.ino", so the linker replaces the two question marks with 1500. Note: Because there is no extern keyword for whichMenu in the INO file, the linker assigns it an address (i.e., defines it) when it compiles that file. This means you defined whichMenu in ubitx_20.ino, but you declared it in ubitx_menu.cpp so the compiler would let you use it in that file. Programming's hard enough without screwing up the meaning of the terms.

I changed the files and created the necessary header file for Arhhar's code about two weeks after the µBITX came out. I called it: Prototypes.h and this is what it looks like:

#ifndef PROTOFLAG
#define PROTOFLAG
#include <Wire.h>
//#include <EEPROM.h>

#include <stdint.h>
#include <inttypes.h>
//#include <pgmspace.h>
#include <Arduino.h>
#include <LiquidCrystal.h>

#define ENC_A (A0)
#define ENC_B (A1)
#define FBUTTON (A2)
#define PTT   (A3)
#define ANALOG_KEYER (A6)
#define ANALOG_SPARE (A7)

#define TX_RX (7)
#define CW_TONE (6)
#define TX_LPF_A (5)
#define TX_LPF_B (4)
#define TX_LPF_C (3)
#define CW_KEY (2)

#define TX_SSB 0
#define TX_CW 1

#define MASTER_CAL 0
#define LSB_CAL 4
#define USB_CAL 8
#define SIDE_TONE 12
// these are ids of the vfos as well as their offset into the eeprom storage, don't change
// these 'magic' values
#define VFO_A 16
#define VFO_B 20
#define CW_SIDETONE 24
#define CW_SPEED 28


// Function prototypes:
void checkPTT(void);                                      // from ubitx_20_standard
void setFrequency(unsigned long f);                       //      ubitx_20_standard
void startTx(byte txMode);                                //      ubitx_20_standard
void stopTx();                                            //      ubitx_20_standard
void ritDisable();                                        //      ubitx_20_standard
void ritEnable(unsigned long f);                          //      ubitx_20_standard
void si5351bx_setfreq(uint8_t clknum, uint32_t fout);     //      ubitx_si5351.cpp
void initOscillators(void);                               //      ubitx_si5351.cpp
void si5351_set_calibration(int32_t cal);                 //      ubitx_si5351.cpp
void updateDisplay(void);                                 //      ubitx_ui.cpp
int btnDown(void);                                        //      ubitx_ui.cpp
int enc_read(void);                                       //      ubitx_ui.cpp
void printLine1(char *c);                                 //      ubitx_ui.cpp
void initMeter(void);                                     //      ubitx_ui.cpp
void printLine1(char *c);                                 //      ubitx_ui.cpp
void printLine2(char *c);                                 //      ubitx_ui.cpp
void doMenu(void);                                        //      ubitx_menu.cpp
void factoryCalibration(int btn);                         //      ubitx_menu.cpp
void menuSetupCarrier(int btn);                           //      ubitx_menu.cpp
void factory_alignment(void);                             //      ubitx_factory_alignmment.cpp
void cwKeyer(void);                                       //      ubitx_keyer.cpp
void cwKeydown(void);                                     //      ubitx_keyer.cpp
void cwKeyUp();                                           //      ubitx_keyer.cpp
void checkCAT(void);                                      //      ubitx_cat.cpp
#endif

All of the *.cpp files #include "Prototypes.h" in them. If you look at Ashhar's code, you see why the items are in the header file. What shows me that Ashhar is a professional programmer is the absence of global variables that span multiple files (i.e., no externs). Instead, he passes the data as parameters between files, which is why we need function prototypes.

If you plan on dinking around with the code, I would urge you to use *.cpp files in your project. If you just want to use the code as it is, the all-ino files is fine. Your choice.

Jack, W8TEE

On Saturday, May 12, 2018, 11:13:33 AM EDT, Jerry Gaffke via Groups.Io <jgaffke@...> wrote:


Opinions vary, no obvious winner among the options.
    https://groups.io/g/BITX20/topic/7715019

Jack's recommendation is closer to what normal C programmers do,
and allows the compiler to do a good job of error checking.
But if there are *.c files in addition to that *.ino file, then we also have a new header file
that must be kept current, which new programmers will find to be a burden.

It seems ArduinoLand is structured to best support one big fat ino file.
Also allows the good error checking.  Not all that big if we're coding for a Nano.

Multiple *.ino files is a compromise for those that aren't comfortable with their text editor.
Some error checking is defeated.
Does make it easy to substitute a new keyer or CAT protocol and the like.

It's a choice to be made by whoever puts it together.
Those with other opinions can create their own distribution, see if it gains traction.

Jerry

On Sat, May 12, 2018 at 06:30 am, Jack Purdum wrote:
Also, I would like to argue for not using multiple *.ino files in any project that we use in conjunction with the µBITX.

Tim Gorman
 

No matter what you do, Ian's software is going to fill up the nano's
memory space. That *will* limit the ability of novice and intermediate
coders to make changes that they would like.

In essence it will push the ubitx to being more like a
kenwood/icom/yaesu rig where the software does not lend itself to
experimentation by the user.

Ian's software is quite easy to install if one is not interested in
experimentation.

Perhaps make it an ordering option? Basic software for experimenters
and Ian's software for appliance operators.

tim ab0wr


On Sat, 12 May 2018 11:38:30 +0530
"Ashhar Farhan" <farhanbox@...> wrote:

Peeps,

Given that Dr.Lee's software is now pretty stable from 1.06 onwards,
what do you all say about using this as the 'shipped' firmware? I
have some personal quirks that make me modify it for my personal use
(ex: I prefere general coverage when changing the bands rather than
steps to and from ham bands) but do we consider it to be usable and
stable for our needs?

I resisted feature-ful software as the base because smaller code base
makes it easier for people to get in and modify, there is space in
the memory for modifications, etc.

If there is a general consensus, then, we will customize it to the
standard hardware, and start burning this into the next batch of
ubitx.

Opinions, please.

- f

Tom Christian
 

Ashhar,
I have been using Ian's firmware because of the added features, especially CAT.  But, if possible, I would like to have the choice to use your preference for general coverage when changing the bands rather than steps to and from ham bands.  As much as I like Ian's software as a whole, I miss that part from your firmware.  Thanks!
Tom
AB7WT

Mike Woods
 

Ian’s firmware has always had the option of toggling to general coverage RX (at least since v0.33 by my notes).  How to do this is documented in the manual.

M


On Sun, 13 May 2018 at 7:42 AM, Tom Christian <tmchristian@...> wrote:
Ashhar,
I have been using Ian's firmware because of the added features, especially CAT.  But, if possible, I would like to have the choice to use your preference for general coverage when changing the bands rather than steps to and from ham bands.  As much as I like Ian's software as a whole, I miss that part from your firmware.  Thanks!
Tom
AB7WT

tony.vasile@...
 

Personally, I think there is great value in maintaining the original "factory" code base, simply because this is a hacker's dream!

Delivering with your original core software takes nothing away from those that wish to adopt Ian's, or anyone else's mods (inclusing their own).

The only drawbacks I see are:

1) Ian (or others) would have to maintain their branches if you were to make any changes to the core that would "need" to be proliferated. This can be achieved by ensuring that any changes you make to the core are communicated (documented).

2) Those enthusiasts who wish to use alternate firmware, but are not comfortable with, or equipped to, modify the Raduino may be discouraged from becoming a BitX enthusiast.  Possible solutions are building a stronger community of support (which is essentially happening with this online community), or in the extreme some of us becoming a pass-through for Raduino uogrades.

Just some thoughts!

Tony, KB9A 

UBitx #1:  Cigar Box case, KD8CEC firmware
Bitx40 #1: Grey case kit from Amateur Radio Kits, PE1NWL firmware
UBitx #2: Maroon case kit from Amateur Radio Kits (still under construction)

On May 12, 2018 3:42 PM, "Tom Christian" <tmchristian@...> wrote:
Ashhar,
I have been using Ian's firmware because of the added features, especially CAT.  But, if possible, I would like to have the choice to use your preference for general coverage when changing the bands rather than steps to and from ham bands.  As much as I like Ian's software as a whole, I miss that part from your firmware.  Thanks!
Tom
AB7WT


Jerry Gaffke
 

Partition the code so the keyer or CAT stuff or whatever can be ifdef'd out.
Then experimenters will have plenty of room to play.

Jerry



On Sat, May 12, 2018 at 09:14 am, Tim Gorman wrote:
No matter what you do, Ian's software is going to fill up the nano's
memory space. That *will* limit the ability of novice and intermediate
coders to make changes that they would like.

In essence it will push the ubitx to being more like a
kenwood/icom/yaesu rig where the software does not lend itself to
experimentation by the user.

Ian's software is quite easy to install if one is not interested in
experimentation.

Perhaps make it an ordering option? Basic software for experimenters
and Ian's software for appliance operators.

K9HZ <bill@...>
 

Or WSPR code…

 

 

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

 

Owner - Operator

Big Signal Ranch – K9ZC

Staunton, Illinois

 

Owner – Operator

Villa Grand Piton – J68HZ

Soufriere, St. Lucia W.I.

Rent it: www.VillaGrandPiton.com

Like us on Facebook! facebook icon

 

Moderator – North American QRO Group at Groups.IO.

 

email:  bill@...

 

 

From: BITX20@groups.io [mailto:BITX20@groups.io] On Behalf Of Jerry Gaffke via Groups.Io
Sent: Saturday, May 12, 2018 5:35 PM
To: BITX20@groups.io
Subject: Re: [BITX20] Should we adopt the KD8CEC firmware?

 

Partition the code so the keyer or CAT stuff or whatever can be ifdef'd out.
Then experimenters will have plenty of room to play.

Jerry



On Sat, May 12, 2018 at 09:14 am, Tim Gorman wrote:

No matter what you do, Ian's software is going to fill up the nano's
memory space. That *will* limit the ability of novice and intermediate
coders to make changes that they would like.

In essence it will push the ubitx to being more like a
kenwood/icom/yaesu rig where the software does not lend itself to
experimentation by the user.

Ian's software is quite easy to install if one is not interested in
experimentation.

Perhaps make it an ordering option? Basic software for experimenters
and Ian's software for appliance operators.


Virus-free. www.avg.com