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: 11704     Entry time: Tue Oct 20 17:36:01 2015     In reply to: 11690     Reply to this: 11709
Author: gautam 
Type: Update 
Category: CDS 
Subject: Frequency counting with moving average 

I'm working on setting up a moving-average in the custom C code block that counts the zero crossings to see if this approach is able to mitigate the glitchy frequency readout due to mis-counting by one clock cycle between successive zero crossings. I'm storing an array the size of the moving average window of frequency readouts at each clock cycle, and then taking the arithmetic mean over the window. By keeping a summing variable that updates itself each clock cycle, the actual moving average process isnt very intensive in terms of computational time. The array does take up some memory, but even if I perform the moving average over 1 second with 16384 double precision numbers stored in the array, its still only 130 kB so I don't think it is a concern. Some tests I've been doing while tuning the code suggest that with a moving average over 16384 samples (i.e. 1 second), I can eliminate glitches at the 1Hz level in the frequency readout for frequencies up to 5 kHz (generated digitally using an oscillator block). Some tuning still needs to be done, and the window could possibly be shortened. I also need to take a look at the systematic errors in this revised counting scheme, preferably with an analog source, but this is overall, I think, an improvement.

On a side note, I noticed some strange behaviour while running the cds average command - even though my signal had zero fluctuations, using z avg 10 -s C1:TST-FC_FREQUENCY_OUT gave me a standard deviation of ~1 kHz. I'm not sure what the problem is here, but all the calibration data I took in earlier trials were obtained using this so it would be useful to perform the calibration again. 

ELOG V3.1.3-