[Moon] Spid Ras

[W2DRZ-TOM]

THIS SITE  HAS PRINTS ON ENCODER

http://www.w2drz.ramcoinc.com/


http://www.w2drz.ramcoinc.com/encoders.htm

http://www.w2drz.ramcoinc.com/download.htm


----- Original Message ----- 
From: "graham.d via Moon" <moon at moonbounce.info>
To: <jewell at btinternet.com>; "Zach Leffke" <zleffke at vt.edu>; 
<moon at moonbounce.info>
Sent: Sunday, July 07, 2019 4:11 AM
Subject: Re: [Moon] Spid Ras


>
> 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
>>
> _______________________________________________
> Moon mailing list
> Moon at moonbounce.info
> /mailman/listinfo/moon
>
> Join eQSL.cc  https://eqsl.cc/qslcard/Index.cfm