mirror of
https://github.com/praktimarc/kst4contest.git
synced 2026-09-10 19:25:32 +02:00
manual: corrected behaviour description of simplelogfile, Airscout, MYQTF, corrected some typos
This commit is contained in:
Marc Froehlich
@@ -2,7 +2,7 @@
|
||||
|
||||
> 🇬🇧 [English version](en-AirScout-Integration) | 🇩🇪 Du liest gerade die deutsche Version
|
||||
|
||||
AirScout (von DL2ALF) ist ein Programm zur Erkennung von Flugzeugen für den Aircraft-Scatter-Betrieb. KST4Contest ist eng mit AirScout integriert und zeigt reflektierbare Flugzeuge direkt in der Benutzerliste an.
|
||||
AirScout (von DL2ALF) berechnet Aircraft-Scatter-Gelegenheiten anhand aktueller Flugzeugpositionen. KST4Contest übernimmt diese Ergebnisse und zeigt für die jeweilige Gegenstation geeignete Flugzeuge direkt in der Benutzerliste an.
|
||||
|
||||
> **Aircraft Scatter** ermöglicht sehr weitreichende Verbindungen auf VHF und höher – auch für Stationen mit geringer Höhe über NN oder ungünstigen topografischen Verhältnissen.
|
||||
|
||||
@@ -15,9 +15,9 @@ Download von AirScout:
|
||||
|
||||
---
|
||||
|
||||
## Flugzeugdaten-Feeds (ADSB)
|
||||
## Flugzeugdaten-Feeds (ADS-B)
|
||||
|
||||
Öffentliche Flugzeugdaten-Feeds im Internet sind oft unzuverlässig und begrenzt nutzbar. Eine empfohlene Alternative bietet **OV3T (Thomas)** mit einem dedizierten ADSB-Feed-Dienst:
|
||||
Öffentliche Flugzeugdaten-Feeds im Internet sind oft unzuverlässig und nur eingeschränkt nutzbar. Eine empfohlene Alternative bietet **OV3T (Thomas)** mit einem dedizierten ADS-B-Feed-Dienst:
|
||||
|
||||
- https://airscatter.dk/
|
||||
- https://www.facebook.com/groups/825093981868542
|
||||
@@ -28,7 +28,7 @@ Für diesen Dienst ist ein Account erforderlich. Bitte eine Spende für Thomas i
|
||||
|
||||
## AirScout einrichten
|
||||
|
||||
### Schritt 1: ADSB-Feed in AirScout konfigurieren
|
||||
### Schritt 1: ADS-B-Feed in AirScout konfigurieren
|
||||
|
||||
1. AirScout starten.
|
||||
2. In den AirScout-Einstellungen den OV3T-Feed-Account eintragen (Benutzername, Passwort, URL).
|
||||
@@ -85,32 +85,40 @@ Andernfalls kann es zu fehlerhaften AP-Daten kommen.
|
||||
|
||||
## AP-Spalte in der Benutzerliste
|
||||
|
||||
Nach der Einrichtung erscheint in der Benutzerliste eine **AP-Spalte** mit bis zu zwei reflektierbaren Flugzeugen pro Station.
|
||||
Nach der Einrichtung erscheint in der Benutzerliste eine **AP-Spalte**. Sie zeigt für jede Station die Ankunftszeit und das von AirScout berechnete Reflexionspotenzial der ersten beiden geeigneten Flugzeuge.
|
||||
|
||||
Beispiel-Darstellung:
|
||||
|
||||
| Station | AP-Info |
|
||||
|---|---|
|
||||
| DF9QX | 2 Planes: 0 min / 0 min, je 100% |
|
||||
| F5DYD | 2 Planes: 14 min / 31 min, je 50% |
|
||||
| DF9QX | 0 (100 %) / 0 (100 %) |
|
||||
| F5DYD | 14 (50 %) / 31 (50 %) |
|
||||
|
||||
Die Zahl vor der Klammer gibt die verbleibenden Minuten bis zur berechneten Gelegenheit an. Die Prozentzahl beschreibt das von AirScout gemeldete Reflexionspotenzial. Sie ist keine QSO-Wahrscheinlichkeit.
|
||||
|
||||
Die AP-Informationen sind auch im **Privatnachrichten-Fenster** verfügbar.
|
||||
|
||||
Die Prozentzahl gibt das Reflexionspotenzial an (Größe des Flugzeugs, Höhe, Entfernung).
|
||||
## Einfluss auf Priority Score und Timeline
|
||||
|
||||
Mindestens ein von AirScout als erreichbar gemeldetes Flugzeug erhöht den Priority Score der Station. Eine unmittelbar bevorstehende Gelegenheit in null, einer oder zwei Minuten wird zusätzlich zeitabhängig gewichtet. AirScout ist dabei nur ein Faktor neben Worked-Status, verfügbaren Bändern, QRB, Antennenrichtung, Chat-Aktivität und Skeds.
|
||||
|
||||
Die AP- und Sked-Timeline verwendet den Priority Score zur Auswahl interessanter Stationen und ordnet die nächste geeignete Aircraft-Scatter-Gelegenheit zeitlich ein. Das Reflexionspotenzial bestimmt zusätzlich die Darstellung des AP-Symbols. Die Timeline bleibt eine Vorschau; sie garantiert kein QSO.
|
||||
|
||||
---
|
||||
|
||||
## AP-Variablen in Nachrichten
|
||||
|
||||
Die Flugzeugdaten können direkt in Nachrichten eingefügt werden:
|
||||
Die Flugzeugdaten der ausgewählten Station können direkt in Shortcuts, Snippets und andere stationsbezogene Nachrichten eingefügt werden:
|
||||
|
||||
- `FIRSTAP` → z. B. `a very big AP in 1 min`
|
||||
- `SECONDAP` → z. B. `Next big AP in 9 min`
|
||||
|
||||
Details: [Makros und Variablen](de-Makros-und-Variablen#variablen)
|
||||
|
||||
Da die Werte eine ausgewählte Gegenstation benötigen, stehen `FIRSTAP` und `SECONDAP` nicht als globale Beacon-Variablen zur Verfügung.
|
||||
|
||||
---
|
||||
|
||||
## „Show Path in AirScout"-Button
|
||||
|
||||
In der Benutzerliste gibt es einen Button mit einem Pfeil, der die Richtung (QTF) zur ausgewählten Station anzeigt. Ein Klick maximiert AirScout und zeigt den Pfad mit reflektierbaren Flugzeugen zum ausgewählten Gesprächspartner.
|
||||
In der Benutzerliste gibt es einen Button mit einem Pfeil, der die Richtung (QTF) zur ausgewählten Station anzeigt. Ein Klick maximiert das externe AirScout-Fenster und lässt dort den Pfad zur ausgewählten Gegenstation mit den berechneten Aircraft-Scatter-Gelegenheiten anzeigen. Die Schaltfläche startet keine eigene Gelände- oder Ausbreitungsberechnung in KST4Contest.
|
||||
|
||||
@@ -34,6 +34,8 @@ v1.42 führt mehrere bisher getrennte Auswertungen zusammen. Bandinformationen,
|
||||
|
||||
- **Manuelle QTF-Eingabe:** Die aktuelle Antennenrichtung kann auch ohne PSTRotator direkt in KST4Contest geändert werden.
|
||||
|
||||
- **Nachrichtenvariable `MYQTF`:** Die aktuelle Antennenrichtung kann als numerischer Winkel in Grad in Shortcuts, Snippets und andere unterstützte Nachrichtentexte eingesetzt werden.
|
||||
|
||||
- **Filter zurücksetzen:** Ein eigener Reset-Button entfernt die aktiven Filterprädikate der Benutzerliste zuverlässig.
|
||||
|
||||
- **Kartencluster:** Räumlich dicht beieinanderliegende Stationen werden bei niedrigen Zoomstufen zusammengefasst. Die ausgewählte Station und relevante Richtungsgelegenheiten bleiben einzeln sichtbar.
|
||||
@@ -80,7 +82,7 @@ v1.42 führt mehrere bisher getrennte Auswertungen zusammen. Bandinformationen,
|
||||
|
||||
- **DXLog-Gesamtlog übernommen:** Der UCXLog-kompatible UDP-Listener verarbeitet neben `contactinfo` auch `contactreplace`. Dadurch kann ein von DXLog.net als vollständiges Log ausgesendeter Datenbestand eingelesen werden.
|
||||
|
||||
- **Simplelogfile-Verhalten präzisiert:** Die ausgewählte Textdatei wird einmal pro Minute mit einem festen Rufzeichenmuster ausgewertet. Treffer setzen den globalen Worked-Status aller aktiven Varianten des Basisrufzeichens, werden aber nicht in SQLite persistiert. Eine fehlende Datei wird angelegt; Lese- und Erstellungsfehler beenden die periodische Auswertung nicht.
|
||||
- **Simplelogfile-Verhalten präzisiert:** Die ausgewählte Textdatei wird einmal pro Minute mit einem festen Rufzeichenmuster ausgewertet. Treffer setzen den globalen Worked-Status aller aktiven Varianten des Basisrufzeichens, werden aber nicht in SQLite persistiert. Eine fehlende Datei wird angelegt; Lese- und Erstellungsfehler beenden die periodische Auswertung nicht. Ein Datenbank-Reset verändert die Datei nicht, sodass enthaltene Rufzeichen bei der nächsten Auswertung erneut als gearbeitet markiert werden.
|
||||
|
||||
- **Automatische QRG-Übernahme abgesichert:** `MYQRG` wird nur von einer aktivierten Schnittstelle aktualisiert, die tatsächlich gültige `RadioInfo`- beziehungsweise Win-Test-`STATUS`-Pakete liefert. Eine aktivierte, aber nicht liefernde Quelle ersetzt die notwendige Funktionsprüfung oder manuelle QRG-Pflege nicht.
|
||||
|
||||
@@ -415,7 +417,6 @@ Erste öffentlich veröffentlichte Version. Grundfunktionen:
|
||||
|
||||
## Geplante Features
|
||||
|
||||
- `MYQTF`-Variable (eigene Antennenrichtung als Text)
|
||||
- ~~Lebensdauer für den Worked-Status (automatisches Zurücksetzen)~~ ✅ **Umgesetzt in v1.40** (3-Tage-Lebensdauer, kein manuelles Zurücksetzen mehr nötig)
|
||||
- Filterung des „Cluster & QSO der anderen"-Fensters auf eigenes QTF
|
||||
- Weitere Topografie-basierte Berechnungen für die Richtungswarnung
|
||||
|
||||
@@ -207,7 +207,7 @@ Im Klartext: Ein erkannter Hinweis bedeutet „wahrscheinlich auf diesem Band ak
|
||||
|
||||
Worked-, NOT-QRV- und Großfeldinformationen aus den Netzwerkschnittstellen sowie manuelle Markierungen werden in der internen SQLite-Datenbank gespeichert und beim nächsten Start wieder geladen. Die Einträge laufen nach drei Tagen automatisch ab. Ein Reset vor jedem Contest ist deshalb normalerweise nicht erforderlich.
|
||||
|
||||
Simplelogfile-Treffer sind davon ausgenommen. Sie werden nicht in SQLite persistiert, sondern bei jedem Programmlauf aus der ausgewählten Datei abgeleitet. Die Datei ist damit die dauerhafte Quelle. Der Interpreter entfernt während der laufenden Sitzung keine bereits gesetzte Worked-Markierung und setzt den Zustand beim Wechsel zu einem neuen Contest nicht automatisch zurück.
|
||||
Simplelogfile-Treffer sind davon ausgenommen. Sie werden nicht in SQLite persistiert, sondern bei jedem Programmlauf aus der ausgewählten Datei abgeleitet. Die Datei ist damit die dauerhafte Quelle. Der Interpreter entfernt während der laufenden Sitzung keine bereits gesetzte Worked-Markierung und setzt den Zustand beim Wechsel zu einem neuen Contest nicht automatisch zurück. Ein manueller Datenbank-Reset verändert oder leert die Datei ebenfalls nicht. Darin enthaltene Rufzeichen werden bei der nächsten Auswertung innerhalb einer Minute erneut als gearbeitet markiert.
|
||||
|
||||
Ein manueller Reset unter **Workedstn database** entfernt sämtliche Worked-Markierungen, NOT-QRV-Tags und gespeicherten Worked-Großfelder. Die bekannten Rufzeichenzeilen bleiben dabei in der Datenbank erhalten. Einzelheiten: [Worked Station Database Settings](de-Konfiguration#worked-station-database-settings-gearbeitete-stationen-datenbank).
|
||||
|
||||
@@ -523,7 +523,7 @@ UDP selbst bestätigt außerdem keine Paketzustellung. Bleibt die QTF unverände
|
||||
|
||||
Im Klartext: KST4Contest liefert die Zielrichtung und verarbeitet die gemeldete Position. Die mechanische Realität bleibt Aufgabe des Rotators – und gelegentlich der Blick aus dem Fenster.
|
||||
|
||||
Konfiguration und Portbelegung: [Konfiguration – PSTRotator-Einstellungen](de-Konfiguration#pstrotator-einstellungen-ab-v131-vollstaendig-konfigurierbar-ab-v140).
|
||||
Konfiguration und Portbelegung: [Konfiguration – PSTRotator-Einstellungen](de-Konfiguration#pstrotator-einstellungen-ab-v131-vollständig-konfigurierbar-ab-v140).
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -109,7 +109,7 @@ Drei Methoden stehen zur Verfügung, um gearbeitete Stationen automatisch zu mar
|
||||
|
||||
### Universal File Based Callsign Interpreter (Simplelogfile)
|
||||
|
||||
Liest die ausgewählte Textdatei einmal pro Minute mit einem fest eingebauten Rufzeichenmuster. Die Treffer werden auf Basisrufzeichen normalisiert und setzen für alle aktiven Varianten nur den globalen Worked-Status. Band- und Locatorinformationen können daraus nicht abgeleitet werden. Die Funktion eignet sich als Fallback für Logprogramme ohne unterstützte Netzwerkschnittstelle.
|
||||
Liest die ausgewählte Textdatei einmal pro Minute mit einem fest eingebauten Rufzeichenmuster. Die Treffer werden auf Basisrufzeichen normalisiert und setzen für alle aktiven Varianten nur den globalen Worked-Status. Band- und Locatorinformationen können daraus nicht abgeleitet werden. Die Funktion eignet sich als Fallback für Logprogramme ohne unterstützte Netzwerkschnittstelle. Vor der Verwendung sollte deshalb geprüft werden, ob das eingesetzte Logprogramm bereits eine der unterstützten Netzwerkschnittstellen bereitstellt.
|
||||
|
||||
Existiert die ausgewählte Datei noch nicht, legt KST4Contest sie an und zeigt einmalig den vollständigen Pfad sowie Hinweise zum Funktions- und Contesttest. Die Datei ist selbst die dauerhafte Quelle; aus ihr abgeleitete Worked-Markierungen werden nicht in SQLite gespeichert und nicht automatisch für einen neuen Contest zurückgesetzt.
|
||||
|
||||
@@ -862,7 +862,7 @@ Die interne SQLite-Datenbank speichert die contestbezogenen Zustände unabhängi
|
||||
- manuell gesetzte NOT-QRV-Tags pro Band und
|
||||
- gearbeitete vierstellige Großfelder pro Band.
|
||||
|
||||
Eine Ausnahme bilden Worked-Markierungen des Simplelogfile-Interpreters. Sie werden nur aus der ausgewählten Datei in den laufenden Zustand übernommen und nicht in SQLite persistiert. Die Datei ist die dauerhafte Quelle und besitzt keinen automatischen Contest-Reset.
|
||||
Eine Ausnahme bilden Worked-Markierungen des Simplelogfile-Interpreters. Sie werden nur aus der ausgewählten Datei in den laufenden Zustand übernommen und nicht in SQLite persistiert. Die Datei ist die dauerhafte Quelle und besitzt keinen automatischen Contest-Reset. Ein Datenbank-Reset verändert oder leert sie nicht; enthaltene Rufzeichen werden bei der nächsten periodischen Auswertung erneut als gearbeitet markiert.
|
||||
|
||||
Als Schlüssel wird das normalisierte Rufzeichen ohne sichtbare Chat-Klammern oder Kategorieformatierung verwendet. Dadurch können aktive Varianten desselben Rufzeichens konsistent ausgewertet werden.
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@ Die Grenze ist ebenso eindeutig: Aus einem reinen Rufzeichentreffer lassen sich
|
||||
|
||||
Den Pfad der Textdatei im Reiter **Log sync** auswählen. Fehlt die Datei, legt KST4Contest sie an und zeigt einmalig einen nicht blockierenden Hinweis mit dem Pfad und den nächsten Prüfschritten an. Lese- oder Erstellungsfehler werden protokolliert; die minütliche Auswertung läuft beim nächsten Termin weiter. Für bandbezogene Auswertungen sollte nach Möglichkeit eine der Netzwerkschnittstellen verwendet werden.
|
||||
|
||||
Der aus dem Simplelogfile abgeleitete Worked-Status wird nicht in der internen SQLite-Datenbank gespeichert. Die ausgewählte Datei ist die dauerhafte Quelle und wird auch nach einem Neustart erneut eingelesen. Der Interpreter setzt nur positive Worked-Markierungen; er entfernt während der laufenden Programmsitzung keine bereits gesetzte Markierung und führt beim Wechsel zu einem neuen Contest keinen automatischen Reset durch. Vor jedem Contest sollte deshalb geprüft werden, ob das Logprogramm genau die aktuelle Contestdatei beschreibt.
|
||||
Der aus dem Simplelogfile abgeleitete Worked-Status wird nicht in der internen SQLite-Datenbank gespeichert. Die ausgewählte Datei ist die dauerhafte Quelle und wird auch nach einem Neustart erneut eingelesen. Der Interpreter setzt nur positive Worked-Markierungen; er entfernt während der laufenden Programmsitzung keine bereits gesetzte Markierung und führt beim Wechsel zu einem neuen Contest keinen automatischen Reset durch. Auch ein manueller Datenbank-Reset ändert oder leert das Simplelogfile nicht. Darin enthaltene Rufzeichen werden bei der nächsten Auswertung innerhalb einer Minute erneut als gearbeitet markiert. Vor jedem Contest sollte deshalb geprüft werden, ob das Logprogramm genau die aktuelle Contestdatei beschreibt.
|
||||
|
||||
---
|
||||
|
||||
@@ -203,6 +203,6 @@ Die Datenquellen liefern unterschiedlich genaue Informationen:
|
||||
| QSO-UDP-Listener | ja | ja, wenn im Paket enthalten | ja, wenn Band und Locator enthalten sind |
|
||||
| Win-Test-Netzwerk-Listener | ja | ja | ja, wenn ein Locator enthalten ist |
|
||||
|
||||
Die in SQLite gespeicherten Daten werden beim Programmstart wieder geladen und bei neuen Logeinträgen während des Betriebs aktualisiert. Sie laufen nach drei Tagen automatisch ab. Ein Reset vor jedem Contest ist daher normalerweise nicht erforderlich. Für den Simplelogfile-Interpreter gilt diese Lebensdauer nicht: Seine Datei bleibt die dauerhafte Quelle und wird nicht automatisch auf einen neuen Contest zurückgesetzt.
|
||||
Die in SQLite gespeicherten Daten werden beim Programmstart wieder geladen und bei neuen Logeinträgen während des Betriebs aktualisiert. Sie laufen nach drei Tagen automatisch ab. Ein Reset vor jedem Contest ist daher normalerweise nicht erforderlich. Für den Simplelogfile-Interpreter gilt diese Lebensdauer nicht: Seine Datei bleibt die dauerhafte Quelle und wird durch einen Datenbank-Reset weder geändert noch geleert. Enthaltene Rufzeichen setzt die nächste periodische Auswertung erneut auf den globalen Worked-Status.
|
||||
|
||||
Ein vollständiger manueller Reset entfernt Worked-Markierungen, NOT-QRV-Tags und Worked-Großfelder gemeinsam. Weitere Einzelheiten: [Worked Station Database Settings](de-Konfiguration#worked-station-database-settings-gearbeitete-stationen-datenbank).
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
> 🇬🇧 You are reading the English version | 🇩🇪 [Deutsche Version](de-AirScout-Integration)
|
||||
|
||||
AirScout (by DL2ALF) is a program for detecting aircraft for aircraft scatter operation. KST4Contest is tightly integrated with AirScout and shows reflectable aircraft directly in the user list.
|
||||
AirScout (by DL2ALF) calculates aircraft-scatter opportunities from current aircraft positions. KST4Contest receives these results and displays aircraft suitable for the path to each remote station directly in the user list.
|
||||
|
||||
> **Aircraft Scatter** enables very long-distance communication on VHF and higher – even for stations with low altitude above sea level or unfavourable topographic conditions.
|
||||
|
||||
@@ -15,9 +15,9 @@ Download AirScout from:
|
||||
|
||||
---
|
||||
|
||||
## Aircraft Data Feeds (ADSB)
|
||||
## Aircraft Data Feeds (ADS-B)
|
||||
|
||||
Public aircraft data feeds on the internet are often unreliable and limited in use. A recommended alternative is the dedicated ADSB feed service provided by **OV3T (Thomas)**:
|
||||
Public aircraft data feeds on the internet are often unreliable and of limited use. A recommended alternative is the dedicated ADS-B feed service provided by **OV3T (Thomas)**:
|
||||
|
||||
- https://airscatter.dk/
|
||||
- https://www.facebook.com/groups/825093981868542
|
||||
@@ -28,7 +28,7 @@ An account is required for this service. Please consider donating to Thomas –
|
||||
|
||||
## Setting Up AirScout
|
||||
|
||||
### Step 1: Configure the ADSB Feed in AirScout
|
||||
### Step 1: Configure the ADS-B Feed in AirScout
|
||||
|
||||
1. Start AirScout.
|
||||
2. Enter your OV3T feed account details (username, password, URL) in the AirScout settings.
|
||||
@@ -85,32 +85,40 @@ Otherwise, it may result in incorrect AP data.
|
||||
|
||||
## AP Column in the User List
|
||||
|
||||
After setup, an **AP column** appears in the user list showing up to two reflectable aircraft per station.
|
||||
After setup, an **AP column** appears in the user list. For each station, it shows the arrival time and the AirScout reflection potential of the first two suitable aircraft.
|
||||
|
||||
Example display:
|
||||
|
||||
| Station | AP Info |
|
||||
|---|---|
|
||||
| DF9QX | 2 Planes: 0 min / 0 min, 100% each |
|
||||
| F5DYD | 2 Planes: 14 min / 31 min, 50% each |
|
||||
| DF9QX | 0 (100%) / 0 (100%) |
|
||||
| F5DYD | 14 (50%) / 31 (50%) |
|
||||
|
||||
The number before the brackets is the number of minutes remaining until the calculated opportunity. The percentage is the reflection potential reported by AirScout. It is not a QSO probability.
|
||||
|
||||
AP information is also available in the **private messages window**.
|
||||
|
||||
The percentage indicates the reflection potential (aircraft size, altitude, distance).
|
||||
## Effect on the Priority Score and Timeline
|
||||
|
||||
At least one aircraft reported as reachable by AirScout raises the station's Priority Score. An opportunity expected in zero, one or two minutes receives additional time-dependent weighting. AirScout is only one factor alongside Worked status, available bands, QRB, antenna direction, chat activity and skeds.
|
||||
|
||||
The AP and sked timeline uses the Priority Score to select interesting stations and places the next suitable aircraft-scatter opportunity on the time axis. The reflection potential also controls how the AP marker is displayed. The timeline remains a preview and does not guarantee a QSO.
|
||||
|
||||
---
|
||||
|
||||
## AP Variables in Messages
|
||||
|
||||
Aircraft data can be inserted directly into messages:
|
||||
Aircraft data for the selected station can be inserted directly into shortcuts, snippets and other station-specific messages:
|
||||
|
||||
- `FIRSTAP` → e.g. `a very big AP in 1 min`
|
||||
- `SECONDAP` → e.g. `Next big AP in 9 min`
|
||||
|
||||
Details: [Macros and Variables](en-Macros-and-Variables#variables)
|
||||
|
||||
Because these values require a selected remote station, `FIRSTAP` and `SECONDAP` are not available as global beacon variables.
|
||||
|
||||
---
|
||||
|
||||
## "Show Path in AirScout" Button
|
||||
|
||||
In the user list there is a button with an arrow showing the direction (QTF) to the selected station. Clicking it maximises AirScout and shows the path with reflectable aircraft to the selected contact.
|
||||
In the user list there is a button with an arrow showing the direction (QTF) to the selected station. Clicking it maximises the external AirScout window and displays the path to the selected remote station together with the calculated aircraft-scatter opportunities. The button does not start a separate terrain or propagation calculation in KST4Contest.
|
||||
|
||||
@@ -34,6 +34,8 @@ v1.42 brings several previously separate calculations together. Band information
|
||||
|
||||
- **Manual QTF input:** The current antenna direction can be changed directly in KST4Contest when PSTRotator is not being used.
|
||||
|
||||
- **`MYQTF` message variable:** The current antenna direction can be inserted as a numeric angle in degrees into shortcuts, snippets and other supported message texts.
|
||||
|
||||
- **Filter reset:** A dedicated reset button reliably removes the active user-list filter predicates.
|
||||
|
||||
- **Map clustering:** Stations close to each other are grouped at lower zoom levels. The selected station and relevant direction opportunities remain individually visible.
|
||||
@@ -80,7 +82,7 @@ v1.42 brings several previously separate calculations together. Band information
|
||||
|
||||
- **DXLog full-log import:** In addition to `contactinfo`, the UCXLog-compatible UDP listener processes `contactreplace`. This allows a complete log broadcast by DXLog.net to be imported.
|
||||
|
||||
- **Defined Simplelogfile behaviour:** The selected text file is evaluated once per minute using a fixed callsign pattern. Matches set the global Worked status for all active variants of the base callsign but are not persisted in SQLite. A missing file is created, and read or creation errors do not terminate the periodic task.
|
||||
- **Defined Simplelogfile behaviour:** The selected text file is evaluated once per minute using a fixed callsign pattern. Matches set the global Worked status for all active variants of the base callsign but are not persisted in SQLite. A missing file is created, and read or creation errors do not terminate the periodic task. A database reset does not change the file, so callsigns contained in it are marked as worked again during the next evaluation.
|
||||
|
||||
- **Guarded automatic QRG updates:** `MYQRG` is updated only by an enabled interface which actually supplies valid `RadioInfo` or Win-Test `STATUS` packets. An enabled source which provides no data does not remove the need for a functional check or manual QRG maintenance.
|
||||
|
||||
@@ -414,7 +416,6 @@ First publicly released version. Core features:
|
||||
|
||||
## Planned Features
|
||||
|
||||
- `MYQTF` variable (own antenna direction as text)
|
||||
- ~~Lifetime for worked status (automatic reset)~~ ✅ **Implemented in v1.40** (3-day lifetime, no manual reset needed anymore)
|
||||
- Filtering the "Cluster & QSO of others" window to own QTF
|
||||
- Further topography-based calculations for direction warnings
|
||||
|
||||
@@ -136,7 +136,7 @@ The general QSO UDP listener is the recommended interface for UCXLog, QARTest, N
|
||||
|
||||
Win-Test uses its own network protocol and therefore has a separate listener. Its default port is `9871`. If this port is changed while the listener is enabled, KST4Contest restarts the Win-Test listener on the new port. After changing the shared UDP port `12060`, KST4Contest must instead be restarted completely.
|
||||
|
||||
All enabled input paths may be used in parallel and identical reports do not create separate Worked states. Network-derived Worked information is stored in the internal database. Simplelogfile marks remain runtime state derived from the selected file. KST4Contest must be running when a network QSO is transmitted unless the logging application can resend the existing log.
|
||||
All enabled input paths may be used in parallel and identical reports do not create separate Worked states. Network-derived Worked information is stored in the internal database. Simplelogfile marks remain runtime state derived from the selected file. Before using Simplelogfile, check whether the logging application already provides one of the supported network interfaces. KST4Contest must be running when a network QSO is transmitted unless the logging application can resend the existing log.
|
||||
|
||||
Configuration of the individual logging applications, band and locator handling, and the Win-Test sked handover are described under [Log Synchronisation](en-Log-Sync).
|
||||
|
||||
@@ -919,7 +919,7 @@ The internal SQLite database stores contest-related state independently of the l
|
||||
- manually assigned NOT-QRV marks per band, and
|
||||
- worked four-character grid squares per band.
|
||||
|
||||
Worked marks from the Simplelogfile interpreter are the exception. They are copied from the selected file into runtime state only and are not persisted in SQLite. The file is the durable source and has no automatic contest reset.
|
||||
Worked marks from the Simplelogfile interpreter are the exception. They are copied from the selected file into runtime state only and are not persisted in SQLite. The file is the durable source and has no automatic contest reset. A database reset does not change or empty it; callsigns contained in the file are marked as worked again during the next periodic evaluation.
|
||||
|
||||
The normalised callsign, without visible chat brackets or category formatting, is used as the key. This allows active variants of the same callsign to be evaluated consistently.
|
||||
|
||||
|
||||
@@ -208,7 +208,7 @@ In plain terms: an automatically detected hint means "probably active on this ba
|
||||
|
||||
Worked, NOT-QRV and worked-grid information received from network interfaces, together with manual marks, is stored in the internal SQLite database and restored on the next start. Entries expire automatically after three days, so a reset before every contest is normally unnecessary.
|
||||
|
||||
Simplelogfile matches are excluded. They are not persisted in SQLite but are derived from the selected file during each application session. The file is therefore the durable source. The interpreter does not remove an existing Worked mark during the current session and does not reset the state automatically for a new contest.
|
||||
Simplelogfile matches are excluded. They are not persisted in SQLite but are derived from the selected file during each application session. The file is therefore the durable source. The interpreter does not remove an existing Worked mark during the current session and does not reset the state automatically for a new contest. A manual database reset does not change or empty the file. Callsigns contained in it are marked as worked again when the file is next evaluated within one minute.
|
||||
|
||||
A manual reset under **Workedstn database** removes all Worked marks, NOT-QRV marks and stored worked grid squares. The known callsign rows remain in the database. See [Worked Station Database Settings](en-Configuration#worked-station-database-settings) for details.
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@ The limitation is equally clear. A callsign match alone provides neither a relia
|
||||
|
||||
Select the text-file path in the **Log sync** tab. If the file is missing, KST4Contest creates it and displays a one-time, non-blocking notice with the path and the checks to perform next. Read or creation errors are logged; the scheduled task continues with its next one-minute pass. Use one of the network interfaces where possible if band-specific information is required.
|
||||
|
||||
Worked status derived from the Simplelogfile is not stored in the internal SQLite database. The selected file is the durable source and is read again after every restart. The interpreter only adds positive Worked marks; it does not remove an existing mark during the current application session and does not reset automatically for a new contest. Before each contest, verify that the logging application is writing the current contest log to this exact file.
|
||||
Worked status derived from the Simplelogfile is not stored in the internal SQLite database. The selected file is the durable source and is read again after every restart. The interpreter only adds positive Worked marks; it does not remove an existing mark during the current application session and does not reset automatically for a new contest. A manual database reset does not change or empty the Simplelogfile either. Callsigns contained in it are marked as worked again when the file is next evaluated within one minute. Before each contest, verify that the logging application is writing the current contest log to this exact file.
|
||||
|
||||
---
|
||||
|
||||
@@ -204,6 +204,6 @@ The input sources provide different levels of detail:
|
||||
| QSO UDP listener | yes | yes, if included in the packet | yes, if both band and locator are available |
|
||||
| Win-Test network listener | yes | yes | yes, if a locator is available |
|
||||
|
||||
The information stored in SQLite is restored when KST4Contest starts and updated during operation when new log entries arrive. It expires automatically after three days, so a reset before every contest is normally unnecessary. This lifetime does not apply to the Simplelogfile interpreter: its file remains the durable source and is not reset automatically for a new contest.
|
||||
The information stored in SQLite is restored when KST4Contest starts and updated during operation when new log entries arrive. It expires automatically after three days, so a reset before every contest is normally unnecessary. This lifetime does not apply to the Simplelogfile interpreter: its file remains the durable source and is neither changed nor emptied by a database reset. Callsigns contained in it set the global Worked status again during the next periodic evaluation.
|
||||
|
||||
A complete manual reset removes Worked marks, NOT-QRV marks and worked grid squares together. See [Worked Station Database Settings](en-Configuration#worked-station-database-settings) for details.
|
||||
|
||||
Reference in New Issue
Block a user