OSF Format Description

General description of the OSF format

Valid for format versions 4 and 5 -

The Open Streaming Format (OSF) is a binary, block-oriented data format for the continuous recording of time-related measurement and process data. It is designed to be optimally suited not only for streaming on embedded systems with limited resources, but also for efficient block-by-block processing of large amounts of data on powerful analysis platforms – whether on servers, PCs, or in post-processing directly on embedded devices.

Basic principles

Time as the central axis: All data is stored with unique time information—equidistant with a fixed time grid or individually with timestamps.
Streaming capability: Data can be continuously written to the file during ongoing measurement without prior knowledge of the total amount.
Robustness: Even in the event of a power failure or unexpected shutdown, all data stored up to the last written block remains readable.
Open structure: Combination of a clear meta block (XML for OSF4, JSON for OSF5) and a simple, binary data stream.
Block-by-block storage: Instead of writing individual values sequentially, data blocks are used. This reduces write operations and enables fast loading of large amounts of data.
Flexibility: Support for various data types – from simple scalars to vectors and matrices to binary data such as images or audio files.
Metadata: Each channel can be described with names, physical units, dimensions, and optional additional information.

Basic structure of an OSF file

Regardless of whether it is version 4 or version 5, every OSF file follows the same basic structure:

OSF Dateistruktur.

Magic Header
- Format identifier (OSF4, OSF5, OCEAN_STREAMING_FORMAT4)
- Specification of the length of the following meta block
Metablock (XML or JSON)
- Contains information about channels, data types, physical units, and context data
- Defines the structure of the subsequent data blocks
Binary data blocks
- Contain the actual measured values in streaming format
- Support equidistant and time-stamped data
- Can contain single values, vectors, matrices, or binary data
Optional closing block
- Optional XML trailer with statistics and channel overview for OSF4
- This trailer is omitted by default in OSF5

Data organization

Channels: Each data stream is described as a channel containing the name, data type, physical unit, and optional additional attributes.
Time base: All time stamps are stored in nanoseconds since epoch, enabling high-precision synchronization.
Block header: Each data block begins with a channel index and a length specification, so that the stream remains interpretable even in the case of unknown channels or interruptions.
Control byte: Defines the type and structure of the following data block (e.g., start, continuation, timestamp type). In OSF5, the use of this byte is simplified but remains functionally compatible.

Magic header

Every OSF file begins with what is known as a magic header. It serves two purposes:

Unique identification as an OSF file.
Indication of the length of the following meta block so that it can be read and parsed directly.

Structure

The Magic Header is an ASCII line terminated with a line feed (\n).

Example OSF4:

OSF4 173762\n

OSF4 is the format identifier.
173762 specifies the length of the meta block in bytes.

Example OSF5:

OSF5 84512\n

OSF5 indicates the new version.
84512 The number indicates the length of the meta block, which is JSON by default in OSF5.

Supported identifiers

For compatibility reasons, OSF implementations recognize several headers:

OSF4 – classic OSF4 file
OCEAN_STREAM_FORMAT4 – historical identifier for OSF4 files
OSF5 – OSF5 file

Recognition of the Metablock format

Whether the following metablock is XML or JSON is determined by the first character after the header:

< → XML (OSF4 format)
{ → JSON (OSF5 format)
Other character → Error

Advantages

Fast start: Readers can extract the metablock immediately and pass it to the correct parser.
Streaming capable: No knowledge of the total file size is required.
Backward compatible: OSF5 processes OSF4 files (including OCEAN_STREAM_FORMAT4).
Easy implementation: One line is enough to determine the version and parser.

Here is the general text for the metablock for OSF4 and OSF5, without specifics on XML/JSON and without vector/matrix parameters:

Metablock – Channels and metadata

The metablock follows directly after the magic header in every OSF file. It contains all the information needed to correctly interpret the subsequent data blocks. This includes:

File parameters: Context information about the file and its creation.
Channel definitions: Describe each data stream with its name, data type, and physical properties.
Metadata: Additional information that is not directly linked to a channel (e.g., system status, comments, calibration data).

The meta block forms the "table of contents" of the file and is designed to be unique, machine-readable, and easy to expand.

File parameters (in the metablock)

created_utc – Time of file creation in UTC in ISO 8601 format
creator – optional Identification of the creator (e.g., device serial number, program name, UUID)
created_at_longitude / created_at_latitude / created_at_altitude – optional Geographical position where the file was created
reason – optional Reason for file creation (e.g., BOOT, SEQUENCE, TRIGGERED)
total_seq_no – obsolete Absolute sequence number since system startup (starting at 0)
triggered_seq_no – obsolete Relative sequence number since the last trigger event (starting at 0)
namespacesep – optional Separator for hierarchical channel names (default ".")
tag – optional Free tag for classifying the file (e.g., preview)
comment – optional Optional comment text

Channel definitions (channel)

Each channel describes a data stream within the file. The parameters are described below

Identification and organization

index Unique channel index within the file (starting at 0).
name Channel name, optionally with hierarchical path (e.g., Motor/Temperature).
reference Optional unique reference or UUID for identifying the data source.

Time base

timeincrement Fixed time increment in nanoseconds for equidistant channels. Value = 0 or not set → Channel uses individual timestamps.

Data types and structure

datatype Data type of the stored values (e.g., bool, int32, double, string, candata, gpsdata). → A complete description of all data types and their encoding can be found in the chapter Data Types.
channeltype Structural type of the channel:
- scalar – Single values over time
- binary – Any binary blocks (e.g., images) (Vector and matrix are described in a separate document) → A detailed explanation of channel types can be found in the chapter Channel Types.
sizeoflengthvalue Size of the length specification for each data block:
- 2 → 2 bytes (uint16, max. block size ~64 kB)
- 4 → 4 bytes (uint32, max. block size ~4 GB) Used to determine the block size and read data blocks correctly in the stream. → A detailed explanation can be found in the chapter sizeoflengthvalue.
mimetype Optional, MIME type for binary channels (e.g., image/jpeg, audio/wav).
spectrumtype Optional, type of spectral data:
- amplitude (default)
- realImag
- ampPhaseRad
- ampPhaseDeg

Physical properties

physicalunit Optional, physical unit (SI-compliant, e.g., V, °C).
physicalunit1 New in OSF5 Optional, physical unit for the second data set in multi-component data types such as pair or triple (SI-compliant, e.g., V, °C).
physicalunit2 New in OSF5 Optional, physical unit for the third data set in multi-component data types such as pair or triple (SI-compliant, e.g., V, °C).
physicaldimension Optional, description of the physical dimension (temperature, pressure, ...).
scale Optional, scaling factor for integer data types → conversion to physical values.
offset Optional, offset for integer data types → zero point shift in physical values.

Display and additional information

displayname Optional display name for visualization or GUI.
comment Optional comment on the channel.

Metadata (info)

Metadata supplements the file with additional information that is not tied to a channel. Typical parameters:

name – Name of the information
value – Value (as string or typed)
datatype – Type of the value (string, int32, float, bytearray, etc.)
physicalunit – Optional, physical unit of the value

Metadata can be freely defined and is suitable for:

System or device data
Comments and status messages
Calibration values
User-defined additional information

Advantages of the structure

Clear separation of data and description: The metablock defines how data is interpreted without containing any measured values itself.
Self-descriptive: Files can be read and interpreted without external definitions.
Extensible: New channels, data types, or meta information can be added without changing the basic format.
Robust: Fixed indexes and length specifications ensure that the file remains interpretable even if not all channels are known.

Core parameters of the channel description

The following parameters define the basic structure of a channel in OSF and determine how data is stored and interpreted in streaming format. They are relevant for all channels and form the foundation of the channel description.

Data types (datatype)

The datatype parameter specifies the data format of the values of a channel. Each value is stored in a precisely defined binary format.

Supported data types and encoding:

Data type	Size (bytes)	Description
`bool`	1	True/False (0 = false, 1 = true)
`int8`	1	Signed integer
`int16`	2	Signed integer
`int32`	4	Signed integer
`int64`	8	Signed integer
`float`	4	IEEE 754 single precision
`double`	8	IEEE 754 double precision
`string`	variable	UTF-8 encoded, length defined by block size
`binary`	variable	Any byte sequence; the maximum length of the block is determined by the channel's `sizeoflengthvalue` field; for image, audio, or other binary data with MIME type
`candata`	16	Structure for CAN frames (see below)
`gpsdata`	24	Structure for GPS positions (see below)
`pair`	16	`New in OSF5` A data type for two related double values in one unit. Ideal for X/Y value pairs such as force/distance, voltage/current, or complex numbers (real/imaginary). (see below)
`triple`	24	`New in OSF5` A data type for three related double values in one unit. Typical for 3D sensor data such as acceleration, gyroscope, or magnetic field measurements. (see below)

Structure `candata`

struct can_frame {
    uint32 can_id;   // 32-bit CAN ID + flags
    uint8  can_dlc;  // Length of payload (0..8 bytes)
    uint8  data[8];  // CAN user data
} __attribute__((aligned(8)));

Structure `gpsdata`

struct gps_location {
    double longitude;  // Longitude
    double latitude;   // Latitude
    double altitude;   // Altitude
};

`New in OSF5` Structure `pair`

// 2-component values
struct pairdouble {
    double v1;   // X or real
    double v2;   // Y or imaginary
};

`New in OSF5` Structure `triple`

// 3-component values
struct tripledouble {
    double v1;   // X 
    double v2;   // Y 
    double v3;   // Z 
};

Note: For channels with datatype="binary", it is recommended to define the MIME type (mimetype) in the channel (e.g., image/jpeg, audio/wav) in order to be able to interpret the data unambiguously. The maximum block size is determined by the channel's sizeoflengthvalue parameter.

Channel types (channeltype)

The channeltype parameter defines the logical organization of the values of a channel. It specifies how many values are stored per data block and the structure of these values.

OSF recognizes three basic channel types:

scalar

Description: A channel with exactly one value per point in time. Typical application: continuous physical quantities (temperature, voltage, pressure) or digital signals (e.g., door status).
Properties:
- Each data block contains one or more samples with a single value.
- Supports equidistant sampling via timeincrement or individual timestamps per value.
- Simplest and most commonly used channel type.
XML example (OSF4):

xml
JSON example (OSF5):

  ```json
  {
    "index": 0,
    "name": "Sensor/Temperature",
    "channeltype": "scalar",
    "datatype": "double",
    "physicalunit": "°C"
  }

vector

Description: A channel in which each data block contains a sequence of several values that belong together logically. Typical application: Frequency spectra (FFT), time series segments, multi-channel recordings in one block.
Properties:
- Vector length can vary per block.
- Saves overhead at high sampling rates, as multiple values are written in one block.
- Can work with both timestamps per block and fixed time increments.
- Requires additional parameters for axis information (separate document).
XML example (OSF4):

xml
JSON example (OSF5):

  ```json
  {
    "index": 2,
    "name": "FFT/Magnitude",
    "channeltype": "vector",
    "datatype": "float",
    "physicalunit": "dB"
  }

matrix

Description: A channel that stores a two-dimensional data structure per timestamp. Typical application: Rainflow classifications, heat maps, 2D sensor arrays, image data.
Properties:
- Matrix size can vary per block.
- Enables complex data structures in a uniform time base.
- Requires additional parameters for row and column description (separate document).
XML example (OSF4):

xml
JSON example (OSF5):

  ```json
  {
    "index": 5,
    "name": "Rainflow/Matrix",
    "channeltype": "matrix",
    "datatype": "int32",
    "physicalunit": "counts"
  }

Notes on vectors and matrices

Additional parameters: Both types require meta information on dimensions, axes, physical units, and labels, if applicable. These are described in detail in separate documents.
Efficiency: Vector and matrix channels reduce write operations and are particularly suitable for data with high sampling rates or complex structures.
Flexibility: The size and structure of the blocks can vary, allowing adaptation to different measurement scenarios.
Synchronization: They share the same time base as scalar channels, so different data types can be stored in a file in exact synchronization.

Summary

scalar – Simple channel type, one value per point in time. Ideal for continuous measurements.
vector – Multiple values in one block, optimized for frequency spectra and high-frequency data.
matrix – Multidimensional blocks, suitable for classifications, image, and array data.

Note: By combining these channel types, OSF covers both simple signals and complex data sets while remaining easy to implement.

Block size field (sizeoflengthvalue)

The parameter sizeoflengthvalue defines the size of the length field that precedes each data block of a channel. It therefore determines how many bytes are used to specify the block size and thus the maximum size of a single data block.

Purpose

OSF is a streaming format. Each data block can be of different sizes and contains a variable number of measured values. In order to read these blocks correctly, their length must be known. The sizeoflengthvalue field specifies whether 2 bytes or 4 bytes are used for the length specification.

Values

2 – Length field is 2 bytes (uint16).
- Maximum value: 65,535 bytes per data block.
- Default value for typical measurement channels with moderate block sizes.
- Lower memory consumption and overhead.
4 – Length field is 4 bytes (uint32).
- Maximum value: ~4 GB per data block.
- Suitable for channels with very large data packets, e.g., image, audio, or binary data.

Default value

If not explicitly specified, sizeoflengthvalue="2" is used.

Effects

Memory requirements: 2 bytes save space for small blocks, 4 bytes enable large data.
Readability: Before interpreting each block, the reader must read the length specification and treat the next N bytes as a block.
Error resistance: Even if writing is interrupted, the reader can skip blocks correctly and find the next valid block.

Recommendations

For continuous signals and channels with scalar values → use 2.
For binary channels with images, audio, or large data packets → select 4.
Uniform selection per channel; can be set per channel in the channel definition.

Data blocks

Data blocks form the core of the OSF format. They contain the actual measured values and are structured in such a way that they can be efficiently written and read both in continuous streaming on embedded systems and in block-by-block processing on servers and PCs. Each data block is self-contained and remains interpretable even if recording is interrupted.

Introduction

In OSF, all measured values are stored in data blocks. Each block is a self-contained unit that contains one or more values from a channel and is linked to time information.
The block concept enables two key features of the format:

Continuous streaming: Values can be written continuously during recording without knowing the entire file structure.
Efficient processing: Block-based storage allows large amounts of data to be quickly loaded and processed on servers, PCs, or in post-processing.

Each data block is designed so that it remains readable up to the last completely written unit, even if the measurement is suddenly interrupted (e.g., power failure).
The structure of the data blocks is identical for OSF4 and OSF5 and forms the basis for robust, loss-free recording of time-related measurement data.

General structure of a data block

A data block in OSF consists of a fixed header structure, followed by optional metadata and the actual measured values.
The structure is designed so that each block can be interpreted independently and remains valid even in the event of streaming or file termination.

Basic structure:

Channel index (uint16)
- Identifies which channel the data belongs to.
- Corresponds to the index attribute in the meta block.
Length field (uint16 or uint32)
- Size of the subsequent data area in bytes.
- The length of the field is defined by the channel parameter sizeoflengthvalue.
- Enables blocks to be skipped or, in the event of errors, to jump correctly to the next unit.
Control byte (uint8)
- Defines the type of data block and contains information about the structure of the following data.
- The most significant bit (bit 7) indicates whether the block contains a single value (0) or multiple values/value pairs (1).
- A complete overview of the control byte values can be found in the section The Control Byte.
Data area
- The actual measured values or data blocks.
- The format and size depend on the channel type (typically scalar) and the data type.

The control byte

Each data block in OSF contains a control byte (blockContent) that determines the type of block and the structure of the data it contains.
In addition, the most significant bit (bit 7) contains information about whether the block contains only a single value or multiple values or value pairs:

Bit 7 = 0 → A single value or value pair in the block.
Bit 7 = 1 → Multiple values or value pairs in the block (N > 1).

The control byte is interpreted as an 8-bit value. The lower 7 bits define the block type, the upper bit defines the number of values.

Overview of block types

Value (0–6)	Enum	Meaning	Data block content
0	`bcReserved`	Reserved for future use. Originally bcMetaData, not yet used.	Variable, internal special functions
1	`bcTrustedTimestamp`	`Not applicable` Originally intended for constant values with "valid until" timestamp. Recommendation: Set support points through the application.	`int64`: Absolute timestamp (ns since epoch)
2	`bcTimebaseRealign`	`Not applicable` Adjustment of the time axis. Can be replaced if necessary by writing a new block with an absolute start time.	`int64`: Absolute timestamp `int64`: Time shift (ns)
3	`bcStatusEvent`	`Not applicable` Used to carry status information per channel. No longer used.	`int64`: Absolute timestamp `uint32`: Status word
4	`bcMessageEvent`	`Not applicable` Can be completely replaced by `bcAbsTimeStampData` with `datatype=string`.	`int64`: Absolute timestamp `string`: Text without 0 termination
5	`bcContinuedData`	Continue data with fixed sampling rate. If bit 7 is set, multiple values in block.	`[uint32 N]`: Number of samples (only if bit 7 is set) `N` × data values
6	`bcStartData`	First data block with fixed sampling rate (e.g., for trigger). Always contains an absolute start timestamp.	`int64`: Absolute timestamp `[uint32 N]`: Number of samples (only if bit 7 is set) `N` × data values
7	`bcContinuedRelStampData`	`Not applicable`, `Supported in OSF5 when reading` Originally used to save 4 bytes per sample with relative timestamps.	`[uint32 N]`: Number of samples (only if bit 7 is set) `N` × (`uint32` relative time + data value)
8	`bcAbsTimeStampData`	Data blocks with absolute timestamp per value. Now also supports strings and binary data in conjunction with `datatype` and `mimetype`.	`[uint32 N]`: Number of samples (only if bit 7 is set) `N` × (`int64` absolute time + data value)
`[uint32 N]`: Number of samples (only if bit 7 is set) `N` × (`int64` absolute time + da

Restriction of block types with regard to channel information:

ENUM type	Equidistant data	Time-stamped data
bcStartData	allowed	not allowed
bcContinuedData	allowed	not allowed
bcContinuedRelStampData	not allowed	allowed
bcAbsTimeStampData	not allowed	allowed

bcStartData	allowed	not allowed

Data structure per control type

The structure of the user data in a block depends directly on the control type.
The following sections describe how values for different data types are stored and what restrictions apply.

bcStartData (equidistant data, start block)

Use:
- Start of a data series with a fixed sampling rate.
- Always contains the absolute start time of the series.
- Only permitted for numeric datatype (int*, float, double).
Block structure:
1. int64 – Absolute start time stamp (ns since epoch).
2. [uint32 N] – Number of samples (only if bit 7 is set, otherwise 1).
3. N × data values – Raw data according to datatype.
Example datatype=double: [int64 timeStart] [uint32 N] [double value1] [double value2] ... [double valueN]
Note:
- Always marks the start of a series or a new segment (e.g., after a trigger).

bcContinuedData (equidistant data, continuation)

Usage:
- Continues a series started with bcStartData without a new timestamp.
- The first value follows directly on from the last value of the previous block.
- Only allowed for numeric datatype (int*, float, double).
Block structure:
1. [uint32 N] – Number of samples (only if bit 7 is set, otherwise 1).
2. N × data values – Raw data according to datatype.
Example datatype=int16:[uint32 N] [int16 value1] [int16 value2] ... [int16 valueN]

bcAbsTimeStampData (timestamped data)

Use:
- For channels with individual timestamps per value.
- Supports all datatype, including string and binary.
Block structure:
1. [uint32 N] – Number of samples (only if bit 7 is set, otherwise 1).
2. N × (int64 time + data value) – Absolute timestamp + value.
Example datatype=int16:[uint32 N] [int64 time1] [int16 value1] [int64 time2] [int16 value2] ...
Example datatype=double:[uint32 N] [int64 time1] [double value1] [int64 time2] [double value2] ...
Example datatype=string:
- Strings are stored without null termination.
- Number of samples determines the length. Bit 7 must be set.
- [uint32 N] [int64 time] [UTF-8 bytes of the string]
Example datatype=binary:
- Binary data is written as raw bytes.
- mimetype in the channel defines the interpretation.
- Number of samples (N) determines the length. Bit 7 must be set.
- [uint32 N] [int64 time] [byte1] [byte2] ... [byte N]
Note: If there are multiple samples per block (N>1), strings or binary data must be in segments of equal length or written as individual blocks.

bcContinuedRelStampData (timestamped, relative)

Use:
- For channels with individual timestamps and relative intervals.
- No longer used as of OSF5, but retained for OSF4 readers.
Block structure:
1. [uint32 N] – Number of samples (only if bit 7 is set, otherwise 1).
2. N × (uint32 Δt + data value) – Relative time interval in ns + value.
Example datatype=int16:[uint32 N] [uint32 Δt1] [int16 value1] [uint32 Δt2] [int16 value2] ...
Further examples under bcAbsTimeStampData
Note:
Originally developed to save 4 bytes per sample.
In OSF5, this type has been omitted in favor of simpler implementation.

Restrictions

Equidistant channels (bcStartData, bcContinuedData):
- Only direct numeric data types (int*, float, double).
- No strings, no binary data, no complex structures.
Timestamped channels (bcAbsTimeStampData, bcContinuedRelStampData):
- Support all data types.
- Strings without null termination; length exceeds block size.
- Binary data with datatype=binary and optional mimetype.

Important points

Compatibility:
- OSF5 can read all OSF4 block types.
- Starting with OSF5, bcContinuedRelStampData, bcStatusEvent, and bcMessageEvent are no longer generated.
- bcTrustedTimestamp is ignored and marked as deprecated.
Implementation:
- Readers must always check bit 7 to correctly interpret single vs. multi-value blocks.
- Unrecognized block types can be skipped based on the length specification.
Strings and binary data:
- For bcAbsTimeStampData with datatype=string, zero termination is not required.
- The block length is determined by sizeoflengthvalue.
- Binary data uses datatype=binary plus mimetype.

File termination and magic trailer

At the end of an OSF file, an info data block with the special channel index 0xFFFF can be written optionally.
This block provides meta information about the completed data stream and marks the regular end of the file.

Info data block (channel index 0xFFFF)

Purpose:
Provides a quick overview of the time interval and segmentation of the file without having to read the entire data blocks.
Useful for analysis and indexing tools.
Structure:
1. uint16 – Channel index (0xFFFF)
2. uint32 – Length of the following option block
3. uint8 – Control byte (always bcReserved / 0)
4. string – UTF-8-encoded info block (format depends on OSF version)

Example (OSF4, XML):

xml
<trailer finalized_utc="2019-08-12T12:23:01+02:00" reason="fileStartGrid_min">
    <channels count="8">
        <channel index="0" samples="29452" last_ns="1384899599997800000" last_utc="2019-11-19T23:19:59"/>
        <channel index="1" samples="29452" last_ns="1384899599997800000" last_utc="2019-11-19T23:19:59"/>
        <channel index="2" samples="29452" last_ns="1384899599997800000" last_utc="2019-11-19T23:19:59"/>
        <channel index="3" samples="29452" last_ns="1384899599997800000" last_utc="2019-11-19T23:19:59"/>
    </channels>
</trailer>

Example (OSF5, JSON):

```json
{
  "trailer": {
    "finalized_utc": "2019-08-12T12:23:01+02:00",
    "reason": "fileStartGrid_min",
    "channels": [
      {
        "index": 0,
        "samples": 29452,
        "last_ns": 1384899599997800000,
        "last_utc": "2019-11-19T23:19:59"
      },
      {
        "index": 1,
        "samples": 29452,
        "last_ns": 1384899599997800000,
        "last_utc": "2019-11-19T23:19:59"
      }
    ]
  }
}

Note:
- OSF4 uses XML for the info block by default.
- OSF5 uses JSON, but for compatibility reasons it can also read XML, but not write it.

Magic Trailer

Optionally, a Magic Trailer can follow the info data block. This serves as a fixed marker for the end of the file and indicates where the 0xFFFF block begins.

Format:

OSF_STREAM_END 321316454==============

The number indicates the position in the file where the 0xFFFF block begins.
The trailer tag is padded to 40 bytes, with = characters following the number until the length is reached.

Purpose of the magic trailer

Allows the info data block at the end of the file to be found without searching the entire file.
Facilitates random access implementations and indexing of large files.
Provides a clear marker for the regular end of an OSF file.

Optionality and implementation effort

Letter:
- The info block and magic trailer are not mandatory.
- If they are written, they enable quick indexing and determination of the file's time interval.
- They can be omitted for embedded systems with limited resources.
Read:
Parsers must not assume the existence of the block.
- Parsers must not assume the presence of the block.
- Files without trailers are interpreted up to the last fully readable block.
- In the event of a hard termination, the last block may be shorter than its specified length—in this case, the reader must terminate at the end of the file.

Advantages

Quick determination of time intervals and statistics without having to read the entire file.
Useful for long measurements and automated analysis.
Enables random access for analysis tools.

Disadvantages

Increased implementation effort for writing and reading.
If the file is interrupted, the trailer may be missing or incomplete.
Not absolutely necessary for simple streaming.

Next steps

The previous chapter describes the general structure of the Open Streaming Format (OSF) and all components that apply to OSF4 and OSF5 alike.
For a complete implementation or deeper integration, the following topics are recommended:

Specifics of OSF4 and OSF5:
- Details on the respective header formats (XML vs. JSON)
- Differences in the control byte and trailer
- Backward compatibility and implementation notes
- Continue with OSF4 or OSF5
Vectors and matrices:
- Advanced channel types for multidimensional data
- Additional parameters for axes, dimensions, and physical units
- Examples for FFTs, classifications, and image data
Examples:
- Complete OSF files (OSF4/XML and OSF5/JSON) with header, metablock, and data blocks
- Hex dumps and annotated structures
Access to source code and open source:
- Reference implementations for OSF4 and OSF5
- Parser and writer libraries for various platforms
- Sample code for embedded systems and PC analysis

General description of the OSF format​

Basic principles​

Basic structure of an OSF file​

Data organization​

Magic header​

Structure​

Supported identifiers​

Recognition of the Metablock format​

Advantages​

Metablock – Channels and metadata​

File parameters (in the metablock)​

Channel definitions (channel)​

Identification and organization​

Time base​

Data types and structure​

Physical properties​

Display and additional information​

Metadata (info)​

Advantages of the structure​

Core parameters of the channel description​

Data types (datatype)​

Supported data types and encoding:​

Structure candata​

Structure gpsdata​

New in OSF5 Structure pair​

New in OSF5 Structure triple​

Channel types (channeltype)​

scalar​

vector​

matrix​

Notes on vectors and matrices​

Summary​

Block size field (sizeoflengthvalue)​

Purpose​

Values​

Default value​

Effects​

Recommendations​

Data blocks​

Introduction​

General structure of a data block​

The control byte​

Overview of block types​

Data structure per control type​

bcStartData (equidistant data, start block)​

bcContinuedData (equidistant data, continuation)​

bcAbsTimeStampData (timestamped data)​

bcContinuedRelStampData (timestamped, relative)​

Restrictions​

Important points​

File termination and magic trailer​

Info data block (channel index 0xFFFF)​

Example (OSF4, XML):​

Example (OSF5, JSON):​

Magic Trailer​

Purpose of the magic trailer​

Optionality and implementation effort​

Next steps​