Heartbeat - HdrType=1

Overview

This is the structure and behavior of Heartbeat (HdrType=1) in Extended Telemetry

The goal was to define an a message which:

• Gives an "I'm alive" message when gps lock not available
• Helps identify flight channel
• Helps identify flight start/stop time
• Gives additional useful data

Give an "I'm alive" message when gps lock not available

Can be (but not only) sent when a GPS lock is not acquired but the tracker is alive and able to send.

Gives positive confirmation the flight is in progress.

Help identify channel

Carries data in the message which identifies channel, helping to disambiguate.

This data is a tracker-affirmed statement about intended frequency, which can help condition the search for related data.

Help identify flight start/stop

Carries data in the message which gives insight into the duration of the flight.

Give additional useful data

Precision location and/or other details can ride along when appropriate.

When this message can be sent

Send whenever

Any window.

Any slot.

In as many slots as you want (all 5 is valid).

Ok to send in Slot 3 in one window and Slot 4 in another. Or any combination.

Suitable to replace Slot 1 Type1 Callsign message when no GPS lock available.
Suitable for other scenarios as well (see Example Use Cases).

Message Structure Primer

The header, as explained in Header Fields explains the whole message header structure.

The fields below are for when the HdrType=1 indicating a Heartbeat message.

The structure of the Heartbeat message is multi-part

The first few fields (FreqHz and GpsLockType) tell you some data.

The DataType tells you how to interpret the rest of the message.

Message Structure

Link to Playground

The leading structure of the Heartbeat message is

Field	Unit	LowValue	HighValue	StepSize	# Values
FreqHz	Idx	0	200	1	201
GpsLockType	Enum	0	2	1	3
DataType	Enum	0	3	1	4

FreqHz

FreqHz - Intended TX frequency

Values

Value = Which of the 201 frequencies making up the WSPR band is the intended TX frequency?

eg:

• 20m band has 201 frequencies making up the WSPR band:
  • 14,095,600 Hz notional Dial frequency
  • 14,097,000 Hz Low end frequency
  • 14,097,200 Hz High end frequency
• For a given WSPR Encoded message (where id13 set to, say, Q5):
  • You know you are looking at channels 500-519
  • You can determine Lane by the FreqHz value falling into that Lane
  • You can determine Channel by combination of the HdrSlot and minute of reception

With the above, you can definitively identify the Channel of the transmitter.

Intended purpose

Lets receivers:

• Match up transmitter to intended channel definitively.
• Better understand relationship between TX frequency and RX reports.

Rationale

Q: What channel is a data stream attempting to transmit on?
A: At the moment, we have to infer

Q: Should we pack in the Channel then to identify?
A: No, we can do better, cheaper.

When you have data in the WSPR Encoded format, the id13=Q/0/1 already tells you a "column" in the Channel Map, so actually we only have to identify "Lane."

However, "Lane" may later change/expand, and we don't think "Lane" or even the strict concept of "Channels" are a hard requirement, and may change quantity in the future.

What will remain, though, is the WSPR Encoded format. And, also remaining, the fact that you're in a band with only 200Hz of possible intended frequencies to transmit on.

So ... indicate a value 0-200 inclusive, the literal intended Hz of transmission as an index offset from the lowest frequency to the highest within the given band.

This tells you: The channel (because today, sites can interpret the FreqHzIdx as being within one of the "Lanes" Later, if the scheme changes, the tracker is still going to intend to transmit on a given Hz, this identifies it

GpsLockType

GpsLockType - Whether GPS is locked at this moment or not

Values

Distinguish between 3 states:

• NoLock = 0
• TimeLock = 1
• LocationLock = 2

Intended purpose

Trackers are not always dependent on GPS to know the current time, and to therefore know when to transmit data.

It is possible that a tracker has achieved some amount of GPS data (time, position), or none at all.

This field distinguishes.

DataType

DataType - What additional data does this message carry?

Values

Enumerated set of possible appendages.

• DataType=0 - Opaque data (default integer display)
• DataType=1 - High-res latitude and longitude
• DataType=2 - Small GPS stats
• DataType=3 - Not yet defined

Intended purpose

There are different sets of data which may make sense to send in one situation vs another.

This is an option the tracker can select to decide what data to send given those circumstances.

DataType=0

No defined structure (tracker-dependent meaning).

By default appropriate to be considered an integer number to be displayed in decimal form as-is.

Useful to be used as a counter since a last relevant event.

Link to Playground

The structure of the DataType=0 fields

Field	Unit	LowValue	HighValue	StepSize	# Values
Opaque	Value	0	252160	1	252161

This can be sent with any level of GPS lock.

DataType=1

High-res latitude and longitude information.

The structure of the DataType=1 fields

Field	Unit	LowValue	HighValue	StepSize	# Values
Reference	Bool	0	?	1	?
Latitude	Idx	0	??	??	??
Longitude	Idx	0	??	??	??

Reference values:

• 0 = No reference, this is the highest resolution latitude and longitude available.
• 1 = Reference prior Type1 grid4 value, increases accuracy of this value.
• 2 = Reference prior BT-enhanced grid6 value, increases accuracy of this value.
• 3 = Reference prior Heartbeat-enhanced value, increases accuracy of this value.

This should not be sent when there is no GPS Location lock.

DataType=2

Small GPS stats.

Total seconds associated with current GPS lock attempt in current attempt (completed or not). Total number of relevant satellites in view (tracker-dependent determination).

The structure of the DataType=2 fields

Field	Unit	LowValue	HighValue	StepSize	# Values
AttemptDuration	Seconds	0	??	??	??
SatsInView	Count	0	??	??	??

This can be sent with any level of GPS lock.

Example Use Cases

When	What
Altitude under 10k ft / 3km	Send high-resolution location. This is the most interesting time to know high-res location. Also useful to send when no GPS lock on initial launch.
No GPS Location lock	Send to indicate proof of life.
Periodically at float	Send to reveal counter stat
During likely crashing scenario	Send high-resolution in many slots to maximize recovery possibility