---
source_files:
  - Common/DTS.Common.Serialization/IRIGCH10/Enums/Enums.cs
generated_at: "2026-04-16T03:42:48.006856+00:00"
model: "Qwen/Qwen3-Coder-Next-FP8"
schema_version: 1
sha256: "cc430983f5236d17"
---

# Documentation: `DTS.Serialization.IRIGCH10.Enums` Namespace

## 1. Purpose  
This module defines a set of strongly-typed enumerations used to represent standardized IRIG-106 Chapter 10 data types, time sources, time formats, and related metadata as specified in the IRIG-106 standard. These enums serve as the semantic foundation for parsing and serializing IRIG-106-compliant binary data files, mapping raw packet header values (e.g., data type codes, checksum types, time formats) to human-readable and type-safe enum members. They are used internally by serialization/deserialization logic to interpret and construct IRIG-106 packets correctly.

## 2. Public Interface  
All types are `public enum`s in the `DTS.Serialization.IRIGCH10.Enums` namespace. No classes, interfaces, or methods are exposed.

### `DataFileDataTypes`
- **Description**: Enumerates all defined IRIG-106 Chapter 10 data format types (e.g., PCM, MIL-STD-1553, Video, Ethernet), identified by a `PacketHeaderValue` (1-byte code) and a `DataTypeVersionValue`.
- **Key Members**:
  - `ComputerGeneratedDataFormat0` (0x00), `ComputerGeneratedDataFormat1` (0x01), ..., `ComputerGeneratedDataFormat7` (0x07)
  - `PCMDataFormat1` (0x09) — *Chapter 4 or 8*
  - `TimeDataFormat1` (0x11) — *RCC/GPS/RTC*
  - `MILSTD1553DataFormat1` (0x19) — *MIL-STD-1553B*
  - `AnalogDataFormat1` (0x21) — *Analog Data*
  - `DiscreteDataFormat1` (0x29) — *Discrete Data*
  - `MessageDataFormat0` (0x30) — *Generic Message Data*
  - `ARINC429DataFormat0` (0x38) — *ARINC-429 Data*
  - `VideoDataFormat0` (0x40) — *MPEG-2/H.264 Video*
  - `VideoDataFormat1` (0x41) — *ISO 13818-1 MPEG-2*
  - `VideoDataFormat2` (0x42) — *ISO 14496 MPEG-4 Part10 110 AVC/H.264*
  - `VideoDataFormat3` (0x43) — *MJPEG* (version 0x07)
  - `VideoDataFormat4` (0x44) — *MJPEG 2000* (version 0x07)
  - `ImageDataFormat0` (0x48) — *Image Data*
  - `ImageDataFormat1` (0x49) — *Still Imagery*
  - `ImageDataFormat2` (0x4A) — *Dynamic Imagery*
  - `UARTDataFormat0` (0x50) — *UART Data*
  - `IEEE1394DataFormat0` (0x58) — *IEEE 1394 Transaction*
  - `IEEE1394DataFormat1` (0x59) — *IEEE 1394 Physical Layer*
  - `ParallelDataFormat0` (0x60) — *Parallel Data*
  - `EthernetDataFormat0` (0x68) — *Ethernet Data* (version 0x07)
  - `EthernetDataFormat1` (0x69) — *Ethernet UDP Payload*
  - `TSPI_CTSDataFormat0` (0x70) — *GPS NMEA-RTCM*
  - `TSPI_CTSDataFormat1` (0x71) — *EAG ACMI*
  - `TSPI_CTSDataFormat2` (0x72) — *ACTTS*
  - `ControllerAreaNetworkBus` (0x78) — *CAN Bus*
  - `FibreChannelDataFormat0` (0x79) — *Fibre Channel Data* (version 0x07)
- **Note**: All formats follow a pattern: `XxxDataFormatN`, where `N` (0–7) allows for vendor-specific or variant definitions. Only `Format1` variants (e.g., `AnalogDataFormat1`) are standardized; others are reserved.

### `TimeSource`
- **Description**: Specifies the origin of time metadata in a packet.
- **Members**:
  - `Internal` (0x00) — *Time derived from a clock in the recorder*
  - `External` (0x01) — *Time derived from a clock not in the recorder*
  - `InternalFromRMM` (0x02) — *Internal from RMM (Time derived from the clock in the RMM)*
  - `None` (0x0F) — *No time source*

### `TimeFormats`
- **Description**: Specifies the encoding format of time data (e.g., IRIG-B, UTC, GPS).
- **Members**:
  - `IRIGB` (0x00) — *IRIG-B*
  - `IRIGA` (0x01) — *IRIG-A*
  - `IRIGG` (0x02) — *IRIG-G*
  - `RTC` (0x03) — *Real-Time Clock*
  - `UTC` (0x04) — *UTC Time from GPS*
  - `GPS` (0x05) — *Native GPS Time*
  - `None` (0x0F) — *No time format*

### `DataTypeVersion`
- **Description**: Represents the version of the IRIG-106 standard used for the data type definition.
- **Members**:
  - `InitialRelease` (0x01) — *Initial Release (IRIG-106-04)*
  - `TG78` (0x02) — *TG-78 (IRIG-106-05)*
  - `IRIG106_07` (0x03) — *IRIG-106-07*

### `SecondaryHeaderTimeFormat`
- **Description**: Indicates the binary format of time in the secondary header (if present).
- **Members**:
  - `IRIG106Chapter4` (0x00) — *IRIG 106 Chapter 4 binary weighted 48-bit time format*
  - `IEEE1588` (0x01) — *IEEE-1588 Time format*

### `DataCheckSumType`
- **Description**: Specifies the checksum algorithm used for packet integrity.
- **Members**:
  - `None` (0x00)
  - `EightBit` (0x01)
  - `SixteenBit` (0x02)
  - `ThirtyTwoBit` (0x03)

## 3. Invariants  
- **`PacketHeaderValue` is unique per enum member**: Each enum value is annotated with `[PacketHeaderValue(byte)]`, and no two members share the same value. This ensures unambiguous mapping between raw bytes and enum members.
- **`DataTypeVersionValue` is consistent per `DataFileDataTypes` member**: Every `DataFileDataTypes` member has exactly one `[DataTypeVersionValue(byte)]` attribute. Values observed are `0x06` (most common) and `0x07` (e.g., `ComputerGeneratedDataFormat1`, `VideoDataFormat3`, `VideoDataFormat4`, `EthernetDataFormat0`, `FibreChannelDataFormat0`).
- **Reserved formats are strictly reserved**: All enum members with descriptions containing “Reserved for future use” must not be interpreted as active data types. Their `PacketHeaderValue`s are contiguous in blocks (e.g., `0x04`–`0x07`, `0x0A`–`0x0F`, etc.), but their usage is undefined.
- **No overlapping `PacketHeaderValue`s across enums**: While not enforced in code, the values are allocated per IRIG-106 spec to avoid ambiguity (e.g., `TimeSource.None = 0x0F` does not conflict with `TimeFormats.None = 0x0F` because they apply to different contexts).

## 4. Dependencies  
- **Internal dependencies**:
  - `DTS.Serialization.IRIGCh10.Attributes` — Custom attributes `[PacketHeaderValue]`, `[DataTypeVersionValue]`, and `[Description]` are defined here (not shown, but referenced).
- **External dependencies**:
  - `System.ComponentModel` — Used for `[Description]` attribute.
- **Consumers** (inferred from naming and structure):
  - Serialization/deserialization logic for IRIG-106 Chapter 10 files (e.g., packet header parsers, metadata extractors).
  - Likely used in `Packet` or `Stream` classes in sibling namespaces (e.g., `DTS.Serialization.IRIGCH10.Packets`).

## 5. Gotchas  
- **Typo in enum member name**: `FibreChannelDataFormats1`, `FibreChannelDataFormats2`, etc. (note the trailing `s` in `Formats`) — inconsistent with naming pattern (`FibreChannelDataFormat0`). Likely a typo; verify usage in deserialization logic.
- **Version inconsistency**: Most `DataFileDataTypes` use `DataTypeVersionValue(0x06)`, but `ComputerGeneratedDataFormat1`, `VideoDataFormat3`, `VideoDataFormat4`, `EthernetDataFormat0`, and all `FibreChannelDataFormats*` use `0x07`. Ensure deserialization logic handles version-specific parsing.
- **`None` values are context-sensitive**: `TimeSource.None` (0x0F) and `TimeFormats.None` (0x0F) are distinct and valid in their respective contexts (e.g., absence of time metadata), but must not be confused.
- **No validation of reserved ranges**: The enum does not prevent invalid or future-use values (e.g., `0x80`–`0xFF` are undefined). Consumers must handle unknown values gracefully.
- **Missing `Description` attributes**: Some members (e.g., `MILSTD1553DataFormat0`, `AnalogDataFormat0`) lack `[Description]`, relying solely on naming. This may cause issues if `Description` is used for logging or UI.