[amsat-bb] Optical shaft encoders
zleffke at vt.edu
Thu Mar 17 16:08:56 UTC 2016
This will be "Too Long - Did not read". Sorry. But for those with Alfa
Radio HR model rotators, maybe you have same/similar issues?
So first off, Bob is basically asking if anyone has built a custom
optical shaft encoder to replace the magnetic hall effect sensors in the
High Resolution Big-Ras rotators. Machining, circuit design,
But to answer your question about the exact problem:
Pinning down the 'exact problem' has been the trick since installing
these rotators. I now believe it has been a series of problems that
presented a mish-mash of symptoms. Every time one problem is resolved
it removes some of the symptoms to reveal others. I will attempt to
describe the symptoms and the *fixes* so far.
The specific sensors IC used in the Alfa Radio High Resolution kits are
the AM4096 chips from RLS. The output of this is a pair of signals in
phase quadrature. The lead or lag of one signal relative to the other
gives the direction of rotation, while the pulse count (together with
gearing ratios) gives the angle. Best I can figure the AM4096 output is
sine wave with only about two volts peak to peak, but the output of the
HR sensor assembly is square pulses with 0V at low and 12V at peak,
still in quadrature, so there must be additional circuitry in the sensor
The first major symptom was noise Noise NOISE on the feedback lines.
When first installed, I could turn on the control box and the feedback
would start counting away as if the rotator was moving without even
touching the U/D/L/R buttons. One day the issue would be on azimuth,
next day it would be on elevation, sometimes both, sometimes not at all
(very elusive and hard to re-create the conditions to troubleshoot). I
have about 85 feet of cable from the MD-01 control box to the rotator,
basically a massive antenna. The noise voltage was 1 or 2 volts peak to
peak when measuring the lines with an o-scope.
The guidance for best performance is to have a three conductor cable
(two wires plus shield) for each sensor: azimuth feedback plus shield
on one cable, elevation feedback plus shield on the next, power/ground
plus shield on the third. The shields of the cables are connected
together at the connector on the rotator (8 pin MIC connector) and at
the connector on the MD-01 control box. The shield is also jumpered to
a good station ground at the control box.
The major fix to the noise issue was bypass capacitors. I installed
these inside the sensor interface box on the rotator between each
feedback signal line and ground as well as on the terminal block
interface on the control box. This massively helped suppress the noise
(less than 100mV pk-pk) on the feedback lines.
So at this point no more random 'angle incrementing' when the motors
weren't even turning.
This just revealed the next issue. The 12V high square pulses going
into the control box had a major notch right in the center of the pulse
going almost down to 0 volts. Since the signals are in quadrature, this
notch lined up almost perfectly with the rising edge of the other
signal. The result of this was when I push the "up" button the
elevation readout starts counting DOWN. Push the 'left' button (which
should decrement the angle) and the feedback counts up. Basically,
whatever direction a motor turns, the feedback goes in the OPPOSITE
direction. My guess here is that the quadrature 'reader' in the control
box sees a rising edge on one signal and then checks the other signal,
if its high, the motors are turning one way, if its low they are turning
the other. Since this Notch is present (lined up with the rising edge
of the 'trigger' signal) what it should detect as a high it falsely
detects as a low and thinks the motor is turning the 'other' direction.
The fix for this was more capacitors on the control lines. Lots of
experimentation with cap values was required to find one with a time
constant such that it held the feedback signal high across the notch
period but decayed fast enough to not overly distort the falling edge of
Which leads to the current state of the system. It works reliably maybe
90% of the time. occasionally though I'm experiencing what I call the
'runaway feedback' problem. Every now and then the motor is in some
perfect position that causes the feedback to start counting away again.
This happens randomly on both the elevation and azimuth motors (one or
the other, never both at once so far). This is similar to the first
symptom I described but is different (took me a while to realize the
symptoms were slightly different). In the case where noise was the
issue, the incrementing (or decrementing) of the feedback was random and
sporadic. In the current situation it keeps counting away at a fairly
constant rate (though the rate does vary from incident to incident). I
can turn the box off and back on and it picks right up and keeps
counting. The only fix for this is a "nintendo cheat code" button press
maneuver I have to do where I place the MD-01 in calibration mode, zero
the feedback, and then press a motion button to "bump" the motor to turn
a bit all in less than a second. I have to zero the feedback first
because the reported position in the controller is usually far outside
the software position limits programmed into the box and the motor won't
turn when I press the button. As soon as the motor moves a small
amount, the feedback stops counting away. I then have to go through a
manual calibration process to re-align the antennas to a known az el (0
and 0) and then reset the positions in the controller.
99.9% of our operation is remote or automated. So I have custom
software that is responsible for interfacing with the MD-01 control box
via ethernet. I detect this runaway feedback problem via angular
speeds. I *KNOW* that the antennas can't actually move faster than say
2.75 degrees per second. I query the box 4 times a second for feedback
and then compute angular speed based off of the current pointing angle
and the previous pointing angle (and the approximate quarter second
interval between each reading). When the rate exceeds the threshold of
2.75 degree/sec threshold, the custom sw issues a STOP command to the
box, and then shuts down the control thread to stop sending SET
commands. I'd have to comb back through the logs, but the reported
angular rates are anywhere from maybe 10 deg/s to hundreds of deg/sec
(not physically possible).
Since the physical position of the motor shaft seems to matter with this
problem, I'm leaning away from an EMI/RFI issue and more towards some
kind of mechanical problem. I've experienced this problem with multiple
control boxes and multiple rotators (swapping rotators was fun with an
already built H-Frame and a pair of UHF antennas and pair of VHF
antennas to get out of the way!). I've tried three separate sensor
cables, with similar/same results. The big difference seems to be
"loaded vs unloaded." I have a second rotator/control box installed for
the next antenna system (this one has about 110 ft of sensor cable at
the new antenna location) and have not experienced the problem at all.
The rotator is on the tower, but no antenna is installed yet. So it
seems that there is a mechanical difference here that has something to
do with it. Bob's theory that I'm currently working with is that some
kind of mechanical resonance is occurring in the VHF/UHF H-Frame stack
causing something to mechanically "glitch out" the hall effect sensor.
I'm experimenting with counterweight balancing to try to manipulate the
resonant frequency of the stack to avoid hitting that perfect alignment
that jams up the sensor.
So that's about it in a 'nutshell.' I've tried one or two other things
that I've left out of the description because they seem to have minimal
effect on the problem. Very elusive problem, which makes
troubleshooting very difficult since I can't manually re-create the
conditions that cause the problem.
Any thoughts, comments, similar experiences, would be very useful and
appreciated. Sorry If I maxed out your inbox's storage space.
Ted & Karyn Hume Center for National Security & Technology
Virginia Polytechnic Institute & State University
Work Phone: 540-231-4174
Cell Phone: 540-808-6305
On 3/16/2016 6:53 PM, Daniel Cussen wrote:
> You could use an interface like this one:
> to read the optical/hall effect encoders. One of the main problems
> with this setup is that there is no absolute position sent, so any
> pulses missed result in increasing and increasing errors. Also if
> there is no end stop switches you can end up moving too far damaging
> coax cables.
> Normally it is recommended to use separate screened cables for the
> sensors to try prevent noise pickup.
> Can you link to the sensors you are using and what exact problems are occurring?
> On 16/03/2016, Robert McGwier <rwmcgwier at gmail.com> wrote:
>> I would like to consider adding optical shaft encoders to augment or
>> replace the hall effect sensors in use on an Alfa Spid az/el installation.
>> We have the high resolution sensors and are experiencing some annoying
>> anomalies that have been very difficult to trace and are detrimental to
>> autonomous operation at our ground station at Virginia Tech.
>> Any information or help would be appreciated.
>> Sent via AMSAT-BB at amsat.org. AMSAT-NA makes this open forum available
>> to all interested persons worldwide without requiring membership. Opinions
>> are solely those of the author, and do not reflect the official views of
>> Not an AMSAT-NA member? Join now to support the amateur satellite program!
>> Subscription settings: http://www.amsat.org/mailman/listinfo/amsat-bb
> Sent via AMSAT-BB at amsat.org. AMSAT-NA makes this open forum available
> to all interested persons worldwide without requiring membership. Opinions expressed
> are solely those of the author, and do not reflect the official views of AMSAT-NA.
> Not an AMSAT-NA member? Join now to support the amateur satellite program!
> Subscription settings: http://www.amsat.org/mailman/listinfo/amsat-bb
More information about the AMSAT-BB