Pop VU2POP shared pictures of his homemade ubitx cabinets. The design involves a common cabinet for both the standard manufacturer supplied 2 line 1602 LCD display as well as the 2.8″ TFT Nextion display. Pop says “You need to change out the bezel.” This is a really good idea.
He supplies the complete cabinet, fixtures, microphone, microphone and PTT sockets, associated PCBs, and the speaker, fuse holder, fuse, heat sink insulation kit, heat sink compound, tags, screws, usb cable panel mount, knobs, folding feet, glue, and a USB to rear panel connector cable to fit on to Radiuno.
This is similar to his earlier cases, except this case will have common front panel bezels for 2.8 inch TFT & 2 line LCD. Just change out the bezels! Constructors can build the stock µbitx to get going and then upgrade to a 2.8″ TFT display at a later date when they have the basic rig working perfectly.
At present these cases are only available for VU amateur operators.
Complete kit and kaboodle
DX shipments will be available at www.radiokart.in from Feb 2019.
Both are very small and perfect for QRP travel ops! They both use open source code based on JackYack keyer code
Also, ND6T has given permission for another release of his AGC. This version of the very popular kit add-on for the µBITx includes a few added goodies like an S-meter tap! This version will not require any drilling and should (if all goes as planned) solder right in and sit flat on the ubitx PCB.
The source code for JackAl is now available for download at our web site, hamradiodesigns.com. I apologize for the delay and that delay is totally on me. Al had his work done months ago. In my defense, it not easy to get 11,000+ lines of C/C++ code to play nice with each other. That said, we think the final result is worth the wait, with features we think everyone will appreciate.
Some details:
There are multiple files in the project. Only one file has a secondary file name of INO. This file contains the setup() and loop() functions and, therefore, all program control elements start in the INO file. All other files are CPP (i.e., C++) files. While this is different than some of you are used to, it brings two advantages to the party: 1) it allows for type checking across files, and 2) it allows for incremental compiles. This second feature can be a real time saver. Instead of compiling almost 400K of source code spread out over 19 files, incremental compiling causes the IDE to only compile those files that have been changed since the last compile.
Line number 4 in the JackAl.h header file contains this line:
#define DEBUG
In setup(), you’ll see
#ifdef DEBUG
Serial.begin(115200);
#endif
In a few places you will also find:
#ifdef DEBUG
Serial.print(“x = “);
Serial.println(x);
#endif
If you leave line 4 in the header file unchanged, the Serial object is compiled into the code which can be useful for debugging, like the Serial.print() lines above. If you comment out line 4, the Serial object is NOT compiled into your program, and all of the subsequent debug print statements are also not compiled into the program. This technique is called “scaffolding” and it allows you to “remove” debug statements without actually removing them from the code. Because you don’t have to retype your debug statements in the highly unlikely event your changes have a bug in them. This can be a real timesaver. You decide what to do with line 4.
Even if you’ve never programmed, you will eventually get tired of seeing Al’s and my names on the Splash screen. The Splash() function is in the INO file and feel free to change it to your own name and call. Note if you want to change something, you must have installed the Arduino IDE and the Teensyduino patch. Details are in manuals.
This code is Open Source, as is the hardware. This is an experimenters platform and we hope you will do just that. That said, we ask that you leave the file header comments unchanged and at the top of the file. Feel free to add whatever you wish after our comments.
There is a JackAl group now (https://groups.io/g/JackAl) and all comments, questions, and support will be done via that Forum. Please check the site from time-to-time, as we know we want to improve a number of things in the software.
It is better to have a quiet fan that meets all of the requirements without any extra circuitry that can fail. You can make a fan more quiet by adding a series resistor. Experiment to find the right value, but perhaps start with around 500 – 1000 ohms.
Another easy solution is to simply run the fan from the 12V transmit power, assuming that is not what you are already doing. No reason to run the fan while receiving.
If a noisy fan is the only choice, then putting in a controller to minimize the noise while still removing the heat is the next best solution. If properly designed, installed, and tuned, then there would not be a change in the amount of heat that can be removed as the heat sinks get hotter. The response time can get in the way of keeping the finals cool quick enough to not cause an issue. An always on at max fan does not have this issue.
Woody KZ4AK suggests fan controllers are easy to build and minimize noise when not needed.
Something like these… YMMV
Variable analog – Had to add the 3.3 ohm to reduce induced noise in the uBITx from high current fan.
OR
Jack, W8TEE and Al AC8GY have formed the JackAl Group for those who may be interested. Because JackAl is an add-on board for the µBITX, we designed the board to be an experimenters’ platform.
While JackAl does use over 200K of flash memory, its processor (a Teensy 3.6) scoots along at 180MHz and leaves about 780K of flash and 230K of SRAM free for experimentation and you still have about a dozen I/O pins to experiment with, too. They are also using the PJRC companion audio board to augment the DSP that JackAl supports.
Those who may be interested should visit the site:
Raj VU2ZAP has uploaded to the files section on the BITX20 IO Groups list an Excel spreadsheet with the full range of test point RX/TX voltages without modulation. His power supply was adjusted to 12.0V during RX and TX.
You will need to be logged in to the IO Groups site to access this file.
The power output of the µBITx varies according to frequency.
Richard Pushman provided a chart showing the power output of the rig by frequency from 2MHz to 30Mhz for two different supply voltages. The shape of the peaks and troughs is, of course, influenced by the LPF filters in the output stage.
He added a tandem match from eb104.ru, 4 arduino relays for PTT and ATT (-6dB) and an optocoupler board for switching the LPFs.
The Nano is connected to the ubitx via i2c. Mark had to insert some lines of code to send the frequency and PTT info to his amplifier. It was a tight fit in Ian KD8CEC’s software, as there was not much memory left for additional code.
I tend to forget to switch antennas when changing fom 40/80m to higher bands and blew up a few finals in the past, so the code in the amplifier demands a low power tune after band changes.
When transmitting and high SWR occurs, PTT is disabled.
ATT is enabled on 20-80m as Mark’s µBITx puts out more than 5W on these bands.
Mark will gladly share all details if anybody is interested,
Link to the low pass filter used in the linear amplifier by Mark.
Ashhar Farhan VU2ESE writes that “there seems to be a light at the end of this tunnel now” with respect to improving the µBITx.
Over the last few weeks he has been talking in the group and off the group with a number of people: Raj, Jerry, Allison, Bill (Meara) and the following represents the consolidated wisdom of this group on the failings (and cures) for the v4 board:
1. The spurs were cause by the harmonic distortion in the 45 MHz IF amplifier. This resulted in a 90 MHz harmonic that mixed with the local oscillator to produce a spur. the local oscillator was at 45 Mhz + tuned freq. The spur was as 90 MHz – local oscillator, that is 90 – (45 + tuned freq) = 45 – tuned frequency. Hence for 21 MHz ,we had a spur at 45-21 = 24 MHz, etc.
The cure was to increase the current in the amp by decreasing R26 from 470 ohms to 220 and introducing a low pass filter between the front-end mixer and the 45 MHz IF amplifier. This consists of L31, C205 and L32. A little snick and solder job can do this on existing boards. WIth these mods, the spurs are well under control. This hack was due to the preliminary work that Raj did followed by taking 50 odd readings of how the spurs moved and analyzing them. in the end, a two variable equation out of a 7th grade algebra book could point out this problem; but we never knew.
2. The harmonics at below 14 MHz were due to the bad routing in the LPF relays. Allison provided a simpler and far better option. The unfortunate part is that the existing boards can’t do this. The other tragedy is that the way these relays are wired . The 28 MHz filter permanantely in the tx output path and the other three LPFs switch in, in series with it. So, the Arduino code for these LPFs is going to be different too.
3. Change of 2nd IF frequency. I am moving the 2nd IF to 11.059 MHz from 12 MHz. This will avoid the frequent problem of having the the 16 mhz oscillator generating spurs inside the IF pass band. The new filter is also a little broader, it is about 2.7 KHz. The audio sounds better, at least I personally prefer it so. Hence, the crystal filters’ caps are changed from 100pf to 68 pf.
4. The LM386 returns. Ashhar Farhan says he is regretting it already. The audio amplifier is now the old frenemy of hams, the LM386. We had to do this because it is the only one that is readily available to manufacture as well as to those who are going to scratch build. This is an open source project that must use easily available components and also strive for a minimum complexity. Using an op-amp with a complementary npn-pnp pair could have worked, but the complexity would have had us to use a bigger board. We wanted to keep the board size same, to allow others to upgrade as well.
5. It is vital that the output above 14 Mhz must be kept to 5 watts. Over-driving this rig will certainly lead to spurs. Check out the captures of 21 MHz. One is with a 5 watts output, the other has it over-driven to 10 watts. It will stay within the legal limits with the supplied electret mic.
Check out the pictures. The green line across the screen is drawn at -43 dbc, the legal limit in the United States for harmonics and spurs. Ashhar adjusted the RF attenuator so that the transmitted power stayed at -20dbc. See how the distortion adds to the spurs in the two 21 Mhz captures.
v5 board at 21MHz on 10w (overdriven)v5 Board spurs with 5w (not overdriven)
Ashhar says “If things look good, we will roll with this as v5 board”. We can expect an update in 2019.
