Brad's comments on scalers » History » Version 3
Richard Trotta, 12/03/2020 12:26 PM
1 | 1 | Richard Trotta | h1. Brad Sawatzky's comments on scalers |
---|---|---|---|
2 | |||
3 | 3 | Richard Trotta | In general, the scaler trees for each arm expose the scaler data for modules associated with that arm (likely stating the obvious). However, a number of signals are fanned out to two scaler modules, one in each arm. If you're running in 'COIN mode' (single DAQ for both arms), then the counts for those duplicated signals should be (basically) identical. Strictly speaking, the content of the two scaler trees is entirely controlled by the analyzer software configuration (THcScaler* configs). |
4 | 1 | Richard Trotta | |
5 | 3 | Richard Trotta | Known reasons for discrepancies between the two scalers viewing the same signal could include: |
6 | 1 | Richard Trotta | |
7 | 3 | Richard Trotta | * There appears to be a problem with some of the "G0 scalers". Apparently, they have a bit-flip issue. "Steve documented this":https://hallcweb.jlab.org/DocDB/0010/001058/001/Scaler_Problem.pdf |
8 | |||
9 | * If the scaler channels you're seeing issues with are in the same physical modules, then that is almost certainly your problem. |
||
10 | ** Mitigations are discussed in that file as well. (Carlos should be familiar with this.) |
||
11 | 1 | Richard Trotta | |
12 | 3 | Richard Trotta | * Electronic artifacts and low-level timing differences in the gating between the two scalers |
13 | ** Should only be a difference of a few counts at most on high-rate channels |
||
14 | 1 | Richard Trotta | |
15 | |||
16 | 3 | Richard Trotta | You do need to be mindful that the HMS 'trigger scalers' may be different than the 'SHMS trigger scalers'. Each arm has a scaler that counts the 'T1, T2,...' trigger signals plugged into each arm's Trigger Master module. Those are not necessarily the same triggers, but the names can be confusing because each arm can have its own set of T1, T2, etc. The trigger assignments are documented in HCLog entries, and should also be reflected in the hcana scaler configuration git commits. |
17 | 1 | Richard Trotta | |
18 | 3 | Richard Trotta | If you're looking at Coincidence-mode runs, and you think you're looking at the same hardware signals in two different modules, then try plotting the difference between the two duplicate scaler channels for each scaler read (note scalers are read out periodically, not on every trigger). It would be interesting to see one duplicate is always reading X% more than the other, or if they are generally identical except form some occasional outliers. |
19 | 1 | Richard Trotta | |
20 | 3 | Richard Trotta | The scaler dbase/param files should shed a lot of insight into the hardware configuration (without having to get eyes on the physical setup). For direct duplications, we typically jumper an entire 16 channel ribbon cable across 2 scaler modules, so you'll see two 16 channel groups in the dbase files that have identical names in the same |
21 | 1 | Richard Trotta | order. |
22 | |||
23 | 3 | Richard Trotta | If you see a situation where an HMS scaler channel and an SHMS scaler channel have the same 'name' but they are not embedded in a block of 16 other identical channels, then you'll want to look a little more closely at the details to see if they are really individually fanned out copies of the same channel, or if it is a 'similar name' issue. |
24 | |||
25 | For example, one channel is the SHMS arm 'T3', and the other is the HMS arm 'T3'.(In that case it is possible they are looking at different input signals.) |