Tag: VK2ETA

Posted on

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
Posted on

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
Posted on

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