VK2ETA variation updated (based on KD8CEC firmware)

John VK2ETA has uploaded two updates of his Raduino firmware and ATU firmware in the folder: Variations on KD8CEC Software (by VK2ETA) + ATU sketch .

This firmware is targeted at portable and /PM operations. John doesn’t plan to add much in the way of further features unless they are of value to portable operations.

If you want to use sections of code in your projects, follow the #ifdef/#endif segments that mostly enclose the sections of code of interest. John is happy to help with extraction of code if requested.

The software is organised in options that can be enabled/disabled (mostly) independently.

The key features added in this version are:
1. Reduction in libraries size by 1K byte (this allows for more features to be added in the limited memory of the Arduino).
2. Added a “Stock Standard” option for unmodified rigs wired as per HF Signals instructions.
3. Added a two adjustable levels supply voltage monitor with visual and audio indication. Level two will disable TX to protect the battery.
4. Added the WSPR beacon option from KD8CEC software version 1.061.
5. Changed logic for CW modes: frequency displayed is carrier frequency, with Rx frequency shifted up or down (CWL / CWU).
6. In split modes, the VFO A/B label and frequency change when going from Rx to Tx.
7. RIT display:  frequency is kept fixed, RIT is now shown as +/- frequency difference.
8. Added ALC levels for MAX level too. Used to be no attenuation.

The second update is part of his approach to continuously look for program size reduction to have as many features as possible concurrently in the Nano’s memory.   Inspired by Ian Lee’s KD8CEC version 1.701, he has included a modified version of his TinyLCD library.  Compared to the complete default LiquidCrystal library this cut down version saves 452 bytes of program flash memory.  He has made this code into an object oriented class so it can be easily retrofitted into other projects as there were only two lines of code to change.

Reference

Using 2nd channel of TDA2822 for S-meter

John VK2ETA suggests using a section of the original AGC circuit of the µBITx (design by Ashhar Farhan VU2ESE) for generating a signal for an S-meter so that this can be used by his modified software.

This was part of the pre-production uBitx diagram but was not implemented in the production version.

The 2N7002 is used as an automatic gain control and can be used or not for that application.   The circuit has limitations since it was not included in the production version.

You would need to insert a trim-potentiometer (10K ohms is good) between pin 6 of the TDA2822 and the VOL-H connection to adjust the sensitivity, plus (VERY IMPORTANT) a voltage divider, between the cathode of the diode and the ground, to limit the voltage to under 5VDC for the analogue input of the Raduino.

John would use 330K ohm in series with 100K ohm to the ground, and connect A7 to the junction of the two resistors.

Further adjustments are available in the software if required as we define the 9 stages of the S-meter display (first stage is zero, then 6 stages for growing bars, 1 stage showing “+” and one stage showing the custom “++” symbol). In ubitx_20.ino it shows as:

int sMeterLevels[] = {0, 5, 17, 41, 74, 140, 255, 365, 470};

The values in the array are the measured values on the analogue input (defined as A7 above) at which we step into a higher “stage” and can go from zero for zero volts to 1023 for a 5V DC value.

Reference

SSM2167 Mic Compressor: Avoiding feedback

John VK2ETA notes that Simon, VK3ELH, pointed out  an issue that when inserting an SSM2167 mic compressor circuit between the microphone and the uBitx mic-preamp, it can create feedback when the microphone was placed near the speaker while in RX.  This is because the SSM2167 module is always on.

The solution John has applied is to connect the shutdown pin of the SSM2167 (pin 3) to the Raduino T/R digital output (D7) through a 2.7K ohm resistor. This disables the chip while in RX and removed the mic feedback issue.

Pictured above is an indication of where he picked up pin 3 on the SSM2167 on his module. The purple wire is connected to what is the right hand side of resistor R4. The 4.7K resistor on the RHS is for the mic-bias and the 51K resistor on the top-left is for bringing the compression ratio towards 4.

John feeds the Vcc pin on the board from the regulated 5V of his Raduino. Measured consumption at 2mA is a very small extra load on the Raduino regulator.

There is a DC blocking cap on the input and output circuits of the board already, so no external blocking capacitors are needed.  However, a bias resistor does need to be added for the microphone.

The 2.7K resistor is not mounted on the module, so is not shown in the picture.

Also not shown on the picture are an axial choke of 100uH between the “in” connection and the Mic, plus a 1nF capacitor between the “in” connection and ground to block RF feedback when Txing on higher frequencies. For John, RF feedback was noticeable from 15m through 10m. Others may not have this issue.

John also has a 10K adjustable potentiometer between the “out” connection on the module and the original Mic input to the uBitx.  His is turned to about 80% through its range.

John mounted his board on header pins so he can remove it as required.  He extended the header pin on the “out” side (bottom LHS on picture) past the board to provide an extra connection for the shutdown wire.

John finds the compression and noise gate work quite well on the module. When he is silent the background noise does not trigger any movement of the power needle, but it goes up as soon as he speaks into the Mic. Also despite showing quite an increase in average power, he hasn’t had any negative comments on his  audio. I was told that it was noticeable, but not unpleasant, “good for DX”.   And this was with a change in the standard resistor value for compression to give around 4: 1 compression.

Reference

 

Extensive VK2ETA mods to KD8CEC firmware

John, VK2ETA, has implemented a range of changes in Ian KD8CEC’s software targeted at portable operations (the software can be downloaded here in the files section of the BITX20 IO Group).

VK2ETA Software modifications to KD8CEC firmware

The scope of these modifications is described below:

Options for various features – These can be turned on or off. Key objective is to be able to customise the rig based on your needs and unfortunately on the restricted memory size of the Nano. So not all features can be selected at once. Choices, choices…

ATU control – A servo-based L-Network ATU. The communication between the Raduino and the ATU Arduino is via I2C. There is a separate sketch for the ATU Arduino (Nano or Pro-mini).   ATU operating mode can be set to OFF, Manual as in on-demand, or auto-RX meaning that it pre-tunes based on historical data on a change of band and after first change of dial frequency (for a quick scan of the bands). It uses the EEPROM data of the closest stored frequency for pre-tune or tune on-demand to accelerate the tuning process.

Handsfree microphone/headphone – Using an Android style 3 rings (TTRS) handsfree earpieces/mic combination, with 1 or 3 buttons (Play/Pause, +, -), the PTT is controlled by Play/Pause as toggle, and I use long presses on + and – as respectively pre-tune and smart-tune of the ATU. Short + or – presses could be used for frequency up and down. Requires a very simple hardware mod to free-up A6 (see below).

S-meter measure and display – using analogue input A7 from an 2N7002 based AGC or a MAX9814 circuit or any other for that matter.

Software based AGC range extender – to augment (as in double or triple) the dynamic range of an audio AGC. This uses the slope of the 1st If filter at 45Mhz to attenuate the Rx signal when the audio AGC reaches its limit. Adds over 50dB of dynamic range.

Forward power and SWR measure and display – Currently assumes that the ATU is providing that info over I2C. Otherwise could be adapted with a pair of analogue inputs for measure. See the excellent NT6D design on the wiki.

Options for displaying the S-Meter, SWR and forward power –  in either easy to see “fat” bars with no number, or “skinny” bars with more text and numbers.

Enable a “Memory mode” – selectable by menu, which cycles through all the populated memories (channels). Dial lock also locks the change of channels.

Made some rarely used or once-off functions as options  – to recover program memory after initial tuning and allow for more options to be selected.

Fixed some issues with the IF-shift option – Ian has resolved these in his new V1.06 and later releases. Two issues were present: IF-shift in USB would change the receive frequency and it was applied to TX as well. Now applies to Rx only.

Hardware modifications required to use VK2ETA software mod

The only required hardware mod is to connect the CW key input to the PTT. Since in Ian’s software we select the mode by menu, there is no need to have a separate analogue input tied-up for the CW key. This frees-up analogue input 6 for use by other functions like the handsfree option above.

Still to come

John plans to apply Ian’s improvements in v1.06, especially the CW transmit frequency option and if possible the WSPR beacon mode (as a further add-in option).

How to use VK2ETA software

Download the zip files, and unzip these in your Arduino sketches folder.  Edit the ubitx_20 options sections, using #define for enabled and #undef for disabled.

Perform a CTRL-R to compile and check how much memory is used. If you go over the limit, a warning is issued.  Providing you have enough memory to run the software, upload the sketch to the Arduino.

John has uploaded both the Raduino as well as the Arduino sketch for the ATU and SWR measurement. They can be found in the folder “Variations on Ian Lee’s Software (by VK2ETA) + ATU sketch”. 

All software is released under GPL V3.
Reference

Use the 45MHz Roofing Filter for an RF AGC?

 

John, VK2ETA, came across an idea in the search for a greater range for his MAX9814 AGC circuit.

Stations, above S9+10 would produce distortion in the audio circuit with the MAX9814 AGC in circuit.   He isolated this to the MAX circuit as the distortion would disappear when it was bypassed.

John was curious as to what the first 45Mhz filter (Roofing Filter) shape was like and if there was some plateau to be used somewhere for attenuating the strong signals.

He modified Ashhar Farhan’s original software to include an “Adjust First IF” menu item, in steps of [1000Hz].

By using a local station’s carrier aligned on 1,500Hz audio as a reference and an Android audio spectrum display he plotted the response of the single crystal roofing filter. This also gave an idea of the effect on the audio of shifting the filter up and down. The “noise” in the graph below near the peak is the effect of changing from a measure every [10,000Hz] to a measure every [1000Hz], plus the inaccuracy of John’s rudimentary instrumentation.

As you can see, there are rather slow slopes on each side of the peak (which is off-center by [7,000Hz] approximately when compared to 1,500Hz – the centre frequency of an SSB signal).

So John has proceeded with changing Ian’s software (based on v1.04) to incorporate an automatic AGC step-down when the signal reaches S9+10 and and automatic step-up when it reached S0. In the middle range, the MAX audio circuit does the AGC job.

John used the up side of the filter as he got some birdies on some of the shifts on the down side.

Now the uBitx can handle S9++++ stations with ease, that is until the first amplifier stage before the filter saturates which John suspects is unlikely in “normal” conditions.

The only concern would be for another, possibly even stronger, station which would be placed at the peak of the filter (possibly several KHz away). This could produce intermod distortion. But the chances of that happening are pretty remote.

So, this approach works quite well and is surprisingly effective for AGC control at an early stage in the receiver.

It also works in reverse, with the transmit SSB signal being attenuated by the same amount, thereby leading to a possible ALC software control for the units which measure the power out (or possibly just the current).   It could also be a simple solution to set attenuation (e.g. on digital modes).  Again, check the effect of the slope on the voice tone.

John has attached snippets of his code.  He has also uploaded the modified uBitx software for testing the filter both in RX and TX in the  “Software based IF attenuation” folder in the BITX20 IO Group files.

John will soon publish the complete set of Ian’s modified software including mods to control his ATU unit.   However, in seeing discussions on an IF AGC in the group, he thought this update would be of interest to constructors.

Code Snippets

#define OPTION_SMETER
#define OPTION_SOFTWAREAGC

void doSoftwareAGC() {
#ifdef OPTION_SMETER

int newSMeter;

//VK2ETA S-Meter from MAX9814 TC pin
newSMeter = analogRead(ANALOG_SMETER);
//Serial.print(“newSMeter:”); Serial.println(newSMeter);

//Faster attack, Slower release
currentSMeter = (newSMeter > currentSMeter ? ((currentSMeter * 3 + newSMeter * 7) + 5) / 10 : ((currentSMeter * 7 + newSMeter * 3) + 5) / 10);

//Serial.print(“currentSMeter:”); Serial.println(currentSMeter);
//Scale it
scaledSMeter = 0;
for (byte s = 8; s >= 1; s–) {
if (currentSMeter > sMeterLevels[s]) {
scaledSMeter = s;
break;
}
}
//Serial.print(“scaledSMeter, un-adjusted:”); Serial.println(scaledSMeter);
#ifdef OPTION_SOFTWAREAGC
//Apply auto-shift of first IF to increase the dynamic range of the Audio AGC circuit
long previousShift = firstIfShift;
if (scaledSMeter >= 7) {
//Reduce gain by shifting the first and second If by the same value, thereby
// leaving the RX frequency the same but using the slope of the roofing
// filter to deliver progressive attenuation.
// 10kHz or 5kHz per step.
firstIfShift += (scaledSMeter > 7 ? 10000 : 5000);
} else if (firstIfShift > 0 && scaledSMeter < 1) {
//Re-increase the gain if we reduced it earlier
firstIfShift -= 5000;
firstIfShift = firstIfShift < 0 ? 0 : firstIfShift;
}
if (firstIfShift != previousShift) {
setFrequency(frequency);
//Serial.print(“firstIfShift:”); Serial.println(firstIfShift);
//Adjust meter by IF attenuation except for the first 10Khz. Approx 6dB per 5KHz.
scaledSMeter += (firstIfShift > 10000 ? (firstIfShift – 10000) / 5000 : 0);
//Serial.print(“scaledSMeter, adjusted:”); Serial.println(scaledSMeter);
}
#endif //OPTION_SOFTWAREAGC
#endif //OPTION_SMETER

}

//And the setfrequency function becomes:

void setFrequency(unsigned long f) {
f = (f / arTuneStep[tuneStepIndex – 1]) * arTuneStep[tuneStepIndex – 1];

setTXFilters(f);

if (cwMode == 0)
{
if (isUSB) {
//si5351bx_setfreq(2, SECOND_OSC_USB – usbCarrier + f + (isIFShift ? ifShiftValue : 0));
si5351bx_setfreq(2, SECOND_OSC_USB + firstIfShift – usbCarrier + f – ((isIFShift && !inTx) ? ifShiftValue : 0));
si5351bx_setfreq(1, SECOND_OSC_USB + firstIfShift);
}
else {
//si5351bx_setfreq(2, SECOND_OSC_LSB + usbCarrier + f + (isIFShift ? ifShiftValue : 0));
si5351bx_setfreq(2, SECOND_OSC_LSB + firstIfShift + usbCarrier + f + ((isIFShift && !inTx) ? ifShiftValue : 0));
si5351bx_setfreq(1, SECOND_OSC_LSB + firstIfShift);
}
//VK2ETA Bring back the BFO to default if using IF Shift and we are TXing
si5351bx_setfreq(0, usbCarrier + ((isIFShift && !inTx) ? ifShiftValue : 0));
}

else
{
if (cwMode == 1) { //CWL
//si5351bx_setfreq(2, SECOND_OSC_LSB + cwmCarrier + f + (isIFShift ? ifShiftValue : 0));
si5351bx_setfreq(2, SECOND_OSC_LSB + firstIfShift + cwmCarrier + f + ((isIFShift && !inTx) ? ifShiftValue : 0));
si5351bx_setfreq(1, SECOND_OSC_LSB + firstIfShift);
}
else { //CWU
//si5351bx_setfreq(2, SECOND_OSC_USB – cwmCarrier + f + (isIFShift ? ifShiftValue : 0));
si5351bx_setfreq(2, SECOND_OSC_USB + firstIfShift – cwmCarrier + f – ((isIFShift && !inTx) ? ifShiftValue : 0));
si5351bx_setfreq(1, SECOND_OSC_USB + firstIfShift);

}
//VK2ETA Bring back the BFO to default if using IF Shift and we are TXing
si5351bx_setfreq(0, cwmCarrier + ((isIFShift && !inTx) ? ifShiftValue : 0));

}

Reference

An ATU mod from VK2ETA

The news item http://ubitx.net/2018/03/11/ubitx-modders-are-hard-at-work/ has flushed out one or two further modders.

John, VK2ETA, writes:

“For my part I don’t know if it’s hard code developer or more mad hacker, but it is fun.   Here is a picture of the latest addition, an L-Network ATU built in the uBitx case, driven by two servos and controlled by an Arduino mini pro linked over I2C to the Raduino.

“It is now working well (80m to 10m) but needs cleaning up, shields (just to make sure) and a nice display of SWR and Power on the LCD.  More details to come.”

Ron, W7HD, was very interested in the servo control code and components and wiring as he would like to adapt this idea to handle a pair of servos for an az-el rotor for his satellite Arrow antenna, which only weighs about 1-2 pounds. Then he just needs to add a bit of code to show the actual antenna position and he’ll be all set!

Ron suggests another adaptation of this project would be to remotely tune a magnetic loop antenna. One of the problems you run into when trying to tune a loop is that your body affects the tuning.

Reference

 

Mic Compression and Noise gate with SSM2167 module

John, VK2ETA, has  used the small circuit board “SSM2167 Microphone Preamplifier Board Preamp COMP Compression Module DC 3V-5V”available on eBay or Aliexpress as a compression and mic pre-amplifier.

He simply connected the input to the mic, added a 4.7K ohm resistor between the mic input and the 5VDC (taken from the Raduino) for biasing the electret and put a 10K ohms potentiometer in the output to adjust the power level to the mic preamp stage.

He didn’t modify his uBitx board,  but simply inserted the board prior to the mic input.  The gain of 20dB is reduced back with the output potentiometer. John removed the “R1” resistor and replaced it with a 51K Ohms resistor to get a 4:1 compression factor, up from the 2:1 as delivered, but this change has yet to be tested “on air”.

John hasn’t received any negative feedback about the compressor except when I pushed the output potentiometer too high.

Reference

 

Simon VK3ELH used the same board and a similar scheme for powering the module from the regulated 5v line on the Raduino.  It is also installed separate to the main board and inline with the mic input.

Simon used a 75k ohm resistor for compression and 1k ohm resistor for the noise gate and a 100k pot on output. At full output, his audio was readable but distorted based on an audio check QSO, so the output has been turned down.

He put a larger heatsink on the IRF510 to cater for the higher average output, as the stock one was getting warm!

A side effect of the mic being on all the time is that there is leakage through to the speaker and it causes some feedback if the mic is within 2 inches or so of the speaker.

AGC Mod

Challenges with AGC circuits

Finding an AGC mod that works, and works well (with sufficient AGC range, that does not impact on the dynamic range of the receiver, and that does not distort) is proving to be difficult.  Nobody has probably tried out more AGC mods than John VK2ETA.

See his thread here for his experiences with a range of AGC mods.

MAX 9814 Circuit

John VK2ETA has now settled on using the MAX9814 circuit for his AGC.

He used the Adafruit MAX9814 board but there are a few variations on eBay with some probably requiring less hacking than the Adafruit design. John had to solder a wire on an SMD component to access the CT (time constant capacitor) pin of the MAX IC, and remove the Electret capsule.

Refer to the schematic and a few pictures of the AGC circuit. The 5VDC required for the Adafruit board is taken from the Raduino.

John took two sets of measures, one with the AGC turned down low and one with the AGC turned one third of the way up.

He used an A/B comparison with an FT-817, with the pre-amp off, receiving  a carrier at 1,500Hz from local radio stations (with attenuation). The FT-817 S-Meter seem non-constant in the steps between the S-units, but nevertheless, this was John’s reference for calibrating the AGC. The AGC voltage was taken on the CT pin of the MAX9814.

The AGC voltage fluctuates quite a lot, so he used the average value shown over time.

To determine whether any saturation was coming from the AGC circuit or the uBitx upstream at high signal strengths, he would bypass the AGC and keep the volume down to prevent the audio circuit after the volume pot from saturating. If harmonics of the audio disappeared, the AGC alone was producing distortion, otherwise it appeared at least prior to the AGC, and possibly from the AGC circuit as well.

Results

“Medium” AGC: input pot turned to about 30% of full scale.

FT817         AGC
S-Meter     voltage(mV)       Notes
S0                  0
S1               300
S2               350
S3               400
S4               460
S5               510
S6               650
S7               750
S8             1,700          Large variation. FT-817 S-meter S8 plateau issue?
S9            2,200          Some saturation of AGC noted (starts to appear in audio FFT, not noticeable)
S9+10     2,460           Saturation of AGC audible, but not unpleasant.
S9+20     2,460          Audible saturation of both uBitx and AGC (harsh sound).

The AGC kicks in early and keeps the volume pretty constant until saturation occurs. Saturation of AGC does limits the dynamic range of receiver.

“Low” AGC: input pot turned to about 7-10% of full scale.

FT817          AGC
S-Meter      voltage (mV)       Notes
S0 -S4               0
S5                50-200                  (100mv avg)
S6                  200
S7                  360
S8                  500
S9                1,260
S9+10         1,800
S9+20         2,300                 Saturation of both uBitx and AGC  (visible in audio FFT, but not really audible)
S9+30         2,400                 Audible saturation of uBitx and mostly of AGC.

This is the most “FT-817 AGC” like, from my perspective, and is what I have settled for.  I want to use the AGC voltage as an s-meter input and this setting does produce a gap at the bottom end, but this is not critical IMO.

In both cases I noted some small “clicks” when the AGC kicked in on strong sudden signals.

The maximum gain of the MAX9814 as set in the schematic attached is of 50dB and requires screened cables in the audio circuit. I originally had the input and output of the circuit fed to a two core “stereo” screened cable and I would get feedback. I had to use two single screened audio cables.

Reference

Experimenting with Mitsubishi RD16HHF1s

John VK2ETA has done a strait replacement of the IRF510s with RD16HHF1s in his uBITx.  You can see from the photo above that he has them installed cross-legged.   John says, “To replace the finals I simply cut the legs of the IRF510s about 3mm above the board and correspondingly cut and crossed over the drain and source pins of the RD16s to match, then soldered in place”.

What follows are the before and after values of output power and PA current that John measured.   All tests were done with the uBitx VR1 drive level in the same position of approx 60% of range.

1. IRF510s and main board at 12.1V. PA idle current checked at 0.20A total (factory setting) so assume 100mA in each final.

(For info, Rx currents: 164mA no volume, about 209mA “normal” volume).
– At 7.1Mhz: 10W, total current: 1.79A, of which PA current: 1.31A, therefore main board current 0.48A
– At 14.2Mhz: 5.5W, total current: 1.39A, of which PA current: 1.0A, therefore main board current 0.39A
– At 21.2Mhz: 2.2W, total current: 0.95A, of which PA current: 0.53A, therefore main board current 0.42A
– At 28.1Mhz: 1.3W, total current: 0.95A, of which PA current: 0.53A, therefore main board current 0.42A

2. IRF510s with 16.5V, 13.8V for main board. PA total idle current checked at 0.21A.
(For info, Rx currents: 188mA no volume, about 230mA “normal” volume).
– At 7.1Mhz: 19W, total current: 2.65A, of which PA current: 2.09A, therefore main board current 0.56A
– At 14.2Mhz: 11W, total current: 2.20A, of which PA current: 1.80A, therefore main board current 0.40A
– At 21.2Mhz: 5.5W, total current: 1.40A, of which PA current: 1.00A, therefore main board current 0.40A
– At 28.1Mhz: 2.2W, total current: 1.02A, of which PA current: 0.60A, therefore main board current 0.42A

John hasn’t managed to find a definitive reference for the safe and optimum values of the RD16HHF1s idle bias current but it seems to range from 200 to 500mA. He would not recommend long term usage of the 500mA bias used for these measurements and will reset his idle current to the 400-450mA range.

3. RD16HHF1s and main board at 12.1VDC, 250mA idle bias each (Total 0.5A PA idle current).
– At 7.1Mhz: 10W, PA current: 1.20A
– At 14.2Mhz: 9W, PA current: 1.21A
– At 21.2Mhz: 4.5W, PA current: 0.65A
– At 28.1Mhz: 5.5W, PA current: 0.95A

4. RD16HHF1s and main board at 12.1VDC, 500mA idle bias each (Total 1A PA idle current).
– At 7.1Mhz: 10W, PA current: 1.18A
– At 14.2Mhz: 9W, PA current: 1.26A
– At 21.2Mhz: 5W, PA current: 0.71A
– At 28.1Mhz: 6W, PA current: 1.11A

5. RD16HHF1s and main board at 13.8VDC, 500mA idle bias each (Total 1A PA idle current).
– At 7.1Mhz: 13.5W, PA current: 1.95A
– At 14.2Mhz: 13.5W, PA current: 1.93A
– At 21.2Mhz: 6W, PA current: 1.38A
– At 28.1Mhz: 9.5W, PA current: 1.79A

John made the following observations:

A. The RD16HHF1 produces a much flatter power curve over frequency (in his device), although it shows a dip somewhere near the 15m band.

B. The IRF510 can produce some nice power in the lower frequencies when increasing the PA supply voltage, but it comes at the price of a steep power drop at higher frequencies.

C. The bias does not seem to influence the efficiency of the finals at full power with RD16HHF1, since biasing at 250 and 500mA produces essentially the same output for the same DC power input. Assuming distortion reduces with higher bias, can we assume a higher bias (within limits) is preferable? Any risk of thermal runaway?

D. The board main current (which includes the current in the driving stages of the power amplifier) does not seem to change with frequency from 20m onwards. Is this because the gain is pretty constant? If so, most of the drop in power with increasing frequency seems to be in the IRF510s, supporting the results obtained with the RD16HHF1s.

E. With the current uBitx PA circuit the RD16HHF1 seems limited in output, but without the appropriate test instruments he can’t say where the limitation occurs.

F. When he increased the drive through VR1, he noticed that at around 40% for the lower frequencies and at around 60% for the top frequencies he gets a compression effect.   The output does not increase much more from increasing the drive level.   John left the drive gain at around 60% and got positive feedback on the voice quality on his first QSO on 40m.  He assumes that any compression/clipping is not significant at that level (but he hasn’t measured the sprectral purity).

So since his target was around 10W on 10m and 10 to 15W on 40m minimum, he is pleased to  have reached his goal just by changing out the finals to RD16HHF1s and supplying the board with 13.8VDC.   This is below the 15.2/15V stated in the respective datasheets of the RD16HHF1.

DK5LV experience with RD16HHF1s

Henning Weddig DK5LV thanked John for his intensive research on the PA stage and commented that in his experience, “the RD16HFF1 really needs a very high quiescent current of about 500 mA each, which is not good for a QRP design”.

He  goes on to say, “The output transformer plays an important role in the design. Normally a 1 to 4 impedance transformation (12.5 ohms to 50 ohms) is sufficient. Each transistor “sees” half of that impedance i.e. 6.25 ohm. The windings of the transformer must be capacitively compensated and the leakage inductance mimimised on the windings.”

“Another big issue is the choke for the supply voltage: the commonly used centre-tapped transformer without the choke is not recommended. Ashhar Farhan uses two isolated chokes, and in my experience a bifilar wound choke is the better choice.”

Reference

An annoying fault (solved)

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.

The problem

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.

Group responses

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.”

Reference