SkylarkField guide / 01

Improve / Skylark field guide

Tune a receiver like an experiment

Change one thing, keep a baseline, and resist the natural temptation to turn everything up.

Documentation reviewed 19 Sep 20263 minute readEdition 01

More gain is not a universal improvement

Gain changes amplification in the receiving chain. It is not a "more aircraft" knob. A setting should earn its place by improving the observations you care about without causing other problems. Different radios and decoder packages expose different controls. Check your installed version's documentation, particularly before replacing an automatic setting with a number found online. [1] [2]

Begin by recording the current configuration. Leave it in place long enough to understand an ordinary day. Inspect the monitoring your installation provides; graphs1090 is one project designed for receiver and host statistics. [3]

Measure a baseline, change one factor, then return to baseline to check whether the difference repeats. This is a suggested experimental design, not measured receiver performance.
Measure a baseline, change one factor, then return to baseline to check whether the difference repeats. This is a suggested experimental design, not measured receiver performance. Original Skylark illustration; schematic unless labelled as a computed model.

Choose a question you can actually answer

"Can I improve reception?" is too broad for an experiment. "Does this antenna position increase fresh local positions on the western approach without reducing the rest?" is better. So is "Do missing messages coincide with host load?"

Pick one primary outcome. Record other observations as checks against a misleading win. For example, a higher total message count is less persuasive if your desired low-altitude sector becomes worse. Do not mix received messages, aircraft count, decoded positions and maximum range as if they were interchangeable.

These are suggested experimental practices, not published performance results. This guide contains no claimed improvement from hardware we have not tested.

An A-B-A comparison

  1. Save configuration A and record an observation window with your current setup.
  2. Change one factor to B. Leave antenna, cable, other settings and software version alone.
  3. Record the same measures over a comparable window. Note unusual traffic, weather and outages.
  4. Return to A and repeat. A reversible improvement is stronger evidence than one busy half-hour.
  5. Keep B only when the benefit survives the checks that matter to your use case.

Traffic is not a controlled laboratory signal. If the result is close, call it inconclusive. There is no prize for giving a small random fluctuation a confident explanation.

Look for a host problem before buying a radio

Check uptime, power warnings where your platform exposes them, temperature, available storage and service restarts. Inspect receiver statistics and logs for processing or device problems. The readsb JSON documentation describes separate local and remote statistics; distinguish them when diagnosing your own reception. [4]

When a gap repeats, write down its time before changing anything. Compare it with host events and network status. A local decoder that kept receiving during a remote outage is evidence for investigating the forwarding path, not the antenna.

Disable an unnecessary new workload as a reversible test only when you understand what it does. Avoid deleting services or wiping storage just because a graph looks untidy.

Leave a result somebody else can use

Publish the equipment, frequency, configuration change, observation windows and measures alongside a result. Explain whether observations were local, MLAT or aggregated. Show gaps instead of joining them with an invented line.

Separate facts from interpretation. "The count increased in these windows" is a measurement. "The filter rejected local interference" is a mechanism that needs further evidence. A forum reader can learn from both statements when they are labelled properly.

Sources and review notes

Documentation reviewed on 19 September 2026. Links lead to the source owners. Versions, account benefits and service terms can change. Hardware installation is not independently bench-tested for this edition.

  1. wiedehopf / readsbMaintainer repository. Decoder, receiver and network configuration.
  2. wiedehopf / airspy-confMaintainer repository. Integration and configuration for airspy_adsb.
  3. wiedehopf / graphs1090Maintainer repository. Receiver and system monitoring.
  4. readsb: JSON output formatsMaintainer specification. Field meanings and units. Mutable development-branch documentation.

How we check and maintain this guide