40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log  Not logged in ELOG logo
Entry  Fri Sep 4 20:42:14 2015, gautam, rana, Update, CDS, Checkout of the Wenzel dividers TEK00000.PNGTEK00001.PNGTEK00002.PNG
    Reply  Tue Sep 29 03:14:04 2015, gautam, Update, CDS, Frequency divider box IMG_0014.JPGIMG_0015.JPG
       Reply  Fri Oct 9 19:54:58 2015, gautam, Update, CDS, Frequency divider box - installation in 1X2 rack IMG_0027.JPGtime_seris_25MHz.pdf
          Reply  Mon Oct 12 17:04:02 2015, gautam, Update, CDS, Frequency divider box - further tests calibration.pdfsystematics.pdf
             Reply  Wed Oct 14 17:40:50 2015, gautam, Update, CDS, Frequency divider box - further tests time_series_input_signals.pdfcalibration_20151012.pdfsystematics_20151012.pdf
                Reply  Tue Oct 20 17:36:01 2015, gautam, Update, CDS, Frequency counting with moving average 
                   Reply  Fri Oct 23 18:36:48 2015, gautam, Update, CDS, Frequency counting - workable setup prepared Yscan.pdf
                      Reply  Fri Oct 23 19:27:19 2015, Koji, Update, CDS, Frequency counting - workable setup prepared 
                         Reply  Sat Oct 24 12:34:43 2015, gautam, Update, CDS, Frequency counting - workable setup prepared Yscan.pdfFrequency_readout.pdf
                      Reply  Thu Nov 5 03:04:13 2015, gautam, Update, CDS, Frequency counting - systematics and further changes Systematic_error.pdfsystematics_origin.pdf
Message ID: 11736     Entry time: Thu Nov 5 03:04:13 2015     In reply to: 11709
Author: gautam 
Type: Update 
Category: CDS 
Subject: Frequency counting - systematics and further changes 

I've made a few more changes to the frequency counting code - these are mostly details and the algorithm is essentially unchanged.

  • The C-code block in the simulink model now outputs the number of clock cycles (=1/16384 seconds) rather than the frequency itself. I've kept converting this period to frequency step by taking the reciprocal as the last step of the signal chain, i.e. after the LP filter.
  • In the current version of the FC library block, I've disabled the moving average in the custom C code - I've left the functionality in the code, but the window length at the moment is set to 1, which in effect means that there is no moving average. I found that comparable jitters in the output are obtained by using no moving average, and having two 2-pole IIR low-pass filters in series (at 4Hz and 2Hz) as by doing a moving average over 4096 clock cycles and then passing that through a 2Hz IIR lowpass filter (as is to be expected).

Systematic error

The other thing that came up in the meeting last week was this issue of the systematic errors in the measured frequency, and how it was always over-estimating the 'actual' frequency. I've been investigating the origin of this over the last few days, and think I've found an explanation. But first, Attachment #1 shows why there is a systematic error in the first place - because we are counting the period of the input signal in terms of clock cycles, which can only take on discrete, integer values, we expect this number to fluctuate between the two integers bounding the 'true value'. So, if I'm trying to measure an input signal of 3000Hz, I would measure its period as either 5 or 6 clock cycles, while the "true"  value should be 5.4613 clock cycles. In attachment #1, I've plotted the actual measured frequency and the measured frequency if we always undercounted/overcounted to the nearest integer clock cycles, as functions of the requested frequency. So the observed systematic error is consistent with what is to be expected.

The reason why this doesn't average out to zero is shown in Attachment #2. In order to investigate this further, I recorded some additional diagnostic variables. If I were to average the period (in terms of clock cycles - i.e. I look for the peaks in the blue cuve, add them up, and divide by the number of peaks), I find that I can recover the expected period in terms of clock cycles pretty accurately. However, the way the code is set up at the moment, the c code block outputs a value every 1/16384 seconds (red curve) - but this is only updated each time I detect a zero crossing - and as a result, if I average this, I am in effect performing some sort of weighted average that distorts the true ratio of the number of times each integer clock-cycle-period is observed. This is the origin on the systematic error, and is a function of the relative frequency each of the two integer values of the clock-cycle-period occurs, which explains why the systematic error was a function of the requested frequency as seen in Attachment #1, and not a constant offset. 

At the frequencies I investigated (10-70MHz in 5MHz steps), the maximum systematic error was ~1%.

Is there a fix?

I've been reading up a bit on the two approaches to frequency counting - direct and reciprocal. My algorithm is the latter, which is generally regarded as the more precise of the two. However, in both these approaches, there is a parameter known as the 'gate-time': this is effectively how long a frequency counter measures for before outputting a value. In the current approach, the gate time is effectively 1/16384 seconds. I would think that it is perhaps possible to eliminate the systematic error by setting the gate time to something like 0.25 seconds, and within the gate time, do an average of the total number of periods measured. Something like 0.25 seconds should be long enough that if, within the window, we do the averaging, and between windows, we hold the averaged value, the systematic error could be eliminated. I will give this a try tomorrow. This would be different from the moving average approach already explored in that within the gate-time, I would perform the average only using those datapoints where the 'running counter variable' shown in Attachment #2 is reset to zero - this way, I avoid the artificial weighting that is an artefact of spitting out a value every clock cycle. 

Attachment 1: Systematic_error.pdf  17 kB  | Hide | Hide all
Attachment 2: systematics_origin.pdf  23 kB  | Hide | Hide all
ELOG V3.1.3-