Many people use HF transceivers in situations where they back the power down significantly from full output. Examples are driving an amplifier that may require 20 or 30 watts for full output, or using a transverter that might want just a few milliwatts.
The method many modern HF transmitters use to reduce power is to adjust the ALC (automatic level control) circuit. This circuit is a feedback loop that adjusts the transmitter to maintain a desired maximum output power. The detected power at the output drives the automatic gain setting. This circuit doesn’t respond instantly; there’s a time constant of a few milliseconds. As a result, some rigs overshoot when their output power is reduced — there is a full-power spike at the beginning of a transmission before the ALC kicks in to back down the power.
This spike can damage amplifiers and transverters. The question was whether the Icom IC-7300 exhibited this behavior. I did a set of simple tests to find out.
I connected the output of the IC-7300 to a power attenuator with 40 dB of loss. The attenuator output went to the vertical input of a digital oscilloscope. I set the scope to “peak detect” mode, set the trigger level and trigger time appropriately, pushed the “SINGLE” sweep button, and then keyed the transmitter either via the built-in CW keyer, or with a whistle to the microphone. This let me capture the very beginning of the RF output.
I didn’t see any sign of overshoot at any of the power settings I tried. The ‘7300 seems to use something other than ALC for its power control, which given its SDR architecture makes sense; it’s really easy to control levels in the digital domain.
Here’s a screen capture of a CW “dit” at 30 WPM with a power setting of 100%:
Here’s the power set to 10%. The only change in the waveform is that the leading edge rises a bit more slowly:
I zoomed in to the leading edge of the dit at 10% power to see if there was any really, really short overshoot. Nothing seen (note that the V/div is different here):
After doing all this work, I wondered if the CW path might be different than the one used for voice, so here are two shots showing a whistle into the microphone. The first is 100% power, and the second is 10%; the same scale settings were used for both:
So, based on this I don’t think the IC-7300 poses any concerns for use at low power settings to drive amplifiers or transverters.
UPDATE: I’m planning to look at some other rigs as well. Here are 10% and 100% images of the ANAN 7000DLE:
There’s no sign of overshoot with this rig, either.
14 comments
My experience from real life tells different. I have a tube amp with G3SEK protection board and with wsjt-x 2.0.1 amp sometimes goes into protection mode. It never did that with ft-897, but started immediately after switching to ic-7300. It is bit annoying when running msk at 6M, every 10th transmission is at rig’s power and waiting for flashover.
Dear “One Thought”,
A measurement is very much “real life”, but only accounts for the measurement setup, i.e. no ALC.
Do you use ALC from your amp back to the 7300? Does the problem occur if you remove the ALC cable and reduce drive to be certain you cannot overdrive?
The IC-7300 does indeed suffer a power overshoot in SSB mode.
With the Compressor ON and the recommended level of ALC, there is 2dB power overshoot for less than 5mS.
This was repeatable in two tests each using different methods.
In theory, you need to de-rate an external linear amplifier to 63% of its peak rated power.
Using the same methods, my TS-590s, which has Kenwood ALC modification, its measured overshoot is just 1dB.
So is it is or is it ain’t? I have an ALS1300 awaiting the 220 to my radio room. Does setting timing up to 25ms work to remedy this problem between 7300 and the amp and are solid state amps different in this situation and tube types more susceptible?
Cleve
So, what is the curative takaway on the hotkey/overshoot problem with the 7300 so that amps don’t eventually turn into toasters?
Is this problem seen as much with Solid state auto tune amps as with tubes?
I have a new ALS-1300 I am anxious to.put online with my 7300.
Is the reset on the xmit Tim ng to 25ms now a fix myth as well?
I have an older 7300 which I update the software when I bought it used. I’ve tried running it into an Elecraft KPA500 amp which has a straight line of different colored LEDs for power output. The LEDs are green up to 500w then goto yellow for overdrive and finally red when amp is way over powered. I would consistently get a red flash when I keyed and sometimes on voice peaks. I could also see the spike on a peak and hold power meter. So maybe the later 7300s don’t have the problem but certainly the earlier ones do. I run that radio with my 811 amp and the tubes can handle it.
Ive since then switched back to my old 746 Pro to run with that amp and no problems.
Upon reading this there is overshoot and there is not overshoot…which is it?
There is definitely overshoot with the 7300. The 7300 is useless with my solid state amp..
I have measured a large (13dB) overshoot on 4m. A YouTube video about it is here: https://youtu.be/7ZHfjuET0Kk
I can confirm the massive overshoot on 70MHz.
Much worse than the other bands.
Those who cannot see any overshoots need to open their eyes and look again !
I have been using for two years an IC7300 that I purchased new driving a Mercury III solid state amp using a single LDMOS. Never seen any spike or overshot of my amp in any band. I do not use ALC at all, I just drive the amp with just the needed input power to see a KW PEP when talking on SSB.
My IMD3 is always not Less than -30 db and according others report my BW is just 2.8 Khz.
Hector,
Can you explain more what you mean by saying you don’t use ALC at all. Is there a way to turn ALC off on the 7300?
Thanks.
Using an ic7300 – an early one – since I bought it in combination with an Acom600S solid state amp and 90% of the time in ft8/ft4 mode. I have never experienced any problems even with very intensive use during contests…. Never detected any overshoot!.
It seems to me that a firmware update could solve the overshoot issue. I don’t even think it would be a difficult fix from a software perspective if and only if Icom is aware of this issue. Has anyone you know of submitted an official trouble ticket to Icom USA?
KA5UTN