mirror of
https://github.com/praktimarc/kst4contest.git
synced 2026-08-24 11:06:59 +02:00
updated website for sked and timeline features
This commit is contained in:
@@ -1,25 +1,59 @@
|
||||
---
|
||||
title: Log Synchronization
|
||||
title: Log Synchronisation
|
||||
icon: 🔄
|
||||
category: Logger Integration
|
||||
since: "1.31"
|
||||
summary: Import worked stations and current frequencies from supported contest loggers so filters and band information follow the log.
|
||||
description: KST4Contest receives worked-station and, where supported, frequency data from UCXLog, N1MM+, QARTest, DXLog.net and Win-Test through file and UDP interfaces.
|
||||
summary: Import callsign, band, locator and QRG information from supported contest loggers at the level provided by each interface.
|
||||
description: KST4Contest connects chat activity with current log state through file-based evaluation, general QSO UDP packets and the native Win-Test network protocol.
|
||||
tagsList:
|
||||
- Win-Test
|
||||
- UCXLog
|
||||
- N1MM+
|
||||
- QARTest
|
||||
- DXLog.net
|
||||
- contest logger
|
||||
related:
|
||||
- priority-score
|
||||
- dual-chat
|
||||
- sked-reminder
|
||||
---
|
||||
|
||||
## Connect chat and logging
|
||||
## Why connect the logger?
|
||||
|
||||
Contest operation is faster when chat information and log state are connected.
|
||||
The chat may still show a station as an interesting candidate after the QSO has already been logged. Without synchronisation, Worked filters, band columns and priority calculations would continue to use an outdated contest state.
|
||||
|
||||
KST4Contest can use logger information to improve workflow awareness.
|
||||
KST4Contest therefore imports the information provided by the logging application and applies it to the active chat entries of the corresponding base callsign.
|
||||
|
||||
## Worked and band awareness
|
||||
## Three interfaces with different levels of detail
|
||||
|
||||
Log synchronization helps the client understand which stations and bands are relevant.
|
||||
The available information depends on the interface:
|
||||
|
||||
| Interface | Callsign | Band | Locator |
|
||||
|---|---:|---:|---:|
|
||||
| Simplelogfile interpreter | yes | no | no |
|
||||
| General QSO UDP listener | yes | when included | when included |
|
||||
| Win-Test network listener | yes | yes | when included |
|
||||
|
||||
The Simplelogfile interpreter is broadly compatible but can only identify worked callsigns. A callsign match in a file does not provide enough information to infer a reliable band or grid square.
|
||||
|
||||
The general UDP listener processes packets from UCXLog, N1MM+, QARTest and DXLog.net. Where the packet contains band and locator data, KST4Contest also updates the per-band Worked state and worked grid square.
|
||||
|
||||

|
||||
|
||||
## Native Win-Test integration
|
||||
|
||||
Win-Test uses a separate listener for its native network protocol. KST4Contest resolves the Win-Test band ID, including 50 and 70 MHz, and stores the resulting Worked information in the same internal database.
|
||||
|
||||
STATUS packets can also update the local QRG. In multi-operator networks, a station-name filter prevents STATUS packets from another operating position from replacing the frequency of the intended radio.
|
||||
|
||||
Win-Test can additionally receive skeds created in KST4Contest. The handover only takes place when a QRG matching the selected band can be determined. No fixed fallback frequency is inserted merely to make the packet technically valid.
|
||||
|
||||
> The band-aware sked handover and explicit `SSB`/`CW` selection are included in Nightly / v1.42.
|
||||
|
||||
## Stored state and limitations
|
||||
|
||||
Worked, NOT-QRV and worked-grid information is stored in the internal SQLite database and restored after a restart. Contest-related records expire automatically after three days.
|
||||
|
||||
KST4Contest can only use the fields supplied by the selected interface. Missing band or locator data is not reconstructed from guesswork. This makes the result less complete in some cases, but also avoids turning an incomplete log packet into incorrect Worked information.
|
||||
|
||||
[Read the complete log synchronisation setup in the manual.](/manual/en/log-sync/)
|
||||
Reference in New Issue
Block a user