DAQ Meeting/20180601

Back to Main Page >> DAQ Documentation Portal >> DAQ Meetings

previous meeting << >> following meeting

Logistic information

BlueJeans calling instructions:
Toll-Free Number (U.S.& Canada): 888-240-2560
International toll number:     408-740-7256
Bluejeans CODE:         475 839 391
Bluejeans link: https://bluejeans.com/475839391

To Do

• All channels everywhere need to be checked, and Happex ADCs need to have their dynamic range and resistor settings checked as well
• All QWeak ADCs need to have a corresponding backup Happex ADC that is already plugged in and ready to go with the exact dynamic range for signals needing to be replaced (using the new Parity analysis framework in development)
• All of the signals and crates and networking connections should be diagrammed (as well as verified regularly) - as per Bob's presentation in apar@adaq3:~/parity/PREX_DAQ_Oct17.pdf
• Per window electronic noise must be negligible in quadrature w.r.t. 171 ppm (counting statistics asymmetry width relevant for physics result) - basically we want our electronics to be so much better than out other limitations that we don't have to explain their problems or limitations in any papers or presentations - see David Armstrong and Bob McKeown arXiv:1207.5238 and Paul Souder and Kent Pashcke (open source) for far more technical details and explanations
• DAQ software needs to be revived and rewritten

• Long-range plan :
  • PAN, post-PAN and PAN-guin (Parity Analyze software) should all be rewritten, primarily to bring its functionality into the current group's control as JAPAN (Just Another Parity ANalyzer)

Bob's Formal TODO List

• During the 2-week visit we managed to do items 1, 4, 5, 6, and the "deploy" part of 2 but not the "testing" part.
• It was a productive visit. We have a fully working DAQ with enough Qweak ADC channels to run; but also HAPPEX ADCs in the HRS and counting room.
• If another visit happens this summer, we'd do the "testing" part of item 2 and also 7, 8, 9. Testing the rate limit will involve learning how to configure and check the timing.
• Item 3 (testing spares) can be done in our test stand; it doesn't need access to the hall, so we can postpone it to the Fall.
• For the software (item 10) I'll try to have a version of "pan" ready to at least look at raw signals. But I am worried about item 10 being ready for the experiment.
• With a fully working DAQ we could do parasitic tests this Fall, if desired.

1. Revive spectrometer crates.
2. Deploy all ADCs and test them.
3. Obtain and test the spares.
4. Build various DAQ configs with subsets of the DAQ crates.
5. Find / remake the RS485 cable between HRS to build full system.
6. Move our DAQ to new computer. 
7. Test rate limit, ensure deadtime zero.
8. Ensure that ET system fast enough for feedback.
9. Revive the synchronization-check system.
10. Online software, a bit undefined since software is changing.
   Some ideas here:
  (a) automatic production of run-dependent database
  (b) feedback
  (c) coil-pulsing
  (d) panguin (GUI showing real-time plots)
  (e) prompt analysis
  (f) e-logbook entries 
  (g) archiving EPICs data

Minutes - Morning

• Morning - 9AM - Bob, Tyler, Chandan, Cameron : Looked at pre-existing analysis software and ADC testing techniques
  • Using scripts like the apar@adaq3~/adc_18ana and acons1 dumpRegHAPTB() and setDACHAPTB(#,level) functions can let us see what the dynamic range and functionality of ADC channels is
    • #=1 means 16 bit DAC and #=2 means 12 bit, and the 16 bit is negative signal, and the 12 bit is negative or positive signal
    • DAC = Digital signal generated in the computer to Analog Converter
    • HAPTB = Happex Timing Board (they require proprietary Twin-Axis cable, which has a polarity which should be specified for each cable, and which can be converted to Coax with a converted board to communicate with TI modules and QWeak ADCs)
    • ROOT trees are generated and can be used for online and offline analysis and ADC characterization
  • We should automate some software to input DAC signals and characterize ADC channels
    • We should do this to all channels and make sure all QWeak ADCs (versatile) have backup Happex ADCs (need to be tuned to match exact signal dynamic range expectations)
    • Look at dynamic range of voltage inputs, frequency ranges, and gain ratios, and modify these with resistors and appropriate replacement boards if needed
  • The former PAN software resides in ~/bpan18/pan (bpan18 = Bob's PAN from 2018)
    • See the README
    • Simple input of run number should be sufficient to analyze QWeak and Happex ADCs
  • The ideal use of ADCs comes when their expected signal resides at around 75% of the saturation peak use level
    • This reduces the effective signal to noise ratio, while still allowing some room for large signals to pop up
    • We should map out the desired input signals and rates and ensure that the Happex ADCs have the correct signals to facilitate a full QWeak->Happex transition if needed
    • QWeak ADCs are wonderful electronically, but the engineers who supported them have both retired from TRIUMPH in Manitoba, and so we would need to as their replacements to dedicate some time and effort to being QWeak ADC support staff if we want to get rid of Happex ADCs entirely
    • There are backup QWeak ADCs, but they are finite in supply, so this is the motivation for having a backup Happex ADC system

Minutes - Afternoon

• Afternoon - 2:30 PM - Ciprian, Bob, Tyler, Chandan, Cameron : Discussion of PAN->JAPAN Summer and Fall plans
  • Bob is very familiar with the existing PAN software, having written about a fifth of it
  • Kent's plan is to have a more complete framework and versatile platform, based off of the recently written QWeak analysis framework
    • Strip out some unnecessary QWeak stuff that isn't do great
    • Create an engine to do online and offline analysis simultaneously
    • Paul King and Kent Pashcke have started with the QWeak analysis to build back up to the full PAN functionality, including Happex ADCs
  • Bob says that whatever we build must include Happex ADCs, since there is a finite supply of QWeak ADCs, and they aren't supported anymore, since the TRIUMPH engineers who used to maintain them have both retired
  • Presently
    • The code has the QWeak 'analysis classes' which will need to be parsed for further functionality in other parts of the analysis code
    • Ciprian is supposed to build in a module for reading data from a file
    • and develop simultaneous online/offline functionality

• Goals for the new analysis code development:
  • Have a base engine version that works by the end of June
    • Let a small group work on development, to avoid conflict and speed development
    • Take suggestions for further functionality from all collaborators
  • Have the ability to perform full DAQ systems calibration and testing of all channels and dynamic range of Happex ADCs by September
  • Class templates from QWeak framework may need to be shifted to class inheritance philosophy which is more transparent, pending discussions with Paul King and Kent
  • Kent wants to also be able to use this framework to run Prex I replay analyses on old Prex I files
  • Over the Fall all online analysis modules should be developed
  • We should run parasitic measurements during Tritium, and definitely during Apex, and make sure everything is debugged by the end of Spring 2019
  • Cameron will be added to JAPAN analysis soon
  • Chandan and Cameron (or someone from SBU) should visit JLab again once the DAQ debugging functionality is developed
    • This will serve to prepare backup Happex ADCs for all channels, with the correct resistors and dynamic range, and to test the JAPAN software early on, and to build expertise and familiarity with SBU and Prex people
  • The JAPAN engine should work as just one single environment (no Post-Pan or Panguin kinds of add-ons) for all online and offline analysis, testing, regressions and anlyses, etc.

• Miscellaneous discussion:
  • Beam runs in Hall A August 27 2018, and Science begins September 19th
  • GEMs should be developed independently, but CODA interface should work modularly with no problem
  • There will likely be a Prex Collaboration meeting 2 weeks before the next MOLLER Collaboration meeting in July or August
  • Adam and Jinlong will work on the photon detector for the Compton Polarimeter DAQ
  • Juliette and people at Manitoba will work on the elctron detector for the Compton Polarimeter DAQ