Rick,
A friend recently asked for my opinion on the 2000A, and since he owns an
Orion I thought I should alert him about the Arc Fault problem and dug up
your e-mail on the subject from last month.
I have to admit that I only scanned this when you first sent it out and did
not think it through carefully. After re-reading your description of the
problem and "solution", and pondering it for a while, I came to the
conclusion that when ACOM diagnosed the problem SM7YEA must have been
running Orion firmware version 1.369 or earlier. Prior to 1.370, there were
at least two timing bugs in the keying loop logic. The description below
matches exactly what I saw on my scope in 1.369: the Orion would raise TXOUT
at key-up, yet it would continue to transmit the "smooth" trailing edge of
the RF envelope.
The result depends on the amp's keying loop logic. In the case of my Alpha
87A, it would simply switch off high power from the tubes and go into bypass
mode. The 87A can get away with this because it uses PIN diode T/R
switching. There's no vacuum relay to protect from hot switching. On the
scope, you could see the RF envelope plunge from the high power RF envelope
peak to the smooth low power trailing edge. The instantaneous cutoff of RF
from the tubes essentially resulted in a square wave trailing edge, which
caused horrendous key clicks on the air (I received several bitter
complaints about this in a couple of major contests.)
If you think about it, there was another problem: near as I can tell, the
87A keying loop logic is pretty simple -- it just connects TXOUT to TXENA.
So, when the Orion raises TXOUT, TXENA should go high as well and the Orion
should cut off RF. But that's not what was happening -- the Orion continued
to transmit RF even though TXENA was no longer grounded.
The fact that the Orion continued to transmit the trailing edge of the RF
envelope did not affect the 87A because its PIN diodes T/R switch
instantaneously and can do so in the presence of RF without damage. That's
probably why the 87A keying loop logic is simpler than the 2000A.
The result is very different with the 2000A. The description below suggests
that the T/R relay is kept closed and the tubes continue to transmit at high
power even after TXOUT goes high. If that's true, then there's no sharp drop
in RF power, no square training edge, and no key clicks. The 2000A logic is
correct -- it has to keep the relay closed and continue transmitting in
order to prevent hot switching the vacuum relay. Although the 2000A was
correctly designed to prevent damage to the relay and tubes, the hardware
was not designed to deal with the Orion's T/R sequencing in 1.369 and
earlier. The condition of TXOUT high and the trailing edge of the RF
envelope continuing results in pulses in the sensor circuit which in turn
result in misleading Arc Faults.
However, and this is the point of my post, the Orion keying loop bug was
fixed in firmware version 1.370. The Orion now waits until the end of the RF
envelope before raising TXOUT. I have verified this on my scope. There was a
debate about fixing the TXENA part of the problem. Some felt that TXENA
should only prevent initiation of transmit, and that during a transmission
it should not cut off RF but should cut off TXOUT instead. The assumption
was that most QSK amps had logic to deal with this situation. The Acom 2000A
certainly does. I disagreed, since I have two amps that don't deal with it
like the 2000A: the 87A and an old LK-550C. My feeling was, and is, that if
TXENA is low, RF transmission should be allowed; if TXENA is high, RF
transmission should not be allowed. I think the amp should be able to say,
"Hey, don't send me any RF until my relay switches", and expect that to
happen. Sure, the amp should have protection logic in case it doesn't, but
that's beside the point. I'm pretty sure Ten-Tec agreed with me and vaguely
recall verifying with my scope that Orion version 1.370 works this way.
There was another problem after this one was fixed. When the keying loop was
off, TXOUT would continue to function, but TXENA did not. Effectively, TXOUT
became identical to the AMP Key outputs. I thought this was a problem
because a user could connect the keying loop but accidentally leave it off
in the menus. This would cause some amps to hot switch. I don't recall
whether this problem was fixed or not.
Implementing the hardware mod on the Acom will cause no harm and probably
improves the amp. But my opinion is that it is unnecessary with Orion
firmware version 1.370 or later. There are two bits of supporting evidence
for this: 1) a number of Orion/2000A users have not done the mod and do not
have Arc Fault problems (in at least one case, I know the user is running
the latest Orion firmware), and 2) some users have continued to experience
Arc Faults even after implementing the Acom hardware mod. I don't know
whether the latest Orion firmware is being used in these cases. I would
strongly urge the affected users to upgrade to at least 1.370. If they have
done so, and Arc Faults continue, then there is something else going on
here. Sounds like it may be specific to certain Orion/Acom combinations. If
there are continued problem reports, then I'll take the trouble to rewire my
station to have the Orion drive my 2000A and will check the timing out on my
scope.
I should mention that I discontinued use of the keying loop between my Orion
and 87A, and now use AMP Key 1 to drive the amp. This works fine, and is the
method recommended by Alpha -- the PIN diodes do not require TXENA logic to
work correctly.
I can't swear to it, but I think I read somewhere that the Omni VI/2000A
combination generates Arc Faults, too. It's certainly possible that the Omni
VI has the same flawed keying loop logic as the Orion did in 1.369 or
earlier. It's also possible that whatever is causing the continued Arc
Faults on modified 2000As with Orion 1.370 and later is also causing the
problem with the Omni IV/2000A.
73, Dick WC1M
> -----Original Message-----
> From: Dick Green WC1M [mailto:wc1m@msn.com]
> Sent: Saturday, December 04, 2004 11:57 AM
> To: 'Rick@DJ0IP.de'
> Subject: RE: [TenTec] RE: [Orion] Firmware upgrade and
> CW/ACOM2000A issue again
>
>
> Rick,
>
> I would appreciate your e-mailing me details on the mod. I
> have broadband, so 600K is not a problem.
>
> Thanks & 73,
> Dick WC1M
>
> > -----Original Message-----
> > From: NJ0IP [mailto:Rick@DJ0IP.de]
> > Sent: Saturday, December 04, 2004 10:00 AM
> > To: tentec@contesting.com
> > Subject: RE: [TenTec] RE: [Orion] Firmware upgrade and
> > CW/ACOM2000A issue again
> >
> >
> > There is a mod suggesteb by ACOM for both the 1000 and 2000A which
> > will cures this ARC FAULT problem. I can send details, but it
> > includes 3 pictures so the file is pretty large (about 600 kB).
> > This is NOT an Orion firmware issue - it's a fundamental problem
> > which may occur even with other types of transceivers.
> >
> > Here is what's going on:
> >
> > " This modification was introduced about one year ago as a result of
> > co-operation with Piotr SM7YEA. He was experiencing the Arc Fault
> > problem when trying to connect a TenTec OmniVI+ to his ACOM1000.
> > Thanks to his careful research we resolved the problem. The
> > schematic of ACOM1000 and ACOM2000A are similar in that part so we
> > introduced the meant resistor and removed the capacitor in both
> > models.
> >
> > The problem is caused by some different systems of TenTec and ACOM
> > keying. The TXOUT_TXEN concept of TenTec is that the TXOUT controls
> > the RF transmission by TXEN. When you tie TXEN to the ground, the
> > transceiver transmits. However, when the TXOUT finishes, the
> > transceiver continues transmitting a "rounded" trailing edge for
> > still 1 or 2 milliseconds to have a good CW symbol.
> >
> > At the same time, the ACOM amplifiers would expect that the RF drive
> > should disappear before the KEY-IN transmit request disappeared.
> > Once the transmit-request signal (TXOUT in this
> > case) has finished (KEY-IN is no more grounded), no more RF
> > drive is expected until a new transmit request. As a
> > self-guarding function, the amplifier will wait for the RF
> > drive to fully disappear, by continuously monitoring RF drive
> > presence via a comparator (U9 in ACOM2000A) monitoring the RF
> > drive at the tubes grids. The problem was caused by the
> > "rounded" trailing edge which was causing this comparator to
> > generate several pulses while the falling edge of the RF
> > slowly crosses the comparison level.
> >
> > The meant resistor introduces a hysteresis and removing the
> > capacitor eliminates the meant pulses. The modified amplifier works
> > normally with both TXOUT_TXEN loop connection as well as the
> > single-cable one. "
> >
> > (Source: ACOM in Bulgaria)
> >
> > 73
> > Rick
> >
> >
> > -----Original Message-----
> > From: tentec-bounces@contesting.com
> > [mailto:tentec-bounces@contesting.com]
> > On Behalf Of Barry N1EU
> > Sent: Saturday, December 04, 2004 4:54 AM
> > To: tentec@contesting.com; Orion@contesting.com
> > Subject: [TenTec] RE: [Orion] Firmware upgrade and
> > CW/ACOM2000A issue again
> >
> > "Sergei Kulyov" <ua3ap@smtp.ru> wrote:
> >
> > >Does anybody got an issue while in CW keying ACOM2000 after
> > upgrade to
> > >1.372? My ACOM immediatly fails to transmitt with "ARC fault" alarm
> > >althouth I'm using it in QSK mode.
> >
> > Sergei, my Orion seems to key my Acom 2000A perfectly with v1.372.
> > Sorry to hear of your troubles.
> >
> > 73,
> > Barry N1EU
> >
> > __________________________________________________________________
> > Switch to Netscape Internet Service.
> > As low as $9.95 a month -- Sign up today at
> > http://isp.netscape.com/register
> >
> > Netscape. Just the Net You Need.
> >
> > New! Netscape Toolbar for Internet Explorer
> > Search from anywhere on the Web and block those annoying pop-ups.
> > Download now at http://channels.netscape.com/ns/search/install.jsp
> > _______________________________________________
> > TenTec mailing list
> > TenTec@contesting.com
> > http://lists.contesting.com/mailman/listinfo/tentec
> >
> >
> >
> >
>
_______________________________________________
TenTec mailing list
TenTec@contesting.com
http://lists.contesting.com/mailman/listinfo/tentec
|