Re: Q about noise in time interval measurement averging

<bill.sloman@xxxxxxxx> wrote in message
news:1176133466.968761.305280@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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.

well I average all the pulses over exactly one revolution,
so any eccentricity wich is there should null out in the average.


I have tried 2 sensors on the same disc, oposite eachother,
and you can see the error due to disc misalignment etc.
however averaging this out over 2000 pulses over 1 revolution gave a
standard deviation of just 500ps.
wich coresponds well to the reduction of 25ns/sqrt(2000).
{i had initialy put this down to mechanical/electrical noise}

Interestingly if I feed it with the same signal as ref and compare it drops
down to 25ps,
im not sure if there isnt some peculiarity with the PIC of pulses ariving at
the same time.
If I use alternate edges its stil quite low.

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.

Yes my initial aproach was to use a time to voltage converter,
but the voltage coresponding to 1ps was very small, and gave rise to its own
noise problems.

the other problem wich actually precluded this and make some of the things
you mentioned much more difficult is that the phase of the 2 signals varies
by more than 180'.

I need to keep track of the total phase change, wich might be upto 20
cycles.
the PIC handles this surprisingly well, as it timestamps every edge with
input capture.

it may stil be possible to do this with a PLD at high clock rate using a
similar technique.
however compared to the simple PIC aproach this seems very involved.

however atm as my mechanical noise is much more than my quantization noise,
so I think the PIC will suffice.
I also think the risetime and bandwidth of the electronics and opto devices
contribute noise wich is best averaged out too, although I have no specs on
this.

My main concern at the moment is to re do the mechanical side of things,
but I needed to know more about how the noise is reduced etc,
so hopefully I can find room to make it easier to improve the mechanical
precision
without losing it in quantisation noise.

The 10ns noise is mechanical and this is what will cuase it to take 3 years
to average out.

with your help I think I understand it well enough now thanks,
also i did a simulation generating computer data with 10ns variation derived
by a random number generator,
the FFT showed a noise floor coresponding to 1/sqrt(samples).

Although I need to work out how I can reduce this further as my signal has a
minimal bandwidth.
im also not exactly a specialist in FFT (yet).

Colin =^.^=


.

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. ... My own inclination would be to go for a faster clock - using ...
    (sci.electronics.design)
  • 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: Image registration/averaging and image quality
    ... Noise and resolution are not exactly related. ... If your 8-bit converter had the linearity of a 12-bit, and the noise happened to simulate a nearly ideal dithering waveform, and signal were stationary during the averaging process, then the average of 256 conversions would be accurate to 12 bits. ...
    (comp.dsp)
  • Re: ISO / Noise / Megapixel
    ... noise algorithm probably will average 4pixels to create a single pixel. ... I should improve the SNR by reducing the resolution. ... averaging, if necessary, afterwards, in an image editor. ...
    (rec.photo.digital)
  • Re: ISO / Noise / Megapixel
    ... Does it mean that if I reduce the Megapixels the noise is also reduce? ... The way I would take this is that noise tends to be single pixels that are ... Just reducing the resolution by itself may ... unless the averaging is also implemented. ...
    (rec.photo.digital)