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