Multi‑Capture Operation Overview

When you initiate a multi-capture session (e.g., Multi‑RxMER or Multi‑DS‑Channel‑Estimation), PyPNM maintains a lightweight file‑based tracking system and stages resulting PNM binaries for downstream workflows.

Directory Layout:

data/
├── db/
│   ├── operation_capture.json      # Maps operations to capture groups
│   ├── capture_group.json          # Records capture groups
│   └── transactions.json           # Lists each staged file transaction
└── pnm/
    └── <.bin files>                # Raw PNM captures retrieved via TFTP

1. Operation Database (operation_capture.json)

Records each background operation and its connection to a capture group.

Example:

{
  "f6afb2d7df2c4a5c": {
    "capture_group": "10b6ea239641487c",
    "created": 1748280293
  }
}

• Key: operation_id (e.g., f6afb2d7df2c4a5c).
• capture_group: Associated capture_group_id.
• created: Unix timestamp when the operation started.

2. Capture Group Database (capture_group.json)

Tracks each high‑level invocation as a distinct capture group.

Example:

{
  "10b6ea239641487c": {
    "created": 1748280293,
    "transactions": [
      "2ee6138bbc1b3c3d",
      "65c04a28d0add931",
      "df4d2b3e3146ef30",
      "6773c9ebc097a579"
    ]
  }
}

• Key: capture_group_id (e.g., 10b6ea239641487c).
• created: Unix timestamp when the group was created.
• transactions: List of associated transaction_ids (one per file).

3. Transactions Manifest (transactions.json)

A detailed manifest of every PNM file moved into data/pnm/ during the capture.

Example:

{
  "2ee6138bbc1b3c3d": {
      "timestamp": 1748280294,
      "mac_address": "aa:bb:cc:dd:ee:ff",
      "pnm_test_type": "DS_OFDM_RXMER_PER_SUBCAR",
      "filename": "ds_ofdm_rxmer_per_subcar_aabbccddeeff_34_1748280294.bin.zst",
      "compression": {
          "is_compressed": true,
          "codec": "zstd",
          "level": 3,
          "size_before": 38427,
          "size_after": 21135
      },
      "device_details": {
          "system_description": {
              "HW_REV": "1.0",
              "VENDOR": "LANCity",
              "BOOTR": "NONE",
              "SW_REV": "1.0.0",
              "MODEL": "LCPET-3"
          }
      }
  }
}

• Key: transaction_id (e.g., 2ee6138bbc1b3c3d).
• timestamp: Unix epoch when the file was staged.
• mac_address: Sanitized MAC of the target modem.
• pnm_test_type: Identifier of the PNM capture type.
• filename: Physical filename in data/pnm/ (includes .zst or .gz when used).
• compression: Compression metadata when stored in compressed form.
• device_details.system_description: Snapshot of modem metadata at capture time.

Workflow Summary

1. Start Multi‑Capture: System generates a new operation_id linked to a new capture_group_id.
2. Periodic Triggers: SNMP instructs the modem to TFTP-upload the PNM blob.
3. File Staging: PyPNM stores each artifact in data/pnm/ (raw or compressed) and appends a JSON entry.
4. Database Updates: Timestamps and transaction lists are updated in both operation_capture.json and capture_group.json.
5. Completion: After the capture ends, the three JSON tables fully describe what was captured, when, and for which operation/group.

Downstream tools can monitor transactions.json as a manifest to automatically discover and process new PNM files—no manual polling required.

1. Start Multi‑Capture: System generates a new operation_id linked to a new capture_group_id.
2. Periodic Triggers: SNMP instructs the modem to TFTP-upload the PNM blob.
3. File Staging: PyPNM copies each .bin into data/pnm/ and appends a JSON entry.
4. Database Updates: Timestamps and transaction lists are updated in both operation_capture.json and capture_group.json.
5. Completion: After the capture ends, the three JSON tables fully describe what was captured, when, and for which operation/group.

Downstream tools can monitor transactions.json as a manifest to automatically discover and process new PNM files—no manual polling required.