DAQ Testing/20190523

Back to Main Page >> DAQ Documentation Portal >> DAQ Testing >> DAQ Commissioning Notes

Previous Day of Testing << >> Next Day of Testing

May 23rd, 2019 Testers: Cameron Clarke, Paul King

Status

• New HAPTB based VQWK timing in CH and INJ
  • Optimizing for given TSettle and VQWK wait
  • Avoiding beam-sync jitter induced patern phase=4 block3 pickup of following integration window (time dependent)
• DAQ and Japan setup for ideal battery noise/pickup testing
• ADC wait time effects on block 0
• Beam sync and timing board status
• Remote control power strips
• Minimal functioning Japan setup and further options

New HAPTB based VWQK timing in CH and INJ

We have changed the VQWK start signal used in the CH and the spectrometers from being a short pulse generated at the transition to T_stable to be a short pulse generated at a variable time after the transition to T_settle by the HAPPEX timing board in the CH crate.

This was done before run 2430.

ADC timing optimization so integration starts at Tstable

By putting a copy of the T_stable/T_settle signal into a VQWK channel in the CH crate, we have determined that for the current 90us T_settle and a VQWK gatedelay setting of 10, the VQWK integration begins just after the transition to T_stable with a HAPPEX timing board delay setting of 23.

We also saw the vqwk number of samples could now be increased slightly while staying inside the T_stable, to make up for the fact that the integration is starting earlier. We can see fluctuations of the timing in the fourth subblock due to the variation of the T_stable due to being in the "line sync" mode, and would be able to set the integrations to terminate before the fourth block starts to pick up the varying end of T_stable. We have not changed the VQWK integration (nsamp) settings.

From now on, when we change the T_settle setting, we will need to adjust the delay so that the VQWK integration is timed appropriately.

We replicated exactly the timing setup mentioned above in the injector and performed the same tests. See attached plots - 120Hz jitter at end of integration, CH Tsettle scan,INJ Tsettle scan.

We see effective the same behavior and timing as was seen in the counting house and chose to use the same settings (setTimeHAPTB(23,3000)) in both locations.

We modified the bootscripts and CRLs of all 4 crates to recognize the newly written ~/devices/timebrd_scan/timebrd_scan.o utilities and added two new methods for specifically setting the above mentioned timing settings directly (and currently that method is hardcoded to these chosen values). This hardcoding will be addressed in the future with some more intelligent parameter file system.

Timing Jitter for 120 Hz linesync

We also noticed that the jitter in the last block and the end of the pattern phase is no longer present in data taken at 7:30 PM, and this is likely due to reduced power consumption reducing the line noise and phase jitter later in the day (and means we need to perform this test again during other potentially more disruptive times of the day to see if it gets worse than was seen - see attached plots).

HAPTB memory location

One other note is that the apar@adaq1 timing board libraries use 0xf0f0 instead of 0xb0b0 (as is done in the tedf test stand library) as the hw address for the timing board.

Optimal Battery DAQ and Japan setup

When performing battery noise floor/crosstalk/pickup studies we want to ensure that the batteries are connected (preferably with a capacitor in the way) to the same ground as the Main detector High Voltages or to the Main detector pre-amps' outputs, or in INJ/CH floating w.r.t. the VME crate ground.

In order to analyze battery data we want to use the standard detector map (properly updated with battery and empty channels names)

detectors = prex_detectors.map

We do not want to normalize against BCMs

QwDetectorArray.normalize = 0 
QwBlindDetectorArray.normalize = 0 

We want to allow differences for all types of signals for comparisons

enable-differences = 1 

And we want to ignore stability cuts

ring.stability_cut = 0 

The form that the data takes is determined by the map files which can contain pedestals and scale factors for the data, but a raw channel with no such map file provided will be given in total integrated ADC samples/number of samples as the .hw_sum values, and as total integrated ADC samples (an integer) in the .hw_sum_raw (and .block[0,1,2,3]_raw values). These raw values are not available in the mul (pattern) tree, but can be obtained by multiplying by num_samples. As long as the pedestal maps don't give a conversion factor then the hw_sum (_raw) outputs will always be in ADC counts/sample units (ADC counts units).

ADC Wait Time effects in block 0

Testing vqwkdelay internal timing effects on data sub-blocks - we cannot see any immediately clear effects from changing the VQWK ADC internal delay time, but we can look into this more. prex_ALL runs 2332-2350 investigate these questions explicitly.

Scan over vqwkdelay parameter, start at 0, go to 5, then 10, 10 minute runs from 1024->4 samp/block dividing by 4 each time

• Run 2332 - block 0 > 1, 2, 3 by 0.34 channels
  • 4096 samples per window, 1024 per block
  • crateheader=3,badc=0x80,nadc=10,vqwksamples=1024,vqwkdelay=0,vqwkblocks=4,vqwkperiod=0,vqwkinternal=2,nscaler=1
• Run 2333 - block 0 > 1, 2, 3 by 1.3 channels
  • crateheader=3,badc=0x80,nadc=10,vqwksamples=256,vqwkdelay=0,vqwkblocks=4,vqwkperiod=0,vqwkinternal=2,nscaler=1
• Run 2334 - block 0, 1, 2 < 3 by 2.057 channels
  • crateheader=3,badc=0x80,nadc=10,vqwksamples=64,vqwkdelay=0,vqwkblocks=4,vqwkperiod=0,vqwkinternal=2,nscaler=1
• Run 2335 - approximately uniform
  • crateheader=3,badc=0x80,nadc=10,vqwksamples=4,vqwkdelay=0,vqwkblocks=4,vqwkperiod=0,vqwkinternal=2,nscaler=1
• Run 2336 - approximately uniform
  • crateheader=3,badc=0x80,nadc=10,vqwksamples=1,vqwkdelay=0,vqwkblocks=4,vqwkperiod=0,vqwkinternal=2,nscaler=1
• Run 2337/8 - now set vqwkdelay to 5 and see if it's fixed, redo run 2334 timing
  • block 0, 1, 2 < 3 by 1.92 channels
  • crateheader=3,badc=0x80,nadc=10,vqwksamples=64,vqwkdelay=5,vqwkblocks=4,vqwkperiod=0,vqwkinternal=2,nscaler=1
• Run 2339 - now set vqwkdelay to 10 and see if it's fixed, redo run 2334 timing
  • crateheader=3,badc=0x80,nadc=10,vqwksamples=64,vqwkdelay=10,vqwkblocks=4,vqwkperiod=0,vqwkinternal=2,nscaler=1
  • block 0, 1, 2 < 3 by 2.08 channels
• Run 2340 - now set vqwkdelay to 20 and see if it's fixed, redo run 2334 timing
  • crateheader=3,badc=0x80,nadc=10,vqwksamples=64,vqwkdelay=20,vqwkblocks=4,vqwkperiod=0,vqwkinternal=2,nscaler=1
  • block 0, 1 < 3 by 2.08 channels, 2 < 3 by 1.875 channels
• Run 2341 - now set vqwkdelay to 256 and see if it's fixed, redo run 2334 timing
  • crateheader=3,badc=0x80,nadc=10,vqwksamples=64,vqwkdelay=256,vqwkblocks=4,vqwkperiod=0,vqwkinternal=2,nscaler=1
  • block 0, 1 < 3 by 2.08 channels, 2 < 3 by 1.875 channels
• Run 2342 - now set vqwkdelay to 20 and see if it's fixed, redo run 2333 timing instead
  • crateheader=3,badc=0x80,nadc=10,vqwksamples=256,vqwkdelay=20,vqwkblocks=4,vqwkperiod=0,vqwkinternal=2,nscaler=1
  • block 0 > 1, 2, 3 by 1.3 channels
• Run 2344 - go back and do 16 samples per block now
  • crateheader=3,badc=0x80,nadc=10,vqwksamples=16,vqwkdelay=0,vqwkblocks=4,vqwkperiod=0,vqwkinternal=2,nscaler=1
  • block 0 < 1 < 2 < 3 (it looks like 2 and 3 straddle the corruption time)
• Run 2345 - 16 samples per block now - delay+5
  • crateheader=3,badc=0x80,nadc=10,vqwksamples=16,vqwkdelay=5,vqwkblocks=4,vqwkperiod=0,vqwkinternal=2,nscaler=1
  • block 0 = 1, < 2 ~< 3 (it looks like 2 and 3 are now beyond the corruption time...)
• Run 2346 - 16 samples per block now - delay+20
  • crateheader=3,badc=0x80,nadc=10,vqwksamples=16,vqwkdelay=20,vqwkblocks=4,vqwkperiod=0,vqwkinternal=2,nscaler=1
  • block 0 < 1 < 2 = 3 (no idea... still falling down the ramp of corruption?)
• Run 2347 - 16 samples per block now - delay+64
  • crateheader=3,badc=0x80,nadc=10,vqwksamples=16,vqwkdelay=64,vqwkblocks=4,vqwkperiod=0,vqwkinternal=2,nscaler=1
  • Run 2348 - 1024 - adjust delay, start at 10
• crateheader=3,badc=0x80,nadc=10,vqwksamples=1024,vqwkdelay=10,vqwkblocks=4,vqwkperiod=0,vqwkinternal=2,nscaler=1
  • Run 2349 - 1024 - adjust delay to 20
  • crateheader=3,badc=0x80,nadc=10,vqwksamples=1024,vqwkdelay=20,vqwkblocks=4,vqwkperiod=0,vqwkinternal=2,nscaler=1
• Run 2350 - 1024 - adjust delay to 5
  • crateheader=3,badc=0x80,nadc=10,vqwksamples=1024,vqwkdelay=5,vqwkblocks=4,vqwkperiod=0,vqwkinternal=2,nscaler=1

Beam Sync and timing board status

The Beam Sync signal arriving into the Hall A counting house is distributed by a fiber/bnc distribution chassis in rack CH01B05 at about eye level. When plugging this signal into a scope (after translating it through a VME fiber translator board) it appears as a 0V ("NIM false") signal for 354 us and then the remainder of the 60Hz pulse is "NIM true" with a negative voltage (but this may be the fiber translator's fault for having inverted logic).

Comparing this beam sync 60 Hz signal to the MPS Tsettle signal coming from the injector's helicity control board via fiber connection and looking at it on a scope I see that the MPS signal comes at about 350+-25 us (the variation being due to using 120Hz 4-window/quartet pattern and so only triggering a new pattern every 30Hz and under or overshooting the phase lag/jump in the line sync signal that generates the beam sync signal) after the beginning of 354 us part of the beam sync signal (and it consistently comes before the end of that 354 us signal, though this may be the result of the beam sync signal being delayed due to its path around the accelerator before arriving at this distribution chassis).

If I instead utilize the April 2019 firmware revision Helicity control board, plugged into the counting house VME crate and using the same Beam Sync signal as described above (sourced in the CH chassis) to trigger it, I see the MPS Tsettle signal consistently being formed about 200 ns after the end of the beam sync signal's 354us portion (indicating to me that the end of the 354 us pulse is used to trigger the helicity control board).

If I again change boards in the CH and use the February 2019 firmware revision Helicity control board in the same way I see exactly the same behavior as the April revision.

Remote control Power Strips

Alexandre Camsonne has installed some remote controlled power strips.

Dustin's RPI GUIs

https://github.com/gahljust/RHRS-LHRS-motion-control-GUI

Minimal working Japan + bonus config features

To get a minimal working version of a Japan config file you need to do the following steps in order

git clone git@github.com:JeffersonLab/japan (https://github.com/JeffersonLab/japan)
cd japan
mkdir build
cd build
cmake ../
make
cd ../Parity/prminput

• The engine assumes several environment variables exist, so be sure to define them first

setenv QW_DATA [path to CODA data files]
setenv QW_ROOTFILES [path to where you want to store output files]

• Then populate [config_name].conf with the following options (a conf file stands in place of a long string of command line options, and Japan default assumes that a qwparity.conf file exists and fails if it is not overwritten with --config [config_name].conf instead).

vim [config_name].conf

• The engine will search for a default data file name "QwRun_#.log" and so you should overwrite the prefix and data extension with the following .conf options

codafile-stem = [CODA file stem (prex_ALL_)]
codafile-ext = [extension (dat)]

• The engine will search for a default map file for the detector names and channel map in "detectors.map" and should be overwritten with

detectors = [map name (prex_detectors.map)]

• Because the ROCs for the Parity DAQ are < 31 we need to add a flag (either in a separate conf file or by itself)

add-config = prexbankflag.conf

• • Where prexbankflag.conf contains

allow-low-subbank-ids = yes

• The engine will automatically give the Rootfile prefix as "Qweak_#.trees.root" and can be overwritten with

rootfile-stem = [stem (prexALL_)]

• To use the analyzer on the command line now you will need to pass your config file and the run number (or else it will use runnumber 0)

./build/qwparity --conf [config name.conf] -r [run number]

With all of these in place the analyzer will behave in a user defined and consistent way.

Several other important options

Other options that can be utilized are as follows:

• To use the data handlers you should include them in their own map

datahandlers = [data handler map]

• To define the event ring stability cut

ring.size = [event length] 
ring.stability_cut = 1

• To enable storing differences (in addition to yields and asyms)

enable-differences = 1 

• To turn off normalization (w.r.t. BCM charge)

QwDetectorArray.normalize = 0 
QwBlindDetectorArray.normalize = 0

• To allow bursts (miniruns)

enable-burstsum = 1 
print-burstsum = 1 
burstlength = [length of patterns to burst over]

• To enable running sums

enable-runningsum = 0 
print-runningsum = 0 

To run in online mode you will want to add the following features:

online      = yes 
ET.hostname = adaq3.jlab.org
ET.session  = par2
ET.station  = realtime

• Set the interpreted run number to a very high value so we always pick up the most recent parameter files

online.RunNumber = 999999
mapfile-update-interval = 500 

• Circular buffer: Default is 0, set it to 0 to save significant computation time not using the circular buffer

circular-buffer = 0 

• ROOT compression to minimum to save time

compression-level = 0 

• Trimming output can be done with the following

enable-tree-trim = yes 
chainfiles = no
single-output-file = TRUE
disable-slow-tree = yes
disable-mps-tree = yes
disable-histos = yes 
disable-burst-tree = yes 
enable-burstsum = no
enable-differences = no
enable-alternateasym  = no