On Monday 10 August 2015 02:40:02 Nicholas Mc Guire wrote: > On Sat, 08 Aug 2015, Peter C. Wallace wrote: > > > I think the trick the Resolute encoder uses is this: the image is > > > captured in a perhaps sub microsecond flash of the LED, and then > > > the "image" can be shifted out of the sensor at a leisurely rate. > > > The specifications sort of suggests this (very fast capture (ns) > > > time, but only multi KHz maximum update rate) > > > > > > Peter Wallace > > > Mesa Electronics > > > > They may in fact use a laser for illumination as AFAIK you can get > > higher peak power with a pulsed laser than a LED. These are in the > > $30 region for 75W peak 40 ns pulse width, not much vibration or > > motion blur in 40 ns :-) > > the problem is not the vibration in the 40ns > but that the recorded encoder image is more or less > a random position within the vibration range of > the device + vibration of the laser - I was thinking > about compensations like done with satelite images > where multiple pictures are taken and then the signals > are compensated by filtering out szintilation effects > > If the actual sampling is in the multi kHz range only then > that would be well in the modes that such systems can have > and one - worst case - would have the full vibration in > the positional information. Just wonder if there are any > detection algorithms that look into such issues. Naively > one could do a fft on the position data under the assumption > that motion should be constant/known-trajectory and that > could reveale such vibration/aliasing induced errors.
And once the vibration period is known, an auto-correlation over that time period could improve the accuracy quite a bit, perhaps as much as 10x if the vibration is bad enough to hear. The problem then is the resultant position data, if the machine is moving, is now old by the amount of time the butterfly transform took, then the auto-correlation over the period its output could detect, which could be even slower than the butterfly transform that did the FFT. Its faster than a true FFT by quite a bit, and has the added advantage that running it twice, the second time on the data output by the first pass, which restores the original data. Or is the butterfly transform old hat for FFT, and something even newer & faster has taken its place? Its been probably 20 years since I played with it on an 16 bit machine & I haven't heard a lot about it since. A 256 bucket transform on that machine took several seconds IIRC. Not having enough memory I never tried a 1024 bucket test. > > http://www.osram-os.com/osram_os/en/products/product-catalog/laser-d > >iodes/high-power-laser-diodes/pulsed-laser-diodes/hybrid-pulsed-laser > >-diodes/index.jsp > > > > ( thank you Harold Edgerton ) > > thx! > hofrat > > ---------------------------------------------------------------------- >-------- _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> ------------------------------------------------------------------------------ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
