Something has stopped. Start here.

Keep one question in view

Ask where the evidence stops. Can the operating system see the radio? Does the decoder receive messages? Does it produce positions? Does the local map load them? Does the destination accept them? A fault somewhere in this chain can produce the same unhelpful sentence, "There are no planes."

Record the first failure time and the last change. Preserve logs before restarting. Check the local side even when your usual habit is to open a network's website. The symptom finder narrows the next checks without sending your data anywhere.

The local map is empty

Check whether the decoder is running and whether it reports received messages. A message count without positions is different from no messages at all. Verify the actual radio and antenna connection, and look for USB ownership conflicts after a new install.

On systemd Linux, use the correct unit name for your installation. These commands read recent status; they do not change configuration.

systemctl status readsb --no-pager
journalctl -u readsb --since "30 minutes ago" --no-pager

Replace readsb with the actual unit where appropriate. Container and appliance installs have different log paths. Use their documentation. If the decoder has current positions, inspect the map's configured data source and browser errors rather than moving the antenna immediately. [1] [2]

The local map works, but a network does not

Check that the relevant feeder process is running, not just the decoder. Confirm the intended account or station, private key, configured source and outbound connection. Read the destination's status message and current guide. Avoid posting a full configuration file to a forum.

Distinguish a connected socket from accepted current data. Check timestamps at the decoder, forwarder and destination. Compare with another feed only after confirming that it uses the same local observations. A remote contact visible in one map may have come from another receiver.

For Skylark, a pending station can receive privately before publication is approved. That state is not fixed by repeatedly generating new station keys. [3]

Reception is good in one direction and poor in another

Compare the bad sector with physical obstructions and aircraft height. Look at comparable periods, not a single missing flight. Return to a previous safe antenna position to test whether a recent move caused the change.

If the problem began after cable or connector work, inspect that work first. If it follows a gain change, restore the recorded setting as a controlled test. Do not change gain, antenna and cable together and then try to infer a cause from the resulting map.

Positions freeze, jump or look impossibly old

Check the original snapshot time and position age. A browser can keep drawing an old result after a connection stops. Uploading that result now does not make the observation new. Use the local JSON inspector to examine basic structure and age.

Look for mixed sources, duplicate identifiers, a stale file path or a clock problem before blaming aircraft behaviour. The inspector's age threshold is a chosen diagnostic threshold, not a network acceptance rule. A file can pass a few structural checks and still contain bad observations.

Ask for help with evidence, not secrets

A useful help request states the host and SDR models, install route, software versions, the last known-good time, what changed and the first point where data disappears. Include a short redacted log excerpt and one annotated screenshot if they help.

Remove account keys, recovery keys, precise receiver location and unrelated personal details. Keep an unredacted copy privately. End with the checks you already tried and their results. It gives maintainers a starting point better than "I followed a guide."