7.4 KiB
7.4 KiB
source_files, generated_at, model, schema_version, sha256
| source_files | generated_at | model | schema_version | sha256 | |
|---|---|---|---|---|---|
|
2026-04-16T03:42:48.006856+00:00 | Qwen/Qwen3-Coder-Next-FP8 | 1 | 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 enums 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 aDataTypeVersionValue. - Key Members:
ComputerGeneratedDataFormat0(0x00),ComputerGeneratedDataFormat1(0x01), ...,ComputerGeneratedDataFormat7(0x07)PCMDataFormat1(0x09) — Chapter 4 or 8TimeDataFormat1(0x11) — RCC/GPS/RTCMILSTD1553DataFormat1(0x19) — MIL-STD-1553BAnalogDataFormat1(0x21) — Analog DataDiscreteDataFormat1(0x29) — Discrete DataMessageDataFormat0(0x30) — Generic Message DataARINC429DataFormat0(0x38) — ARINC-429 DataVideoDataFormat0(0x40) — MPEG-2/H.264 VideoVideoDataFormat1(0x41) — ISO 13818-1 MPEG-2VideoDataFormat2(0x42) — ISO 14496 MPEG-4 Part10 110 AVC/H.264VideoDataFormat3(0x43) — MJPEG (version 0x07)VideoDataFormat4(0x44) — MJPEG 2000 (version 0x07)ImageDataFormat0(0x48) — Image DataImageDataFormat1(0x49) — Still ImageryImageDataFormat2(0x4A) — Dynamic ImageryUARTDataFormat0(0x50) — UART DataIEEE1394DataFormat0(0x58) — IEEE 1394 TransactionIEEE1394DataFormat1(0x59) — IEEE 1394 Physical LayerParallelDataFormat0(0x60) — Parallel DataEthernetDataFormat0(0x68) — Ethernet Data (version 0x07)EthernetDataFormat1(0x69) — Ethernet UDP PayloadTSPI_CTSDataFormat0(0x70) — GPS NMEA-RTCMTSPI_CTSDataFormat1(0x71) — EAG ACMITSPI_CTSDataFormat2(0x72) — ACTTSControllerAreaNetworkBus(0x78) — CAN BusFibreChannelDataFormat0(0x79) — Fibre Channel Data (version 0x07)
- Note: All formats follow a pattern:
XxxDataFormatN, whereN(0–7) allows for vendor-specific or variant definitions. OnlyFormat1variants (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 recorderExternal(0x01) — Time derived from a clock not in the recorderInternalFromRMM(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-BIRIGA(0x01) — IRIG-AIRIGG(0x02) — IRIG-GRTC(0x03) — Real-Time ClockUTC(0x04) — UTC Time from GPSGPS(0x05) — Native GPS TimeNone(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 formatIEEE1588(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
PacketHeaderValueis 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.DataTypeVersionValueis consistent perDataFileDataTypesmember: EveryDataFileDataTypesmember has exactly one[DataTypeVersionValue(byte)]attribute. Values observed are0x06(most common) and0x07(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
PacketHeaderValues are contiguous in blocks (e.g.,0x04–0x07,0x0A–0x0F, etc.), but their usage is undefined. - No overlapping
PacketHeaderValues across enums: While not enforced in code, the values are allocated per IRIG-106 spec to avoid ambiguity (e.g.,TimeSource.None = 0x0Fdoes not conflict withTimeFormats.None = 0x0Fbecause 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
PacketorStreamclasses in sibling namespaces (e.g.,DTS.Serialization.IRIGCH10.Packets).
5. Gotchas
- Typo in enum member name:
FibreChannelDataFormats1,FibreChannelDataFormats2, etc. (note the trailingsinFormats) — inconsistent with naming pattern (FibreChannelDataFormat0). Likely a typo; verify usage in deserialization logic. - Version inconsistency: Most
DataFileDataTypesuseDataTypeVersionValue(0x06), butComputerGeneratedDataFormat1,VideoDataFormat3,VideoDataFormat4,EthernetDataFormat0, and allFibreChannelDataFormats*use0x07. Ensure deserialization logic handles version-specific parsing. Nonevalues are context-sensitive:TimeSource.None(0x0F) andTimeFormats.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–0xFFare undefined). Consumers must handle unknown values gracefully. - Missing
Descriptionattributes: Some members (e.g.,MILSTD1553DataFormat0,AnalogDataFormat0) lack[Description], relying solely on naming. This may cause issues ifDescriptionis used for logging or UI.