DAQ Testing/20181128

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

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

November 28th, 2018 Testers: Bob, Cameron, Paul

See Today's Meeting Notes (Analyzer Meeting)

Goals

• Figure out how to read raw .dat files to find helicity signals by hand
• Update timing diagrams (include the 1us between start of T_settle and Helicity flipping, don't show multiple helicity flips if subsequent T_settle's aren't shown too)
• Work with Ed Jastrzembski to implement/verify the synchronization of the TS between Counting House and Injector
• Understand how to monitor data transfer in ET system using monitorGui
  • Understand DAQ deadtime implications
  • Figure out the parameters to be tweaked to allow data to flow unobstructed
  • If this doesn't yield an obvious solution, explore a homemade data buffer solution that allows for DAQ vs. online analysis decoupling
• Incorporate Helicity sequence monitor into deadtime testing and scaler testing
  • Also incorporate it into raw .dat file reading to determine helicity sequence and relative offsets of other copies of HEL+/-

Injector/Counting House Synchronization

• Ed Jastrzembski is busy this week, so Bob and Cameron will work with him in the first half of next week
• Paul King says that fiber optics cables were run to the second floor of the counting house for this purpose during QWeak, so we should be able to use those
• Possibly related: Bob added resistor termination to he TI board in the LHRS (and removed them from the RHRS)

Reading Injector .dat Files in xcefdmp

Scaling the data file in xcefdmp to 14 words wide is helpful. Event banked data is 14 x 45 - 3 = 627 words. I will enumerate them with the first word indexed at 0. Each word has 8 hex digits to it, and each hex digit has 4 bits = 32 bit data flow.

Header Words

What are the headers?

• Event header = 0xffb0b444 - word 0
• SCAL_BTYPE = 0x3101 - word 1, 37 data words follow, 1 footer word = 0xf0f0f0f0 appended (word 39)
• VQWK_BTYPE = 0xff902902 - word 40, 528 data words follow
• VQWKERR_BTYPE = 0x3112 - word 569, 32 data words follow
• HEL_BTYPE = 0x3103 - word 602, 24 data words follow

HEL_BTYPE

The helicity data is stored at the end of the event data and is obtained from the FLEXIO (as the first data word, word 603) and possibly also the STR7200 data words (next 5, 605-609) if needed

• Word 603 = the input signals, read from flexioReadData(2)
  • Method loaded from ~/devices/flexio/PaulVers/flexioLib.c/h (KentVers used in Counting House)
  • The data being read is the FLEXIO "input_reg", which (I believe) is the 16-bit hexadecimal word corresponding to the FLEXIO's input channels (assumed NIM logical pulses that are static per event)
  • Because for the tests yesterday I plugged an extra copy of HEL+ into the FLEXIO's last (index 15) input bit then we should expect to get a 0 or 8 in the 4th hex digit of the FLEXIO "input_reg" data
  • The normal bits are 0 = HEL+, 1 = HEL-, 2 = QRT, 4 = Pair Sync
• Word 604 = the FLEXIO output control bit, read from flexioReadData(1)
  • This word is trivially zero
• Words 605-609 = the STR7200 measured data
  • This data is stored in an "event_registers[16]" array
  • This array is filled by the STR7200 loaded library methods (see DAQ_Hardware_STR7200)
  • The CRL claims (checked the actual cabling in previous testing
    • Word 605 = MPS counter
    • Word 606 = QRT counter
    • Word 607 = MPS per quartet
    • Word 608 = ADC Gate per MPS
    • Word 609 = ADC Gate counter
• The rest of the words are blank

SCAL_BTYPE

This reads the assorted scan words and the SIS3801 scaler control bits and scaler data

• Words 2-4 = scan words
• Word 5 = 0x0
• Word 6 = calcuates the length of the scaler data and prints that out here = 0x20 (hex 0x20 = 32 words) for SIS3801 data (~/devices/sis3801IntLib/scalIntLib.c)
• Words 7-38 = scaler data read by sis3801ReadOneModule(id, num_of_words, rol->dabufp) method
  • These data words have their highest 8 (out of 32) bits encoding the SIS3801 control bit information, with the highest (31) bit = QRT, 30 bit = HEL+, and 29 bit = Tsettle/MPS
  • The rest of the 24 bits encode the scaler value itself
  • It is not immediately clear from the CRL how the data is actually getting placed in the data buffer, but it actually works when you read it out in xcefdmp (utilize the mask feature, bottom right corner), so it must be working I guess
  • Pan is not configured to mask the top 8 bits of control data, so it gives gibberish when you analyze a run
  • For the tests yesterday I plugged an extra copy of the HEL+ signal through the V2F into scaler channel 2, which shows up in Word 8 here
• The 3 copies of 4MHz clocks show up nicely, and it is clear that it is working because the scaler counts the number of pulses, meaning that a 4MHz signal is counted 4,000,000 * 1/30 = 133333 times in a 30Hz integration window. The empty V2F channels appear to be pulsing at 1MHz as well, and the helicity information in V2F channel 2 shows up at ~ 1.3MHz when it is true, and 1.1 when it is false, and the ADC gate counter is at about 1.1 MHz (because it is a narrow signal I guess)
• Word 7 = ADC Gate Counter
• Word 8 = my (temporary) copy of V2F HEL+
• Word 39 = footer word = 0xf0f0f0f0

VQWK_BTYPE

The vqwks get read out in sequence, executes the vqwkReadRegisters -> calls vqwkReadForwards methods (~/devices/qweak/vqwk_32.c)

• Calls read on rol->dabufp with a mask "0xff" and the reads through the (11) vqwk ADCs, 8 channels, and 4 blocks per read (8*6 = number of words per ADC, return value of vqwkReadRegisters)
• 6 words per channel
  • Reads 4 blocks
  • Reads 4 block sum
  • Reads nsamples_seqnum
• 528 total words for the vqwk ADCs
• Word 555 is vqwk10_5's sum = the HEL+ copy I added for the tests yesterday
• When xcefdmp reader is 14 words wide then word 555 is directly above the 0x3112 header

Helicity in yesterday's tests

Now I know where all copies of HEL+ are in raw data and what form they take

• SIS3801 scaler control bit - top 8 bits in each scaler word
• SIS3801 scaler data - word 8, must mask top 8 bits to see it well, (probably) still interpretable otherwise though if you look in the lower bits
• FLEXIO - word 603, and adding HEL+ to input 15 (last input) make life easier as the HEL+ will be 0 or 8 in the 4th degit
• vqwk10_5 - word 555, 32 bit number that is easy to read

Bit-wise operations

• A 16 bit hexadecimal integer looks like
  • n = (digits) 0x4th 3rd 2nd 1st = n_16 n_15 n_14 n_13 | n_12 n_11 n_10 n_9 | n_8 n_7 n_6 n_5 | n_4 n_3 n_2 n_1
• And the number 0x0177 is arrived at by
  • n = 0x0177 = 0000|0001|0111|0111

Hexadecimal numbering system

Hex Digit	Decimal	binary hex components	binary	binary hex components powers	Decimal
0	0	0000	0	0^3 + 0^2 + 0^1 + 0^0	0
1	1	0001	1	0^3 + 0^2 + 0^1 + 2^0	1
2	2	0010	10	0^3 + 0^2 + 2^1 + 0^0	2
3	3	0011	11	0^3 + 0^2 + 2^1 + 2^0	3
4	4	0100	100	0^3 + 2^2 + 0^1 + 0^0	4
5	5	0101	101	0^3 + 2^2 + 0^1 + 2^0	5
6	6	0110	110	0^3 + 2^2 + 2^1 + 0^0	6
7	7	0111	111	0^3 + 2^2 + 2^1 + 2^0	7
8	8	1000	1000	2^3 + 0^2 + 0^1 + 0^0	8
9	9	1001	1001	2^3 + 0^2 + 0^1 + 2^0	9
a	10	1010	1010	2^3 + 0^2 + 2^1 + 0^0	10
b	11	1011	1011	2^3 + 0^2 + 2^1 + 2^0	11
c	12	1100	1100	2^3 + 2^2 + 0^1 + 0^0	12
d	13	1101	1101	2^3 + 2^2 + 0^1 + 2^0	13
e	14	1110	1110	2^3 + 2^2 + 2^1 + 0^0	14
f	15	1111	1111	2^3 + 2^2 + 2^1 + 2^0	15

Bitwise Operators

• Logical And (&) -> a = b & c
  • Takes the bitwise (0's and 1's) representation of b and c and the result of each bit's & is "a"
• Logical Inclusive Or (|) -> a = b | c
  • Takes the bitwise representation, and if either is 1 then a's corresponding bit is 1
• Logical Exclusive Or (^) -> a = b^c
  • Takes the bitwise representation, and if just one of b or c's bits is 1 then a's corresponding bit is too, but if both are == then the result is 0
• Logical Not (~) -> a = ~b
  • Takes each bit and returns its complement
• Bit shift (>> or <<) -> a = b>>N
  • Takes the bit contents of b and shifts them N places to the right to produce a

• Examples
  • Grab the 3rd digit of a hexadecimal integer and make that a new variable -> mask the other digits and shift the result to the right by 2
    • a = (b & 0x0f00)>>2
  • Mask off the top 8 bits (8th and 7th digit) of a 32 bit integer
    • a = b & 0x00ffffff
  • Mask off all but the last bit
    • a = b & 0x1
  • Mask off just the last bit
    • a = b & ~0x1

Results

Using this information to parse (by eye) the runs from yesterday I see (in addition to Pan not giving helicity errors for anything where HEL+ was plugged into FLEXIO):

• Run 4663 - Benchmark initial settings: Scaler readout (just the scaler data, I haven't parsed the control bits yet, and we should since we can use them as a redundant check of FLEXIO data later) matches FLEXIO control bit and vqwk10_5
  • This means that the data being read in the current event from the scaler, FLEXIO, and vqwk10_5 are all from the prior event's integration window
• Delay Shifted FLEXIO LNE tests
  • Run 4673 - LNE delay = Tsettle + 50 us: the FLEXIO data matches the vqwk and scaler data (like in 4663)
  • Run 4674 - LNE delay = Tsettle + 10 us: the FLEXIO data is 1 before the vqwk and scaler data (but Pan gave no errors)
  • Run 4675 - LNE delay == Tsettle: matches 4663
  • Run 4677 - +200 us LNE delay: matches 4663
• Delay Shifted SIS3801 LNE tests
  • Run 4677 - 98.75 us LNE delay (close to nominal 102.5 us delay): matches 4663 behavior (SIS control bit is in line with scaler integrated data, and 4676 and 4673 also show this)
  • Run 4678 - 0 us LNE delay: The SIS3801 control bits are behind the scaler integrated data by 1 helicity window
  • Run 4679 - very large delay, should have been beyond one integration window, delay generator may have flaked out: matches 4663

• Issues
  • It is very likely that I didn't scan far enough in either direction to trigger off-by-one errors
  • I need to parse the SIS3801 control bit helicity information to see if it is off-by-one too
  • I may have made some mistake plugging in the wrong signal at one point, but I definitely was changing the delays correctly
  • I will do more tests with more extreme delays to get an error at least once

• How is the scal_data variable in Pan being generated? How is Pan calculating helicity errors in the first place
  • I think Pan's helicity information always comes from the FLEXIO, so it can't generate helicity errors if it is too far forward or backwards, since the helicity is that signal itself (obvious you can have it in the wrong place, if it doesn't match the helicity that was set during the vqwk integration time, but I don't think Pan can even know if this is happening or error out if you do it wrong)
  • I think the helicity errors are coming from control.db not being set to the actual helicity sequence and timing (i.e. the issues we had on the 11th were actually due to assuming octet 120 Hz when we were actually getting quad 30 Hz, and the FLEXIO was probably actually timed just fine before (and after) adding the delay

To Do

• Perform more tests of the FLEXIO and SIS3801 timing
• Incorporate Bob's Helicity sequence predictor to more carefully check off-by-one errors with these helicity signals
• Figure out ET deadtime, use monitorGui and Bob's Helicity sequence predictor code
• Work with Ed Jastrzembski next week on Injector/Counting house TS synchronization