Optical shaft encoders
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
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
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
for those with Alfa Radio HR model rotators, maybe you have same/similar issues?
I do not have a HR model, but I do have a similar system and we are seeing similar problems.
First off there is no end stop safety switches. This means if the control box becomes confused it can damage coax cables and move elevation to positions to damage antennas etc.
Second, there is no absolute position sent, meaning if it gets confused it cannot reset itself as only the amount of movement is sent, not the actual current position. Over time this means errors accumulate and grow.
The basic Yaesu G5500 has both safety protections meaning it is unlikely a confused control box will result in damaged antennas or coax.
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.....?
I do not know, however I have nearly added safety switches to a similar model to turn off the motor to protect the coax cables. This is also very important if the relays stick in the control box.
Others have removed or replaced position sensors with more accurate absolute positions sensors. In particular the HH-12 is used by a lot of large EME stations as it is both accurate, cheap and absolute position. If you connect it using a rubber hose it will protect itself from damage if you try turn it too much.
http://www.vk5dj.com/hh-12.html Mounting it to the Big-Raz is unknown, but here is a similar project: http://e-kutz.eu/seite10.html Here is a complete controller with two sensors: http://f1frv.free.fr/main3o_AZ_EL_Display.html
The noise voltage was 1 or 2 volts peak to peak when measuring the lines with an o->scope.
This is not good.
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.
To reduce noise the recommendation it to only connect the shield AT ONE END, and not both ends. Normally only at the shack end. I think this prevents ground loops.
So that's about it in a 'nutshell.'
So in my case we have a similar sensor. All the HAMTV ground stations in Europe (6) are using Prosistel Az/El with uses hall magnetic sensors with thousands of pulses per second. We too are seeing positions change with the motor stop, so much so thousands of pulses must be read while stopped.
The solutions we have used so far: 1) Multiple screened cables as you suggest grounded at one end 2) Adding filters to the motor wiring to reduce motor noise/cross talk 3) I experimented with stepping up rotation feedback from 0/5V to 0/20V 4) I am working on a replacement control box, where we can modify the code 5) I am adding safety switches to protect the coax.
The real solution would be for the manufacturer to use absolute position feedback. There is complete controllers available, if you can manage to connect their sensors to your existing system using belts/gears/cogs etc.
Another option I think you should consider is using your own control box. We found that the Prosistel supplied control box was flawed in some ways. The open source control box is already designed to take pulse inputs, and seems to work with thousands of pulses per second. You can even just hook the inputs in parallel to see if the problem is the control box or the sensor outputs. All you need is an arduino (mega preferably) and the correct version of the code. It will display a second opinion of the position, so you can determine if the control box has issues too. We found our control box misses some pulses, we think it is busy updating the LCD or talking to the computer and misses pulses.
Other features of this is a master/slave option, meaning the controller can be mounted at the antenna, meaning only short cable runs to the position sensor.
http://blog.radioartisan.com/yaesu-rotator-computer-serial-interface/
In the long term absolute position sensors combined with safety switches are the only real solution. For HF even a bog standard potentiometer would probably work better. Some suppliers use 3 or 10 turn potentiometers to allow 360 degrees or 1.5 turns rotation.
Since my Alfa Spid RAS-HR after Christmas was installed, it requires calibration to 0 azimuth and 0 elevations weekly. In a given week, elevation and azimuth both tend to drift 10-15 degrees. It varies based on the number of tracked satellites in the given period.
Not only is this issue annoying to a manned station, it makes remote operation of my station especially annoying.
Finally, as others have mentioned, there is a potentially dangerous situation that has occurred more than once. While I have feed line and rotor loops for approximately 720 degrees of rotation, it is not a parameter I would like to utilize. I would prefer to stay somewhere in the range of 540 degrees to be safe and not stretch any cabling. On more than one occasion, the MD-01 controller decided it lost its mind and was continuing to turn far past the command that had been sent to it. Fortunately on these occasions, I was watching the rotor interface closely and was able to manually send a stop command. Thanks to Zach Leffke, I will now refer to this Alfa Spid RAS-HR & MD-01 feature as undocumented "runaway feedback" mode.
I'm using shielded #18 wire running approximately 50' from the rotor sensor output to the controller. There are 6 conductors in the same bundle which I'm breaking out for the 2 rotors (az & el.) Had there been better documentation (any,) I might have used two separate, shielded 3 conductor cables.
As others have stated, the Alfa Spid RAS-HR (or it's big brother) have been very reliable minus this strange anomaly.
One course of action in my shack recently has been to bypass SatPC32's spid.exe and utilize PstRotator. It has some added benefit to allow me to use greater than 450 degrees of azimuth rotation. It also allows me to set fixed limits on az and el rotation capabilities of the Alfa Spid. However, it will not prevent the runaway feedback.
73 Clayton W5PFG
On 3/16/2016 13:10, Robert McGwier 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
I don't own a Alfa Spid, or any other rotator at the moment. I started building a custom rotator and writing my own controller, using quadrature encoders, pots, and 9DOF sensors to determine position. While researching my options, I discovered that rotary encoders don't like long lengths of wire. They work best with short runs of low capacitance wire. I2C is even more picky. I had all kinds of issues when I was using cheap patch cables for the i2c interface on the 9DOF board. I decided early on to locate the controller in the rotator and keep the wire runs short, with final control via ethernet.
I can't imagine that 50' wire runs are noise free. Is there any way to locate the controller closer to the rotators? Perhaps interface to the controller via ethernet? Ethernet can handle long runs quite well. I'm surprised that so much of the ham equipment still requires serial ports.
Steve KD8QWT
On Sat, Mar 19, 2016 at 6:11 PM, Clayton W5PFG w5pfg@amsat.org wrote:
Since my Alfa Spid RAS-HR after Christmas was installed, it requires calibration to 0 azimuth and 0 elevations weekly. In a given week, elevation and azimuth both tend to drift 10-15 degrees. It varies based on the number of tracked satellites in the given period.
Not only is this issue annoying to a manned station, it makes remote operation of my station especially annoying.
Finally, as others have mentioned, there is a potentially dangerous situation that has occurred more than once. While I have feed line and rotor loops for approximately 720 degrees of rotation, it is not a parameter I would like to utilize. I would prefer to stay somewhere in the range of 540 degrees to be safe and not stretch any cabling. On more than one occasion, the MD-01 controller decided it lost its mind and was continuing to turn far past the command that had been sent to it. Fortunately on these occasions, I was watching the rotor interface closely and was able to manually send a stop command. Thanks to Zach Leffke, I will now refer to this Alfa Spid RAS-HR & MD-01 feature as undocumented "runaway feedback" mode.
I'm using shielded #18 wire running approximately 50' from the rotor sensor output to the controller. There are 6 conductors in the same bundle which I'm breaking out for the 2 rotors (az & el.) Had there been better documentation (any,) I might have used two separate, shielded 3 conductor cables.
As others have stated, the Alfa Spid RAS-HR (or it's big brother) have been very reliable minus this strange anomaly.
One course of action in my shack recently has been to bypass SatPC32's spid.exe and utilize PstRotator. It has some added benefit to allow me to use greater than 450 degrees of azimuth rotation. It also allows me to set fixed limits on az and el rotation capabilities of the Alfa Spid. However, it will not prevent the runaway feedback.
73 Clayton W5PFG
On 3/16/2016 13:10, Robert McGwier 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
This is an awesome conversation and we are extremely grateful.
Zach is trying to build a robust repeatable super ground station.
Bob On Mar 18, 2016 6:30 AM, "Daniel Cussen" zg3410@gmail.com wrote:
for those with Alfa Radio HR model rotators, maybe you have same/similar
issues?
I do not have a HR model, but I do have a similar system and we are seeing similar problems.
First off there is no end stop safety switches. This means if the control box becomes confused it can damage coax cables and move elevation to positions to damage antennas etc.
Second, there is no absolute position sent, meaning if it gets confused it cannot reset itself as only the amount of movement is sent, not the actual current position. Over time this means errors accumulate and grow.
The basic Yaesu G5500 has both safety protections meaning it is unlikely a confused control box will result in damaged antennas or coax.
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.....?
I do not know, however I have nearly added safety switches to a similar model to turn off the motor to protect the coax cables. This is also very important if the relays stick in the control box.
Others have removed or replaced position sensors with more accurate absolute positions sensors. In particular the HH-12 is used by a lot of large EME stations as it is both accurate, cheap and absolute position. If you connect it using a rubber hose it will protect itself from damage if you try turn it too much.
http://www.vk5dj.com/hh-12.html Mounting it to the Big-Raz is unknown, but here is a similar project: http://e-kutz.eu/seite10.html Here is a complete controller with two sensors: http://f1frv.free.fr/main3o_AZ_EL_Display.html
The noise voltage was 1 or 2 volts peak to peak when measuring the lines
with an o->scope.
This is not good.
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.
To reduce noise the recommendation it to only connect the shield AT ONE END, and not both ends. Normally only at the shack end. I think this prevents ground loops.
So that's about it in a 'nutshell.'
So in my case we have a similar sensor. All the HAMTV ground stations in Europe (6) are using Prosistel Az/El with uses hall magnetic sensors with thousands of pulses per second. We too are seeing positions change with the motor stop, so much so thousands of pulses must be read while stopped.
The solutions we have used so far:
- Multiple screened cables as you suggest grounded at one end
- Adding filters to the motor wiring to reduce motor noise/cross talk
- I experimented with stepping up rotation feedback from 0/5V to 0/20V
- I am working on a replacement control box, where we can modify the code
- I am adding safety switches to protect the coax.
The real solution would be for the manufacturer to use absolute position feedback. There is complete controllers available, if you can manage to connect their sensors to your existing system using belts/gears/cogs etc.
Another option I think you should consider is using your own control box. We found that the Prosistel supplied control box was flawed in some ways. The open source control box is already designed to take pulse inputs, and seems to work with thousands of pulses per second. You can even just hook the inputs in parallel to see if the problem is the control box or the sensor outputs. All you need is an arduino (mega preferably) and the correct version of the code. It will display a second opinion of the position, so you can determine if the control box has issues too. We found our control box misses some pulses, we think it is busy updating the LCD or talking to the computer and misses pulses.
Other features of this is a master/slave option, meaning the controller can be mounted at the antenna, meaning only short cable runs to the position sensor.
http://blog.radioartisan.com/yaesu-rotator-computer-serial-interface/
In the long term absolute position sensors combined with safety switches are the only real solution. For HF even a bog standard potentiometer would probably work better. Some suppliers use 3 or 10 turn potentiometers to allow 360 degrees or 1.5 turns rotation. _______________________________________________ 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
Bob et. al.:
Would something like this: https://www.adafruit.com/products/2472
...be useful for the purpose of determining absolute position without relying on mechanical linkages of gears, belts, pulses, potentiometers, etc.? It uses 3-axis magnetometers, 3-axis gyros, and 3-axis accelerometers, and a Cortex M0 ARM to do all the hard computations that combine the three types of data into a viable position indication. It is inexpensive enough that I will probably install one when I finally get around to raising a tower at my new QTH, and using it only for readouts at first. I have been using and will resume using Yaesu rotators when the tower goes up, so no urgent need to add safety limit switches etc. In many years of operation at my prior QTH, the rotator never got "confused" about its position except when somebody put tension on the cable plugged into the back of the control box and loosened some of the connections between plug and socket. I do realize that even the G1000SDX model I was/will be using is not hefty enough for some applications, but again it served me well for many years in spite of temperature swings from -40F to +105F. (Yeah, it turned a bit slower at the begining of a contest when the temp was -40F and the wind chill was -60F. OK, wind chill doesn't apply to inanimate objects, but -40F actual is pretty darned cold. Plus the ice and snow added on didn't help.) :-)
73 de W0JT/5 EN34js -> EL09vu
On Tue, Mar 22, 2016 at 8:53 PM, Robert McGwier rwmcgwier@gmail.com wrote:
This is an awesome conversation and we are extremely grateful.
Zach is trying to build a robust repeatable super ground station.
Bob On Mar 18, 2016 6:30 AM, "Daniel Cussen" zg3410@gmail.com wrote:
for those with Alfa Radio HR model rotators, maybe you have same/similar
issues?
I do not have a HR model, but I do have a similar system and we are seeing similar problems.
First off there is no end stop safety switches. This means if the control box becomes confused it can damage coax cables and move elevation to positions to damage antennas etc.
Second, there is no absolute position sent, meaning if it gets confused it cannot reset itself as only the amount of movement is sent, not the actual current position. Over time this means errors accumulate and grow.
The basic Yaesu G5500 has both safety protections meaning it is unlikely a confused control box will result in damaged antennas or coax.
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.....?
I do not know, however I have nearly added safety switches to a similar model to turn off the motor to protect the coax cables. This is also very important if the relays stick in the control box.
Others have removed or replaced position sensors with more accurate absolute positions sensors. In particular the HH-12 is used by a lot of large EME stations as it is both accurate, cheap and absolute position. If you connect it using a rubber hose it will protect itself from damage if you try turn it too much.
http://www.vk5dj.com/hh-12.html Mounting it to the Big-Raz is unknown, but here is a similar project: http://e-kutz.eu/seite10.html Here is a complete controller with two sensors: http://f1frv.free.fr/main3o_AZ_EL_Display.html
The noise voltage was 1 or 2 volts peak to peak when measuring the lines
with an o->scope.
This is not good.
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.
To reduce noise the recommendation it to only connect the shield AT ONE END, and not both ends. Normally only at the shack end. I think this prevents ground loops.
So that's about it in a 'nutshell.'
So in my case we have a similar sensor. All the HAMTV ground stations in Europe (6) are using Prosistel Az/El with uses hall magnetic sensors with thousands of pulses per second. We too are seeing positions change with the motor stop, so much so thousands of pulses must be read while stopped.
The solutions we have used so far:
- Multiple screened cables as you suggest grounded at one end
- Adding filters to the motor wiring to reduce motor noise/cross talk
- I experimented with stepping up rotation feedback from 0/5V to 0/20V
- I am working on a replacement control box, where we can modify the
code
- I am adding safety switches to protect the coax.
The real solution would be for the manufacturer to use absolute position feedback. There is complete controllers available, if you can manage to connect their sensors to your existing system using belts/gears/cogs etc.
Another option I think you should consider is using your own control box. We found that the Prosistel supplied control box was flawed in some ways. The open source control box is already designed to take pulse inputs, and seems to work with thousands of pulses per second. You can even just hook the inputs in parallel to see if the problem is the control box or the sensor outputs. All you need is an arduino (mega preferably) and the correct version of the code. It will display a second opinion of the position, so you can determine if the control box has issues too. We found our control box misses some pulses, we think it is busy updating the LCD or talking to the computer and misses pulses.
Other features of this is a master/slave option, meaning the controller can be mounted at the antenna, meaning only short cable runs to the position sensor.
http://blog.radioartisan.com/yaesu-rotator-computer-serial-interface/
In the long term absolute position sensors combined with safety switches are the only real solution. For HF even a bog standard potentiometer would probably work better. Some suppliers use 3 or 10 turn potentiometers to allow 360 degrees or 1.5 turns rotation. _______________________________________________ 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
John, I'm testing this board with my custom rotators and controller. The board has been working quite well, with consistent reading for both az and el. The az readings are even accurate when the el is at 90 degrees.
That said, I won't be using it as a primary position sensor. Optical encoders with sufficient resolution are still superior. I haven't tested this board in the presence of RF, so I'm not sure what it will do on transmit. The board also can't tell you if the rotators are pointing at 360 degrees or 0. A POT, or something similar, is still needed to determine that. The i2c bus needs to be as short as possible, so whatever is reading it needs to be mounted on the rotators. Positioning the controller with the rotators will also improve the reliability of the optical encoders. This board works well for calibrating the rotator to magnetic north and zeroing the el, as well as validating the az & el positions reported by the optical encoders. How well the validation will work on transmit is yet to be determined.
If all you want to do is read the position outside the controller circuit, then I would think it would work quite well connected to an Arduino mounted on the rotator. An ethernet shield would allow for a simple web page that could display the rotator's position. Reading the values off the board is quick and doesn't require very much resources. Calibration is the main issue with these types of sensors. It's much easier to deal with on this board. The on-board micro helps a great deal. The calibration data is lost when the board powers up. Until it is calibrated, the values are useless. Once calibrated, previous saved calibration values can be passed to the board when it powers up. The initial calibration does call for specific movements outside the range possible by just mounting it to the rotator and moving it around. The initial calibration would need to be done close to the actual mounted position on the rotator. Once the rotator and sensor are in their final positions and the rotator az and el moved around a bit, the on-board micro will update it's calibration values from the initial calibration. These final calibration values would be the values to save and re-apply on power up. Since the on-board micro continues to update the calibration, it might be a good idea to update the saved values periodically.
Steve KD8QWT
On Wed, Mar 23, 2016 at 5:58 PM, John Toscano tosca005@umn.edu wrote:
Bob et. al.:
Would something like this: https://www.adafruit.com/products/2472
...be useful for the purpose of determining absolute position without relying on mechanical linkages of gears, belts, pulses, potentiometers, etc.? It uses 3-axis magnetometers, 3-axis gyros, and 3-axis accelerometers, and a Cortex M0 ARM to do all the hard computations that combine the three types of data into a viable position indication. It is inexpensive enough that I will probably install one when I finally get around to raising a tower at my new QTH, and using it only for readouts at first. I have been using and will resume using Yaesu rotators when the tower goes up, so no urgent need to add safety limit switches etc. In many years of operation at my prior QTH, the rotator never got "confused" about its position except when somebody put tension on the cable plugged into the back of the control box and loosened some of the connections between plug and socket. I do realize that even the G1000SDX model I was/will be using is not hefty enough for some applications, but again it served me well for many years in spite of temperature swings from -40F to +105F. (Yeah, it turned a bit slower at the begining of a contest when the temp was -40F and the wind chill was -60F. OK, wind chill doesn't apply to inanimate objects, but -40F actual is pretty darned cold. Plus the ice and snow added on didn't help.) :-)
73 de W0JT/5 EN34js -> EL09vu
On Tue, Mar 22, 2016 at 8:53 PM, Robert McGwier rwmcgwier@gmail.com wrote:
This is an awesome conversation and we are extremely grateful.
Zach is trying to build a robust repeatable super ground station.
Bob On Mar 18, 2016 6:30 AM, "Daniel Cussen" zg3410@gmail.com wrote:
for those with Alfa Radio HR model rotators, maybe you have
same/similar
issues?
I do not have a HR model, but I do have a similar system and we are seeing similar problems.
First off there is no end stop safety switches. This means if the control box becomes confused it can damage coax cables and move elevation to positions to damage antennas etc.
Second, there is no absolute position sent, meaning if it gets confused it cannot reset itself as only the amount of movement is sent, not the actual current position. Over time this means errors accumulate and grow.
The basic Yaesu G5500 has both safety protections meaning it is unlikely a confused control box will result in damaged antennas or coax.
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.....?
I do not know, however I have nearly added safety switches to a similar model to turn off the motor to protect the coax cables. This is also very important if the relays stick in the control box.
Others have removed or replaced position sensors with more accurate absolute positions sensors. In particular the HH-12 is used by a lot of large EME stations as it is both accurate, cheap and absolute position. If you connect it using a rubber hose it will protect itself from damage if you try turn it too much.
http://www.vk5dj.com/hh-12.html Mounting it to the Big-Raz is unknown, but here is a similar project: http://e-kutz.eu/seite10.html Here is a complete controller with two sensors: http://f1frv.free.fr/main3o_AZ_EL_Display.html
The noise voltage was 1 or 2 volts peak to peak when measuring the
lines
with an o->scope.
This is not good.
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.
To reduce noise the recommendation it to only connect the shield AT ONE END, and not both ends. Normally only at the shack end. I think this prevents ground loops.
So that's about it in a 'nutshell.'
So in my case we have a similar sensor. All the HAMTV ground stations in Europe (6) are using Prosistel Az/El with uses hall magnetic sensors with thousands of pulses per second. We too are seeing positions change with the motor stop, so much so thousands of pulses must be read while stopped.
The solutions we have used so far:
- Multiple screened cables as you suggest grounded at one end
- Adding filters to the motor wiring to reduce motor noise/cross talk
- I experimented with stepping up rotation feedback from 0/5V to 0/20V
- I am working on a replacement control box, where we can modify the
code
- I am adding safety switches to protect the coax.
The real solution would be for the manufacturer to use absolute position feedback. There is complete controllers available, if you can manage to connect their sensors to your existing system using belts/gears/cogs etc.
Another option I think you should consider is using your own control box. We found that the Prosistel supplied control box was flawed in some ways. The open source control box is already designed to take pulse inputs, and seems to work with thousands of pulses per second. You can even just hook the inputs in parallel to see if the problem is the control box or the sensor outputs. All you need is an arduino (mega preferably) and the correct version of the code. It will display a second opinion of the position, so you can determine if the control box has issues too. We found our control box misses some pulses, we think it is busy updating the LCD or talking to the computer and misses pulses.
Other features of this is a master/slave option, meaning the controller can be mounted at the antenna, meaning only short cable runs to the position sensor.
http://blog.radioartisan.com/yaesu-rotator-computer-serial-interface/
In the long term absolute position sensors combined with safety switches are the only real solution. For HF even a bog standard potentiometer would probably work better. Some suppliers use 3 or 10 turn potentiometers to allow 360 degrees or 1.5 turns rotation. _______________________________________________ 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
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
participants (7)
-
Clayton W5PFG -
Daniel Cussen -
Daniel Cussen -
John Toscano -
Robert McGwier -
Steven Kalmar -
Zach Leffke