Project

General

Profile

Actions

Task #1168

open

Generalize Detector Decode methods

Added by Ole Hansen 21 days ago. Updated 4 days ago.

Status:
In Progress
Priority:
Normal
Assignee:
Target version:
Start date:
12/01/2025
Due date:
03/31/2026 (Due in 29 days)
% Done:

26%

Estimated time:
(Total: 382.00 h)
Spent time:
(Total: 44.00 h)
Responsible:
Ole Hansen

Description

Podd 1.7 currently has separate classes for detectors with FADC readouts and with legacy Fastbus modules. We should try to merge these separate classes into one by generalizing the detector Decode methods. This has already been started by implementing a generic Decode method in THaDetectorBase, but we still rely on different hardcoded setups of "DetectorData" objects in ReadDatabase of the detector classes. ("Fadc..." detectors create FADCData objects, while the corresponding legacy detectors instantiate PMTData or ADCData objects.) Ideally, the information about which "DetectorData" child class to use should come from the crate map, which is the authoritative source for the configuration of the frontend modules.

The current FADC decoding in Podd is quite limited. Lacking are
  • multi-hit decoding
  • waveform retrieval
  • waveform analysis
  • reference times (extensively used by hcana)

Furthermore, Podd currently stores raw detector hit data in fixed-size arrays, whose size is that of the number of detector "elements" (paddles, mirrors, shower blocks, etc.) This was fine when detectors had a small number of elements, but it clearly wastes space with high channel counts. More importantly, it is also not really possible to accommodate multiple hits per channel with such arrays. We need to switch to parallel, variable-size arrays recording channel number and channel data, as it is done in SBS-offline.

At the same time, the design of the "detector map" of the detector classes should be revisited. The current design is too inflexible; it assumes a single type of frontend module for a given detector. It even duplicates the module number which is already present in the crate map. What if detector map and crate map disagree on the model number? I propose a "v2" detector map for the detector databases, with key "detector_map" instead of "detmap". THaDetMap should always retrieve the model number as well as other module information (module type, TDC resolution, etc.) from the crate map.

I'll add subtasks here to track the different aspects of this rather big job.


Subtasks 20 (20 open0 closed)

Feature #1175: Support key prefix in database reader and global variable definitionsResolvedOle Hansen01/26/2026

Actions
Task #1184: v1.8 updates to THaDetMapNewOle Hansen

Actions
Feature #1169: Improved database format for detector mapsNewOle Hansen

Actions
Feature #1170: Eliminate hardcoded model list in THaDetMapNewOle Hansen

Actions
Task #1185: Complete ChannelData classesIn ProgressOle Hansen12/01/2025

Actions
Feature #1174: Database readers for ChannelDataIn ProgressOle Hansen12/01/2025

Actions
Feature #1178: Convert ChannelData structures to varsize event dataIn ProgressOle Hansen02/11/2026

Actions
Task #1179: Collect list of all database keys and global variables used by SBS codeIn ProgressOle Hansen02/02/2026

Actions
Feature #1180: Export global variables from ChannelData classesNewOle Hansen

Actions
Feature #1181: Implement Waveform ChannelDataNewOle Hansen

Actions
Task #1186: Update Detector classesNewOle Hansen

Actions
Feature #1182: Instantiate ChannelData based on detector map infoNewOle Hansen

Actions
Feature #1183: Move detector map initialization to THaDetectorBaseNewOle Hansen

Actions
Task #1187: v1.8 Decoder improvementsIn Progress02/11/2026

Actions
Feature #1171: Support global configuration strings in crate mapResolvedOle Hansen02/25/2026

Actions
Feature #1172: Support additional configuration string parameters in decoder modulesNewOle Hansen

Actions
Feature #1173: Extend/review decoder module APINewOle Hansen

Actions
Feature #1176: Standalone waveform analyzerNewSayak Chatterjee

Actions
Feature #1177: Support firmware v3 in FADC250ModuleIn ProgressLasitha Lankabhara Mudalige02/11/2026

Actions
Task #1188: Test, document, and deployNew03/31/2026

Actions
Actions #1

Updated by Ole Hansen 21 days ago

  • Estimated time deleted (120.00 h)
Actions #2

Updated by Ole Hansen 14 days ago

  • Tracker changed from Feature to Task
Actions

Also available in: Atom PDF