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.

Reference

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!

Reference

A month of FT8

Yesterday was when Tom  AB7WT completed his first month of using his uBITx on the air and it’s been 100% FT8.

After one month, Tom has had 252 FT8 contacts!

This has been achieved with a modest random length end-fed 59 ft antenna with one end up in a tree.  He’s worked 80m, 60m, 40m, 30m, 20m, 17m, & 15 meters.

Almost all contacts have been using 4 watts or less. The results have
been great.  It includes 45 of 50 US states confirmed toward Worked All States (WAS).   He is still trying to nail down those last 5 states.  Tom has worked New Zealand, Australia, Russia AS, Samoa, Cuba, Japan,
and Canada.

So, he’s been very happy with FT8.  He’ll be even happier when
the sunspot cycle turns upwards …..:)

Are there other happy op stories out there?

Reference

AE7TO experience with evening up power output

Mark Cantrell (AE7TO) has been having fun getting his uBITx to have more even power out.

All this experimentation was to allow Mark to get enough power out of his µBITx to make up for low efficiency portable antennas.  He didn’t want to carry a separate power amp.  He just needs to build a 24 VDC battery pack now!

His rig can be seen in the photo above.   At the left hand side (with controls incorporated on the rear panel) is an Antenna Tuning Unit and in the middle is a new daughter board.

Step 1

The new daughter board implements the relay-based band output power leveling mod designed by Bill (K9HZ). 

This mod helped quite a bit at 10 and 14 MHz.  Here is a summary of power levels, as observed by Mark, on each band after the mod:

  • 7 MHz and lower frequencies = 11 watts out (no change from before the mod
  • 10 MHz = 8 watts out (twice was I was seeing before the mod)
  • 14 MHz = 8 watts out (also twice what I was getting before the mod)
  • 18 MHz = 6 watts out (never checked that band before the mod)
  • 21-28 MHz = 3-4 watts out (didn’t test that band before the mod)

Mark didn’t bother adding a 4th relay for tuning as he usually uses an antenna analyzer and manual tuner anyway.

A 3D model file is available for the plastic bridge built to hold the daughter-card above the main uBITX circuit board.  Someone else may find that file useful.    

Step 2

Mark split off the PA power line and fed it 25 VDC (two small lead acid batteries in series).  A buck converter was used to reduce the 25 volt main supply to 13.5 VDC for the rest of the uBITX main board.
That gave 25W at 3.5 to 7 MHz, 12W at 10 MHz, 14W at 14 MHz, 5W at 21 MHz, and 4.5W at 28 MHz.

Then he added a 33 uH inductor in series with R86, and 220 pF caps in parallel with R87 and R88, as suggested by Howard WB2VXW.

Here is a summary of power levels after the above changes (plus replacement of RV1 with the 3-relay/4-pot mod discussed below):

Freq / Power Out / Current Draw
  • 3.5 MHz / 28 W / 2.3 A
  • 7 MHz / 28 W / 2.2 A
  • 10 MHz / 16 W / 1.4 A
  • 14 MHz / 20 W / 1.5 A
  • 18 MHz / 11 W / 1.1 A
  • 21 MHz / 7 W / 0.7 A
  • 28 MHz / 7 W / 0.7 A

These numbers are good enough that Mark no longer feels the need to fiddle any more.  In particular, he is not going to change the bias settings on the finals as they seem well adjusted from the factory.   Mark has turned back the power output on the low bands to give no more than 20w out to protect his finals.

VU2ESE power mod for 10m operation


Ashhar Farhan VU2ESE notes that 28 Mhz has, unusually, been open for the last week.  As a result, he realised that the ubitx output was woefully low on 10m.  Hence the experiment below:

Ashhar suggests the following final fix, and asks for others to try it out and see if it is replicable:

Replace C81 from 0.1uf to 470pf
Replace R83 from 10 ohms to 2.2 ohm
(you can short R83 as well)
Replace 97, R98 from 47 ohms to 220 ohms
Remove C261, C262.
So, what happens is that removing the C261 and C262 increases the gain of the finals. They are run open. Hence greater gain at 28 mhz.
However, the gain is very high at lower frequencies. So, in order to reduce the gain at the lower frequencies, the 0.1 uf cap is replaced by the 470 pf. As the frequency of the signal drops, less and less RF flows through the 470 pf, decreasing the gain of the predriver. 470 pf is not a magical value, 220 pf works almost as well.

Step #1 Increase the predriver gain towards the higher frequencies

The predriver Q90 has a emitter degeneration capacitor C81 (0.1uf) and and R83 (10 ohms). Replace C81 with a 470 pf and R83 with 2.2 ohms. Altenatively, short R83.

With this, the emitter reactance decreases with increasing frequency, yielding higher gain beyond 14 MHz.

Step #2 Take off the feedback from the IRF510s.

a) Replace the existing  R97 and R98 with a value of 47 ohms  with 220 ohm resistors.
b) Remove C261, C262.
Reference #1
Reference #2