ON4KST contest workflow for 144 MHz and above

KST4Contest

ON4KST shows you the traffic. KST4Contest helps turn it into an operating decision by combining chat, candidate prioritisation, sked planning, AirScout data and logger integration in one desktop client.

The available information is filtered, related to active stations and presented in a contest-oriented workflow. The final decision still belongs to the operator.

Functions sharing the same station context
KST4Contest Functions
↩️ Automatic Private Replies Answer repeated private messages or QRG requests without losing the complete callsign, chat category or protection against automatic reply loops.
🧭 PSTRotator Control Point the antenna at a selected chat station and use the azimuth reported by PSTRotator throughout the KST4Contest operating context.
👁️ QSO Monitoring Follow messages sent or received by one station across its KST suffixes without changing the actual message destination or chat category.
⚡ Macros and Variables Insert recurring text through shortcut buttons or snippets and add current QRG, locator, heading, station-name and AirScout information when the message is used.
✈️ AirScout Integration Request station-specific aircraft-scatter information from AirScout and include the returned AP timing in the user list, timeline and candidate priority.

The operating problem

The useful station is rarely the only station in the chat

During an active contest, messages, sked requests, frequency information and band changes arrive continuously. The task is to identify which part of that traffic matters now, which candidate should be monitored and which contact is better scheduled for later.

Observe

Messages, locators, detected frequencies and known band activity are assigned to stations across as many as two ON4KST chat categories.

Evaluate

Direction, distance, worked status, NOT-QRV information, chat activity, sked context and aircraft scatter data feed filters and candidate scores.

Act

Candidates can be contacted, scheduled or monitored. Skeds remain visible, while supported loggers and station interfaces receive the information required for the next operating step.

Functions

One workflow, shared context

The individual functions are not isolated tools. They use the same station, message, band and timing information, so that a change in one part of the workflow can also affect filters, priorities and reminders.

🧭

Station Control

PSTRotator Control

Point the antenna at a selected chat station and use the azimuth reported by PSTRotator throughout the KST4Contest operating context.

Read how it works →
👁️

ON4KST Chat

QSO Monitoring

Follow messages sent or received by one station across its KST suffixes without changing the actual message destination or chat category.

Read how it works →

Operator Speed

Macros and Variables

Insert recurring text through shortcut buttons or snippets and add current QRG, locator, heading, station-name and AirScout information when the message is used.

Read how it works →
✈️

Aircraft Scatter

AirScout Integration

Request station-specific aircraft-scatter information from AirScout and include the returned AP timing in the user list, timeline and candidate priority.

Read how it works →
🎯

Contest Workflow

Priority Score System

Calculate one priority per base callsign, exclude known unusable band combinations and order the remaining active stations by band, distance, direction, activity, AirScout, reply and sked context.

Read how it works →
🔔

Sked Management

Sked Reminder

Create a timed contact, raise its priority, show it on the timeline and optionally send reminder PMs before the agreed time.

Read how it works →

Limits

A priority score is not a propagation forecast

KST4Contest can only evaluate the information it knows. Scores, AP windows, filters and path profiles support the operator's decision; they do not guarantee a contact. If the input data is incomplete or outdated, the result can be incomplete or outdated as well.

Project status

Stable for operation, Nightly for testing

KST4Contest is open-source software. The current stable release is the normal choice for contest operation. Nightly builds follow ongoing development and are useful when a particular fix or feature needs testing. A few minutes before a contest is not the ideal time to discover what changed.