With four components, and the on:off switch, Bill K9HZ provides the ultimate reverse voltage and over-current protection system for your µBITx. The fuse protects the circuit from excessive current draw – so you won’t blow your finals when you wind up the bias too far and they try to go into thermal runaway. The relay must be powered on to power your µBITx (and the switch must be turned on). With the series diode in place the relay cannot turn on unless the power is wired up correctly.
Upgrading the PA output transformer
JerryW0PWE notes that in the posts on boosting and/or leveling output power he saw pictures of a binocular core being used as the output transformer in place of the toroid that comes with the uBitx board. He asks “What size is that binocular core?”
Allison plans to use the longer version of the BN43-6802 (or two BN43-302 cores end to end).
John VK2ETA says he went back to IRF510s in the finals and has used a BN43-3312 as the single 302 was getting warm on the low frequencies and he could not put more than 2/3 turns in the core. He tried both 1/2T and 2/4T in the 3312 and settled on 2/4T due to better efficiency. The 1/2T drew too much current at 80M.
There is plenty of gain and power at 14MHz and below on 16.8V for the PA but has had to resort to a gain control for flattening the power curve despite 330pF caps in all 6 drivers emitter resistors, 22uH inductor in the base feedback of the pre-driver, 330 pF across the primary of the finals transformer and 820ohms in the finals feedback resistors.
Nick VK4PLN uses the BN43-202 with a winding ratio of 2:4 using 0.64mm enameled CU. His rig is outputing 20W+ on 80/40/20 using RD16HHF1. Nick doesn’t detect any heating… Maybe it will at that power level on 10m?
His plan is to now try using:
– the MPSH10 in the pre-driver
– a single 10T bifilar wound FT50-43 for feeding the power to the RD16HHF1s
– removing the PA feedback loop
– and other pre-driver mods as per Farhans suggestions….
This appears to be the common approach on most of the RD16 amp designs out there…and Nick hopes he will get 20w+ output from 80-10m….
Bill K9HZ tried a BN61-002 and it seems to be a winner. It doesn’t heat up at full power and it seems to be extremely wide band.
Reference
Finding a compiled Hex file for the arduino
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.
Reference
Variable IF bandwidth from W1EAT
Tom W1EAT provides a schematic for his mod of a variable IF bandwidth circuit for the µBITx. The RX and TX voltages are about 12V, so he used a resistor network to keep the applied voltage to about 1 to 9V because that is the usable range for the varicap diodes he uses. As the voltage on the caps is reduced the higher audio frequencies are reduced until the bandwidth is probably 100Hz or so at 1 volt. The filter centre frequency is very low, 200 Hz or so with Tom’s BFO setting.
The BB112 has about 500pf capacity at 1 volt applied.
The 4.7K resistors that feed the voltage to the VVC diodes could be 10 or 20 K, or what have you, as there is very little current needed.
Reference
uBITx Ver 2
Bill Franzwa K6SIK suggests
“New software and hardware improvements will continue to come as the uBITX is purchased by more and more users. This is natural. Rather than incrementally improving pieces and parts and wind up with a hodgepodge of boards and operating systems, it might be better to step back and wait a year for uBITXII.”
This idea generated some responses, with support for the general idea:
- Walt VE7CWS suggests “address the microphone audio drive level, the power out issues and generally do a complete workaround on those things that have been addressed. As to the software, keep it simple and for those that want to adapt other sketches or write their own continue support for that.”
- Rich KE1EV says “I wonder if the uBitx filter can be adapted to vary it’s bandwidth, perhaps with an external pot rather than under processor control. Tested and verified mods should also be included. Rig operation is awkward due to the lack of front panel controls.”
Reference
Fake PA FETs
Watch out for fake RD16HHF1 devices. Buying on Alibaba and Ebay is a risk some are willing to take, but there are plenty of fake devices for sale through these channels.
Reference
What makes a good receiver? And what about the uBITx
Somebody on the list asked how the µBITx receiver performs compared to other transceivers. Allison KB1GMX provides an extensive commentary on factors that relate to receiver performance with the µBITx as a reference point that will be of interest to constructors.
She notes that receiver performance has many dimensions:
- Sensitivity
- Bandwidth
- Overload performance and dynamic range.
- Stability, Especially important in the days of VFOs.
- Spurious signals, birdies and unexpected signals.
The µBITx is unique in a new generation of simple radios with microcomputers to provide the basis for the user interface.
From Allison’s perspective, and work she has done, the BITx40 had too much gain and required an attenuator most nights. However, this was an easy fix.
The µBITx when measured on an RX only test bed from about 3-4 years ago reflects a good receiver in the 1-10 mhz range. However, Allison prefers a bit more RF gain for 10 through 30MHz. As you go up in frequency there is more weak signal propagation and reduced manmade noises and sensitivity approaches the background galactic noise floor. At 40m a 1uV senstivity is plenty, at 28mhz .2uV is more useful.
For selectivity, Allison prefers a tight filter: 2.1 to 2.4khz is fine as SSB is about that wide on transmit (except for the ESSB people where a 3khz filter would be better). However, she prefers steeper skirts and that requires more crystals, with 5 crystals being the bare minimum and 7 approaching very good.
Why is this important? Strong signals down the skirts [edges of the filter] are audible if not suppressed adequately and if the same filter is used for TX it assures the unwanted sideband is suppressed.
Overload is a big area for BITx40 users and the same forBITx20 users. There is a lot of RF gain and HF bands are known for big signals. Attenuation or circuit changes help greatly. The uBITX runs without an RF gain control and was optimised for a decently high overload point. So fewer people complain of overload but AGC is a common wish list item.
Stability has been mostly solved by going with Si5351 and Si570 digitally controlled local oscillators in modern HF receiver designs. This requires adding an Arduino microprocessor, LCD display and a some form of encoder to tune. The other implication is there will be signals generated by the microprocessor and in communicating with external devices like the display. It does open up a whole new arena of user interface that didn’t exist in earlier analog designs. An example of this is KB1OIQ’s version of uBitx that is blind user friendly (speech synth output and keypad controls) as its really well thought out.
Adding a Raspberry Pi or similar [STMFxx series] to do signal processing is on face a good idea, but the cost is considerable in terms of software development, and the need for a more sophisticated user interface and power. Power utilisation is an important aspect of a compact portable radio. Many wish to use batteries and a Raspberry Pi eats about 3-4watts continuously. Adding a touch screen adds an additional 3-5 watts to that figure. At some point its no longer a simple radio, no longer inexpensive and has become battery unfriendly. Some problems are easily solved without resorting to a computer.
Look at what is being done for the various SDR radios. If you are going digital its smarter to start with a new architecture and build in the computer rather than hang it on like a laptop on the side.
With all that said, yes the µBITx is a decent receiver in Allison’s view. Can it be improved? Yes. However, improvements depending on the use case. Different constructors will have a different idea of what that may be.
A naming competition for a new Raduino replacement
W0EB/W2CTX and N5IB have announced the upcoming release of a complete new board for the uBITX transceiver that utilises the PJRC Teensy 3.6 as the micro-controller rather than the Arduino NANO.
The team have been selling the Raduino replacement I2C display board that we lightheartedly named the “RadI2Cino” pronounced “rad eee too CEE no” as it’s part Raduino, uses the I2C bus to run the display and can replace the Raduino. It has met with a fair bit of success both NANO based and more recently with an N5IB designed adapter board that allows a Teensy 3.6 to plug into the RadI2Cino in place of the original NANO.
The Teensy adapter allowed for a number of extra digital and analog I/O pins that could be used for CW Keyer, S meter, Voltage Monitor and an almost limitless number of features not yet implemented.
Now Jim W0EB, Ron W2CTX and Jim N5IB, have come up with a newly designed board (still in prototype) that will, when the design is finalised, be offered in bare board or kit of all parts (less the Teensy 3.5 or Teensy 3.6).
This new board replaces the Raduino and does not modify the µBITx main board. It adds much more programming space and computing power while keeping as much plug-in compatibility with the original Raduino as possible.
It does however require several more encoders and one or more 1/8″ stereo jacks so more panel space will be required. The actual debut of the card will come after the naming contest and proof of concept prototypes have been built and tested before a production run will be made.
To go with this announcement the team has launched a naming contest for this board. It needs a catchy name to identify it!
The Naming contest for the new board starts NOW and runs through 23:59 UTC May 20, 2018.
The PRIZE awarded to the person who the team (W0EB/W2CTX and N5IB) judge to have come up with the best name for the new board will receive, free of charge, a complete kit of parts for the new board postage paid to the mailing address they specify.
This is open to all on the BITX20@groups.io reflector and the uBITX group on Facebook. The announcement has also been posted on the w0eb.com website.
Entries must be by direct email to the email address jrg.qrv (at) gmail (dot) com only.
You may enter as many times as you like (different name for each entry though). In case the winning entry is duplicated by another person, the earliest date/time on the submitted entry will determine the winner.
Should NO entry be deemed suitable to name the board (we reserve the right to accept or reject any/all entries), the contest will be extended for another time period (to be decided if necessary) and that will be announced.
The winner was Vince Vielhaber, K8ZW who submitted “BITeensio” (pronounced Bit-EEN-cio) as the winning entry.
There were a number of really decent and catchy entries, but in the end, by unanimous decision of all the judges, Vince’s entry of BITeensio was declared the winner. Vince will receive a complete board kit for the BITeensio card as soon as the production boards arrive from the factory.
Reference
KD8CEC as the factory firmware?
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.
The case for using KD8CEC firmware
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.
Reference
W8TEE JackAL Board at FDIM
Jack W8TEE provides a bit more insight into the JackAL board that uses the Teensy 3.6 to give lots of processing grunt.
Jack suggests that he and Al were going to put an SWR meter on the JackAl board, but have backed away from it for this iteration. The main reason was because of the board size. The nano-acres it would take on the board would raise the PCB cost above the 100x100mm size to do it right for the possible power levels that might be involved. That doesn’t mean you can’t add one…
The good news: Right now, there are about a dozen “empty” pins available on the board for experimenting. They are currently using less that 15% of the 1MB of flash memory and less than 10% of the 256K of SRAM. That includes code space for some features that we’ve coded for (e.g., a RTC) but have not implemented yet (e.g, adding a button battery to power the Teeny’s RTC in sleep mode).
The Teensy is a 3.3V device, so we have an onboard regulators for 5V and 3.3V. Al and Jack think this will up the “fun level” for hackers considerably…at least that’s our intention.
The bad news: They got caught in some kind of Chinese holiday and other “delays” to get the PCB. Al ordered the board since he did all the work on the EE design. It seems our Beta PCB order got pushed to the back of the line.
When Jack wrote to them and pointed out that he was disappointed with their service, especially after ordering more than 1000 boards from them last year, the order suddenly went from “In line” to “shipped” in under 24 hours. They received the board this week and discovered errors on the board (2 from the design team, 1 from the manufacturer of the board). The Beta board will have some “hairs” on it.
Jack and Al will be demoing JackAl at FDIM, but not all of the features will be implemented. The order for the new board will be sent this week. We’ll immediately send it to our Beta testers and then make it available via an announcement on the BITX20 list.
Al and Jack look forward to seeing uBITx constructors at FDIM!