The All-band HF Amateur Radio Transceiver: Just waiting to be modified
Michael VE3WMB figured after playing around with the KD8CEC firmware for a while that he would prefer to have the Main VFO frequency and Mode displayed in the top line, instead of the bottom line of the display and the secondary info (VFO B etc) on the bottom line of his display.
Under ‘User Interface’ of the uBitx Memory Manager application (scroll way down), checking the ‘1/2 Line Toggle’ works to swap the first and 2nd lines on the display. No coding is required to achieve this.
Ashhar Farhan VU2ESE have created a next version of the base software after thinking hard about it. You can download it here:
https://github.com/afarhan/ubitx4.
Ashhar invites you all to test it. if you are not familiar with C code or Arduino programming, it is suggested you wait for a few days until we get all the bugs sorted out. This is only for Arduino regulars.
Send any bug reports directly to Ashhar’s email box at farhanbox@gmail.com. In the subject line use the word “#ubitx40”. I will try to answer all emails but I can’t promise responses to all.
Ashhar has measured the mood of the BITX20 list and has made the call to substantially borrow from Ian KD8CEC’s code and back port it to the original ubitx code. The new code has about 10% more lines but it is substantially more robust and useful.
The main features that Ashhar has cherry picked from Ian’s code are:
1. Keyer. You have to choose which keyer type to use, but the keying is much better and robust now. This code is a total copy/paste of Ian’s keyer. The auto-keyer (that sends out preset phrases in CW) is left out. The Iamabic A, Iambic B and the handkey sending works very well.
2. CAT control. Given the popularity of FT8, Ashhar has rewritten the CAT control by following Ian’s code but follows the ubitx coding conventions. It represents a miminal set of controls.
3. Split operation has been included.
4. Rationalised menus: the menu system is now more consistent.
5. Tuning mechanism: The accelerated tuning works, and it doesn’t jump randomly like before, nor does it work at the same speed. For very long band changes, it is recommended to use the menu option to change band.
Among the things left out was support for different types of displays, WSPR, and many other goodies. The EEPROM memory map has been kept consistent with KD8CEC’s plan. You can switch between both code bases easily.
Ashhar has kept usage of English words at a minimum.
Jack W8TEE has provided directions on how find a compiled hex file:
1. Go to your Preferences settings (File –> Preferences) and check “Set verbose output during” and check “compilation”
2. Compile the program. Do not upload as that erases all temporary files, including the hex file. In other words, just click on the
check mark icon that appears below the File menu option.
3. Scroll down the long list of output your compile generated until you see: “Linking everything together…” followed by a series of
lines with path and file names. The hex file for you program will be one of them. Just use that path name to find the hex file.
While you’re there, use a text editor to open the *.lst file. It shows a blending of C and assembler generated by the compiler. It’s an interesting way to find if one way of writing a piece of code is “better” (i.e., faster execution, or perhaps using less memory) than an alternative way.
Ashhar Farhan VU2ESE asks:
“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?”
The responses have been varied.
uBITx.net has supported the suggestion of supplying the KD8CEC version as the default firmware. There is no question that the KD8CEC sketch represents more mature firmware. It runs on an unmodified uBITx, but provides for minor hardware enhancements that add additional functionality. All other firmware options require hardware changes prior to installation, so there is no obvious contender from other firmware developers at this juncture. This is not to downgrade the importance and innovation brought by other firmware developers. Each firmware hack has its merits and brings features that are important to groups of µBITx constructors. No other firmware, other than the stock firmware, has such a large group of supporters.
The KD8CEC software brings a significant increase in the range of features and reliability of the product. Manuals are available for both the stable version and the beta version of the firmware. The factory product does not come with a manual, has not been improved in six months or even had basic bugs removed, and has caused frustration for some constructors. This is not to say, that the stock firmware is of low quality – it is basically sound, but needs work. Ashhar has not had time to address these issues because of the huge demand for the µBITx and need to resolve other issues as they have arisen.
The case for not using KD8CEC firmware
There are of course arguments against using the KD8CEC version as the factory install. The feature packed nature of the firmware leaves little room for constructors to hack the firmware to customise it for their own purposes. This has been largely overcome now through the modularity of the latest firmware design. Features can be enabled or disabled in the configuration section of the code. This modularity will become increasingly important as hardware enhancements are combined with code to support the hardware changes. The addition of uBITx Manager software for the PC expands the potential to customise the firmware in future to reflect different hardware configurations.
Suggestions that the firmware is not a good fit, because the factory alignment procedure is not included by default, is a complete red herring. Different features can be configured by setting a few configuration flags in the sketch. This is a configuration issue, not a practical issue. The code remains in the sketch and the sketch can be simplified by removing many of the extensions through a simple five minute configuration exercise to produce a stock version.
Some prefer Ashhar Farhan’s unique approach to tuning. This is a matter of personal preference. Again, this feature could be reincorporated easily, and enabled or disabled through a single configuration setting that chooses the tuning style that suits the user.
The biggest improvements to functionality for just about any modern appliance come as a result of firmware enhancements. µBITx firmware enhancements come free, but hardware enhancements cost constructors.
Note: This article reflects the personal views of the author (Mike ZL1AXG) and not those of the manufacturer.
SP VU2SPF and Joe VE1BWV have just released the latest version of the TFT Colour Touch Control software.
This software/hardware combination is low cost, uses standard easy to get parts and provides a colour, touch control and physical buttons if you want them.
You will require a TFT (Touch) Display module, an At Mega 2650 arduino board, Si5351 DDS module, a µBITx and a few wires
The result is an all-band rig with a computer controlled Radio Touch Control Colour Display.
Automatic Scanning – up to band edges in both the directions is now added in V2.9bU of software. Scanning finds signals of interest across the band. Two small buttons labeled ‘U’ and ‘D’ scan in up and down from the currently set frequency. Scanning can be stopped by touching the display panel.
CAT Control – the software now has new code to emulate FT817 CAT commands. This provides radio and computer control for digital modes.
User Manual – A new comprehensive user manual has also been added. Constructors have been looking for this for quite a while.
The new version is available on Github at : https://github.com/sprakashb/TFT_TouchScreen_for_uBitx
Information is also available at:
http://vu2spf.blogspot.ca
and
https://www.youtube.com/watch?v=zkg-IrjV2h4&t=375s
(UBITX ver2.9bu Installation Results)
Jack W8TEE notes how easy it is to find where Hex files and Assembly files for a compile of an Arduino sketch are placed on your computer, along with some other compile-time information.
First, go to your Preferences dialog (File –> Preferences) and check the compilation check box for the “Show verbose output during:”
Second, compile your program. Do not click the compile/upload icon, only the check mark for compile only. You will see a lot of stuff scroll by just below the IDE’s Source Code Window.
Third, look towards the end of that list of output for YourProgramName.hex. For example, Jack’s test program was:
C:\Users\econjack\AppData\Local\Temp\arduino_build_160543/TestProgram.ino.hex
Fourth, go to the directory and look at the output files. You will see file types:
elf — executable-linkable file, used for a debugger
hex — the flash output file
eep — th eEEPROM outout file
sym — symbol table information
lst — assembler output
The first file is very interesting to look at, as it shows the C code mixed in with its associated assembler output. (You can load the file into any text editor.) For example, which is more efficient: a cascading series of if statements or a switch/case? Write a short test program using both constructs and then look at the assembler output. You find that the switch/case produces a jump table, which is very efficient in terms of speed, but may be less efficient in terms of memory. Even if you don’t know assembler, you’ll get a feel for the answer. Use whichever fits the situation.
If you want to directly load a hex file into an Arduino, you could use an AVR programmer, or XLoader (http://www.hobbytronics.co.uk/arduino-xloader).
My BFO was way off after I first tried to calibrate it. I then started over with mine at 996.4 and ended up at 996.7. If yours is a long way off from that then I’ll bet you hear psk at 7074 when in LSB.
