This must be the best calibration guide yet from Steve N3SB. Thanks to MVS Sarma for bringing it to our attention.
Ashhar Farhan VU2ESE observes that ALC is just one way of controlling output power from a linear amplifier stage and that an easier approach is to do it in software.
This needs software that can control the ‘mic volume’. You could set the value differently for each band. There is another pay-off with software mic gain, it can make a major difference to the transmit IMD. At voice peaks, the tx linear chain compresses. The gain is not constant between low and high levels of modulation. This is the cause of in-channel IMD. Now, if we have a look up table that amplifies the peaks more than the lows, we can ‘correct’ the gain back to being linear. This simple concept goes by the name of ‘pre-distortion’ in the SDR world.
Don KM4UDX lived with with non-trivial frequency/calibration error until (in his words he, “finally found my boy-bits and went back to reading everything ever written on uBITX calibration (with CEC firmware and memory manager). The result was extraordinary levels of fear and confusion.”
In desperation, he said “foo it” and calculated the error ratio @ 10.00 MHz, multiplied that ratio by the base calibration number to get ~~-5000, then added -5000 in Memory Manager, and hit reboot.
Then he went to wsjtx’s freqcal mode to measure his new error relative to 3.330 (-7Hz) and 10.00 (-18Hz) reference signals. He was now close enough that he didn’t want to touch anything.
But of course he did… And every time he tried to reduce the error further by tweaking the calibration numbers, everything got worse. So he quickly realised he was as close as a mere mortal could aspire.
But he did run the complete freqcal process in wsjtx. That process reduced his µBITX freq error to 1hz or less in wsjtx. Don says , “That wsjtx is wicked. If anyone wants help with uBITX wsjtx freqcal mode, I’m your dude.”
Here are his wsprnet results using the humble v4 µBITX.
Don says, “That was without any real effort other than stumbling in the dark, and GREAT help from fellow hams and wonderful persons”.
He is now ranked ~155 in 2 way WSPRnet spots after only a few days of auto band hopping.
“NEVER did I expect my little uBITX to get to Australia and Antarctica” says Don and he adds, “All hale the mighty uBITX.” We might all agree!
Ron K0EIA gives a quick love note for the µBitx … He recently worked Andy VK5MAV/6 with just seven watts on his µBITx. Ron heard Andy coming through loud and clear, with really excellent receive reception on his radio. Andy is a top notch operator and took my call split in traffic. He was activating some island off the west coast of Australia (OC-211 according to website search).
He definitely did his part; I have a very quiet listening location; and my antenna is doing most of the work … but still an exciting QSO to log.
7.005MHz CW, uBitx v5, only mods are RTLSDR tap on 45MHz first IF, and N6DT AGC. Ant = fixed two element wire beam at 65ft.
John (VK2ETA) has been working on a successful modification to get the clock #1 mixer to unbalance on CW key down. This involves the following steps:
1. Re-wire the T4 transformer input and output as per T2. That means as Jerry said to “… cut traces to T4 pins 3,5 and 6. Swap them so T4 pins 3,5 are in from R47, pin 6 is out to C211.”
2. Disconnect (cut trace) from R105 to the common connection of C10, R27 and T2 (3,5).
3. Connect via a wire the disconnected side of R105 to the common connection of T4 (3,5), C211.
John used an audio shielded cable, and passed the wire under the board by drilling two small holes next the two connection points to ensure minimal pick-up of RF.
Pictures of R105 trace cut and wire to T4. (partially obscured by the hot melt glue on the toroids as I use my rig /P and /PM).
Picture of T4 traces swapped and cable from R105. (The line from the yellow toroid is a hot melt glue filament, not a wandering wire..hihi)
4. Change the software. When in TX CW mode, disable clock #0, generate a clock #1 at “SECOND_OSC_USB” – “usbCarrier” = 45Mhz (+ or -) and clock #2 at (that same 45Mhz signal + target Tx frequency).
The difference in signal strength between key-up and key-down as seen on a control receiver is from way below S0 to S9+20dB or so, giving a dynamic range of over 70dB (indicative value in light of the basic test method).
The output power in CW mode can now be controlled finely by shifting the 45MHz clock slightly along the slope of the Xtal filter. For example I go from 14W max to between 1.5 and 2 watts by shifting the clock #1 frequency by 30Khz on the 20M band. On the 10M band, I need a shift of about 10Khz to reduce the 8 watts out to the same level.
Now, thanks to a bit of programming, John has full control of SSB as well as CW power across all bands. Great for his built-in ATU.
If someone with a spectrum analyzer could check the implications for the harmonics and spurs that would be a plus. John would expect in CW mode that the harmonic for 80, 40 and 30M bands would reduce, but some spurs to appear since we have the beat of two clocks now. If there is interest John could modify Farhan’s code to match that modification (or publish some code snippets).
By the way, before he did the mod above, he also tried to put a trim-pot between R105 / Ground / slider to T4 (3,5) and even when turned all the way to zero (slider to ground) it would still constantly unbalance the clock #1 mixer. So the change in topology as described above is the only way he could get it to work as intended.
Dexter ZL2DEX posits that a uBitx is a bit difficult to *really* remote. Its control and display are done by Arduino, but the unit supplied by default in the ‘kit’ has that as the ‘Raduino”, with the ‘VFO’ part of that, being the on-board SI5351. This puts RF generation at the ‘control head’, so any distance of ‘remote’ has to be minimal.
The solution, it would seem, is a homebrewed Arduino control, where the SI5351 can be controlled by the likes of its I2C-bus connection.
By this means frequency control can be a non-critical function, with distance achieved digitally: 3 wires (2 active and earth) which do not behave as transmission-lines needing such radical shielding (and can even be optically-isolated)!. This leaves Audio (By ‘dongle’?) and PTT/Keying (likewise able to be opto-isolated but also perhaps able to be encoded into the I2C bus?). Some (most?) of these modifications are already being worked on.
It’s only a short step from the above to full-USB or HDMI – or LAN/internet. Who needs megabuck rigs or even an SDR to get a remote head?
Ted K3RTA’s first attempt at establishing a uBitx with a remote head in his vehicle was with the original 20×2 LED screen. He extended the volume, tuning & function knob, and the microphone, along with the LED screen by means of a 25-wire printer cable. The Arduino/Raduino stuff remained with the mainboard in a box under the passenger seat.
The current model uses a 2.8″ Nextion LCD screen on a 4-wire shielded keyboard cable so I can see it at dashboard height. One could have run the rest of the controls to the same location. However, the screen data nose gets hard to isolate… and Ted wanted the finger controls at a convenient arm-rest position rather than at a reaching position. There’s also one less microphone cable flopping around right in front of other things. The tuning/function knob and other controls are, therefore, located in a separate control head that’s fed with a separate, VGA monitor extension cable. The VGA cable is a Cheap-Old-Man compliant solution. Better yet when it originated from a supply that Ted didn’t pay for in the first place. The variation and complexity of so thin a cable makes it ideal… though an accidental discovery more so than a plan. Ted was just looking toward the shielded, 15 wires inside!
A VGA cable has four separate, shielded paths along with some extras, all shielded again by the outer layer. These can protect the audio path.
Ted can still hear some of the Nextion activity, chiefly the data streams associated with the 2nd Nano and spectrum/s-meter action. This is mostly on weaker signals with the volume control turned right up.
He found the speaker audio, even with a Motorola public-safety type radio speaker, a bit mild for 70mph highway use so Ted is adding a 15-watt amp to make it louder.
SOTABEAMS make a Digital Variable Audio Filter Module that could usefully be added to your uBITx.
David Balfour didn’t like the lack of a mechanical connection for the raduino. So he made a 3D printed frame for the Raduino and uses 12 mm long 3mm screws and nuts to hold it together. It deploys stock front mounts with the original screws replaced by 12mm screws. It sure looks professional. The 3D printer template can be found here:
The v5 uBITx has an LM386 for the audio amplifier stage. Philip G7JUR suggests connecting a 10 microFarad capacitor to the LM386. The +ve end should go to pin1 and the -ve end of the capacitor to pin 8. The easiest place to access is to solder to C75. This will give a bit more gain, and bass.
Ashhar Farhan VU2ESE commented that the LM386 distortion really increases with increased gain. He also notes that more gain is not increased sensitivity. He thinks a better idea might be to bypass pin 7 to ground with the 10 uf. Either way, he suggests that Philip keep experimenting!
Jerry KE7ER suggests for uniform gain from 300 to 2300 Hz
with no capacitor gives at least 26dB but under 46dB with a 10uF capacitor.
Adding a resistor in series with the 10uF cap would reduce the gain.
The Nano in the Raduino is readily damaged from wires touching 12v points, being exposed to RF, and from the Raduino being plugged in to the DuPont connector incorrectly. Since the middle of 2018, these have been socketed, making it relatively easy to replace the unit. Earlier units were soldered in place.
Ted K3RTA asks, “Have any of my fellow uBitx / Bitx40/20 owners experienced a different life span or robust survival rate between US$22 authentic Arduino processors over their cheap-as-dirt clones out of the Far East?”
“Some of the Nano failures reported here can be attributed to not enough protection on the IO pins. For example, a couple pins going out to a keyer may as well be protected from static discharge with series 1k resistors. Raduino should have protection against reverse power. RF could conceivably get into some of these wires and zap an IO pin, though I tend to doubt that unless very long.
I had one of my stock Nano’s go south, though it could well have been something I said. Several reports in the forum of stock Nano’s working out of the box, but sucking far more power than they should. Suggests to me a Nano clone manufacturer with a quick go/no-go test, but not much more in the way of quality control.
When mine blew I then bought three from Elegoo at over $4 each, no troubles with them. Expensive? Well not really, but there are Nano’s on Ebay for down around $2. Those $2 ebay boards have little pressure to maintain quality control, all they need to do is get their board a nickle cheaper and ship something that vaguely works. Seems likely that some would be built using somebody else’s reject parts. Elegoo has a name to defend, they get good reviews, and likely monitor their sources closely for trouble. At least, that’s my theory. Seems worth a few bucks to (slightly?) reduce my odds of spending a day tearing at my hair. What little hair (and time) I have is well worth $5.
I have yet to spend big bucks on a genuine Arduino Nano.
There’s no doubt that “real” Arduino boards rarely have any problems when used and are of better quality than the clones. I used nothing but the real thing for years. Somewhere along the line I started trying the clones…
I’ve been pretty lucky with the clones. The biggest problem I’ve had is the non-standard drivers. However, in most cases, downloading/installing the CH340 device driver fixes that problem. More recently, I thought I was seeing the driver problem again, but even installing the CH340 didn’t fix it. Turns out some of the clone manufacturers are using an ancient bootloader that is confused by the recent versions of the IDE. Fortunately, it’s easily solved. Use the menu sequence Tools –> Processor: “ATmega328p” –> ATmega328P (Old Bootloader) and do another compile/upload sequence and that should take care of it.
At times, I do feel guilty that I’m no longer using the “real” Arduino controllers. I try to make up for this by making a small donation every time I download a new release of the IDE. I think that probably more than makes up for the small profit they might have made had I purchased the real thing. I hope so. I also hope everyone else does make some kind of donation from time-to-time. Now, if they want to integrate a full symbolic debugger….