DAQ Meeting/20180730

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

Agenda

• Cameron and Chandan : Ask Bob about problems from yesterday

Minutes

• Morning - 9AM - Bob, Cameron, Chandan :
  • The LHRS and RHRS have all of their HAPPEX and QWeak ADCs tested
    • Issue: There appears to be a PAN issue with reading the data and messing up the signed vs unsigned integer which causes the intended centering around the mid point of the dynamic range to end up as centering about 0/max value
    • This is a software issue that can likely be easily fixed and has no effect on the raw data files
  • We didn't test HAPPEX ADCs in the counting house yet
    • Issue: The Counting House DAQ (ROC 23) doesn't allow us to change HAPPEX ADC Gains within the RampTest.crl readout list on the fly
    • This is due to some persistent problems with the counting house DAC that can be circumvented by just doing the DAC12 ramp without changing gains
    • So just assume a good gain and verify that it doesn't saturate and we are good
  • There is a standalone .crl for the injector
    • So we can just move our RampTest.crl ramping functionality into a copy of it
    • However, there is no HAPPEX Timing Board in the Injector, and so doing ramp tests is not immediately possible
    • Because other people are using the Injector DAQ we will not add a HAPTB to it right now, but it should be very simple to do
    • So then we just would need to add the HAPTB handling code from Prex_ts.crl into Injector.crl and proceed
• Morning - 10AM - Bob, Cameron, Chandan :
  • Fix the PAN software error

diff VaEvent.cc ~/bpan16/pan/src/VaEvent.cc2722c2727,2728
<   lrawd = rawd;
---
>   lrawd = static_cast<int32_t>(rawd);//FIXME
>   //lrawd = rawd;

• • • Now the zero-volt signal is at ~0 in the y axis of the PAN plots and the negative voltage is in the negative range and positive is in positive y axis range
    • Some of the "Bad" channels from yesterday have a few (3 or 4) bad initial events which skew the plotted y axis
      • just cut them out to see the fluctuating pedestal for bad channels
  • The bad channels in the QWeak ADCs (particularly vqwk4 in Counting House) may be due to bad addressing
    • ~/devices/devices/vqweak.c is the library used to define QWeak ADCs
    • Our .crl is incrementing the address increment (unsigned int addrinc_vqwk = 0x10000;) by 1000 each time, baseaddr_vqwk starts somewhere else
    • Caryn had taken out the vqwk ADC initialization from the main Prex_ts.crl (that we copied for our RampTest.crl) and moved it into the boot scripts for the ROCs themselves
  • Check addressibility of VQweak ADCs by logging into ROC 23 with telnet/ssh and run the vqwkInit(UINT32 addr, UINT32 addr_inc, int nadcs) function to test ADCs
    • Using an intentionally wrong address crashes the ROC (like with setting the HAPPEX ADCs gains did before)
    • Using an intentionally correct address (by rebooting and watching boot script print to screen) it correctly finds all 5 ADCs and addresses them happily
  • Looking at data output from PAN (Corrected axes) for vqwk3 and 4 (4th and 5th in the crate) - 4 had all pedestals for run 4103
    • Looking at the "crosstalk" output for the channels of 4 wrt 3s run in 4102 shows that the neighboring channels are responding to the ramp input DAC voltage
    • There is just crosstalk - vqwk3_1 is responding to exactly the same input signal as vqwk3_0, and doesn't respond at all in run 4103 when the ramp voltage is plugged into its inputs
    • We will run new tests to see what is going on with these malfunctioning ADC channels - see DAQ Testing/20180730 - NOTE: There was some user error or something that was not reproducible, there is crosstalk of some form with neighboring channels on an ADC, but not between two ADCs - further tests are done to see if this is a QWeak ADC hardware error or something in software
  • Looking at the cooling fans, the fan on the left (underneath the ROC) is broken, making it pretty hot in there - the left fan needs to be replaced
  • Checking if the VME Board or QWeak ADC is broken
    • Replace the QWeak ADC with a spare to see if that fixes the broken channels
    • The new QWeak ADC (set to have the same hardware address = 880000)

Testing

Today's testing