Project

General

Profile

Actions

Feature #1168

open

Generalize Detector Decode methods

Added by Ole Hansen about 13 hours ago. Updated about 10 hours ago.

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

12%

Estimated time:
(Total: 366.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 definitionsIn ProgressOle Hansen01/26/2026

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

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

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

Actions
Task #1185: Complete ChannelData classesNewOle Hansen12/01/2025

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

Actions
Feature #1178: Convert ChannelData structures to varsize event dataNewOle Hansen

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 improvementsNew

Actions
Feature #1171: Support global configuration strings in crate mapNewOle Hansen

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 FADC250ModuleNew

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

Actions
Actions #1

Updated by Ole Hansen about 11 hours ago

  • Estimated time deleted (120.00 h)
Actions

Also available in: Atom PDF