[Moon] Spid Ras

jewell at btinternet.com jewell at btinternet.com
Sun Jul 7 10:25:59 CEST 2019


Thanks Graham,Yes, mine sounds like one of those early ones.The odd thing is that that apart from a few dropped elevation counts, it has operated reliably for many, many years!I bought it from another local amateur who had managed to drop it from a great height onto a concrete path with no damage apart from a  slight dent in one of the covers. It is indeed built like a battleship!I am going to check for that broken cable, but I just don’t see how, with just two wires and direction detection by motor direction, how it can count clockwise and not anticlockwise. Changing the az/el connectors over transfers the fault onto the the elevation direction, so it certainly looks like a sensor fault, but how on earth......?
73 de Sam


Sent from Yahoo Mail for iPad


On Sunday, July 7, 2019, 9:19 am, graham.d <graham.d at orange.fr> wrote:


Sam,

Early spids have no direction information from the pulse generator.

The direction information comes from the user pushing the button

if the button is operating the rotator but the pulses are not counted in 
the correct sense , then that is indeed a strange fault as the detection 
of direction would normally be an internal firmware detector.

In the very beginning he was not turning off the counter at all and so 
the thing sat there counting pulses if the motor stopped where the reed 
was close to being operated, after much nagging I got him to make a 
firmware revision. The controller however remained very inadequate. The 
guy had never heard of capacitors, in the entire early boxes there were 
none, not one, an EMI nightmare, a DC pulse all over everything 
nightmare,  and a lost count every hour/day/week meant recalibrating the 
entire system on a weekly or even daily basis if a lot of tracking was 
going on.

There are now several solutions offered as better controllers , so 
honestly the best advice is to bin the controller and build one of them.

You can start on the F1TE site, where Lucien outlines solutions for 
everything, including proper electrical endstops a controller and even 
how to mount the new sensor, he shows mechanical as well as 
electrical/electronic solutions

Graham

G8MBI


On 07/07/2019 09:59, jewell--- via Moon wrote:
> Zack,Many thanks for taking time to explain the operation of the Spid.I strongly suspect that my Spid pre-dates yours. My Spid Ras is at least ten years old. It uses reeds rather than Hall effect sensors. No LS series logic in the controller. Apart from the single main controller chip I don’t see any other ‘electronics’ on the main board and I don’t think that the optocouplers would be associated with the  LED display board behind the main panel.The optocouplers don’t appear to be used in mine, with the sensor inputs direct to the controller chip!I need to do a bit more investigating of the board. Maybe the optocouplers are under the PCB, but I don’t see anything that I recognise as an optocoupler. I wonder if early Spid Ras didn’t use them?The label on the controller chip says ROT2 version 1.00, as Infecall.All very puzzling.
> I will indeed keep the group informed of my progress with sorting the fault, or replacing the Spid!
> 73 de Sam
>
>
>
> Sent from Yahoo Mail for iPad
>
>
> On Sunday, July 7, 2019, 6:17 am, Zach Leffke via Moon <moon at moonbounce.info> wrote:
>
> First off, let me offer my very sincere condolences........this is a
> VERY frustrating situation, and I can sympathize with your situation.
>
> I apologize in advance for the super long email, but when I started
> dealing with this issue (and the others), there wasn't much out there
> about it on various forums/listservs, so hopefully my experiences will
> help reduce your troubleshooting time and anyone that might find this
> thread in the future!
>
> I have had many problems like this at the Virginia Tech Ground Station
> (running 4 Big-RAS/HRs and 1 RAS/HR at work, and another RAS/HR at home
> all w/ MD-01 controllers), compounded by things like EMI corrupting the
> feedback (I've seen the az and el increment when the motors aren't even
> energized), random incrementing/decrementing on controller power up,
> multiple 'dropped counts' screwing up the pointing calibration over
> time, and my absolute 'favorite'...what I call the 'runaway feedback'
> situation where the motors aren't moving but the readout for one or both
> motors is sitting there ticking away at a rapid rate (like 100s-1000s of
> degrees per second), quickly outside of the software limits, making it
> impossible to move the motors to kick it out of this state without doing
> a 'nintendo cheat code' with the control buttons to quickly 0 the
> feedback long enough to move the motor by a degree or two which somehow
> stops the 'runaway' problem.
>
> Ok to your specific issue.....(thanks for letting me vent :-) )
>
> First realize that you are dealing with quadrature encoders.  So the
> feedback for one direction of motion (say azimuth as in your case) is a
> pair of square pulses that are 90 degrees out of phase.  lets call these
> signal A and signal B.  Lets call signal A the reference signal.  Every
> time there is a rising edge on signal A, an interrupt fires in the
> microcontroller.  When the interrupt occurs, the controller checks the
> hi/lo state of signal B.  If B is Hi, then it thinks its rotating
> counter clockwise and decrements the angle, if it is Low, it thinks it
> is rotating clockwise and increments the angle (I might have the
> directions reversed there, but the logic for reading the quadrature
> feedback is valid).  The count of rising edges is converted by the
> gearing ratio of your system (different between the RAS and the Big-RAS)
> to number of degrees to increment or decrement.
>
> For your specific problem, I'm willing to bet that if you put an
> oscilloscope on the two quadrature signals for the azimuth feedback, you
> will see little 'notches' in the center of the square pulses (by center
> I mean exactly between the rising and falling edge of each pulse).  So
> in my example above lets say you are rotating clockwise....signal A
> rises, interrupt fires, checks signal B, sees a low signal, increments
> the angle count.  Now lets say it is rotating counter
> clockwise....signal A rises, interrupt fires, checks signal B.....and
> NOW we encounter the problem....what SHOULD be a high signal and thus a
> decrement of the angle is instead this weird notch thing.  The notch is
> low enough that microcontroller instead interprets it as a LOW instead
> of a HIGH and it then increments the count instead of decrementing the
> count.  Net result.....whether you turn left or right the angle always
> counts up!!!!
>
> I have yet to actually figure out the fundamental cause of this
> problem......so I can't offer a 100% cure.......but I have found a way
> to treat the symptoms.  I suspect it has something to do with the tiny
> magnet in the 'top hat' looking piece that mates to the shaft of the
> motor.  This little top hat spins with the shaft, and the 'hockey puck'
> bolted on top has the actual hall effect sensor that sense the rotation
> of the magnet and produces the quadrature pulses (theres a tiny gap
> between the hall effect sensor and the top of the 'top hat').  My
> current guess is that the magnet might be 'broken' and is really 'two'
> magnets producing a weird field effect between the tophat and the hall
> effect sensor......so it sees polarity reversals when it
> shouldn't.......kind of a weak theory, and I could be wrong about how
> the magnets are oriented, and one I can't test yet because I have yet to
> find replacement 'top hats' with magnets in them.......just kind of
> shows that I'm clutching at straws for an actual 'cure.'
>
>
> Back to your problem and the 'band aid' that seems to work for
> me..........bypass caps on each quadrature line to ground.
>
> I say 'bypass caps' because originally when experimenting with this I
> was doing it to suppress noise on the lines from EMI (in some cases as
> high as 2 or 3 volts peak of ripple).  place a cap between each
> quadrature line and ground.  You'll have to experiment with different
> values for the caps to make sure your RC curves are still mostly
> 'squarish', but the goal is to keep the center of the pulse high enough
> through the 'notch window' so that it is properly detected as a HIGH.
> Most recently 0.22uF caps worked for me (also on an azimuth problem).
> Of my 4 Spid Big-RAS/HRs, I've had to use bypass caps on 3 of them...and
> the values are not always the same between the three of them and between
> az and el for a given unit (probably has something to do with the
> capacitance of the feedback cables themselves and the different length
> runs).  Experiment with different values with an oscope on the lines to
> make sure it looks basically square (maybe with 'rounded edges') but is
> high enough to hold the pulse high through the 'notch window'.  I would
> recommend doing this close to the MD-01 (or MD-02) just before the
> feedback enters the box, but there are handy screw terminals on the
> rotator side that sometimes works as well.  Once you've figured out the
> required value, you might even be able to fit the caps inside the
> backshell of the DB-9 connector for the feedback connection to the MD-01.
>
>
> Final thought/bit of info:
>
> Because of the long runs between our controllers and the rotators
> (80-150 ft), I use differential encoders to help suppress EMI.
> Basically, I convert each quadrature signal into a pair of differential
> signals right at the rotator (just enough 'quadrature cable' for the
> rotator loop, with the encoder mounted on the pipe just under the
> rotator).  I then use outside rated, shielded cat5E cable to send the
> signals back to the shack to a decoder mounted in the rack with the
> MD-01.  The decoders convert the differential signals back into
> quadrature signals that I then inject into the MD-01s with a short
> (maybe 2 ft or so) DB-9 cable.  For each encoder I have to run a
> separate cable from the 12V supply pins on the MD-01 (same DB-9
> connector as the feedback) out to the tower to power both the encoder
> circuit and up to the rotator for the hall effect/quadrature circuit.
>
> I'm pretty sure this 'notch' problem is something IN the rotator
> (whether electrical, or as I currently suspect, mechanical) because of
> this differential encoder circuit.  Again, I've had to troubleshoot
> multiple 'layers' of problems simultaneously, so I might be 'mixing
> symptoms' so to speak, but with the differential circuit I have
> effectively removed the EMI part of the problem from the troubleshooting
> steps.  This results in a very clean notch on the output of the
> differential decoder!  So I believe the source of the notch effect is on
> the rotator side of the path, BEFORE I encode the quadrature signals
> into differential signals. I placed my bypass caps on the encoder
> circuit itself because it was a bit cleaner, but like I mentioned, there
> are screw terminals inside the white box on the rotator that offer
> convenient spots to install the caps....just be careful not to short the
> caps together at all, some of the leads will need to be fairly long to
> reach from the feedback signal terminal to the ground terminal.
>
>
> I hope this helps!  Good Luck!  I'd be happy to hear the results of your
> troubleshooting and what ends up working for you!
>
> 73s,
>
> Zach, KJ4QLP
>





More information about the Moon mailing list