Spot timing & receiver info

What t means depends on the receiver's software. Some programs report when the transmission started; others report when they decoded it, which for FT8 is around 11 to 14 seconds later. So the same transmission can arrive with t values a whole slot apart.

t is always published exactly as the receiver sent it. t_tx is our best statement of when the transmission began. If you want one time per spot, use t_tx when it is present and fall back to t:

const when = spot.t_tx ?? spot.t;

PSK Reporter publishes a list at pskreporter.info/api/characteristics. It gives each reported software version a time_start flag:

{"WSJT-X v2.7.0":{"time_start":0,…}, "WSJT-X v3.0.1":{"time_start":1,…}, …}

This API returns a map of software versions to a time_start flag which shows which [software's] time reported is the start time of the transmission. Otherwise it is the decode time. — Philip Gladstone, PSK Reporter

We take the list exactly as published. If an entry looks wrong, the fix belongs in the list at PSK Reporter, not here. A corrected entry reaches the feed within the hour, because the list is fetched at startup and then hourly.

The flag is per exact version string, not per product. For example, WSJT-X 2.x and 3.0.0 builds are flagged 0, while 3.0.1 onwards are flagged 1. The list has around 2,000 entries.

The receiver's software is looked up in the list (exact match, ignoring case). Software flagged 1 reports the transmission start. Everything else (flagged 0, not in the list, or no software named) reports the decode time.

When t_tx can't be worked out it is left out of the payload, not set to t. A copy of t would claim the transmission started at the decode time, and you would have no way to tell a real transmit start from a copy.

Spots on wspr/ never carry t_tx. WSPR times are already the start of the two-minute slot, so t_tx could only repeat them.

FT8 transmissions start on 15-second boundaries (:00, :15, :30, :45) and last 12.64 seconds. A decoder reports a little later, usually between about :11 and :14, and a slow machine may report after the next slot has begun.

From a decode time, t_tx is the 15-second boundary nearest to t − 13 seconds. In practice, a decode reported 6 to 20 seconds after a boundary belongs to the slot that began at that boundary:

No other mode has a slot model yet. FT4 is the obvious next one, but its 7.5-second slots put half its boundaries on half-seconds, and t_tx is in whole seconds.

A sample of 26 reports of a single FT8 transmission at 15:46:00 UTC was posted to the pskr-mqtt list. The table compares the earlier, incorrect handling with the current rule:

In the last two rows, the reported time doesn't look like what the flag says. t_tx follows the list in both cases. If a flag is wrong, correcting it at PSK Reporter corrects t_tx with no change needed here.

Receiver details that the spot stream doesn't carry (antenna, rig, decoder software and locator) are published as retained messages, one per receiver. Subscribe to pskr/rxinfo/# and you get the current set straight away, then updates as stations change. A / in a callsign becomes . in the topic.

mosquitto_sub -h mqtt.pskreporter.info -t "pskr/rxinfo/#" -v

{"call":"K5RAV","antenna":"OCF at 40 feet","rig":"Icom IC-7600",
 "decoder":"WSJT-X v2.6.1","grid":"EM12kx","time_start":0,"ts":1782438765}

Fields are empty strings when the receiver hasn't reported them. ts is when the snapshot was taken.

time_start

PSK Reporter's flag for the station's decoder, read the same way as above: 1 when it reports the transmission start, 0 when it reports the decode time (including software the list doesn't name). It is absent until the list has loaded. It's a convenience. Each spot's t_tx is worked out from the software named on that spot, and that takes precedence if the two ever differ.

How long a receiver stays

The list comes from PSK Reporter's active receivers and is fetched hourly. A changed receiver is republished on the next fetch.

A receiver that drops out of the list is removed on the first fetch it's missing from. We publish an empty retained message to its topic, which deletes it. Live subscribers see a zero-length payload, so treat an empty message as "this station has gone":

if (payload.length === 0) { stations.delete(callsign); }

Two safeguards stop a bad fetch removing stations that are still active:

• A fetch that returns fewer than half as many receivers as the previous one is treated as incomplete, and nothing is removed that time.
• Nothing is removed until there has been a previous fetch to compare with. A station that left while the service was restarting is removed on the second fetch after it comes back.

As a last resort, every message also expires after 7 days.