SIO pin Jitter or Noise on input signal

[crcac_264396]

Here is an issue I came across on the dev kit for PSOC5 (I think it is ES1). I have mostly resolved it by changing routing internally, but am throwing it out here in case its useful or anyone has any insights.

   

I have an input square wave signal that is variable in frequency and I need to sample this to determine the result of the instrument (a gravity meter). This particular frequency is on the order of 7 kHz and needs to be resolved to 0.005 Hz. I can take a couple of minutes to arrive at this resolution.

   

I decided to "clean" the signal by running it through a comparator, so I chose one of the SIO pins with a voltage comparison. The nice thing here is the signal becomes a great looking square wave that is synchronized to the internal bus clock. I used an external OCXO (26Mhz) as a frequency input to a pin just to get that extra bit of precision (used this as masterclock). To arrive at the frequency with minimal noise, I tried many different peripheral arrangements, but I can get to those later, as depending on timer/counter/capture/trigger routing etc, there was additional "noise" added.

   

The interesting thing about using the SIO as the input was it introduced frequency "noise", I guess it could be called jitter. It did not matter what reference voltage I chose. The syncronized squarewave that came out of this arrangement had lots of error (i really can't recall how much). I don't know if this is related to the voltage reference being slightly unstable, or the internal comparator being slow or something else

   

This I was able to mitigate by changing the routing. Turned out that from trial and error I got the best results by using an analog input pin, followed by an opamp buffer. This signal was fed into a comparator with 0.256V reference, and following this the output was fed into a sync component.

   

This arrangement gave me much better jitter probably 10 times better (lets say 90% of the time)

   

Now of course I am wondering can I get into one of the components and use an non-synchronized (dangerous!) clock signal...

[Bob_Marlowe]

31 bits resolution is quite a challenge, what precision are you expecting?

   

A quarz usually has a precision (when temperature stabilized) of 0.01 ppm which is about 27 bits precision.

   

So the question arises, why not let the whole chip run on a precize stabilized external frequency which could minimize a couple of other errors.

       

Bob

[Anonymous]

@Bob,

   

How did you arrive at a requirement of 31 bits resolution?

   

When I used this information: "I have an input square wave signal that is variable in frequency and I need to sample this to determine the result of the instrument (a gravity meter). This particular frequency is on the order of 7 kHz and needs to be resolved to 0.005 Hz. I can take a couple of minutes to arrive at this resolution." I calculated a required resolution of 21 bit. Nevertheless, this is still very high. considering that the frequency is in the order of 7 khz.

   

@Willemite: Did I get this right, you need to resolve the difference between 7000.005 Hz and 7000.000 Hz in your result? A basic approach to measure the differnce with a timer would end up with a timer clocked at approx. 10 GHz, that is not an option. Using the comparator will introduce a delay of some ns using an OpAmp introduces another delay..... Some of these delays are temperature dependend and given your requirement for resolution, all of this can make a difference in the result.

   

Cleaning up your signal migh introduce so much errors that measuring the clean signal is not as relevant any more.

   

Honestly I don't have a solution for your problem but I would ask the same question that Bob asked. What kind of precision do you expect in the end?

[ETRO_SSN583]

.005 Hz in 7000 Hz is ~ .7 ppm resolution, accuracy another matter.

       

So a 24 bit counter will give you that resolution. Direct form, or use

   

reciprocal counter technique.

           

http://www.leapsecond.com/pdf/an200-2.pdf

       

Noise, I would expect that noise thru a digital port to be an issue. Look at

   

your Vdd with a scope, infinite persistance, you will see something in the order

   

of 100 - 400 mV of crap. That all gets directly (scaled) coupled to Vddio buss.

   

Do the same looking at Vdda, see if its noise scales with your observations.

       

You might have to perform filtering/averaging to get rid of noise. Note this

   

approach only works if noise un-correlated. Clocking noise of course in a UP

   

system highly correlated. So try out averaging.

       

Regards, Dana.

[ETRO_SSN583]

A couple more useful references -

       

http://www.agilent.com/metrology/xtals.shtml

       

http://literature.agilent.com/litweb/pdf/5965-7984E.pdf

       

Regards, Dana.

[Bob_Marlowe]

Sorry, I mis-red 7MHz.. 7000 / 0.005 = 1400000 which as binary number has turned on bit 21.

   

I cannot get to 10 GHz. with the (corrected) 7kHz I just reach 2.8 MHz to get the needed precision.

       

Bob

[crcac_264396]

Thanks for the pointers, I will check them out over the next few days (currently on vacation, yay!)

   

I know the design is doable, I am "updating" a 1980's build that used 4 motherboards and condensing into one IC -- pretty cool. It will be in a fairly stable temperature box. They used a 1 MHz quartz oscillator (not even temperature controlled other than in an enclosure), a timer that counted for a minute, and then a CPU that averaged several minutes of data to get better. There were 4 boards because, well, each peripheral used a whole board, instead of a nifty drag and drop component.

   

My main point in posting was that the routing greatly affected the noise/resolution whatever it should be called. Just like any design, the layout made a huge difference. I obviously gave up using the SIO pins and went to a cleaner input signal transition than could be provided by the SIO pin.

[crcac_264396]

@LookAtSystemSolutions:

   

"you need to resolve the difference between 7000.005 Hz and 7000.000 Hz in your result?"

   

Yes, sort of. This is the precision I would like. The sensor output I am resolving is only specifed to an accuracy 10 times that, but based on the output (truncated to say 7000.00 or 7000.01) there is quantization error that, to me at least, indicates it can do better. I won't really know how much better until I measure it! But my quick and dirty project gave me indications that I could measure 10 times more quickly to achieve the same resolution (not surprising since I was using a reference clock more than 10 times faster....)

   

There is a lot of averaging involved as there is quite a lot of low frequency "noise" present inthe signal--its seismic noise, so technically its a real signal, just not the one I want.

[crcac_264396]

Couldn't wait, so I read though some of the papers provided by Dana, thanks again!

   

Turns out that the method I was inplementing in my design is the "4th" generation one named  "Multiple Time Stamp Average Continuous Counting" referenced in     http://tycho.usno.navy.mil/ptti/ptti2005/paper67.pdf. Funny, the only reason I was doing it that way was because it was the easiest to implement with my limited skills....

[HeLi_263931]

I would suggest using the reciprocal method. It gives you a high resolution in one (short) measurement cycle, whith the accuracy depending on the counter depth (24 bits should be OK for you) and the measurement time depends on the reference clock (about 0.6 seconds with a 10MHz clock). If you average multiple of these measurement, you should be able to avoid the jitter. I did a write-up of such an implementation here: http://blog.hendriklipka.de/archives/2012/04/freqmeter_intro.html