Email Detail

HTTP 200 OK
Allow: GET, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept

{
    "url": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/email/6JVL4RG4RYGFHRNYYSLAAD4B5CGNZHYY/?format=api",
    "mailinglist": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/?format=api",
    "message_id": "[email protected]",
    "message_id_hash": "6JVL4RG4RYGFHRNYYSLAAD4B5CGNZHYY",
    "thread": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/thread/FT24W6QAMDCPV6T5PW7WAO2AR7GOPLDR/?format=api",
    "sender": {
        "address": "zleffke (a) vt.edu",
        "mailman_id": "57a24afb1cf641f98121841e6753c12e",
        "emails": "https://mailman.amsat.org/hyperkitty/api/sender/57a24afb1cf641f98121841e6753c12e/emails/?format=api"
    },
    "sender_name": "Zach Leffke",
    "subject": "Re: [amsat-bb] Optical shaft encoders",
    "date": "2016-03-17T16:08:56Z",
    "parent": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/email/CNKACM6EWDHHXMKZUSOITVVSMPM44GA2/?format=api",
    "children": [
        "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/email/6P3CPRABVPM6MFZO5B3EXPUK6V2KJZJV/?format=api"
    ],
    "votes": {
        "likes": 0,
        "dislikes": 0,
        "status": "neutral"
    },
    "content": "This will be \"Too Long - Did not read\".  Sorry.  But for those with Alfa \nRadio HR model rotators, maybe you have same/similar issues?\n\nSo first off, Bob is basically asking if anyone has built a custom \noptical shaft encoder to replace the magnetic hall effect sensors in the \nHigh Resolution Big-Ras rotators.  Machining, circuit design, \nperformance.....?\n\nBut to answer your question about the exact problem:\n\nPinning down the 'exact problem' has been the trick since installing \nthese rotators.  I now believe it has been a series of problems that \npresented a mish-mash of symptoms.  Every time one problem is resolved \nit removes some of the symptoms to reveal others.  I will attempt to \ndescribe the symptoms and the *fixes* so far.\n\nThe specific sensors IC used in the Alfa Radio High Resolution kits are \nthe AM4096 chips from RLS.  The output of this is a pair of signals in \nphase quadrature.  The lead or lag of one signal relative to the other \ngives the direction of rotation, while the pulse count (together with \ngearing ratios) gives the angle.  Best I can figure the AM4096 output is \nsine wave with only about two volts peak to peak, but the output of the \nHR sensor assembly is square pulses with 0V at low and 12V at peak, \nstill in quadrature, so there must be additional circuitry in the sensor \nhousing.\n\nThe first major symptom was noise Noise NOISE on the feedback lines.  \nWhen first installed, I could turn on the control box and the feedback \nwould start counting away as if the rotator was moving without even \ntouching the U/D/L/R buttons.  One day the issue would be on azimuth, \nnext day it would be on elevation, sometimes both, sometimes not at all \n(very elusive and hard to re-create the conditions to troubleshoot).  I \nhave about 85 feet of cable from the MD-01 control box to the rotator, \nbasically a massive antenna.  The noise voltage was 1 or 2 volts peak to \npeak when measuring the lines with an o-scope.\n\nThe guidance for best performance is to have a three conductor cable \n(two wires plus shield) for each sensor:  azimuth feedback plus shield \non one cable, elevation feedback plus shield on the next, power/ground \nplus shield on the third.  The shields of the cables are connected \ntogether at the connector on the rotator (8 pin MIC connector) and at \nthe connector on the MD-01 control box.  The shield is also jumpered to \na good station ground at the control box.\n\nThe major fix to the noise issue was bypass capacitors.  I installed \nthese inside the sensor interface box on the rotator between each \nfeedback signal line and ground as well as on the terminal block \ninterface on the control box.  This massively helped suppress the noise \n(less than 100mV pk-pk) on the feedback lines.\n\nSo at this point no more random 'angle incrementing' when the motors \nweren't even turning.\n\nThis just revealed the next issue.  The 12V high square pulses going \ninto the control box had a major notch right in the center of the pulse \ngoing almost down to 0 volts.  Since the signals are in quadrature, this \nnotch lined up almost perfectly with the rising edge of the other \nsignal.  The result of this was when I push the \"up\" button the \nelevation readout starts counting DOWN.  Push the 'left' button (which \nshould decrement the angle) and the feedback counts up. Basically, \nwhatever direction a motor turns, the feedback goes in the OPPOSITE \ndirection.  My guess here is that the quadrature 'reader' in the control \nbox sees a rising edge on one signal and then checks the other signal, \nif its high, the motors are turning one way, if its low they are turning \nthe other.  Since this Notch is present (lined up with the rising edge \nof the 'trigger' signal) what it should detect as a high it falsely \ndetects as a low and thinks the motor is turning the 'other' direction.  \nThe fix for this was more capacitors on the control lines.  Lots of \nexperimentation with cap values was required to find one with a time \nconstant such that it held the feedback signal high across the notch \nperiod but decayed fast enough to not overly distort the falling edge of \nthe signal.\n\nWhich leads to the current state of the system.  It works reliably maybe \n90% of the time.  occasionally though I'm experiencing what I call the \n'runaway feedback' problem.  Every now and then the motor is in some \nperfect position that causes the feedback to start counting away again.  \nThis happens randomly on both the elevation and azimuth motors (one or \nthe other, never both at once so far). This is similar to the first \nsymptom I described but is different (took me a while to realize the \nsymptoms were slightly different). In the case where noise was the \nissue, the incrementing (or decrementing) of the feedback was random and \nsporadic.  In the current situation it keeps counting away at a fairly \nconstant rate (though the rate does vary from incident to incident).  I \ncan turn the box off and back on and it picks right up and keeps \ncounting. The only fix for this is a \"nintendo cheat code\" button press \nmaneuver I have to do where I place the MD-01 in calibration mode, zero \nthe feedback, and then press a motion button to \"bump\" the motor to turn \na bit all in less than a second.  I have to zero the feedback first \nbecause the reported position in the controller is usually far outside \nthe software position limits programmed into the box and the motor won't \nturn when I press the button.  As soon as the motor moves a small \namount, the feedback stops counting away.  I then have to go through a \nmanual calibration process to re-align the antennas to a known az el (0 \nand 0) and then reset the positions in the controller.\n\n99.9% of our operation is remote or automated.  So I have custom \nsoftware that is responsible for interfacing with the MD-01 control box \nvia ethernet.  I detect this runaway feedback problem via angular \nspeeds.  I *KNOW* that the antennas can't actually move faster than say \n2.75 degrees per second.  I query the box 4 times a second for feedback \nand then compute angular speed based off of the current pointing angle \nand the previous pointing angle (and the approximate quarter second \ninterval between each reading).  When the rate exceeds the threshold of \n2.75 degree/sec threshold, the custom sw issues a STOP command to the \nbox, and then shuts down the control thread to stop sending SET \ncommands.  I'd have to comb back through the logs, but the reported \nangular rates are anywhere from maybe 10 deg/s to hundreds of deg/sec \n(not physically possible).\n\nSince the physical position of the motor shaft seems to matter with this \nproblem, I'm leaning away from an EMI/RFI issue and more towards some \nkind of mechanical problem.  I've experienced this problem with multiple \ncontrol boxes and multiple rotators (swapping rotators was fun with an \nalready built H-Frame and a pair of UHF antennas and pair of VHF \nantennas to get out of the way!).  I've tried three separate sensor \ncables, with similar/same results.  The big difference seems to be \n\"loaded vs unloaded.\"  I have a second rotator/control box installed for \nthe next antenna system (this one has about 110 ft of sensor cable at \nthe new antenna location) and have not experienced the problem at all.  \nThe rotator is on the tower, but no antenna is installed yet.  So it \nseems that there is a mechanical difference here that has something to \ndo with it.  Bob's theory that I'm currently working with is that some \nkind of mechanical resonance is occurring in the VHF/UHF H-Frame stack \ncausing something to mechanically \"glitch out\" the hall effect sensor.  \nI'm experimenting with counterweight balancing to try to manipulate the \nresonant frequency of the stack to avoid hitting that perfect alignment \nthat jams up the sensor.\n\nSo that's about it in a 'nutshell.'  I've tried one or two other things \nthat I've left out of the description because they seem to have minimal \neffect on the problem.  Very elusive problem, which makes \ntroubleshooting very difficult since I can't manually re-create the \nconditions that cause the problem.\n\nAny thoughts, comments, similar experiences, would be very useful and \nappreciated.  Sorry If I maxed out your inbox's storage space.\n\n-Zach, KJ4QLP\n\nResearch Associate\nTed & Karyn Hume Center for National Security & Technology\nVirginia Polytechnic Institute & State University\nWork Phone: 540-231-4174\nCell Phone: 540-808-6305\n\nOn 3/16/2016 6:53 PM, Daniel Cussen wrote:\n> You could use an interface like this one:\n> http://blog.radioartisan.com/yaesu-rotator-computer-serial-interface/\n>\n> to read the optical/hall effect encoders. One of the main problems\n> with this setup is that there is no absolute position sent, so any\n> pulses missed result in increasing and increasing errors. Also if\n> there is no end stop switches you can end up moving too far damaging\n> coax cables.\n>\n> Normally it is recommended to use separate screened cables for the\n> sensors to try prevent noise pickup.\n>\n> Can you link to the sensors you are using and what exact problems are occurring?\n>\n> On 16/03/2016, Robert McGwier <[email protected]> wrote:\n>> I would like to consider adding optical shaft encoders to augment or\n>> replace the hall effect sensors in use on an Alfa Spid az/el installation.\n>> We have the high resolution sensors and are experiencing some annoying\n>> anomalies that have been very difficult to trace and are detrimental to\n>> autonomous operation at our ground station at Virginia Tech.\n>>\n>> Any information or help would be appreciated.\n>>\n>> 73s\n>> Bob\n>> N4HY\n>> _______________________________________________\n>> Sent via [email protected]. AMSAT-NA makes this open forum available\n>> to all interested persons worldwide without requiring membership. Opinions\n>> expressed\n>> are solely those of the author, and do not reflect the official views of\n>> AMSAT-NA.\n>> Not an AMSAT-NA member? Join now to support the amateur satellite program!\n>> Subscription settings: http://www.amsat.org/mailman/listinfo/amsat-bb\n>>\n> _______________________________________________\n> Sent via [email protected]. AMSAT-NA makes this open forum available\n> to all interested persons worldwide without requiring membership. Opinions expressed\n> are solely those of the author, and do not reflect the official views of AMSAT-NA.\n> Not an AMSAT-NA member? Join now to support the amateur satellite program!\n> Subscription settings: http://www.amsat.org/mailman/listinfo/amsat-bb\n\n",
    "attachments": []
}