Data-reduction pipeline for the SiPM camera developed at TIFR, Mumbai.
The pipeline reads raw binary EVB files produced by the camera DAQ, extracts and validates event packets, applies DRS offset correction during waveform processing, and produces ctapipe-compatible DL1 HDF5 files containing reconstructed camera images and, for science runs, image parameters including Hillas and concentration parameters.
The pipeline also provides tools for:
- batch processing of multiple EVB files;
- diagnostic charge, arrival-time, waveform, and reference-pulse plots;
- interactive browsing of reconstructed DL1 events;
Primary developer: Shahjahan Iqbal
Project supervisor: Dr Atreyee Sinha , TIFR Mumbai
The initial implementation includes the pipeline architecture, EVB packet parsing, event registry construction, parallel event extraction, waveform processing, DRS offset correction, charge and arrival-time image generation, ctapipe-compatible DL1 output, Hillas parametrization, diagnostic tools, and event-display utilities.
- Installation
- Required Files
- Configuration File
- Analysis Procedure
- CLI Reference
- Project Structure
- Quality Flags
- Input Requirements, Assumptions, and Known Limitations
Run from the repository root:
bash setup.shThe script checks for an existing conda installation. If none is found it
downloads and installs Miniconda3 to ~/miniconda3. It then creates a conda
environment called scicam with Python 3.11, installs all dependencies, creates
the directory layout, and writes a skeleton config/config.yaml.
After it finishes:
conda activate scicamconda create -n scicam python=3.11 -y
conda activate scicam
pip install numpy h5py scipy matplotlib tqdm tifffile pyyaml click \
astropy ctapipe joblib pandas
mkdir -p config geometry log output OBS_INFO model_parameters plotsCreated automatically by setup.sh or by the pipeline on first run. Check out .Configuration File for a detailed description. You must
fill in the three path fields before processing any data:
camera_geometry:
name: SiPMCamera
pcm_count: 16
ddb_count: 4
channel_count: 9 # 4 LG + 4 HG + 1 reference per DDB
expected_packets_per_event: 64
readout:
roi_samples: 150
adc_bits: 14
channel_zero_dual_map: true
layout:
rows: 16
cols: 16
ordering: column-major
pixel_size_mm: 22.1
pixel_gap_mm: 0.05
data:
evbfilepath: /path/to/run.evb # or a .txt file listing multiple EVB paths
calib:
drsoffset: /path/to/drs_offset.txt
io:
output: output/For batch processing, set evbfilepath to a text file listing one EVB path per
line.
Downloaded separately from the calibration system. Not generated by this code.
Plain whitespace-delimited text array, shape (N_PCM × N_DDB × 1024, N_CH_PER_DDB + 1).
For the default layout: (65536, 10). The first column is the DRS capacitor index
(0–1023, repeated for each DDB). Columns 1–9 are per-channel offset values in mV.
DDB ordering is PCM-major.
Example excerpt:
0 0.312 -0.105 0.441 0.088 -0.230 0.317 -0.012 0.205 0.391
1 0.301 -0.110 0.437 0.091 -0.225 0.309 -0.008 0.198 0.384
Required for science runs (not needed with --no-dl2). Place one file per run
in OBS_INFO/. The filename must match the EVB stem with _processed removed
and a .json extension.
Required fields:
{
"Run_No": 419,
"File_Name": "s0534+2201_419_NOR_15012026_1_EVBdata",
"Source_Name": "CrabNebula_ON",
"Date_UTC": "15.01.2026",
"StartTime_UTC": "18:32:00",
"StopTime_UTC": "19:08:00",
"Duration(mins)": 36,
"RA (J2000)": "05h34m31.94s",
"DEC (J2000)": "+22d00m52.2s",
"RA (Precise)": "05:34:31.94",
"DEC (Precise)": "+22:00:52.2",
"MJD": 60690.77,
"Transit_Time": "19:45:00",
"Hour_Angle_Start": "-1.25",
"Hour_Angle_Stop": "+0.00",
"Zen_Angle_Start": "22.4",
"Zen_Angle_Stop": "05.1",
"Az_Angle_Start": "180.0",
"Az_Angle_Stop": "210.3",
"SQM_Start": "21.3",
"Trigger_Threshold_mV": 120,
"Trigger_Logic": "Majority",
"Total_Events": 150000,
"Average_Trigger_Rate(Hz)": "69.4"
}The pipeline configuration is stored in:
config/config.yaml
The configuration controls the camera/readout description, input EVB files, DRS calibration file, and output location.
A default configuration is created automatically by setup.sh and can also be generated by config_loader.py if the configuration file is missing or considered invalid.
The default configuration has four top-level sections:
camera_geometry:
...
data:
...
calib:
...
io:
...The camera_geometry, data, calib, and io sections are required. The configuration loader checks that these sections exist and that the required keys are present, but it does not perform complete type or physical-consistency validation.
This section describes the camera hardware and readout configuration used by the extraction and image-generation stages.
A typical configuration is:
camera_geometry:
name: SiPMCamera
pcm_count: 16
ddb_count: 4
channel_count: 9
expected_packets_per_event: 64
readout:
roi_samples: 150
adc_bits: 14
channel_zero_dual_map: true
layout:
rows: 16
cols: 16
ordering: column-major
pixel_size_mm: 22.1
pixel_gap_mm: 0.05name: SiPMCameraName of the camera configuration.
It is also used when constructing/loading the camera pixel-map file:
geometry/<camera_name>.h5
For the default configuration this is:
geometry/SiPMCamera.h5
pcm_count: 16Number of PCMs in the current camera configuration.
The global number of channels is calculated from:
PCM count × DDB count × channels per DDB
For the default configuration:
16 × 4 × 9 = 576 channels
The value must therefore match the actual hardware/readout structure of the EVB files being processed.
geometry.py reads this value directly from the configuration when constructing the channel mapping.
ddb_count: 4Number of DDBs associated with each PCM.
Together with pcm_count and channel_count, this determines the global channel numbering used by the extractor.
channel_count: 9Number of readout channels per DDB.
For the current camera this corresponds to:
4 LG channels
4 HG channels
1 reference channel
The value is used when translating the CDM/DDB/channel identifiers stored in the EVB packets into global channel indices.
The current extractor also contains a specific workaround for the readout convention in which channel 8 can be represented by channel ID 0.
Do not change this value unless the EVB packet structure and downstream channel mapping have also been changed.
expected_packets_per_event: 64Expected number of packets for one complete event in the current camera configuration.
This value documents the expected event structure, but the current registry implementation does not use it as an explicit validation condition.
The pipeline therefore does not currently reject an event simply because its packet count differs from this value.
For the current camera/readout configuration, however, a normal complete event has 64 packets.
This section describes the ADC readout.
roi_samples: 150Number of samples allocated for each channel in the extracted ADC HDF5 dataset.
This value is not universally fixed to 150.
The extractor reads the actual ROI associated with each channel from the EVB packet and writes the samples into an output array whose size is determined by roi_samples.
Therefore, the configured ROI must be large enough to accommodate the ROI reported by the input event data.
For example, both of the following are possible configurations:
roi_samples: 150and:
roi_samples: 1024provided that the corresponding EVB data and downstream processing are compatible with that configuration.
The DRS calibration uses a separate 1024-cell capacitor space. The event ROI should therefore not be confused with the DRS capacitor depth.
The ADC unpacking operates on pairs of samples. Odd ROI values should be avoided unless the corresponding behavior has been explicitly verified for the dataset being processed.
adc_bits: 14ADC resolution used by the current camera readout.
The current image-generation code assumes a 14-bit ADC and converts the raw ADC values to a 1000 mV full-scale representation.
This value should match the actual ADC encoding of the EVB data.
channel_zero_dual_map: trueConfiguration flag describing the channel-0/channel-8 mapping convention.
The current extractor contains a specific workaround for the case where physical channel 8 appears as channel ID 0 in the packet data.
This setting should therefore remain consistent with the camera's actual readout convention.
This section describes the camera pixel arrangement.
layout:
rows: 16
cols: 16
ordering: column-major
pixel_size_mm: 22.1
pixel_gap_mm: 0.05rows: 16
cols: 16Dimensions of the camera pixel map.
The current downstream geometry and DL1 implementation is built around the present 256-pixel camera configuration.
Although these values are stored in the configuration, parts of the geometry implementation explicitly construct a 16 × 16 map.
Changing the number of rows or columns therefore requires corresponding changes to the geometry/image/DL1 implementation.
ordering: column-majorThis field documents the intended pixel/readout ordering, but the current implementation does not read or use this configuration value when generating the pixel map. The current geometry implementation constructs the pixel map according to the existing PCM/DDB readout arrangement.
The actual channel-to-pixel mapping is hard-coded in geometry.py through the PCM/DDB traversal and pixel-index assignment. If the physical camera readout ordering changes, modifying this configuration value alone is insufficient. The pixel-map generation algorithm in geometry.py must also be updated and the resulting geometry file regenerated.
This field should therefore currently be regarded as descriptive metadata rather than an active configuration parameter.
pixel_size_mm: 22.1Nominal physical pixel size/spacing used by the camera geometry.
The current DL1 camera geometry also contains an explicit 22.1 mm pixel spacing assumption.
pixel_gap_mm: 0.05Pixel gap specified by the camera configuration.
It is part of the configuration describing the physical camera layout.
This section specifies the EVB input.
data:
evbfilepath: /path/to/run.evbThis may contain either:
- The path to a single EVB file, or
- The path to a
.txtfile containing one EVB path per line.
Example for a single run:
data:
evbfilepath: /data/run001.evbExample for batch processing:
data:
evbfilepath: /data/evt.txtThe wrapper also provides an --evb option for extract and process. When supplied, this path overrides the value in the loaded configuration for that execution.
Before processing, verify that:
- the EVB file exists;
- the path is correct;
- the file belongs to the expected camera/readout configuration;
- batch-list entries point to the intended files.
For a batch .txt file, missing entries are skipped while valid entries continue to process.
This section specifies the DRS calibration file.
calib:
drsoffset: /path/to/drs_offset.txtPath to the DRS offset calibration file.
The file is loaded with numpy.loadtxt() by the image-generation/DL1 stages. The calibration is applied using the DRS capacitor index with a 1024-cell cycle.
The DRS file must correspond to the camera/readout configuration being processed.
Before execution, verify:
- the file exists;
- the path is correct;
- the file is readable as whitespace-delimited numerical data;
- the calibration corresponds to the camera/readout configuration;
- the file contains the expected channel/capacitor offset information.
The configuration loader checks that this field is present and non-empty, but it does not verify the contents or numerical shape of the calibration file.
This section specifies where the intermediate extraction output is written.
io:
output: output/Directory used by the event extraction stage for intermediate HDF5 files and output_files.txt.
If the directory does not exist, the event processor creates it.
Make sure the location:
- exists or can be created;
- is writable;
- has sufficient free disk space.
The extracted HDF5 files can be large, particularly for large event counts or unusually large event IDs.
Before running:
python wrapper.py extractor:
python wrapper.py processcheck the following.
Confirm that all four sections exist:
camera_geometry
data
calib
io
and that the required fields are populated.
The loader checks these fields, but does not fully validate their types or physical consistency.
Check:
data:
evbfilepath: ...and make sure it points to the intended EVB file or batch list.
If using --evb, remember that the command-line value overrides the configuration value for that run.
Check:
calib:
drsoffset: ...Make sure the file exists and belongs to the appropriate camera/readout configuration.
Check:
camera_geometry:
readout:
roi_samples: ...against the ROI stored in the EVB data.
The configured value must be large enough for the channel ROI encountered in the input data.
Do not assume that all datasets use 150 samples.
Verify that:
pcm_count
ddb_count
channel_count
match the hardware/readout configuration that produced the EVB file.
Verify that the camera layout corresponds to the data being processed.
For the current production camera this means the expected 256-pixel, 16 × 16 geometry and its existing channel-to-pixel mapping.
For normal DL2/Hillas processing, verify that the corresponding JSON metadata exists in:
OBS_INFO/
or in the directory supplied with:
--json-dirThe filename must correspond to the processed run.
For calibration processing with:
--no-dl2the JSON file is not required.
The current code contains relative paths in several modules. The safest usage is to run the wrapper from the project Codes/ directory with the standard project directory structure intact.
For normal processing, event IDs should be:
positive
1-based
unique
contiguous
The pipeline does not currently enforce all of these conditions. Non-contiguous or duplicated IDs can therefore result in incorrect event mapping or data loss.
A typical configuration for the current camera is:
camera_geometry:
name: SiPMCamera
pcm_count: 16
ddb_count: 4
channel_count: 9
expected_packets_per_event: 64
readout:
roi_samples: 150
adc_bits: 14
channel_zero_dual_map: true
layout:
rows: 16
cols: 16
ordering: column-major
pixel_size_mm: 22.1
pixel_gap_mm: 0.05
data:
evbfilepath: /path/to/run.evb
calib:
drsoffset: /path/to/drs_offset.txt
io:
output: output/Only change the camera/readout parameters when processing data produced with a corresponding camera configuration and after verifying that the downstream geometry and image-generation code support the change.
Parses the raw EVB binary, validates packet integrity, and writes ADC waveforms to an intermediate HDF5 file.
python wrapper.py extract --config config/config.yaml
# with explicit EVB path and worker count
python wrapper.py extract --evb /data/run001.evb --workers 8Output: output/<run_stem>_processed.h5 and output/output_files.txt.
Intermediate HDF5 layout:
/events/event_id (N_events,) int32
/adc/roi_data (N_events, N_ch, ROI) int16
/adc/cstop (N_events, N_ch) int16
/adc/roi_cell (N_events, N_ch) int16
/adc/skip_cell (N_events, N_ch) int16
/adc/quality (N_events,) int16
Reads the intermediate HDF5 files, computes charge and arrival time images in parallel, and writes ctapipe-format DL1 HDF5 files. Run Hillas parametrization by default; skip it for calibration runs.
# Science run
python wrapper.py createH5 events_cta --json-dir OBS_INFO
# Calibration run (no Hillas)
python wrapper.py createH5 calib_out --no-dl2Chain both stages with a single command:
python wrapper.py process events_cta \
--config config/config.yaml \
--evb /data/run001.evb \
--workers 8 \
--json-dir OBS_INFOpython wrapper.py viewDl1 events_cta/run_cta_cont.h5Opens a matplotlib window with Next, Skip 10, and Exit buttons. Camera image on the left; Hillas parameter table on the right when parameters are present.
python wrapper.py saveImg output/run_processed.h5 plots/ \
--start 1 --end 100 --waveformBy default saves LG charge, HG charge, and arrival time images. Additional flags:
| Flag | Effect |
|---|---|
--no-lg |
Disable LG charge images |
--no-hg |
Disable HG charge images |
--no-time |
Disable arrival time images |
--waveform |
Save per-channel LG/HG waveform plots |
--refpulse |
Save reference channel diagnostic plots |
--cdist-lg |
Save LG charge distribution |
--cdist-hg |
Save HG charge distribution |
--tdist |
Save arrival time distribution |
Run without arguments to enter the interactive shell:
python wrapper.pyType help for available commands. Command history is stored in ~/.sipm_history.
Exit with exit, quit, or Ctrl-C.
python wrapper.py [OPTIONS] COMMAND [ARGS]...
Commands:
extract Extract events from EVB file(s) to intermediate HDF5.
createh5 Convert intermediate HDF5 to ctapipe DL1 format.
saveimg Save diagnostic images from an intermediate HDF5 file.
viewdl1 Browse DL1 events interactively.
process Run extract then createH5 in sequence.
Run python wrapper.py COMMAND --help for full option descriptions.
.
├── wrapper.py CLI entry point and REPL
├── event_proc_parallel.py Stage 1: EVB parsing and event extraction
├── registry_creator.py Packet boundary detection and event registry
├── data_extractor.py Per-event ADC waveform unpacking
├── create_h5.py Stage 2: ctapipe DL1 HDF5 writer
├── image_gen.py Charge/time computation and image generation
├── save_raw_img.py Diagnostic image saving from Stage 1 output
├── display_reco_events.py Interactive DL1 event browser
├── classifier.py Random Forest gamma/hadron classifier
├── geometry.py Camera pixel map and channel index utilities
├── config_loader.py YAML config loading and validation
├── h5_writer.py Legacy development script (not for production use)
├── config/
│ └── config.yaml Runtime configuration (edit before first run)
├── geometry/
│ └── SiPMCamera.h5 Auto-generated pixel map
├── OBS_INFO/ JSON run metadata files (one per EVB run)
├── output/ Intermediate HDF5 files and output_files.txt
├── log/ Rotating pipeline log files
├── model_parameters/ Pre-trained classifier model files (.joblib)
└── plots/ Diagnostic image output
Each extracted event carries an integer quality flag written to /adc/quality:
| Value | Meaning |
|---|---|
| 3 | All packets intact; no errors detected |
| 2 | Packet size mismatch between header field and observed length |
| 1 | Missing or duplicate end frames; structural packet error |
The pipeline is intended to process EVB files produced by the SiPM camera readout/acquisition system using the packet and channel structure expected by the current implementation.
The pipeline performs some structural checks while building the event registry, but it is not a general-purpose EVB validation framework. Successful execution therefore does not by itself guarantee that the input data are scientifically valid.
The event extraction stage expects the EVB file to be readable as a binary stream of 32-bit unsigned integers.
Packet boundaries are identified using the expected frame markers:
Start frame: 0xFBDA
End frame: 0xEDAC
The registry builder searches the EVB for these markers and uses the packet header information to determine packet boundaries and event IDs.
For each packet, the code compares:
- the packet size reported in the start frame,
- the packet size reported in the end frame, and
- the measured distance between the start and end frames.
A packet with inconsistent size information is assigned reduced quality and is not added to the event's packet list.
Event IDs are read directly from the EVB packet headers and are used as the indexing mechanism for the intermediate HDF5 file.
The extraction stage assumes event IDs are positive and 1-based because event ID N is written to HDF5 row N-1.
For example:
Event ID 1 → HDF5 row 0
Event ID 2 → HDF5 row 1
Event ID 3 → HDF5 row 2
Contiguous event numbering is therefore strongly preferred, although it is not explicitly validated by the pipeline.
Non-contiguous IDs can result in unused/zero-filled rows in the output HDF5. Large gaps in event numbering can also cause the HDF5 datasets to be considerably larger than the number of actual events.
Duplicate event IDs are merged into the same registry entry. The current registry implementation does not explicitly reject or warn about duplicate event IDs.
For reliable downstream processing, event IDs should therefore normally be:
- unique,
- positive,
- 1-based, and
- contiguous.
The registry assigns a quality value to each event based on packet-level structural checks:
| Quality | Meaning |
|---|---|
3 |
No packet-level structural error detected |
2 |
Packet-size inconsistency detected |
1 |
Missing or multiple end frames detected |
The quality value is propagated into the intermediate HDF5 file.
A quality value of 3 indicates that the packet structure passed the checks implemented by the registry. It should not be interpreted as a complete validation of the physical or scientific quality of the event.
The pipeline can therefore successfully produce output from an event that is structurally imperfect if enough information remains for extraction.
The default configuration describes the current SiPM camera readout:
PCM count: 16
DDBs per PCM: 4
Channels per DDB: 9
Global channels: 576
Camera pixels: 256
ADC resolution: 14 bit
The global channel count is calculated from the configuration:
N_GLOBAL_CH =
PCM count × DDB count × channels per DDB
The event extractor uses the configured channel structure to translate CDM/DDB/channel identifiers from the EVB packet into global channel indices.
The current implementation also contains a specific workaround for the readout convention in which channel 8 can appear with channel ID 0. This behavior is therefore part of the expected current packet format.
Changes to the hardware channel mapping, packet header format, channel numbering, or camera architecture may require corresponding changes to the extraction and geometry code.
The output ROI is read from:
camera_geometry:
readout:
roi_samples: ...and is used to determine the size of the extracted ADC dataset.
The actual ROI reported by each channel is read from the event packet itself:
ROI_Cell
The extractor then places the corresponding samples into the configured output ROI.
Consequently, different datasets may use different configured ROIs. For example, the pipeline can operate with a 150-sample configuration as well as a 1024-sample configuration, provided that the configuration and input event data are mutually compatible.
The important constraint is:
The configured output ROI must be large enough for the ROI reported by the input event data.
If an event contains a channel with ROI_Cell larger than the configured output ROI, the extracted data cannot fit into the allocated output array and processing can fail.
The ADC samples are unpacked two samples at a time from the packed 32-bit representation. Consequently, odd ROI lengths require caution because the current unpacking loop processes ROI_Cell // 2 sample pairs.
The event extraction stage maintains a file named:
output_files.txt
inside the configured intermediate output directory.
This file contains the paths of the extracted HDF5 files produced by the pipeline.
The file is opened in append mode during extraction:
open(..., "output_files.txt", "a")
to accommodate both single file and batch processing.
Therefore, running the extraction pipeline multiple times does not replace the existing list. New output HDF5 paths are appended to the existing file.
Stale entries from previous extraction runs can cause previously processed files to be processed again. Before repeated runs of the pipeline, ensure that stale entries are removed so that it contains only the intermediate HDF5 files intended for the current createh5 operation.
The DRS offset file is supplied externally through:
calib:
drsoffset: ...and is required by the waveform/image-generation stages.
The waveform calibration operates on the DRS capacitor index using a 1024-cell periodic index:
(ROI position + CStop) % 1024
The calibration file must be compatible with the camera/readout configuration and contain the required channel/capacitor offset information.
The current downstream image and DL1 stages are built around the present SiPM camera geometry.
The implemented camera contains:
16 × 16 pixels
256 pixels
22.1 mm nominal pixel spacing
square pixels
The pixel map is generated from the configured camera layout and is stored as an HDF5 PIXEL_MAP dataset.
Although some camera parameters are read from configuration, downstream code still contains explicit assumptions about the current 256-pixel camera architecture and its channel-to-pixel mapping.
Changing the physical camera layout, number of pixels, pixel ordering, or hardware-to-pixel mapping therefore requires corresponding changes to the geometry/image/DL1 code.
Observation JSON metadata are required when create_h5.py is run in normal observation/DL2 mode.
The corresponding JSON file is located using the processed HDF5 filename and the supplied --json-dir.
The metadata provide information such as:
- run number,
- source name,
- pointing coordinates,
- start/stop time,
- observation duration,
- observing mode,
- trigger information, and
- other observation-specific context.
These values are written into the ctapipe observation/scheduling containers and the output HDF5 context.
JSON metadata are not required for the raw EVB extraction stage.
They are also skipped when create_h5.py is run with:
--no-dl2
which is intended for calibration processing.
The image-generation stage converts the extracted ADC waveforms into calibrated charge and arrival-time images.
Several properties of the current readout are assumed by the implementation:
- 14-bit ADC values are converted using a 1000 mV full-scale.
- HG and LG channels are paired according to the current channel layout.
- The final channel in each DDB is treated as the reference channel.
- DRS offsets are selected according to the channel's DRS capacitor mapping.
- A reference-channel edge is used for the relative timing calculation.
- HG is used for the charge image unless saturation is detected, in which case the corresponding LG image is used.
For normal DL2 processing, Hillas parameters are calculated from the generated camera images.
The current implementation applies adaptive image cleaning based on the median absolute deviation (MAD) of the image:
picture threshold = 6 × MAD
boundary threshold = 1 × MAD
The brightest surviving island is selected, and at least three surviving pixels are required before Hillas parameters are calculated.
Events for which the cleaning produces no usable image are therefore not expected to produce valid Hillas parameters.
A structurally valid event can consequently reach the DL1 stage while still failing Hillas parametrization because its reconstructed image is unsuitable for the calculation.
The configured EVB path may refer either to:
- a single EVB file, or
- a text file containing paths to multiple EVB files.
Missing files in a batch list are skipped while other valid files continue to be processed.
If none of the listed files can be processed, the pipeline raises an error.
Several scripts load configuration, geometry, calibration files, or output directories using paths relative to the current working directory.
For example, parts of the image-generation, geometry, and DL1 code expect the standard project directory structure.
Running the pipeline from an unexpected working directory can therefore cause failures even when the EVB data themselves are valid.
The recommended approach is to run the pipeline using the project directory structure and the supplied wrapper/configuration.
For routine processing, an input dataset should therefore satisfy:
[ ] EVB file is readable as the expected 32-bit binary format
[ ] Expected start/end frame markers are present
[ ] Packet size information is internally consistent
[ ] Event IDs are positive and preferably contiguous/unique
[ ] Packet headers contain the fields expected by the extractor
[ ] Channel numbering matches the current camera readout
[ ] Configured ROI is compatible with the ROI stored in the event data
[ ] DRS calibration file is available and compatible
[ ] Camera geometry/pixel map matches the camera configuration
[ ] Observation JSON is available when running normal DL2 processing
[ ] Project directory structure and relative paths are preserved
Successful execution should not be interpreted as complete data validation.
The pipeline validates only the aspects of the input that are explicitly checked by the current implementation. Other problems, including physically invalid waveforms, unexpected event content, duplicate event IDs, missing packets that are not explicitly detected, or scientifically incorrect calibration/observation metadata may not necessarily cause the pipeline to stop.
The pipeline should therefore be regarded as a data reduction and reconstruction pipeline operating under the assumptions of the current SiPM camera readout, rather than as a comprehensive validator for arbitrary EVB files.
Changes to the DAQ/readout format, camera hardware, packet structure, event-numbering scheme, ROI convention, calibration format, or observation metadata convention should be reviewed against the relevant pipeline components before processing the new data.
- wrapper.py is the primary user-facing entry point.
- create_h5.py is the production DL1 writer.
- h5_writer.py is retained as a legacy development script and should not be used for routine processing.