Towertalk
[Top] [All Lists]

Re: [TowerTalk] STEPPIR QUESTION

To: Dick Green WC1M <wc1m73@gmail.com>
Subject: Re: [TowerTalk] STEPPIR QUESTION
From: jimlux <jimlux@earthlink.net>
Date: Wed, 15 Jul 2009 19:40:15 -0700
List-post: <towertalk@contesting.com">mailto:towertalk@contesting.com>
Dick Green WC1M wrote:
> When my lightning disaster occurred, I was using K5FD suppressor boards,
> which have two MOVs per line plus a 5A inline fuse. Each wire in the control
> cable was connected to a suppressor board at both ends of the cable run,
> tower and shack, for a total of four MOVs per wire. The ground system at
> tower and shack is extensive and well-bonded, with large conductors, and
> it's bonded to all other grounds such as AC, telco, etc.
> 
> Every 5A fuse blew, indicating that considerable current flowed through each
> wire to/from the controller. None of the MOVs was shorted, but it wasn't
> possible to tell if they were destroyed in an open condition. As mentioned
> earlier, the MOVs were 82V units, which are standard in K5FD and Polyphaser
> suppressors.
> 
> In trying to prevent a repeat of this incident, I had K5FD replace the MOVs
> with 45V units, which is the value recommended to me by K7IR. The problem
> with selecting a value for the MOVs is that there's a voltage spike above
> the nominal 33V operating level for the driver chips (assuming one is using
> SteppIR's 33V power supply.) Further complicating selection is that MOVs
> have about a 10% tolerance, so they won't necessarily clamp at exactly the
> rated voltage. I've forgotten the research I did on this, but I think the
> tolerance is only on the high side. In other words, a 45V MOV won't clamp
> below that level, but may not clamp until the voltage is near 50V. My
> recollection is that the driver chips have very little headroom for
> overvoltage. At any rate, the exact voltage characteristics may vary from
> one installation to another (or possibly from one wire to another!)


This is probably a situation where zener diode clamps would be better 
than MOVs.  MOVs are cheap (why they use them in $4 plug strips), but in 
an application with something driving an inductor (e.g. a stepper motor 
winding) where you get short spikes, the little spikes gradually kill 
the MOV, which starts to have more leakage current, etc.

The other problem noted is that the driver chip isn't particularly 
robust to overvoltage on the output pins (i.e. it's designed to drive a 
load, not sink energy).

Interesting... I assume SteppIR isn't doing microstepping, so this is a 
full step kind of application.  In this kind of application, where the 
step rate is fairly low and the wires are long, an old style step driver 
with higher voltage and series R (essentially an analog constant current 
source) might be a better design.  Not as compact or convenient as the 
PWM sources popular these days, and it typically requires a fairly high 
voltage (which might raise regulatory hackles.. nice to stay under 50V) 
to get a decent step rate.

It would dissipate more DC power AND it would be more expensive.. but it 
would be pretty tough.



> 
> The problem you suggest, that an MOV shorted by a lightning strike would
> result in the chip being destroyed the next time it operates is
> theoretically possible, but my sense is that MOVs don't fail in the shorted
> condition very often. In other words, I think the odds of that particular
> failure scenario are somewhat low. But certainly not zero.

MOVs fail by gradually having more leakage current, so they get hot and 
melt or start a fire. In a catastrophic overcurrent, they'll fail open, 
just like a fuse.  They're really not appropriate for a lot of the 
applications where people use them.
> 
> As for protecting the rest of the controller, my experience was that the
> primary damage was to the driver chips and RS-232 interface. I tried
> replacing just the driver chips on one of the boards, but it didn't work. So
> it's likely the surge destroyed more components than just the driver chips.
> It may not be possible to protect other components unless the power supplies
> are isolated. The RS-232 interface is mounted on the driver board, and
> probably shares that board's power supply. I think it might be possible to
> protect the RS-232 interface by obtaining its power from the CPU board and
> isolating it as much as possible from the driver board, but that would
> probably take a fair amount of redesign to the boards.

But you'll still have to reference the TTL side of the RS232 driver (a 
MAX232 type part, I'd imagine, as opposed to the 1489/1488) to the power 
supply of the controller.  And the rs232 chips really aren't designed 
for significant isolation.  They DO tolerate transients fairly well. 
What you'd really want is an optoisolated serial port, so there's no 
galvanic connection between Computer and Controller.  Then use an 
isolated power supply for the controller and float the chassis of the 
controller with the shield/ground reference of the wires going to the 
antenna.  Probably still have problems though..

Designing robust, inexpensive equipment that can tolerate multihundred 
foot runs outdoors is nontrivial.  Typically, ham gear is usually 
designed for inexpensively getting what functions you need, because most 
hams won't pay for robust, particularly for a situation which is 
unlikely and for which insurance is available.


> option. Even if optoisolators are used for the CAT5e cable at both ends, I
> would think the optoisolaters would be destroyed in a surge (hopefully,
> they're socketed.) 

The usual problem is a line to ground transient, not a line-line 
transient (the signals going to the motor/data interface, etc. are 
balanced pairs).  The opto will survive 5000V pin to case or one side to 
the other without a problem.   Mind you, if you have one of those lame 
RS232 opto isolator blocks that shares the pin 7 return for all the lines...

There's a reason that old teletypes used 20 and 60 mA current loop.
_______________________________________________



_______________________________________________
TowerTalk mailing list
TowerTalk@contesting.com
http://lists.contesting.com/mailman/listinfo/towertalk

<Prev in Thread] Current Thread [Next in Thread>