Re: Q about noise in time interval measurement averging

On Apr 7, 2:44 am, "colin" <colin.ro...@xxxxxxxxxxxxxxxxxx> wrote:
<bill.slo...@xxxxxxxx> wrote in message

news:1175902280.854739.222930@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx





On Apr 6, 8:42 pm, "colin" <colin.ro...@xxxxxxxxxxxxxxxxxx> wrote:
Hi,
I have a PIC measuring a time interval to 25ns resolution,
the interval is totaly asynchronous to the PIC clock.

So say if I average over 25000 measurements that will give me a limit of
1ps
resolution.

Im trying to do a system noise analysis and im wondering how to work this
out,
I cant seem to recall how the noise reduces with increasing samples,
is it 1/samples ? this would be too good to be true,
or 1/sqrt(samples) this seems rather low.

Noise decreases as one over the square root of the number of samples,
if the noise on successive samples is uncorrellated.

The square root of 25000 is 158.1, so you'd reduce your 25nsec
quantisation error to 158psec rather than 1psec, if you averaged 25000
independent samples.

Ah yes ofc I must of forgoton how to think for a while,
I was getting mixed up with the number of available bits for resolution.

there is also a lot of noise in the signal as it is from an optical
encoder,
seems mostly mechanical, I need to reduce this by averaging over a long
time
too.

I'm trying to work out the optimum rate of pulses per revolution to use.

The optimum number of pulses per revolution is probably one, unless
your need to know the sense of the rotation as well as it's speed.

not too woried about the sense of rotation as I know that anyway,
however im seeing a standard deviation of about 10ns per revolution averaged
over 2000 pulses per rev,
Im working on fixing the mechanics to reduce this,
but 1 pulse per rev would give me 25ns error,

im looking for .1ps resolution,
to reduce my SD of 10ns to this amounts to 100000^2 revolutions wich would
take 3 years at 6000rpm
id rather it only took a few days, as im not quite that patient.

The advantage of one pulse per revolution is that you are looking at
one fiduciary mark on your shaft, so you don't have to worry about the
spacing of the fiduciary marks around the shaft, or the centering of a
radially striped disk on the shaft. and the interval between the
signal edges that define the period of rotation is as long as
possible, so your quantisation noise is 10nsec in 10msec, rather than
10nsec in a shorter period.

If you put an array of detectors around the shaft, so you get one
pulse per revolution from each sensor, you end up with more
observations per revolution with independent quantisation noise on
each value for the period of rotation,

Obviously, if there is noise on the rate of rotation - such as might
be caused by a minimally elliptical shaft rotating in a minimally
elliptical journal bearing - at a frequency that isn't an integral
multiple of the frequency of rotation, the noise on the output of each
sensor in the array would be correlated with the noise on the output
of its nearer neighbours, and averaging wouldn't do as much good as it
would on uncorrelated noise.

My own inclination would be to go for a faster clock - using
Motorola's ECLinPS emitter-coupled logic you could build a very wide
synchronous counter (you'd need 23 bits - four MC100E016) that could
follow a 500MHz clock, which would give you 2nsec of jitter rather
than 25nsec, and drop your three years down to a week.

Peter Alfke of Xilinx - a guru on comp.arch.fpga - programmed a Xilinx
programmable logic device to work as a 1GHz counter a few years ago -
and this might be a better way to go.

If you were in a position do a serious amount of work, you could
combine a fast clock with a time-to-voltage converter, and get the
timing resolution down to around a few tens of picoseconds. Some years
ago, when I was working on a stroboscopic electron microscope with a
digital timebase, we set up such a system that digitised time
intervals with a resolution of 10psec. Our 800MHz clock was not
crystal-controlled, and our jitter never got better than about 50psec
before the project was cancelled. I believe that John Larkin (Inland
Electronics) sells toys that can do better.

--
Bill Sloman, Nijmegen

3 days would mean i would have to get my SD down to 500ps per rev wich is
probably highly optimistic
and id need at least 625 pulses per rev too.

I could try timing both edges and see how the SD changes with twice as many
samples.
I tried feeding the same signal into both A and B, and the SD came out at
about 25ps
wich is lower than one would expect but its probably not a valid thing todo.

the error also seems proportional to 1/shaft speed.

Colin =^.^=- Hide quoted text -

- Show quoted text -


.

Relevant Pages

  • Re: Q about noise in time interval measurement averging
    ... I have a PIC measuring a time interval to 25ns resolution, ... I cant seem to recall how the noise reduces with increasing samples, ... your need to know the sense of the rotation as well as it's speed. ... and averaging wouldn't do as much good as it ...
    (sci.electronics.design)
  • Re: Q about noise in time interval measurement averging
    ... I have a PIC measuring a time interval to 25ns resolution, ... the interval is totaly asynchronous to the PIC clock. ... I cant seem to recall how the noise reduces with increasing samples, ... and averaging wouldn't do as much good as it ...
    (sci.electronics.design)
  • Re: [patch 00/21] hrtimer - High-resolution timer subsystem
    ... Right now the primary function of the state is to tell whether the timer ... > Of course if you consider the possibility of including high resolution ... problem requires solving problems in the clock abstraction first, ...
    (Linux-Kernel)
  • Re: Need to implement a calendar clock with millisecond resolution, please help.
    ... true, as I am a newbie, not even a real programmer), but I need to ... implement a calendar time clock with a millisecond resolution. ... system include clock, delay(), gettimeofday, msleep, ...
    (comp.lang.c)
  • Re: [PATCH] ktimers subsystem 2.6.14-rc2-kt5
    ... > a clock with a better resolution. ... > resolution than the physical clock has. ... reaches this count the timer is expired. ... OTOH We could also do this at the timer interrupt: ...
    (Linux-Kernel)