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@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@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@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