[amsat-bb] Optical shaft encoders

[Zach Leffke]

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, 
performance.....?

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 
housing.

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 
the signal.

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.

-Zach, KJ4QLP

Research Associate
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:
> http://blog.radioartisan.com/yaesu-rotator-computer-serial-interface/
>
> 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.
>>
>> 73s
>> Bob
>> N4HY
>> _______________________________________________
>> 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
>>
> _______________________________________________
> 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