Q about noise in time interval measurement averging

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.

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.

-- Bill Sloman, Nijmegen

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.

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.

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 =^.^=

ok that making sense now, but I have another question im not sure about, that is how to convert that to a noise density, I have a slow periodic signal wich im trying to isolate, I need to detect its presence and also if possible its magnitude and phase, this signal is probably about 0.3ps deviation, in the presence of standard deviation of about 10ns.

So I do a FFT, I need to see the signal significantly above the noise floor, the bandwidth is limited by sample rate ~ 100hz to integration time wich is many days, so say 100hz, is it right to consider the 10ns to be spread out over this bandwidth ?

The FFT I have atm shows lots of spikes, so my problem is probably more than just white noise.

Colin =^.^=

Your approace should start from statisticel methods. You have the ability to get a mean value and the variance (father of standard deviation) from that sample size. Compute it out and it should begin to elucidate your issues.

Fun stuff.

One thing to think about is that when sampling at 100Hz an unlimited BW signal you're aliasing all the wideband noise into your 50Hz final BW, which won't help S/N ratio. You'd have to low pass your time interval signal, either through greater sample rate and digital filter it, or maybe you can PLL your signal before sampling it.

"Fred Bartoli" wrote in message news:4618faa4$0$24758$ snipped-for-privacy@news.free.fr...

hmm im more confused now, the 100hz rate is already an average of 2000 time intervals, wich is one revolution,

the period of the signal im looking for is 1 day. so the bandwidth is like 0.00001 hz

Im going to make a program to generate test data so I can mess around and see stuff on the FFT.

The data gets sent to the PC for as serious number crunching as I can dream up.

Colin =^.^=

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

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

That's Highland Technology. We're only a streetcar ride from the Pacific Ocean.

But digitizing the output of an encoder to sub-ns resolution is a lost cause. Nasty influences, like temperature, bearing wear, led degradation, and a host of others will generate a drift floor well above that. It would help to know what the op is actually trying to do.

John

"so any long term change is ignored" contradicts "the phase varies cyclicly over a much longer period wich is the measurement of interest."

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.

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 =^.^=

Im not so sure, it would just add to the confusion, youd probably have lots more questions ...

basically the signal is cyclic over a few seconds so any long term change is ignored, the phase varies cyclicly over a much longer period wich is the measurement of interest.

Colin =^.^=

ha! see i was right, more questions ... well the detection of the initial signal is where any long term change in the bearings or optics of the encoder should not have any significant effect.

the Phase of this signal should still be preserved if it varies over a longer time.

Colin =^.^=

That was not a question, but an observation.

oo good point, It probably wasnt a very good explanation especially given that I seemd to have snipped of more than I should of.

Colin =^.^=

It is rare for a newby to tell us all we need to know to let us produce good answers to their question on the first or second go round, but their answers do tend to dimish the confusion, rather than adding to it.

Many of the gurus on this user-group have had a lot of practice at going from what the customers think they want to what the customers really needs. Some of us have gotten pretty good at it.

measurement

The phase of what relative to what?

-- Bill Sloman, Nijmegen

Your "two sensors opposite each other" reminded me of a couple of techniques: you can use a single source, a light pipe arrangement to transfer the optical signal so that it passes through the encoder twice at opposite sides of the rotating shaft, and a single receiver. This takes out eccentricity effects, and reduces some other things a bit. That was a way of commercialising the original idea, which was to do a similar thing but distributed all round the rotating shaft. This is a much better technique, but more expensive.

I might still have the original patents kicking around, this was from the mid-1970's, I'll have a look tonight.

Regards Ian

Sounds like loop control systems oscillatory errors. Which may or may not be coupled.

Sorry I dont mean to apear to be shunning your help, in fact ive asked questions here about many different parts of this project, but its just that if I tell you much more it wont make a lot of sense with out telling you a whole lot more, wich I dont realy wish to get involved in discussing right now cos im not sure I understand the physics behind this or even agree with it !

I'm not even sure if what im doing is acheivable but then I like a good challange every now and then.

Ive been into electronics since the early 70s, although I moved into software as people writing software had an easier job and were payed 2-3 times as much. not as interesting perhaps.

however I started by writting device drivers etc, and telling disbeleiving hardware engineers how to fix any hardware bugs I found was sometimes amusing. electronics was delegated to a hobby for some time. Ive ended up being quite well skilled in numerous fields, although trying to be expert in so many wich this project requires means I end up using the internet a lot.

Right now ive got to go and get some precision machining done ...

Think of it like a chopper stabilised op amp, but applied to a mechanical system. The intermediate cyclic rate is just the chopper frequency, this nulls out any offset of phase error and any change of it over a time longer than the period.

The resultant signal, after the chopper part is removed by software, is just the value im measuring. wich is the response to an input wich is made to vary slowly, thereby allowing a complex phase relationship to be measured.

Colin =^.^=