hd_dump does not show Df125Config values

[nsjarvis]

This is what I see for "hd_dump /cache/halld/RunPeriod-2025-01/rawdata/Run131288/hd_rawdata_131288_000.evio -DDf125Config" :

21:21:45.068  [info] Df125Config:
21:21:45.068  [info]  rocid: slot_mask:   NSA:   NSB: NSA_NSB: NPED: WINWIDTH:    PL:  NW:   NPK:    P1: P2:    PG:  IE:     H:    TH:    TL: IBIT: ABIT: PBIT:
21:21:45.068  [info] ------------------------------------------------------------------------------------------------------------------------------------------
21:21:45.068  [info]     25   0x03e7f8  65535  65535    65535    17     65535  65535  200  65535  65535   4  65535  200  65535  65535  65535     4     3     0 
21:21:45.068  [info]     26   0x01e7f8  65535  65535    65535    17     65535  65535  200  65535  65535   4  65535  200  65535  65535  65535     4     3     0 

It looks like some quantities are being decoded properly but most are not. NSA to WINWIDTH are legacy values (I don't care about these). The other 65535s are incorrect.

I hope that slot_mask would be the slot number.
I would mostly like to be able to see H, TH and TL.

The Df125Config library code is here

[nsjarvis]

Beni told me that this is not the fault of hd_dump, it is because we did not provide the descriptions of the new firmware quantities when we updated the library aeons ago.
I suppose I can probably fix this one myself.

[nsjarvis]

Hm, apparently hd_dump does show the Df125Config values, but most of these are not filled. Using hd_root, the list below shows the contents of two Df125Configs from run 132984, the first is for a CDC pulse, the next is for the FDC:

NW 200 
NPK 65535 
P1 65535 
P2 4 
PG 65535 
IE 200 
H 65535 
TH 65535 
TL 65535 
IBIT 4 
ABIT 3 
PBIT 0 

 
NW 80 
NPK 65535 
P1 65535 
P2 4 
PG 65535 
IE 16 
H 65535 
TH 65535 
TL 65535 
IBIT 4 
ABIT 0 
PBIT 0 

The only way (afaik) to access these fadc config parameters from the datastream is via the Df125BORConfig, example linked here

[nsjarvis]

I did not understand how the Df125Config could find P2 but not NPK, etc. @faustus123 cleared up this mystery for me. Here is the explanation:

"The Df125config bank is filled from EVIO banks that are populated with values that came from the configuration files used by CODA at runtime. Those values are written to some global variables and then a selection of them is copied into the EVIO bank. Because this was written out for every block of 40 events, it can become quite a lot of data that is, if everything works correctly, just duplicates throughout the file. This is why it was set up to only write out a few of the values. You can see the code where this happens here:

https://halldsvn.jlab.org/repos/trunk/online/daq/vme/src/rol_1/conf_output.c

The BOR config. info is handled differently. First, wherever possible, it reads the values back from the actual hardware modules so represents actual settings as opposed to the desired settings. It is also written just once at the beginning of the EVIO file and halld_recon keeps that same bank around and just issues a pointer to it to every event. Thus, it takes up nearly no space in the EVIO file. That’s why we didn’t worry about reading everything into it."

I would be tempted to remove from Df125Config the values that are not being filled. NPED=17 would have been for the firmware used before 2015. In the new firmware, H is channel-specific, so that would not be useful. I think we should revisit this after the run.