Prev: Win2Kk insanity - help!
Next: Data Extraction Services
From: John Larkin on 2 Aug 2010 00:59 On Sun, 01 Aug 2010 20:45:26 -0700, Tim Wescott <tim(a)seemywebsite.com> wrote: >On 08/01/2010 08:17 PM, John Larkin wrote: >> On Sun, 01 Aug 2010 19:41:22 -0700, Tim Wescott<tim(a)seemywebsite.com> >> wrote: >> >>> On 07/31/2010 04:26 PM, John Larkin wrote: >>>> On Sat, 31 Jul 2010 15:31:29 -0700 (PDT), dclist<dclist(a)gmail.com> >>>> wrote: >>>> >>>>> I'm looking for a way to do moderately robust angular displacement >>>>> (and angular velocity) measurement. I was trying to use quadrature >>>>> encoders but it appeared the sensors were occasionally missing some >>>>> state transitions possibly due to the discs moving too quickly or some >>>>> occasional optical occlusion. I am therefore looking for alternatives. >>>>> >>>>> What are commonly used alternatives to measuring angular displacement? >>>> >>>> Absolute optical or mechanical encoders, synchro/resolvers, >>>> inductosyns, sin/cos pots, maybe some equivalent capacitive thing. >>>> RVDTs or pots for modest angles, less than a full rotation. >>>> >>>> Incremental encoders are usually pretty reliable. All sorts of >>>> printers and things use them. Maybe you have a signal conditioning >>>> problem. >>>> >>>> There's some sort of cool encoder that uses round PC boards, with >>>> inductive coupling between traces. >>> >>> That's the Inductosyn. Electrically it's just a resolver with lots and >>> lots of poles, although there are enough detail differences that the >>> 'just' needs to be taken with a grain of salt. >> >> Synchros and resolvers are cool. Analog Devices has s/d converter >> chips for about $12. > >It's not that difficult to measure the outputs directly and do the math >in a processor, either. We've been thinking about that lately, or at least doing it in an FPGA. The most popular tracking algorithm is very elegant; it's available in a number of places on the web. The problem with a synchro is that, twice a line cycle, the signals all go to zero and you are blind for a while. The algotithm essentially has inertia and cruises through the line nulls nicely, so the ability to track speed and acceleration is amazing. www.ddc-web.com/documents/synhdbk.pdf Page 19+ John
From: JosephKK on 6 Aug 2010 01:19
On Sun, 01 Aug 2010 21:59:05 -0700, John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >On Sun, 01 Aug 2010 20:45:26 -0700, Tim Wescott <tim(a)seemywebsite.com> >wrote: > >>On 08/01/2010 08:17 PM, John Larkin wrote: >>> On Sun, 01 Aug 2010 19:41:22 -0700, Tim Wescott<tim(a)seemywebsite.com> >>> wrote: >>> >>>> On 07/31/2010 04:26 PM, John Larkin wrote: >>>>> On Sat, 31 Jul 2010 15:31:29 -0700 (PDT), dclist<dclist(a)gmail.com> >>>>> wrote: >>>>> >>>>>> I'm looking for a way to do moderately robust angular displacement >>>>>> (and angular velocity) measurement. I was trying to use quadrature >>>>>> encoders but it appeared the sensors were occasionally missing some >>>>>> state transitions possibly due to the discs moving too quickly or some >>>>>> occasional optical occlusion. I am therefore looking for alternatives. >>>>>> >>>>>> What are commonly used alternatives to measuring angular displacement? >>>>> >>>>> Absolute optical or mechanical encoders, synchro/resolvers, >>>>> inductosyns, sin/cos pots, maybe some equivalent capacitive thing. >>>>> RVDTs or pots for modest angles, less than a full rotation. >>>>> >>>>> Incremental encoders are usually pretty reliable. All sorts of >>>>> printers and things use them. Maybe you have a signal conditioning >>>>> problem. >>>>> >>>>> There's some sort of cool encoder that uses round PC boards, with >>>>> inductive coupling between traces. >>>> >>>> That's the Inductosyn. Electrically it's just a resolver with lots and >>>> lots of poles, although there are enough detail differences that the >>>> 'just' needs to be taken with a grain of salt. >>> >>> Synchros and resolvers are cool. Analog Devices has s/d converter >>> chips for about $12. >> >>It's not that difficult to measure the outputs directly and do the math >>in a processor, either. > >We've been thinking about that lately, or at least doing it in an >FPGA. The most popular tracking algorithm is very elegant; it's >available in a number of places on the web. The problem with a synchro >is that, twice a line cycle, the signals all go to zero and you are >blind for a while. The algotithm essentially has inertia and cruises >through the line nulls nicely, so the ability to track speed and >acceleration is amazing. > >www.ddc-web.com/documents/synhdbk.pdf > >Page 19+ > >John Perhaps one of the more exotic things that i have ever seen is a widget called a resolver tracking bridge, it did the first 12 bits or so and passed the residue (tan theta) to a 16 bit SAR ADC. All of the RTB was done with transformers and relays and stuff. It was just some channels out of hundreds feeding the ADC aat 50 ksamples/second. Late 1960s technology (i worked with it in the late 1970s). |