DAQ Testing/20181127

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

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

November 27th, 2018 Testers: Bob, Cameron

See Today's Meeting Notes

Goals

• Verify the NIM-TTL level translator is not bad and that the real issue with DAQ_Testing/20181114 was improper signal termination in the scope
• Scan Helicity readback from scalers as a function of delay time
  • Likely the readout instance is marginally close to the LNE delayed signal timing)
  • It is important to verify that the FLEXIO is functioning as advertised in the FLEXIO manual
• Add Helicity information to the scalers of interest
  • Find their data in the output data-stream to allow for unambiguously determining the relative timing of the scaler vs. vqwk vs. control bit readouts

Work

TS Timing

Bob emailed Ed Jastrzembski asking for his support in evaluating the TS synchronization. We will likely tour the Counting House and Injector at a time convenient for Ed soon.

Helicity Sequence Monitor

Bob siphoned off the helicity sequence predictor code from the QWeak analyzer and made a standalone code that can be used to verify that no events are skipped in the data stream (offline analysis)

Next:

• Cameron should implement this in his ~/et-12.0/src/cameron/ etclient program that tests for deadtime online
• Cameron should consider utilizing the on or offline versions of this to verify that scalers reading helicity information are reading the correct relative events ** Just eyeballing it is sufficient for our purposes, but using this and calculating the helicity sequence offset for each copy of the sequence would be valuable as well

NIM-TTL Level translator health check

During the Nov 14th testing Cameron noticed issues with the signals in the scope. This was likely caused by failing to 50 Ohm terminate the signals in the scope, and the modules automatically 50 Ohm terminate, so the issues seen on the scope will not afflict the signals read in the modules.

Test:

• If I plug Tsettle into the NIM-TTL level translator by itself, not terminated
  • I get garbage
• If I plug in 2 signals un-terminated
  • Looks ok, but the signal is 1.5 volts and has a long and drastically curved tail
• If I plug in delayed Tsettle by itself un-terminated
  • The signal picks up the Tsettle that is either in the other channel of the NIM-TTL level translator or something
  • Termination is necessary

Lesson learned: Always check for 50 Ohm signal termination, and also add 50 Ohm resistors to the extra ports of NIM-TTL NIM outputs that are otherwise unused to prevent shenanigans elsewhere.

Remaining Concern: If I terminate the scope but not the second NIM out in the level translator then I get a 1.5 Volt signal rather than the NIM standard 0.8 V (and it has a bad tail) - Solution: make sure the second NIM out always gets terminated somehow.

Injector DAQ test - Adding HEL to data stream

These changes are temporary and only affect the runs described in this test

Adding Helicity to data stream:

• Added HEL+ to vqwk10_5 (the only open vqwk channel, in Caryn's injector pan this apparently used to be a BCM, but it is otherwise empty now)
• Investigate Voltage to Frequency (V2F) converter - V2F channels are located in a mounted relay station between the main two sets of VME modules
  • Relay Station Inputs 1-16: Are being routed through the left-most V2F unit into the first 16 inputs of the SIS3801 Scaler
    • Input 1 (in the mounted relay station): A copy of the vqwk_veto Vetoed Tstable signal that is used as the EXT Vqwk gate
    • (For this test) Input 2: I added a NIM HEL+ copy here
    • Inputs 2-16: Empty
  • Relay Station Inputs 17-32: Also empty, but these channels are not being routed through a V2F into the SIS3801 scaler
• SIS3801 Scaler inputs (0-31) - I added some copies of HEL+ - 0-15 are the left-most V2F, 16-31 are the NIM-TTL Level Translator's ECL twisted pair outputs
  • Channel 0: V2F Input 1 = vqwk ext signal
  • Channel 1: V2F HEL+ copy
  • Channel 2-15: Empty
  • Channel 16-18: 4 MHz NIM outs of V2F clocks (going from left to right, 16 is the one that the scaler channels 0-15 come from)
  • Channel 19-30: Empty
  • Channel 31: NIM->ECL copy of HEL+ (for some runs, then it was taken out and the HEL+ multiplication was moved to a different channel multiplier), otherwiser Empty
• I also added a HEL+ copy to FLEXIO channel 15 (the last channel), and HEL+ was already in the control bits of SIS3801 and FLEXIO
• So for these tests HEL+ should be in FLEXIO channel 0 and 15 (and HEL- in channel 1), SIS3801 scaler channel 31 (NIM, only for first bunch of runs) and 1 (V2F output, all runs), and Vqwk10_5 (NIM) for all runs

Testing Injector DAQ timing with HEL+ information

• Run 4662 - "Injector" config test that it works
• Run 4663 - 9000 event test with all HEL+ signals added as described above (this should be a the golden run for how the DAQ has been set up)
  • HEL+ should be in FLEXIO channel 0 and 15 (and HEL- in channel 1), SIS3801 scaler channel 31 (NIM, only for first bunch of runs) and 1 (V2F output, all runs), and Vqwk10_5 (NIM)
  • It works (at least appears to) in Pan - I can see the Helicity information in vqwk10_5 and in tirdata variables are correlated with each other (though there appears to be a sign flip between the two)
    • Is "tirdata" a FLEXIO helicity signal? It is claiming to be decoded from a "tir" device in the control.db in apar@adaq3:~/caryn/paninj2018/pan/control.db*
  • It looks like the scaler (ECL input) data is not being decoded by Pan correctly, or there is a problem with the input channels
    • The input looks like this, and it actually correlates with the HEL+ control bit plugged into the SIS3801 as well
    • Paul King says this is probably because Pan is not decoding the Header control bit words separately from the scaler words
    • When I unplug the HEL+ control bit, the data from the scaler channels no longer has this correlation (instead of the left side being raised, both sides of this kind of plot are equal level)
    • Nonetheless, no matter what signals I plugged into the scaler channel, the first 4 channels (0-3) read as flat lines as a function of event number, and the rest all had the same behavior, though they did appear to not all be exactly the same signal, and would change magnitude if I changed what signals were plugged in (so its probably just a decoding issue)
• Run 4664 - It looked like the scaler channels were all inverted in the NIM-TTL ECL flat cable output (the notch was on the wrong side), so I flipped the cable around (which will invert the input-output channel mapping and flip the polarity of the ECL signals)
  • The ramping direction of the scaler looks to have changed behavior, but the jumps between events are so large its hard to tell if it changed due to me flipping the cables or not
• Run 4665 - I un-flipped the ECL-flat cable, and now I took the HEL+ multiplying signal out of the top (scaler channel 31) NIM-TTL level translator channel and changed that multiplying to be in a separate channel multiplexer, to make sure there wasn't any cross-talk in the NIM-TTL level translator
  • No (noticeable) change in Pan decoded data
• Run 4666 - I removed the HEL+ signal from the SIS3801 scaler input to see if that changes behavior
  • No (noticeable) change in Pan decoded data
• Run 4667 - I Removed HEL+ from the control bit of SIS3801 (and put the scaler HEL+ input back in)
  • Bug: This removes the HEL+ correlation of the scaler readout channels, making me thing it is a Pan decoding bug that made the correlation appear in the first place and that the signal was being dominated by the control bit part of the words rather than the scaler channel readouts
  • Confirmed: The control bit into SIS3801 matches the HEL+ data that is decoded for that even coming from the Vqwk10_5 channel, and also from whatever signal has been read into the "tirdata" variable
  • Confirmed: Because the "tirdata" information continues to track nicely with the vqwk10_5 signal this means tirdata is not SIS3801 control bit HEL+
• Run 4668 - To make sure the issue wasn't just the V2F module in question I switched the HEL+ V2F signal to the second V2F module's input (relay channel number 20, 4th input to V2F, reads out as bit 3 in data stream) in the VME crate and also switched the twisted pair flat cable to read that V2F module's outputs
  • No new change from previous behavior
• Run 4669 - There is an EXT in channel on the V2F modules, so I plugged a Tstable signal into it (400 us after the SIS3801 LNE signal)
  • No new change from previous behavior other than a change of magnitude in V2F outputs
• After these tests I made sure the channel mapping was as in run 4665

Test the FLEXIO Marginal Timing

After giving up on using Pan to understand the scaler data, and not being able to find the Helicity information (properly labeled at least) for the FLEXIO or SIS3801 Helicity inputs I moved on to testing the marginal timing of the scalers using Pan - the diagnostic is if the delayed LNE signal jumps over the point where the scaler is read out in the CRL then the sequence of helicity will be off-by-one and, if that is the helicity being read by Pan to check the helicity sequence, then it will yield helicity sequence read errors in the Pan analysis (as was seen in our modification on Nov 11th 2018 (after the Prex Collaboration meeting day 1, with Caryn, Paul King, Cameron, and Amali).

FLEXIO nominal behavior (post modifications by Bob and Cameron on August 2nd): LNE 97.85 us delay w.r.t. Tstable (597.85 us after Tsettle, 150 ns long pulse width (longer than 30 ns is minimum requirement for proper FLEXIO behavior - per Ed Jastrzembski discussion)

• Run 4663 - serves as nominal behavior benchmark
• Run 4670 - delay at 92.5 us (minus 5 us) - Pan worked, no helicity errors
• Run 4671 - delay at 87.5 us (minus 10 us) - Pan worked, no helicity errors
• Run 4672 - delay at 82.5 us (minus 15 us) - Pan worked, no helicity errors
• Run 4673 - delay at 50.0 us (minus 47.85 us) - Pan worked, no helicity errors
• Run 4674 - delay at 10.0 us (minus 87.85 us) - Pan worked, no helicity errors
• Run 4675 - swapped LNE with Tsettle itself (-500 us w.r.t. Tstable) - Pan worked, no helicity errors
• Run 4676 - delay at 200.0 us (plus 101.15 us) - Pan worked, no helicity errors

Test the SIS3801 Marginal Timing

This is the LNE signal that was changed on 11/11/2018

SIS3801 nominal behavior (post 11/11/2018 modifications): 102.5 us w.r.t Tsettle and 100 ns signal width

• Run 4663 - serves as nominal behavior benchmark
• Run 4677 - delay at 97.5 us (minus 5 us) - Pan worked, no helicity errors
• Run 4678 - swapped LNE with Tsettle (minus 102.5 us) - Pan worked, no helicity errors
• Run 4679 - delay at 92.5 us (minus 5 us) - Pan worked, no helicity errors
• Run 4680 - delay at 0.1 s (plus 100,000 us) - Pan worked, no helicity errors (the delay generator didn't even generate consistent timing, sometimes it was 0.1 s, other times it was 0.1 ms, and sometimes it stopped altogether)
  • So probably the SIS3801 Helicity information is not even used to calculate the helicity sequence information at all.
  • I do remember fixing the helicity sequence assumption in Caryn's control.db on 11/11/2018 (it had been octet and we changed it to quartet since that is what Hall B was using at the time), which may have been the actual Helicity error that had been noticed....?

Idiot Check

Is Pan reading Helicity information at all? I haven't gotten any errors so far.

• Run 4680 - completely unplug HEL+ from the VME crate
  • Helicity read errors
  • Therefore one copy of HEL+ is being read, but I have no idea which one it is (and it probably isn't the SIS3801 - see run 4666)

Results

• As seems to be the case most of the time I do tests, I now understand the DAQ less than I thought I did.
• The scaler information is not being parsed in a useful way by Pan
• The SIS3801 control HEL+ signal is probably not the one being used to determine Helicity sequence errors in Pan
• The timing doesn't seem to be as marginal as we thought it was (if my tests and Pan analyses of the data are to be trusted)

To Do

• Cameron needs to figure out how to read xcefdmp raw .dat files and find the scaler and control bit data without relying on Pan
• Cameron needs to start using JAPAN to decode the data, though the scalers may need to be added into this framework
• Cameron needs to utilize Bob's helicity sequence reading and predicting algorithm to parse through raw data and determine the relative timing of the different helicity sequence data (assuming the data is uncorrupted and issues above were just Pan decoding problems)