Environmental Barometric State IDD

Purpose

Defines the OpenRoadCode message-bus contract for processed barometric state. The contract is source-independent and may be produced from Android phone pressure sensors, BMP3xx hardware, or other implementations of the environmental barometric controller interfaces.

Topic

openroad.environmental.barometric

Schema version

Version 1.

Envelope

Every message contains exactly version, timestamp, source, and data.

timestamp uses the common OpenRoadCode Unix-epoch representation with unsigned whole seconds and fractional nanoseconds.

Data fields

Field	Type	Units	Description
`pressure_pa`	number	Pa	Atmospheric pressure; must be positive.
`temperature_c`	number or null	deg C	Sensor temperature when the source provides it. Android pressure-only sources publish `null`.
`altitude_m`	number	m	Barometric altitude computed using the controller sea-level pressure reference.
`relative_altitude_m`	number	m	Altitude relative to the controller reference established at startup/reset.
`vertical_speed_m_s`	number	m/s	Filtered barometric vertical speed. Positive values indicate increasing altitude.

Example

{
  "version": 1,
  "timestamp": {"seconds": 1787752800, "nanoseconds": 0},
  "source": "android",
  "data": {
    "pressure_pa": 100842.3,
    "temperature_c": null,
    "altitude_m": 40.27,
    "relative_altitude_m": 0.18,
    "vertical_speed_m_s": 0.04
  }
}

Producer requirements

Producers shall normalize pressure to pascals before publication. Derived altitude and vertical speed shall be generated by the environmental barometric controller rather than by hardware drivers. Sources that do not measure temperature shall publish null; they shall not synthesize a temperature value.

Consumer requirements

Consumers shall validate the schema version and message fields before use. altitude_m is pressure-derived and depends on the configured sea-level pressure reference; it shall not be treated as an independent absolute-position measurement without appropriate calibration/fusion.

Versioning

Incompatible field or semantic changes require a schema-version increment. New optional capabilities should be introduced without changing the meaning or units of existing fields.