ON4KST the chat has long been a standard tool for coordinating connections on bands 144 MHz and above, but the chat itself only displays the flow of messages – it does not provide an answer to the question of which station is currently most significant for the operator. This gap is precisely filled by KST4Contest (also known as praktiKST), a Java application by Marc Fröhlich that combines ON4KST chat, connection prioritization, scheduling, data from AirScouts, and integration with logging software in one desktop client.
In the article you will read
What benefits does KST4Contest bring
Počas aktívneho contestu prichádzajú správy, žiadosti o sked, informácie o frekvenciách a zmenách pásma nepretržite. Úlohou operátora je rozpoznať, ktorá časť tejto prevádzky je práve teraz podstatná, ktorého kandidáta sledovať a ktoré spojenie je lepšie naplánovať na neskôr. KST4Contest tento proces rozdeľuje do troch krokov: pozorovanie (správy, lokátory, detegované frekvencie a známa aktivita na pásmach sa priraďujú staniciam naprieč až dvomi kategóriami ON4KST chatu), vyhodnotenie (smer, vzdialenosť, stav QSO, informácie NOT-QRV, aktivita v chate, kontext skedu a dáta z AirScoutu napájajú filtre a skóre pre QSO) a konanie (stanice je možné kontaktovať, naplánovať alebo sledovať, pričom podporované loggery a rozhrania staníc dostávajú informácie potrebné pre ďalší krok prevádzky).
The key feature is that individual functions are not isolated tools - they use the same context of stations, messages, bands, and timing, so a change in one part of the workflow can also affect filters, priorities, and comments in other parts of the program.
How KST4Contest works
The program distinguishes between received information (ON4KST messages, data packets from the logger, network data from Win-Test, and responses from AirScout provide information at various levels of detail - missing fields do not automatically imply negative information) and derived information (bands, frequencies, activity, and candidate priorities can be derived from multiple sources, with explicit NOT-QRV information taking precedence over merely derived opportunities on a given band). Scores, filters, AP windows, and route evaluations reduce the amount of information that needs to be evaluated manuallyevaluate - however, they do not guarantee a connection nor replace the control of the actual operational situation.
The priority score is not the probability of a successful connection, signal strength estimate, propagation forecast, or evidence of the actual direction of the antenna of the station. A value of 800 is not twice as promising as a value of 400 - the values create an order within the current calculation, not a physical scale.
Video: KST4Contest in practice
Connection to PSTRotator, N1MM+, and other logging programs
KST4Contest can calculate the azimuth to the selected station based on both locators and send it directly to the PSTRotator by pressing the button 'Turn ant1 to...' in the Further Info section. The program will turn off the PSTRotator tracking mode, send the target as an integer azimuth, and receive the current position reported by the PSTRotator via UDP (default control port 12000, KST4Contest listens on port 12001). The reported azimuth then becomes the current QTF used as a directional filter, detecting directional opportunities, priority scoring, antenna sector on the map, time axis AP and skeds, and variable MYQTF. For some SPID configurations that do not respond to the first directional command, the program will check the position after two seconds and, if necessary, send a compatible sequence through 0°. The function controls and evaluates only the azimuth; elevation tracking is not part of this interface.
Synchronizácia s logovacím softvérom occurs through three interfaces with varying levels of detail. The Simplelogfile interpreter is widely compatible but can only identify worked callsigns, without band or locator. The general UDP listener for QSO processes packets from UCXLog, N1MM+, QARTest a DXLog.net – where the packet contains band and locator, KST4Contest also updates the QSO status on the given band and locator square. Native integration with Win-Test uses a separate listener for its network protocol, recognizes Win-Test band IDs including 50 and 70 MHz, and stores the resulting activity information in the same internal database. In multi-operator networks, the station name filter prevents STATUS packets from another operating position from overwriting the frequency of the designated radio. Win-Test can also receive skeds created in KST4Contest – submission only occurs when it is possible to determine the frequency corresponding to the chosen band, no fixed backup frequency is inserted solely for the technical validity of the packet. Activity status, NOT-QRV markers, and worked grids are stored in the internal SQLite database and are restored after a restart; contest-related records automatically expire after three days.
Lokálny DX cluster
KST4Contest sa nepripája k verejnému DX klastru a neimportuje externé spoty. Namiesto toho poskytuje lokálny TCP server, ku ktorému sa kompatibilný contestový logger môže pripojiť ako DX-Cluster klient. Program cez toto pripojenie preposiela vybrané informácie už detegované v ON4KST chate – keď sa zdá, že stanica smeruje lokálnym smerom a jej QRG je známe, informácia sa môže objaviť priamo v bandmape loggera bez nutnosti manuálne čítať frekvenciu v chate.
Reálny spot is generated only when all conditions are simultaneously met: detected directed message between two other stations, valid locators of both sender and receiver, sender within the set maximum QRB, lokálna stanica v predpokladanom anténnom koridore odosielateľa, známa použiteľná frekvencia, zapnutý lokálny DX Cluster server and at least one connected client. The directional opportunity is derived geometrically – from comparing the direction between the sender and the receiver of the message with the direction between the sender and the local station, within the configured width of the antenna beam (for example, with a width of 70° it is a corridor of ±35°). The generated spot includes the configured callsign of the spotter, normalized frequency, complete callsign of the detected station, its locator, up to two optional records from AirScout, and the current time. UTC. Lokálne rozhranie DX klastra bolo testované s programami UCXLog a N1MM+.
Information from AirScout
AirScout is able to calculate the route and identify suitable aircraft for signal reflection, but does not know which of the many stations in the ON4KST chat is currently important for the operator. KST4Contest fills in this missing context - it sends relevant active stations to AirScout and assigns the returned information about aircraft to the corresponding chat members. Responsibilities remain separate: AirScout obtains data about aircraft and evaluates the geometry of the reflection, KST4Contest selects the routes of the stations that should be requested and assigns the returned timing to messages, priorities.candidates and the schedule. KST4Contest does not download ADS-B data itself nor does it calculate the geometry of the aircraft.
The program updates requests to AirScout every 60 seconds, with a station included only if it has a usable call sign and locator, its distance is known, its QRB is below the set maximum, and it is possible to determine a usable propagation band. For each AirScout aircraft, it returns the identifier, size category, distance to the expected reflection point, reported potential, and remaining time until expected arrival. This information is displayed in the AP column, in the Further Info section, on a 30-minute timeline and contributes to the priority score - reported.However, the percentage is not interpreted as the probability of connection, nor does a value of 100% mean that the connection will succeed.
Macros and variables
If no station is selected, these variables remain unresolved in the text - intentionally, as an unresolved placeholder is easier to notice than a credible-looking but incomplete message. The completely resolved text of the beacon must not exceed 120 characters, the minimum interval is set to one minute.
Two categories of chat
Activity in VHF, UHF, and microwave bands is not always concentrated in one category of the ON4KST chat. KST4Contest therefore opens up to two simultaneous sessions of the ON4KST chat and processes both in one operational context – each session retains its own chat category, login callsign, public message flow, target category for outgoing messages, and active logged records. Active login is identified by a combination of the complete visible callsign (including suffix) and chat category – both parts are required, so for example,9A0BB-2 and 9A0BB-70 in the same category remain two distinct logins.
Some information describes the radio station as a whole, not a temporary login to the chat - these are aggregated through a normalized basic call sign. The shared context of the station includes the global state of QSO, QSO state by band, manually assigned NOT-QRV tags, known opportunities on bands derived from active variants, and priority scores. A connection with 9A0BB-70 will automatically mark the corresponding basic call sign as worked for other active variants of suffixes - it would be misleading to present 9A0BB-2 as a completely new station immediately afterwards.
Synchronization with the logbook and connection benefits
The chat can continue to display the station as an interesting candidate even after the connection has already been logged. Without synchronization, QSO filters, band columns, and priority calculations would continue to use outdated status. KST4Contest therefore imports information provided by the logging application and applies it to active chat records corresponding to the basic call sign - the program only uses fields provided by the selected interface, missing band or locator data is not estimated.
The QSO monitoring function allows tracking the communication of another station across its KST suffixes directly in the private messages table, without changing the actual direction of the message or chat category. The monitored message is displayed in the format, for example, 'Sniffed: (DN9APW-70 > 9A0BB-23) pse sked 19:30' - useful especially when monitoring how another station from the same team arranges skeds, or when a rare station communicates with multiple potential callers.
Scoring system – QSO priority
Priority score answers the question of which active station to examine next - not whether the connection will succeed. Before assigning weights for activity, AirScout or sked KST4Contest first checks if a usable opportunity on the band is known; if the band opportunities for the distant station are known, but none of them are simultaneously allowed locally and still available, the station receives a score of 0.
The calculation starts with a base value of 100. If the station has not been operated on any supported band, +200 is added; if it has been operated on at least one, −150 is subtracted, with each additional compatible offered band after the first adding +80. The distance then multiplies the sum: under 200 km ×0.7, between 200 km and the set maximum QRB ×1.15, above the maximum QRB ×0.3. AirScout adds +200 for an available aircraft, plus up to +120 depending on the arrival time. The direction of the antenna adds +80 to +200 depending on how close the center of the set beam width is to thestation is located. Current activity in the chat adds +60 to +160 depending on the number of received lines in the set window (default 180 seconds), positive text signals like QRV, READY, or TNX add +120 for five minutes. The response speed after sending /CQ adds +80 (under one minute) or +40 (under three minutes); if no response is received within the set limit (default 13 minutes), a No-Reply strike is added, which divides the running total by 1 + (number of strikes × 0.6). The scheduled sked adds a strong time-dependent contribution of up to +5000 in a three-minute windowbefore the deadline up to one minute after it - a manual designation 'Sked fail' subsequently multiplies the entire final score by 0.15.
Video: Complete workflow KST4Contest
Roadmap
The development of KST4Contest is community-driven and planned through GitHub milestones. The current stable version is 1.42.0 (August Update 2026, released on August 22, 2026), which brought among other things support for 50/70 MHz bands, improved map window behavior, priority boost for band improvement opportunities, and an online indicator.
For version v1.50 ('Greater Overhaul'), features are planned such as filtering in the CQ window, integration of multiple PSTRotators simultaneously, grouping on the map, setting station height, frequency, and k-factor, as well as support for multiple language translations (i18n). Items without an assigned version include, for example, QTF filter with automatic settings, scoreboard integration, a map generator for worked stations, and support for SO2R operation.
Download
KST4Contest je open-source softvér dostupný pre Windows (ZIP x64, bez nutnosti samostatnej inštalácie Javy), Linux (Flatpak, AppImage x86_64, natívne balíčky DEB pre Debian/Ubuntu, RPM pre Fedora a pkg.tar.zst pre Arch Linux) a macOS (DMG pre Apple Silicon aj Intel, od verzie 1.42 podpísané a notarizované Apple). Okrem stabilného vydania sú k dispozícii aj nightly zostavenia priamo z hlavnej vetvy pre testovanie konkrétnej opravy alebo funkcie – tie sú však automatizované, neprehliadnuté a autor výslovne odporúča ich nepoužívať počas reálnej contestovej prevádzky. Súčasťou stabilného vydania sú aj kompletné PDF manuály v angličtine a nemčine. Všetky balíčky sú dostupné cez GitHub repozitár praktimarc/kst4contest.
Summary
KST4Contest addresses a specific operational problem of VKV/UHF/SHF contesting - the conversion of the continuous stream of messages from the ON4KST chat into a clear operational priority. By combining priority scoring, integration with AirScout, rotor control via PSTRotator, synchronization with loggers (including native support for Win-Test), local DX cluster, and a sked system with comments, it creates a unified working context where a change in one place affects filters and priorities elsewhere. The program rigorously distinguishes between what it knows for certain and what is only inferred.hint - the final decision to call a station always remains with the operator. The current stable version, complete documentation, and source code are freely available at kst4contest.hamradioonline.de and on GitHub.