Skip to content

Dashboard Overlapping Telemetry Resolution Spec

Purpose

This spec defines how dashboard processing shall interpret and present overlapping telemetry data carried by the following message types within a single WSPR window:

  • RegularType1 (RT1)
  • BasicTelemetry (BT)
  • ExpandedBasicTelemetry (EBT)
  • HighResLocation (HRL)

It defines: - slot admissibility - per-type message selection - GPS-validity rules - field-family precedence - raw and synthesized table columns - display styling - chart/source usability rules

Definitions

  • Window: One processing interval containing slots 0..4. All rules in this spec apply only within one window at a time.
  • Slot: A transmission position within a window. Higher slot number means more recent within that same window.
  • Candidate: A decoded message instance that survived earlier filtering stages.
  • Selected message: The one message chosen for a given message type within the current window.
  • Field family: A logical data family whose value may be carried by more than one message type. Families in this spec are Location2D, Temperature, Voltage, Altitude, and Speed.
  • GPS-derived data: Data whose usability depends on GPS validity. In this spec, Location2D and Altitude are GPS-derived.
  • Usable: Eligible to participate in resolved-value selection.
  • Resolved column: A synthesized output column representing the final chosen value for a field family, with no message-type prefix.
  • Raw column: A per-message-type output column representing decoded data from that message type, with that type's prefix.
  • Dimmed: Styled to indicate GPS-derived data exists but is unusable.
  • Italicized: Styled to indicate a value is valid raw data but was not selected because a better value in the same family was chosen.
  • Reference grid: The 4-character Maidenhead grid carried by RT1, used as the base for BT, EBT, and HRL location refinement.
  • Location-bearing message: A message type that can contribute to Location2D: RT1, BT, EBT, HRL.

Preconditions

Earlier processing stages are assumed to guarantee: - each slot contains either 0 or 1 surviving candidate - invalid duplicates within a slot have already been eliminated

This spec does not define that earlier filtering logic; it defines behavior after that point.

Allowed Slots

  • RT1 may appear only in slot 0
  • BT may appear only in slot 1
  • EBT may appear only in slots 1..4
  • HRL may appear only in slots 1..4

A message appearing in a disallowed slot is invalid for this spec and should be rejected upstream or by spec-validation logic.

Per-Type Selection

Within a window, define: - RT1Selected: the RT1 in slot 0, if present - BTSelected: the BT in slot 1, if present - EBTSelected: the highest-slot EBT, if present - HRLSelected: the highest-slot HRL, if present

If more than one message of a type exists in allowed slots, the highest slot wins for that type.

Message-Local GPS Validity

GPS validity is local to the message being interpreted. One message's GPS validity does not invalidate or validate another message's raw data.

Rules: - BT.gpsValid = 1 means BT GPS-derived data is usable - BT.gpsValid = 0 means BT GPS-derived data is unusable - EBT.gpsValid = 1 means EBT GPS-derived data is usable - EBT.gpsValid = 0 means EBT GPS-derived data is unusable - HRL.reference = 1 means HRL location data is usable and implies GPS-valid - HRL.reference != 1 means HRL location data is unusable

Temperature, Voltage, and Speed are not invalidated by gpsValid.

RT1 Location Rule

RT1Selected.grid4 is both: - a valid coarse location by itself, and - the reference base needed to refine BT, EBT, and HRL location data

Rules: - If RT1Selected is the only location-bearing message present in the window, it may populate resolved location by itself. - If any of BTSelected, EBTSelected, or HRLSelected exist, then RT1Selected serves only as the reference base for those selected messages and is not itself a resolved location source. - BT, EBT, and HRL location refinement requires RT1Selected.grid4. Without RT1Selected, those message types may still expose non-location raw fields, but cannot produce usable lat/lng.

Field Families

The overlapping families are:

  • Location2D
  • RT1: grid4
  • BT: grid56/grid6
  • EBT: latitudeIdx/longitudeIdx

  • HRL: reference/latitudeIdx/longitudeIdx

  • Temperature

  • BT: Celsius

  • EBT: Fahrenheit

  • Voltage

  • BT

  • EBT

  • Altitude

  • BT: meters

  • EBT: feet

  • Speed

  • BT: knots

Usability By Family

A source is usable for a family if:

  • Location2D
  • RT1: usable if RT1Selected exists and no selected BT/EBT/HRL exists
  • BT: usable if BTSelected exists, BTSelected.gpsValid = 1, and RT1Selected exists
  • EBT: usable if EBTSelected exists, EBTSelected.gpsValid = 1, and RT1Selected exists

  • HRL: usable if HRLSelected exists, HRLSelected.reference = 1, and RT1Selected exists

  • Altitude

  • BT: usable if BTSelected exists and BTSelected.gpsValid = 1

  • EBT: usable if EBTSelected exists and EBTSelected.gpsValid = 1

  • Temperature

  • usable if present in selected BT or EBT

  • Voltage

  • usable if present in selected BT or EBT

  • Speed

  • usable if BTSelected exists

Resolved Selection Rule

Selection is by field family, not by message.

For each field family, choose the most recent usable source among the selected messages that carry that family.

A newer message supersedes older data only for families it carries.

Resolved precedence: - Location2D: latest usable among HRLSelected, EBTSelected, BTSelected, else RT1Selected alone if no selected BT/EBT/HRL exists - Temperature: latest among EBTSelected, BTSelected - Voltage: latest among EBTSelected, BTSelected - Altitude: latest usable among EBTSelected, BTSelected - Speed: BTSelected only

A newer unusable source does not block fallback to an older usable source in the same family.

Examples: - newer EBT.gpsValid=0 does not block older valid BT from supplying Location2D or Altitude - newer EBT.gpsValid=0 still may supply Temperature and Voltage

Raw Output Columns

Each selected message type expands into its own prefixed columns.

BT columns use prefix Bt: - BtGpsValid - BtGrid56 - BtGrid6 - BtLat - BtLng - BtTempC - BtTempF - BtVoltage - BtAltM - BtAltFt - BtKnots - BtKPH - BtMPH

EBT columns use prefix Ebt: - EbtGpsValid - EbtLatitudeIdx - EbtLongitudeIdx - EbtLat - EbtLng - EbtTempF - EbtTempC - EbtVoltage - EbtAltFt - EbtAltM

HRL columns use prefix HiRes: - HiResReference - HiResLatitudeIdx - HiResLongitudeIdx - HiResLat - HiResLng

RT1 columns use prefix Reg: - RegGrid - RegLat - RegLng

RegLat and RegLng are always present when RT1Selected exists.

Raw Column Derivation Rules

  • BtGrid6 is derived from RT1Selected.grid4 + BTSelected.grid56 only if BTSelected.gpsValid = 1 and RT1Selected exists
  • BtLat/BtLng are derived from BtGrid6 only when BtGrid6 is usable
  • EbtLat/EbtLng are derived only if EBTSelected.gpsValid = 1 and RT1Selected exists
  • HiResLat/HiResLng are derived only if HRLSelected.reference = 1 and RT1Selected exists
  • RegLat/RegLng are derived from RT1Selected.grid4 whenever RT1Selected exists

If derivation requirements are not met, the corresponding derived raw columns are null.

Resolved Output Columns

Resolved columns have no prefix:

  • Lat
  • Lng
  • TempF
  • TempC
  • Voltage
  • AltFt
  • AltM
  • Knots
  • KPH
  • MPH

Resolved values are produced from the selected source for that family: - resolved temperature is emitted in both F and C - resolved altitude is emitted in both Ft and M - resolved speed is emitted in Knots, KPH, and MPH

Lat and Lng are the canonical 2D location outputs and replace synthesized grid as the primary downstream location source.

Precision Rules

Displayed decimal places of Lat and Lng must indicate source precision.

Precision should be source-sensitive: - RT1-only location: coarse precision - BT-derived location: precision consistent with grid6 resolution - EBT-derived location: precision consistent with EBT index resolution - HRL-derived location: precision consistent with HRL index resolution

Implementation may use a per-source precision tag internally, but displayed values must preserve visible precision differences between location sources.

Styling Rules

Apply styling per raw value or per raw family-specific cell group, not per whole message.

  • Dimmed:
  • apply to raw GPS-derived values that are present but unusable due to message-local GPS invalidity or equivalent invalid location state
  • dimmed raw GPS-derived values must not be used for resolved synthesis

  • dimmed raw GPS-derived values must not be used for charting or derived map/location output

  • Italicized:

  • apply to raw values that are valid but not selected because a better value in the same family was chosen from a more recent usable source

  • If both conditions apply, apply both styles

Examples: - BtTempC is not dimmed by BtGpsValid=0 - BtLat/BtLng are dimmed when BtGpsValid=0 - older valid BtLat/BtLng become italic if newer valid EbtLat/EbtLng or HiResLat/HiResLng is selected instead

Charting Rules

  • Resolved columns are the default preferred source for charting and downstream analytics
  • Raw GPS-derived columns that are dimmed are not chartable
  • Raw non-GPS columns may remain chartable
  • Raw superseded columns remain available for explicit inspection, but are not charted by default when a resolved equivalent exists

Null / Missing Behavior

  • If no usable source exists for a resolved family, that resolved column is null
  • If a selected message exists but cannot derive location because RT1Selected is missing, its non-location raw fields still appear, but its derived lat/lng raw columns are null
  • If only RT1Selected exists, resolved Lat/Lng may be produced from RT1 alone

Implementation Partitioning

This spec defines behavior, not exact file placement. A conforming implementation should ensure: - slot/type admissibility is enforced - per-type selection occurs before family resolution - family resolution is independent per family - raw columns and resolved columns follow the rules above