Carl Beck W5BEK designed his own case for the uBITx and printed it out on a 3D printer. Check out his PDF: W5BEK uBITx case. It looks pretty cool!
Note that Carl is now Silent Key, so this case is no longer available for constructors.
John VK2ETA raised a request for help on the group list on 24 January after spending over a week trying to figure out an issue he had with his uBITx.
John built his uBitx around a manpack configuration with an external side mounted heatsink, no connection at the back, and room for an autotuner. The issue he had was strong audio tones inside and outside the passband on receive, typically up to 15khz.
He attached an audio recording and took some audio spectrum snapshots made by placing the phone’s microphone near the uBitx speaker. The tones were often near or above the level of the decoded signal which makes them impossible to ignore. The frequency of the tones did not change significantly with tuning up or down, or going through the menu items except when passing over the “CW Speed” option.
After doing all the normal things you would expect, such as redoing the factory alignment and BFO adjustment several times, nothing changed. He changed out the power supply (with three alternatives), he checked the voltage on the Radiuno: 5.01VDC, added capacitors from the Radiuno 5V rail to ground (470uF, 0.1uf mica, no change), power supply rail to ground (470uF, no change), and added 1nF between the casing of the Arduino crystal to ground (which produced a shift in tone, but no reduction in amplitude). He modified the software where I would shift the frequencies of both the first and second oscillators by the same amount, thereby leaving the received frequency the same. The result was no change in frequency of the annoying tone. So only a BFO frequency change produces a shift in tones.
Needless to say John was right out of ideas and welcomed input from the group.
Jerry KE7ER immediately responded:
Your best bet might be to either replace the nano or replace the 16mhz crystal on the nano. It might be possible to shield and filter the nano sufficiently somehow, but that would be tough. It could be that HF Signals would consider replacing your Raduino. You might ask them. Do you have somebody nearby you could swap out the Raduino with, to see if the problem follows the Raduino?
There were a number of other responses from group members, and other group members had observed similar issues with tones inside the filter passband.
The problem solved
On 2 February 2018, John announced to the group that he had solved the problem:
“I bought a cheap Arduino on eBay and after some struggle I changed the Nano, re-programmed it and all came good. The tones within the passband are gone and the ones outside the passband can be eliminated with a careful choice of BFO frequency. Also the tuning noises have disappeared. So it must have been a bad Arduino.
“As an interesting aside, when chasing this issue I changed the first two mixers VFOs thereby changing the alignment between the 45Mhz filter and the 12Mhz one. I noticed that the default values produced a signal around 8dB lower than when “re-aligning” the two passbands.
“If anyone is interested I can share the code for this test (I simply re-assigned the RIT menu item and had an extra variable which was added to the first two VFOs so that the net received frequency stayed the same, but the first IF was shifted correspondingly).
“Please note that I found the removal of the Arduino a challenge and resorted to cutting the edges out of the Arduino board with a Dremel. I cut the plastic spacer between each pin to be able to de-solder each pin individually.”
“Since I have mounted the display remotely and have space in front of the Raduino, I opted to use female headers so that I can plug/unplug the Arduino, just in case.”
It turns out that Jerry KE7ER’s advice was spot on. Afterwards he commented:
“Could be that the old arduino had a faulty 16mhz crystal. But that thing is tiny, swapping in a different crystal would be tough. Could also be that the ATMega382P processor had a faulty oscillator.”
Ashhar Farhan from HF Signals has since commented on this fault:
“Since we noticed these problems, we do check for the presence of these tones. Our pass test includes viewing the audio spectrum at 5v/db, 625 hz per division setting of FFT on rigol. We set the carrier so that the audio passband is inside two cursors at 300 hz and 3000 hz. Then we check for any spurs upto 15 khz that are above the noise floor. If these tests pass, we move to the next test of transmit outputs on 3.5, 7, 14 and 28 mhz. These tests are a part of the firmware being shipped.
“I suspect the 16 mhz crystal must have aged. There are two things you can try. First is go into the bfo settings and move it slightly so the spurs go away. Second is to add some capacitance to the 25 mhz crystal, about 10 pf. There is a third way too, which is to program the si5352 initialization code to enable a different load capacitance on oscillator. I havent tried the third method myself.
“Very often, closed commercial designs tend to ignore or bury design faults. Open source proceeds with acknowledgment and fixing these to make the system better. As the saying goes, given enough eyeballs, all bugs are shallow.”
Fred PE0FKO asks a question about relay K1 after looking at the very nice schematic of the uBITX.
“The K1 relay is used for the RX and TX power switching and also for connecting the antenna in RX to the LP filter. On RX (and TX) the LP filter is also a connection to the TX power amp by C80, that will give a (very) small load on the antenna signal at RX and a mixer (Q90 diode BE) for strong received signals? Could it be improved by switching pins 12 and 14 of K1 and connecting pin 16 of K1 to C80 (removing the connection to the Low Pass filter)?”
Jerry, KE7ER responded:
“It’s a good idea to make use of K1-16 to disconnect Q90 during receive. This would also protect Q90 from local QRO transmissions into a local antenna, The similar Q13 on the Bitx40v3 is often blown in such situations, even when the rig is powered down.”
Alf Baranda asks:
“Can it be the Mod that I have highlighted?”
Of course it is the same mod! Alf goes on to attach images with the signal paths in the RX and TX modes.
Dennis Yancey asked the group “Has anyone used a dynamic mic on the uBITx?” Dave WI6R responded with a guide for modifying the uBITx to use a Dynamic Mic:
Replacing R63 with a Zero Ohm resistor and putting a 10K potentiometer at the Mic input should allow a Dynamic Mic to work now with a Mic Gain Control. Also, R60 that supplies Mic BIAS to the Electret-Condenser Mic needs to be removed. If there is not enough gain after this mod, you might have to reduce the value of R64 to maybe 470 Ohms or so.
If you cannot look at your transmitted signal on a scope at least listen to your audio on another receiver to verify you are not causing distortion.
Members of the BITX20 IO Group have set up real time chat pages in Discord and Slack for you to discuss your BITx20, BITx40 and uBITx experiences and ask questions.
Click on the relevant graphic to join the chat:
Raj VU2ZAP made this 4 way female Dupont socket for mounting either the stock IRF510 or Mitsubishi parts such as the RD16HHF1 or RD15HHF1 in the finals circuit of his BITx40. You must first desolder and remove the stock IRF510. An extra hole is drilled in the circuit board to the left of the three existing holes for the stock IRF510 . The new pin hole to the left of the regular 3 holes is wired to the gate pin of the IRF510.
By reversing the RD16HHF1 orientation, and inserting in the left-most 3 pins of the socket, the device now substitutes for the IRF510. But you can re-insert the IRF510 at any time by unplugging the MOSFET.
Raj’s parting comment is that “you will need to think of a heat sink plate that fits this way!”
And another aluminium case suggested by wishbone_aaa:
Jim Sheldon, W0EB says:
“I’ve got one on backorder for my third uBITX. The uBITX should ship pretty soon, so I hope the case backorder doesn’t take too long. I’ve used the smaller versions of this case on other projects and it’s really nice to work with, but the aluminum front and back panels are really soft aluminium. Be careful drilling holes and cutting out the LCD window.”
John Backo answers the question: “What are those lights on the nano anyway? And do I need them?”
There are usually 4 LEDs on the nano. They are usually in a row and labeled “RX TX PWR L”.
The RX and TX lights are connected to the lines that connect both the USB interface and the ATMega628P. They connect to TX0 and RX0. They are very useful as their flashing shows that communication is taking place during an upload. Likewise, if RX flashes once and then not again during an upload, there is a communications problem. Usually they are red and green; some may be orange. Messing with them will probably mess up RX0 and TX0. It is best to leave them alone. They are always out (low) with no serial communication to the chip. If they stay on, something is wrong…
PWR refers to a direct connection to the voltage regulated 5v line. It is NOT connected to the input voltage, whatever that may be. It is an indication that the board has power either from Vin or USB. That is all it does. It is usually red though I have seen many orange lights. It is useful, but it could be eliminated, I guess.
L is connected to D13. It is a good light and should not be disconnected. If the ATMega has a bootloader (which it should in a nano) this will flash three times when the reset button is pushed and released. That is not guaranteed because earlier versions of the bootloader did not show themselves through D13. And if the ubiquitous Blink program is loaded, it will falsh D13. That alone makes it a good light to retain. It is your “diagnostic visual indicator”.
David N8DAH has been testing the MAX9812L Mic Pre-amp module on his BITx40. In theory this should improve the gain and signal quality.
David says “So far its working ok at best I sound a bit robotish.”
“I am TXing at around 20w with my amp. I took the audio out through a 10uf dc blocking cap to the bitx40 mic in. I powered the board from a 9v just for testing. R136 is about 1/4. If you use a pre-amp you should adjust this lower or you will cause one heck of a noise on tx. I am not yelling or shouting to get audio out now but not sure I like the audio in any case.
This is without the pre-amp … with the audio files from Michigan to Milford PA websdr
This is with the pre-amp …
David has decided he “might just stick with the slight yell to get the audio out. I like the idea of not having to shout but do not like the audio from this version of preamp”.
Others may think differently. Mike ZL1AXG thought his “more robot-like” voice was more intelligible because it was more “punchy”.
Jeff AD6RH says:
“I used another mic housing with a DPDT switch and wired it so voltage is supplied only when PTT is engaged. I am using a CR2032 3v button cell. It seems to work fine, but I have not compared the stock vs. preamp mic with anyone on the air yet. It definitely has more average power on the watt meter. I can hear some peaks come thru the speaker when transmitting. I may try installing a pot to dial back the gain.”
Fred W4JLE writes that he has just discovered the NEXTION display and he has begun using it on his BitX.
He says “what makes it really neat is the software that can be downloaded from the manufacturer’s site. It takes all the pain out of graphics programming. I have replaced the UNO with an STM32 as in addition to the normal stuff I have added a GPS module.”
The display shows time/location/grid square data as well as using the 1PPS in the GPS module to do a continuous correction to the SI5351a oscillator. The higher resolution allows calculating the SWR etc. with much finer gradations.
Fred says he will be adding a filter board from a CODAN that will allow all band operation which he purchased for $12.00 on eBay.
Fred’s concluding comment is that it is “Amazing what is available to the homebrewer today!”.
We are eagerly awaiting a link to his sketch and to see photos of his uBITx!