| We looked into this problem further today. First, a primer on the
Async driver. It is a Digital designed octal async line driver known
as the 5170. It uses TTL level inputs and +/- 10V for power. Herein lies
the problem. The TTL inputs come from gates that are supplied by +5V.
The 5170 outputs are derived from the +/- 10V. Glitching can occur
when the +5V supply either rises slower or decays faster than the +10V
supply. Glitchs happen when the TTL inputs drop below 0.8V and there is
still plenty of 10V supply available.
On the DECserver 700/900's there is a special circuit that cuts off the
+10V as soon as the +5V drops below 4.6V on power down. Glitchs cannot
happen because when the TTL input reachs 0.8V, the +10V is long gone.
Now, for the DS90M results. We tested both a late model unit and a
early production unit. Results were the same. Tests were conducted
with the AC power brick, in a DEChub 90, and in a DEChub 900. A VT220
was attached to the async port and a digital storage scope recording TxD,
+5V and the +10V supply to the driver.
If power is removed at the AC source no glitching occurs. When I say
AC power this means that with the Brick the power cable is attached
to the unit and AC power is removed from the brick. In both hubs we
pulled the AC Power cord. Additionally, in the DEChub 900 we shut off
power on the power supply by turning the retention handle. All these
cases would represent a normal power removal or outage.
We did find a condition where glitching can occur. If the user pulls
the power cable from the back of the unit when using a brick, of if
they remove the unit from a powered hub, glitchs do occur for the
reason I explained above. You should find out from the customer what
the circumstances are around power removal.
Loren
|
| Al,
The tests were conducted with a VT220 attached. We know from
experience, and with the scope attached, that it does not bias incoming
signals. It is still possible that the customer equipment is
aggravating the problem and that if they remove DECserver power at the
AC source, they could still see a break condition.
Think of it this way, you're in a tug of war with a large person and
that you're opponent is much stronger than you (opponent = the DS90 TxD
signal). As long as he is healthy, you go were he wants you to go.
Now, suppose he has a heart attack (AC power removed). If he was very
much larger than you chances are you would not be able to pull him very
far. This is how it should be on a normal async interface. However,
if you approach the size of your oppenent, chances are you might be
able to pull him across to your side. This is what we saw on some
VAX's. They had bias resistors on their RxD inputs and when power was
removed from the DECserver the RxD line drifted positive and it was
interpreted as a Break. Since the DECserver had power removed, there
was nothing it could do to prevent it. The DECserver did not create
the Break but removing power allowed it to happen.
Something similar could be happening in your case and the only way to
tell for sure is to put a storage scope on the TxD line and watch what
happens. If the customer equipment is creating the problem, changing
to a DEChub will not fix it. Will be be blamed, probably. Can we
fix it, not in the DECserver.
Loren
|