DAQ Testing/20190213

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

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

February 13th, 2019 Testers: Cameron Clarke, Ye Tian, Chris Cuevas

Goals

• Understand Helicity Control Board issues
• Establish a standard QWeak ADC Testing Procedure with TEDf test stand and Electronics Group Lab View + Oscopes

Helicity control board updates

Cameron talked with Roger Flood today after understanding the difference in old vs. new firmware that Kyle Hesse helped us understand yesterday.

We have gotten the CRLs to match, and added the Ramp DAC 16 function (-5V to +5V).

Roger Flood says he isn't entirely sure what the change is that makes the old board start in free running mode with a heartbeat, but if it becomes urgent he can try to update the new firmware to behave in this more amenable way. In the mean time we can just keep this old board with old firmware, and if we ever need we can just ask for a fiber 60Hz line sync signal to use new firmware boards.

Cameron asked him about what "line sync" is actually doing and he responded this: line sync is taking the signal from a 60Hz reference line sync signal and using that to trigger the start of new Multiplet windows. Because of the requirement that the multiple start on a true to false transition of this 60 Hz signal, running something like Pair-pattern at 240 Hz will actually miss half of the windows! So we should keep this in mind. He says that the time of the final multiplet window is stretched or squeezed to fit in the appropriate number of 60Hz line reference windows, while the first N-1 windows are all fixed at the nominal width (and as a consequence we should always be careful to Gate our ADCs to integrate for less than 1/Frequency time, to avoid getting burned by 60Hz line fluctuations). Using "free clock" mode will simply make frequency = 1/(t settle + t stable) and doesn't try to sync to line at all.

The problem with line synch that was encountered in the injector recently has to do with using multiplets and frequencies faster than the 60Hz line (like a 240 Hz pair I mentioned above). Previously (a month + ago) the board would re-trigger if it saw the line sync signal = true, and so if you ran faster than the 60 Hz flip rate sometimes you would see the tail of the previous true pulse (or something along these lines) which would re-trigger and make a bit of a mess. Now it requires seeing a transition from true to false, meaning it will not have these extra re-truggerings, but also we should still be careful about running flip patterns that come close to filling T=1/60 seconds and report any weird behavior to Roger.

ADC Testing

Ye Tian and Cameron Clarke met with Chris Cuevas and another electronics group engineer to discuss the steps for getting a ADC repairing pipeline in place. Chris expressed optimism that they can develop an oscope, LRC, tester, and Lab View setup to test hardware components, and then we gave them a tour of the TEDf test stand (as described yesterday). We will log bad boards and upload plots and descriptions of problems to: https://misportal.jlab.org/mis/apps/peer/submit.cfm

• Run 1654 - testing a board to replace CH "vqwk1" "bad" board
  • Plots
  • It works, this board can be used - has label on top "MDBKG"
  • This board is then used to replace the board in CH "vqwk1" and Tao has taken data to establish pedestals
  • HAPLOG 3619 describes BPM 8 test with new ADC in CH crate
  • run 1233 and 1234 were used to test (run 1233 had address conflict, so ignore)
• Run 1655 - A board that was laying around, board 26
  • Plots
  • It works
• Run 1656 - testing original CH "vqwk1" "bad" board (top 4 channels are bad, ch's 4-7).
  • Plots
  • Top 4 channels are bad, as seen in CH crate data

To diagnose "bad" channels we should

• use the _raw data
• look at the error code bits - the bit mask information is catalogued in Analysis/include/qwtypes.hh
• the error code cut should be 3 to allow for saving "bad" data in the root file
• we should change the detector system type from blindable to regular detector
• we should check the data flow in xcefdmp to make sure that the filler data is not causing japan decoding issues (top 4 channels... seems suspicious)
• check the Telnet command line to see if the CRL loading and initializing sees problems with the ADC board or channels
• check the Telnet command line to see if the ADCs are having problems reading or writing during normal running (as when nsamp is too high)
• lower the number of samples from 4141 to lower for safety