P. Tagliamonte 15 April 2026 ARF Container Format arf Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Data Element Formats . . . . . . . . . . . . . . . . . . . . 3 3.1. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1.1. uint8 (byte) . . . . . . . . . . . . . . . . . . . . 3 3.1.2. uint16 . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.3. uint64 . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.4. float64 . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Byte Order . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Format . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Samples . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.4.1. interleaved float32 . . . . . . . . . . . . . . . . . 6 3.4.2. interleaved int8 . . . . . . . . . . . . . . . . . . 6 3.4.3. interleaved int16 . . . . . . . . . . . . . . . . . . 7 3.4.4. interleaved uint8 . . . . . . . . . . . . . . . . . . 8 3.4.5. interleaved float64 . . . . . . . . . . . . . . . . . 8 3.4.6. interleaved float16 . . . . . . . . . . . . . . . . . 9 3.5. UUID . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.6. Frequency . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Packet Syntax . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3.1. Critical . . . . . . . . . . . . . . . . . . . . . . 12 4.4. Length . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.5. Data . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Subpacket Types . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Header . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1.1. Magic . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1.3. Start Time . . . . . . . . . . . . . . . . . . . . . 14 5.1.4. Guid . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1.5. Site Id . . . . . . . . . . . . . . . . . . . . . . . 14 5.1.6. Num Streams . . . . . . . . . . . . . . . . . . . . . 14 5.1.7. Example Subpacket . . . . . . . . . . . . . . . . . . 15 5.2. Stream Header . . . . . . . . . . . . . . . . . . . . . . 15 5.2.1. Id . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.2.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . 16 Tagliamonte Informational [Page 1] ARF Container Format April 2026 5.2.3. Format . . . . . . . . . . . . . . . . . . . . . . . 16 5.2.4. Byte Order . . . . . . . . . . . . . . . . . . . . . 16 5.2.5. Rate . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2.6. Frequency . . . . . . . . . . . . . . . . . . . . . . 17 5.2.7. Guid . . . . . . . . . . . . . . . . . . . . . . . . 17 5.2.8. Site Id . . . . . . . . . . . . . . . . . . . . . . . 17 5.2.9. Example Subpacket . . . . . . . . . . . . . . . . . . 17 5.3. Samples . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.3.1. Id . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.3.2. Example Subpacket . . . . . . . . . . . . . . . . . . 18 5.4. Frequency Change . . . . . . . . . . . . . . . . . . . . 18 5.4.1. Id . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.4.2. Frequency . . . . . . . . . . . . . . . . . . . . . . 19 5.4.3. Example Subpacket . . . . . . . . . . . . . . . . . . 19 5.5. Timing . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.5.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 20 5.5.1.1. Clock Aligned . . . . . . . . . . . . . . . . . . 20 5.5.1.2. POSIX Aligned . . . . . . . . . . . . . . . . . . 20 5.5.2. Seconds . . . . . . . . . . . . . . . . . . . . . . . 20 5.5.3. Nanoseconds . . . . . . . . . . . . . . . . . . . . . 20 5.5.4. Example Subpacket . . . . . . . . . . . . . . . . . . 21 5.6. Discontinuity . . . . . . . . . . . . . . . . . . . . . . 21 5.6.1. Id . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.6.2. Example Subpacket . . . . . . . . . . . . . . . . . . 21 5.7. Location . . . . . . . . . . . . . . . . . . . . . . . . 21 5.7.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . 22 5.7.2. Geodetic System . . . . . . . . . . . . . . . . . . . 22 5.7.3. Latitude, Longitude, Elevation . . . . . . . . . . . 23 5.7.4. Accuracy . . . . . . . . . . . . . . . . . . . . . . 23 5.7.5. Example Subpacket . . . . . . . . . . . . . . . . . . 23 5.8. Vendor Extension . . . . . . . . . . . . . . . . . . . . 23 5.8.1. Extension Id . . . . . . . . . . . . . . . . . . . . 24 5.8.2. Example Subpacket . . . . . . . . . . . . . . . . . . 24 6. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.1. Empty Packet . . . . . . . . . . . . . . . . . . . . . . 24 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 8.1. Normative References . . . . . . . . . . . . . . . . . . 24 8.2. Informative References . . . . . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction This document is maintained in order to publish all information needed to develop interoperable implementations capable of correctly parsing and producing data in the ARF capture format. This spec does not get into how to demodulate any RF protocol specifically. Tagliamonte Informational [Page 2] ARF Container Format April 2026 ARF (short for Archive of RF) provides a standard container format to transport IQ (in-phase and quadriture complex number) streams containing RF (radio frequency) data from SDRs (Software Defined Radios). The ARF format contains facilities for single, multiple, coherent or non-coherent streams of RF information, as well as associated metadata such as physical location, tuned frequencies, or demodulated information. This document specifies the container format used in ARF, along with a baseline of well known subpacket types. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Background There are very few standards for how complex numbers (IQ streams) produced by Software Defined Radios (SDRs) are to be stored and communicated. The SigMF [SIGMF] project comes close, but has some constraints for use as a streaming protocol, and not an offline capture or interoperability format. The RFCAP [RFCAP] project solves the streaming problem, but contains a single fixed header for exactly 1 IQ stream, and no coherent metadata. Most software writes the IQ data to disk or over the network directly, relying on out of band metadata to communicate frequencies of operation, sample rates, and IQ number format. ARF solves these problems in a way that is designed to be as generic as practical (but no more), as simple as possible (but no more) and flexible for implementations to use as both a storage and wire protocol. 3. Data Element Formats This section defines commonly used datatypes used within packet headers, and the subpackets defined in this document. 3.1. Numbers All numbers contained within defined subpackets in this spec are encoded big-endian (network byte order) unless otherwise indicated. 3.1.1. uint8 (byte) (1 octet) Tagliamonte Informational [Page 3] ARF Container Format April 2026 A single 8-bit byte (octet)! Nothing to exotic here. This is treated as an unsigned 8 bit integer which ranges from 0 to 255 (0x00 to 0xFF). 3.1.2. uint16 (2 octets) A single unsigned 16-bit big-endian number. Values range from 0 to 65535 (0x0000 to 0xFFFF). 3.1.3. uint64 (8 octets) A single unsigned 64-bit big-endian number. 3.1.4. float64 (8 octets) A single 64-bit big-endian IEEE 754 floating point number, as defined by IEEE 754 [IEEE.754]. 3.2. Byte Order (byte) This field represents a specific byte order -- endianness -- of a data stream. If the IQ Format is a single octet, such as is the case with int8 (Section 3.4.2) or uint8 (Section 3.4.4) samples, any related Byte Order field MUST be set to 0x00 ("Not Applicable") as defined in the Byte Order Registry shown in Table 1. For any other format types, the related Byte Order field MUST be set according to the correct non-zero encoded data endianness value. The following byte orders are defined: Tagliamonte Informational [Page 4] ARF Container Format April 2026 +======+===============================+ | ID | Description | +======+===============================+ | 0x00 | Not Applicable (octet stream) | +------+-------------------------------+ | 0x01 | Little Endian | +------+-------------------------------+ | 0x02 | Big Endian | +------+-------------------------------+ Table 1: Byte Order Registry 3.3. Format (byte) This field represents a specific sample format type for IQ samples. The Endianness of the IQ samples denoted by this format are communicated alongside the Format field, through an associated Byte Order field. The following formats are defined: +======+===========================================+================+ | ID | Description | Reference | +======+===========================================+================+ | 0x01 | Interleaved 32 bit floating point numbers | Section | | | | 3.4.1. | +------+-------------------------------------------+----------------+ | 0x02 | Interleaved signed 8 bit integers | Section | | | | 3.4.2. | +------+-------------------------------------------+----------------+ | 0x03 | Interleaved signed 16 bit integers | Section | | | | 3.4.3. | +------+-------------------------------------------+----------------+ | 0x04 | Interleaved unsigned 8 bit integers | Section | | | | 3.4.4. | +------+-------------------------------------------+----------------+ | 0x05 | Interleaved 64 bit floating point numbers | Section | | | | 3.4.5. | +------+-------------------------------------------+----------------+ | 0x06 | Interleaved 16 bit floating point numbers | Section | | | | 3.4.6. | +------+-------------------------------------------+----------------+ Table 2: Format Registry Tagliamonte Informational [Page 5] ARF Container Format April 2026 3.4. Samples IQ samples are precisely timed readings of energy over time. IQ samples are complex numbers, which may be represented in one of the defined formats. Encoding implementations MUST NOT produce Samples bytes which are not aligned to the underlying complex number type, and decoding implementations MUST NOT accept any Samples packet which contains a number of bytes not aligned to the underlying complex number type. 3.4.1. interleaved float32 (16 octets) IQ samples that are being processed by software are commonly processed as an interleaved pair of 32 bit floating point numbers, or a 64 bit complex number. The first float32 is the real value, and the second is the imaginary value. The complex number 1+1i is represented as 1.0 1.0 and the complex number -1-1i is represented as -1.0 -1.0. +========+================+ | Number | Representation | +========+================+ | 1+1i | 1.0, 1.0 | +--------+----------------+ | -1+1i | -1.0, 1.0 | +--------+----------------+ | -1-1i | -1.0, -1.0 | +--------+----------------+ | 0+0i | 0.0, 0.0 | +--------+----------------+ Table 3: Examples 3.4.2. interleaved int8 (2 octets) Some hardware encodes RF data as a stream of interleaved signed 8 bit integers (int8 or i8). The first sample is the real (in-phase or I) value, and the second is the imaginary (quadrature or Q) value. Together each pair of values makes up a complex number at a specific time instant. Tagliamonte Informational [Page 6] ARF Container Format April 2026 Formats that use signed integers do have one quirk due to two’s complement, which is that the smallest negative number representable’s absolute value is one more than the largest positive number. int8 values can range between -128 to 127, which means there’s bit of ambiguity in how +1, 0 and -1 are represented. Either you can create perfectly symmetric ranges of values between +1 and -1, but 0 is not representable, have more possible values in the negative range, or allow values above (or just below) the maximum in the range to be allowed. Within ARF, the approach that MAY be taken is to scale based on the max integer value of the type, so the lowest possible signed value is actually slightly smaller than -1. Generally, if your code is seeing values that low the difference in step between -1 and slightly less than -1 isn’t very significant, even with only 8 bits. +========+================+ | Number | Representation | +========+================+ | 1+1i | 127, 127 | +--------+----------------+ | -1+1i | -128, 127 | +--------+----------------+ | -1-1i | -128, -128 | +--------+----------------+ | 0+0i | 0, 0 | +--------+----------------+ Table 4: Examples 3.4.3. interleaved int16 (4 octets) Some hardware encodes RF data as a stream of interleaved signed 16 bit integers (int16 or i16). The first sample is the real (in-phase or I) value, and the second is the imaginary (quadrature or Q) value. Together each pair of values makes up a complex number at a specific time instant. Almost no SDRs capture at a 16 bit depth natively, often you’ll see 12 bit integers being sent around as 16 bit integers. As a result, all IQ samples SHOULD be MSB aligned. Tagliamonte Informational [Page 7] ARF Container Format April 2026 +========+================+ | Number | Representation | +========+================+ | 1+1i | 32767, 32767 | +--------+----------------+ | -1+1i | -32768, 32767 | +--------+----------------+ | -1-1i | -32768, -32768 | +--------+----------------+ | 0+0i | 0, 0 | +--------+----------------+ Table 5: Examples 3.4.4. interleaved uint8 (2 octets) Some (very popular!) hardware encodes RF data as a stream of interleaved unsigned 8 bit integers (uint8 or u8). The first sample is the real (in-phase or I) value, and the second is the imaginary (quadrature or Q) value. Together each pair of values makes up a complex number at a specific time instant. The complex number 1+1i is represented as 0xFF 0xFF and the complex number -1-1i is represented as 0x00 0x00. The complex number 0+0i is not easily representable – since half of 0xFF is 127.5. +========+==========================+ | Number | Representation | +========+==========================+ | 1+1i | 0xFF, 0xFF | +--------+--------------------------+ | -1+1i | 0x00, 0xFF | +--------+--------------------------+ | -1-1i | 0x00, 0x00 | +--------+--------------------------+ | 0+0i | 0x80, 0x80 OR 0x7F, 0x7F | +--------+--------------------------+ Table 6: Examples 3.4.5. interleaved float64 (32 octets) Tagliamonte Informational [Page 8] ARF Container Format April 2026 IQ samples that are being processed by software are uncommonly processed as an interleaved pair of 64 bit floating point numbers, or a 128 bit complex number. The first float64 is the real value, and the second is the imaginary value. The complex number 1+1i is represented as 1.0 1.0 and the complex number -1-1i is represented as -1.0 -1.0. +========+================+ | Number | Representation | +========+================+ | 1+1i | 1.0, 1.0 | +--------+----------------+ | -1+1i | -1.0, 1.0 | +--------+----------------+ | -1-1i | -1.0, -1.0 | +--------+----------------+ | 0+0i | 0.0, 0.0 | +--------+----------------+ Table 7: Examples 3.4.6. interleaved float16 (4 octets) Some targets are capable of processing 16 bit floating point numbers natively, making this an attractive input and output format for a large stretch of the tradespace of size vs precision. This format is not well supported, so some care must be taken when creating or processing files in this format. A single 16-bit big-endian IEEE 754 floating point number, as defined by IEEE 754 [IEEE.754]. This is also sometimes known as "1S5E10M" - 1 sign bit, 5 exponent bits, and 10 bits for the mantissa. The complex number 1+1i is represented as 1.0 1.0 and the complex number -1-1i is represented as -1.0 -1.0. Tagliamonte Informational [Page 9] ARF Container Format April 2026 +========+================+ | Number | Representation | +========+================+ | 1+1i | 1.0, 1.0 | +--------+----------------+ | -1+1i | -1.0, 1.0 | +--------+----------------+ | -1-1i | -1.0, -1.0 | +--------+----------------+ | 0+0i | 0.0, 0.0 | +--------+----------------+ Table 8: Examples 3.5. UUID (16 octets) This field represents a globally unique idenfifer, as defined by RFC 9562 [RFC9562], as raw bytes, not as an ASCII string. If no UUID is set, known or indicated, the "empty" UUID SHOULD be used, which is 16 octets of 0x00, written in the conventional syntax as 00000000-0000-0000-0000-000000000000. The empty UUID MUST NOT be treated as globally unique, if used. 3.6. Frequency (8 octets, 64 bit unsigned integer, big endian) Data encoded in a Frequency field is stored as microhz (1 Hz is stored as 1000000, 2 Hz is stored as 2000000). This was done to avoid issues with floating point precision for the range of tunable frequencies As a result, this has a minimum value of 0 Hz, and a maximum value of 18446744073709551615 uHz, or just above 18.4 THz. In practice, some implementations may have internal factors to consider, such as using a floating point number to represent frequency, using a signed integer to express negative values or a smaller frequency range which may impact what frequencies and frequency resolutions may be produced or properly decoded. 4. Packet Syntax This section describes the structure of the packet format used by ARF. Tagliamonte Informational [Page 10] ARF Container Format April 2026 4.1. Structure At a high level, an ARF file or stream is comprised of a series of ARF packets. Each packet is comprised of the following: Packet: Tag byte Flags byte Length uint16 ... Data (bytes) 4.2. Tag (uint8 Section 3.1.1) Unknown tags SHOULD be ignored by implementers, unless the packet is marked with a CRITICAL flag (as defined in Section 4.3.1), in which case processing of the stream MUST stop, and an error condition indicated. The following tags are defined: +======+==================+=============+ | ID | Description | Reference | +======+==================+=============+ | 0x01 | Header | Section 5.1 | +------+------------------+-------------+ | 0x02 | Stream Header | Section 5.2 | +------+------------------+-------------+ | 0x03 | Samples | Section 5.3 | +------+------------------+-------------+ | 0x04 | Frequency Change | Section 5.4 | +------+------------------+-------------+ | 0x05 | Timing | Section 5.5 | +------+------------------+-------------+ | 0x06 | Discontinuity | Section 5.6 | +------+------------------+-------------+ | 0x07 | Location | Section 5.7 | +------+------------------+-------------+ | 0xFE | Vendor Extension | Section 5.8 | +------+------------------+-------------+ Table 9: Packet Tag Registry 4.3. Flags (uint8 Section 3.1.1) Tagliamonte Informational [Page 11] ARF Container Format April 2026 Flags indicate that a packet MUST be understood in a special way. If the Critical flag is not set, flags which are not defined in this spec MUST be ignored and MUST NOT be used. If the Critical flag is set, subpacket flags which are set but defined in this spec MUST result in processing to stop. The following flags are defined: +====+=============+===============+ | ID | Description | Reference | +====+=============+===============+ | 1 | Critical | Section 4.3.1 | +----+-------------+---------------+ Table 10: Packet Flags Registry 4.3.1. Critical When this flag is set on a packet, implementations MUST understand the subpacket, or further processing of the ARF stream MUST stop. This allows future revisions of the ARF format to indicate backwards incompatible changes in such a way that data will not be incorrectly interpreted. 4.4. Length (uint16 Section 3.1.2) This fields specifies the exact length, in bytes, of data to follow the ARF packet header. 4.5. Data Any remaining bytes inside the Packet beyond the fixed-length header do not have a singular meaning, rather, their meaning is dependent on the value of the packet's Tag (as defined in Section 4.2). If a tag is not understood by an implementer, it MUST NOT ascribe any meaning to the Data inside a packet. 5. Subpacket Types This section defines a set of well-known subpacket types used by ARF, and SHOULD to be implemented by interoperable implementations. Any subpackets which MUST be understood will be clearly noted in this document, and will require the Critical flag to be set on the encapsulating packet. Tagliamonte Informational [Page 12] ARF Container Format April 2026 Unless otherwise indicated, subpackets may become larger in future revisions of the ARF specification. However, no subpacket will ever shrink in size in future revisions. This means implementations MAY rely on subpacket size to shortcut processing invalid packets without inspecting content without risk of breakage. 5.1. Header (57 octets) Header Magic uint64 Flags uint64 Start Time uint64 Guid UUID Site Id UUID Num Streams uint8 ARF Header subpackets MUST be sent before any other ARF packets in the stream, at the very beginning of an ARF stream. This contains the core metadata required of an ARF stream, and is required for all implementations to understand and validate. Packets containing this subpacket MUST set the critical packet flag, as defined in Section 4.3.1. 5.1.1. Magic (uint64 Section 3.1.3) The magic field is used to indicate that the data to follow is actually an ARF stream. The magic value is an uint64 value, and defined as 0x000000FADEDCAB1E. 5.1.2. Flags (uint64 Section 3.1.3) Flags indicate that this subpacket MUST be understood in a special way. Flags which are not defined in this spec MUST be ignored and MUST NOT be used. The following flags are defined: Tagliamonte Informational [Page 13] ARF Container Format April 2026 +====+=============+===========+ | ID | Description | Reference | +====+=============+===========+ +----+-------------+-----------+ Table 11: Packet Flags Registry 5.1.3. Start Time (uint64 Section 3.1.3) Number of nanoseconds since the UNIX Epoch. 5.1.4. Guid (UUID Section 3.5) Globally unique UUID, usually a UUID4. When an ARF stream has the same guid it means the stream was the same -- even if the ARF streams do not hash identically (for instance, if they start at different times, end at different times, or contain a superset or subset of the IQ streams). The format of the GUID is a UUID as defined in Section 3.5. 5.1.5. Site Id (UUID Section 3.5) Indicate the place where the capture has taken place. These are also assumed to be globally unique for a specific location (and a location MAY have multiple UUIDs), coordinated by the capture creator. The format of the GUID is a UUID as defined in Section 3.5. The specific meaning of this identifier is up to the producer of the capture. This field may be helpful to find all captures taken at a specific site or set of sites, for example. 5.1.6. Num Streams (uint8 Section 3.1.1) Indicate the number of streams contained in this stream. This MUST match the number of Stream Headers (as defined in Section 5.2) following the Header. If the number of Stream Headers does not match this number implementations MUST indicate an error condition and refuse to further process the ARF stream. Tagliamonte Informational [Page 14] ARF Container Format April 2026 The specific meaning of this identifier is up to the producer of the capture. This field may be helpful to find all captures taken at a specific site or set of sites, for example. 5.1.7. Example Subpacket 00, 00, 00, fa, de, dc, ab, 1e, // magic 00, 00, 00, 00, 00, 00, 00, 00, // flags 18, 27, a6, c0, b5, 3b, 06, 07, // start time (1740543127) // guid (fb47f2f0-957f-4545-94b3-75bc4018dd4b) fb, 47, f2, f0, 95, 7f, 45, 45, 94, b3, 75, bc, 40, 18, dd, 4b, // site_id (ba07c5ce-352b-4b20-a8ac-782628e805ca) ba, 07, c5, ce, 35, 2b, 4b, 20, a8, ac, 78, 26, 28, e8, 05, ca 5.2. Stream Header (60 octets) StreamHeader Id uint8 Flags uint64 Format Format Byte Order Byte Order Rate Frequency Frequency Frequency Guid UUID Site Id UUID A Stream Header MUST only be encoded into a stream immediately follow either a Header packet (as defined in Section 5.1) or another Stream Header. The Stream Header indicates an IQ stream will follow with the provided description under the defined identifier later on in the ARF stream. Defining the same ID multiple times MUST NOT be permitted. If the same ID is encountered in multiple StreamHeaders, implementers MUST indicate an error condition and refuse to further process the ARF stream. 5.2.1. Id (uint8 Section 3.1.1) Tagliamonte Informational [Page 15] ARF Container Format April 2026 Stream-unique identifier for a stream of RF data to follow. This identifier MUST NOT be reused within the stream, and refers to a single stream of continuous RF data. This usually represents a single channel of an SDR's IQ data. This stream is continuous unless otherwise indicated by using a Discontinuity packet, as defined in Section 5.6. 5.2.2. Flags (uint64 Section 3.1.3) Flags indicate that this subpacket MUST be understood in a special way. Flags which are not defined in this spec MUST be ignored and MUST NOT be used. The following flags are defined: +====+=============+===========+ | ID | Description | Reference | +====+=============+===========+ +----+-------------+-----------+ Table 12: Packet Flags Registry 5.2.3. Format (Format Section 3.3) This field represents a specific sample format type for IQ samples. The format of the Format field is a Format type, as defined in Section 3.3. 5.2.4. Byte Order (Byte Order Section 3.2) This field represents a specific sample byte order for IQ samples, as defined in Section 3.2. 5.2.5. Rate (Frequency Section 3.6) Number of samples per second in the related IQ stream. The format of the Rate field is a Frequency, as defined in Section 3.6. Tagliamonte Informational [Page 16] ARF Container Format April 2026 5.2.6. Frequency (Frequency Section 3.6) Center frequency of the related IQ stream. The format of the Rate field is a Frequency, as defined in Section 3.6. 5.2.7. Guid (UUID Section 3.5) Globally unique ID. The format of the GUID is a UUID as defined in Section 3.5. When an ARF stream has the same guid it means the stream was the same -- even if the ARF streams do not hash identically (for instance, if they start at different times, or end at different times). 5.2.8. Site Id (UUID Section 3.5) Indicate the place where the capture has taken place. The format of the GUID is a UUID as defined in Section 3.5. These MUST be globally unique for a specific location (and a location MAY have multiple UUIDs), coordinated by the capture creator. The specific meaning of this identifier is up to the producer of the capture. This field may be helpful to find all captures taken at a specific site or set of sites, for example. 5.2.9. Example Subpacket 00, 01, // id (1) 00, 00, 00, 00, 00, 00, 00, 00, // flags 01, // format (float32) 01, // byte order 00, 00, 01, d1, a9, 4a, 20, 00, // rate (2 MHz) 00, 00, 5a, f3, 10, 7a, 40, 00, // frequency (100 MHz) // guid (7b98019d-694e-417a-8f18-167e2052be4d) 7b, 98, 01, 9d, 69, 4e, 41, 7a, 8f, 18, 16, 7e, 20, 52, be, 4d, // site_id (98c98dc7-c3c6-47fe-bc05-05fb37b2e0db) 98, c9, 8d, c7, c3, c6, 47, fe, bc, 05, 05, fb, 37, b2, e0, db, Tagliamonte Informational [Page 17] ARF Container Format April 2026 5.3. Samples (1 octet header, followed by iq data) Samples Id uint8 ... IQ samples (bytes) Samples carry a block of IQ data. Implementations MUST NOT encode Samples for an ID that it has not previously encoded a Stream Header for. If a Samples packet is decoded from an ARF stream that has no previously defined Samples Header, processing of the stream MUST stop, and an error condition indicated. The Samples header is exactly 1 octet in length, and will never grow nor shrink. IQ samples inside a single Sample packet MUST be continuous and free of discontinuities. The format of the IQ data provided in this packet is defined in the Stream Header with the same Id value as this packet's Id value, as defined in Section 5.2. The Stream Header will define the sample format (Section 3.3), and the byte order (Section 3.2), as defined in the Sample Header's Format and ByteOrder fields. If a Samples packet is encoded in the ARF stream that has no previously defined Samples Header, processing of the stream MUST stop, and an error condition indicated. 5.3.1. Id (uint8 Section 3.1.1) Identifier, as defined in the related Stream Header (Section 5.2) of the RF stream that the provided IQ samples belong to. 5.3.2. Example Subpacket 01, // id ab, cd, ab, cd, // iq samples 5.4. Frequency Change (10 octets) FrequencyChange Id uint8 Frequency Frequency Tagliamonte Informational [Page 18] ARF Container Format April 2026 This indicates that the center frequency of the IQ stream has changed since the last frequency change or stream header. 5.4.1. Id (uint8 Section 3.1.1) Identifier, as defined in the related Stream Header (Section 5.2) of the RF stream that has changed in center frequency. 5.4.2. Frequency (Frequency Section 3.6) New center frequency of the related IQ stream. The format of the Frequency field is a Frequency, as defined in Section 3.6. 5.4.3. Example Subpacket 01, // id 00, 00, b5, e6, 20, f4, 80, 00 // frequency (200 MHz) 5.5. Timing (24 octets) Timing Flags uint64 Seconds uint64 Nanoseconds uint64 A timing subpacket establishes timing information that must be normalized within the same stream. The seconds and nanoseconds do not need to be UNIX Epoch time (or similar) -- it may use any starting time, so long as that single time is the same for all the streams in the ARF stream. Additionally, the seconds value is only required to be aligned to global time if the CLOCK_ALIGNED (Section 5.5.1) flag is set -- otherwise a value of 0 nanoseconds may not mean it begins at the top of the second. This means a time aligning the IQ stream to globally coordinated time MUST NOT be created from the timing packet unless both POSIX Aligned AND Clock Aligned flags are set. Tagliamonte Informational [Page 19] ARF Container Format April 2026 Even if the the sample rate(s) are different for stream(s) in the capture stream, they must all be in sync at the point in which the `TIMING` information is inserted, and must be timed with reference to the same starting epoch. 5.5.1. Flags (uint64 Section 3.1.3) The following flags are defined: +====+===============+==================+ | ID | Description | Reference | +====+===============+==================+ | 1 | Clock Aligned | Section 5.5.1.1. | +----+---------------+------------------+ | 2 | POSIX Aligned | Section 5.5.1.2. | +----+---------------+------------------+ Table 13: Timing Flags Registry 5.5.1.1. Clock Aligned 0 nanoseconds is globally aligned with the exact globally coordinated wallclock second start, using a 1PPS trigger from something like a GPSDO or other high accuracy clock in sync with UTC. 5.5.1.2. POSIX Aligned If set, seconds is the number of seconds since the UNIX Epoch, (00:00:00 UTC on 1 January 1970). If this is flag is not set, the number of seconds is relative to an arbitrary start time, with no further meaning ascribed. 5.5.2. Seconds (uint64 Section 3.1.3) Number of seconds since a stable, coherent reference point. This MUST NOT be interpreted to be seconds since the UNIX Epoch (00:00:00 UTC on 1 January 1970), unless the POSIX Aligned flag (as defined in Section 5.5.1.2 ) is set. 5.5.3. Nanoseconds (uint64 Section 3.1.3) Tagliamonte Informational [Page 20] ARF Container Format April 2026 Number of nanoseconds since the beginning of the second, in reference to a stable, coherent reference point. A value of 0 MUST NOT be interpreted to be the globally coordinated 0 second mark unless the Clock Aligned flag (as defined in Section 5.5.1.1 ) is set. 5.5.4. Example Subpacket 00, 00, 00, 00, 00, 00, 00, 01, // flags 00, 00, 00, 00, 00, 00, 01, 00, // seconds 00, 00, 00, 00, 00, 01, 00, 00, // nanoseconds 5.6. Discontinuity (2 octets) Discontinuity Id uint8 This subpacket indicates that the stream is no longer coherent -- a break in IQ samples happened between the last samples and the next block of samples for some particular stream. This must be sent every time there's a discontinuity in the stream -- it's otherwise assumed to be coherent. 5.6.1. Id (uint8 Section 3.1.1) Identifier, as defined in the related Stream Header (Section 5.2) of the RF stream that has dropped samples between the last Samples subpacket (as defined in Section 5.2) and the next one. 5.6.2. Example Subpacket 01, // id 5.7. Location (41 octets) Tagliamonte Informational [Page 21] ARF Container Format April 2026 Location Flags uint64 System GeodeticSystem Latitude float64 Longitude float64 Elevation float64 Accuracy float64 This subpacket indicates the physical location where the signal has been collected at. This must be aligned with the rest of the arf payloads. latitude and longitude are in degrees. elevation and accuracy are in meters. system is as defined in Section 5.7.2. 5.7.1. Flags (8 octets, 64 bit unsigned integer) The following flags are defined: +====+=============+===========+ | ID | Description | Reference | +====+=============+===========+ +----+-------------+-----------+ Table 14: Location Flags Registry 5.7.2. Geodetic System (1 octet) The following geodetic systems are defined: +====+=============+==============================================+ | ID | Description | Reference | +====+=============+==============================================+ | 1 | WGS84 | Indicate that the Latitude, Longitude and | | | | Elevation fields are all based off the WGS84 | | | | ellipsoid as defined by WGS84 [WGS84]. | +----+-------------+----------------------------------------------+ Table 15: Geodetic System Registry Tagliamonte Informational [Page 22] ARF Container Format April 2026 5.7.3. Latitude, Longitude, Elevation (float64 Section 3.1.4) The geodetic latitude of a point is the angle formed between the vector perpendicular (or normal) to the ellipsoidal surface from the point, and the plane of the equator, representing the north-south position on the ellipsoid. The geodetic longitude of a point is the angle between the equatorial plane and the normal from the ground at that location, representing the east-west position on the ellipsoid. Elevation is the height, in meters, above the surface of the ellipsoid. This is (critically) not the same as the altitude above the surface of the earth, but rather, is always in reference to the ellipsoid -- which may, in some cases, be above or below the true surface of Earth. 5.7.4. Accuracy (float64 Section 3.1.4) Sensible estimate of the maximum amount of error, in meters, possible in the reading. This error may be in any or all of the dimensions. If this value is set to 0, the accuracy is unknown. 5.7.5. Example Subpacket 00, 00, 00, 00, 00, 00, 00, 00, // flags 01, // system (wgs84) 3f, f3, be, 76, c8, b4, 39, 58, // latitude (1.234) 40, 02, c2, 8f, 5c, 28, f5, c3, // longitude (2.345) 40, 59, 00, 00, 00, 00, 00, 00, // elevation (100) 40, 24, 00, 00, 00, 00, 00, 00 // accuracy (10) 5.8. Vendor Extension (16 octets header, followed by extension-specific data) VendorExtension Extension Id UUID ... data (bytes) This subpacket indicates a custom vendor specific extension to ARF. This subpacket only has a single fixed-length header, containing the extension's UUID. This header is exactly 32 bytes and will never grow nor shrink. Tagliamonte Informational [Page 23] ARF Container Format April 2026 All data beyond the header inside the Packet is data specific to the provided extension_id. Implementations MUST NOT ascribe any meaning to the data following this header unless the header is fully understood. 5.8.1. Extension Id (UUID Section 3.5) The format of the Extension ID is a UUID as defined in Section 3.5. 5.8.2. Example Subpacket // extension id (b24305f6-ff73-4b7a-ae99-7a6b37a5d5cd) b2, 43, 05, f6, ff, 73, 4b, 7a, ae, 99, 7a, 6b, 37, a5, d5, cd, // data (0x01, 0x02, 0x03, 0x04, 0x05) 01, 02, 03, 04, 05 6. MIME Type The MIME content-type that SHOULD be used is application/x.arf 7. Examples This section contains example test vectors with defined meanings 7.1. Empty Packet 00, // tag (0; invalid) 00, // flags (0) 00, 00 // length (0) 8. References 8.1. Normative References [IEEE.754] "Standard for Floating-Point Arithmetic". [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Tagliamonte Informational [Page 24] ARF Container Format April 2026 [RFC9562] "Universally Unique IDentifiers (UUIDs)", DOI 10.17487/RFC9562, . [WGS84] "World Geodetic System WGS84". 8.2. Informative References [RFCAP] Tagliamonte, P., "Overview of the RFCAP format 📸", April 2020, . [SIGMF] "SigMF Specification", . Author's Address Paul Tagliamonte Washington, DC United States of America Email: paul@k3xec.com Tagliamonte Informational [Page 25]