mirror of
https://github.com/praktimarc/kst4contest.git
synced 2026-09-11 11:45:27 +02:00
Compare commits
3
Commits
a9eba266ee
...
047891e109
| Author | SHA1 | Date | |
|---|---|---|---|
 Marc Froehlich
|
047891e109 | ||
|
Marc Froehlich
|
4f88101ab7 | ||
|
Marc Froehlich
|
5955ba4ecf |
@@ -65,6 +65,7 @@ jobs:
|
||||
github_docs/en-Home.md \
|
||||
github_docs/en-Installation.md \
|
||||
github_docs/en-Configuration.md \
|
||||
github_docs/en-Contest-Workflow.md \
|
||||
github_docs/en-Features.md \
|
||||
github_docs/en-User-Interface.md \
|
||||
github_docs/en-Macros-and-Variables.md \
|
||||
@@ -91,6 +92,7 @@ jobs:
|
||||
github_docs/de-Home.md \
|
||||
github_docs/de-Installation.md \
|
||||
github_docs/de-Konfiguration.md \
|
||||
github_docs/de-Contest-Workflow.md \
|
||||
github_docs/de-Funktionen.md \
|
||||
github_docs/de-Benutzeroberflaeche.md \
|
||||
github_docs/de-Makros-und-Variablen.md \
|
||||
|
||||
@@ -21,8 +21,6 @@ Ob die Verbindung lediglich als TCP-Verbindung besteht oder bereits vollständig
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
## Hauptfenster-Überblick
|
||||
|
||||
Das Hauptfenster besteht aus mehreren Bereichen:
|
||||
|
||||
@@ -0,0 +1,277 @@
|
||||
# Contest-Workflow mit KST4Contest
|
||||
|
||||
> [English version](en-Contest-Workflow) | Du liest gerade die deutsche Version
|
||||
|
||||
KST4Contest fasst Chat, Stationsauswahl, bekannte QRGs, Worked-Status, Skeds, Aircraft-Scatter-Zeiten und weitere Stationsdaten in einer gemeinsamen Oberfläche zusammen. Der Nutzen entsteht nicht aus einer einzelnen Anzeige, sondern aus dem Zusammenspiel dieser Informationen während des laufenden Contests.
|
||||
|
||||
Diese Seite beschreibt einen vollständigen Arbeitsablauf. Die einzelnen Funktionen und ihre technischen Grenzen werden weiterhin in den Kapiteln [Funktionen](de-Funktionen), [Benutzeroberfläche](de-Benutzeroberflaeche), [Log-Synchronisation](de-Log-Synchronisation) und [AirScout-Integration](de-AirScout-Integration) erläutert.
|
||||
|
||||
---
|
||||
|
||||
## Zweck und Grenzen
|
||||
|
||||
KST4Contest soll die Zeit zwischen einer erkannten Möglichkeit und dem tatsächlichen QSO verkürzen.
|
||||
|
||||
Das Programm kann unter anderem anzeigen:
|
||||
|
||||
- welche Stationen aktiv sind,
|
||||
- auf welchen Bändern und QRGs sie zuletzt erkannt wurden,
|
||||
- welche Stationen bereits gearbeitet wurden,
|
||||
- welche zusätzlichen Bänder noch infrage kommen,
|
||||
- welche Kandidaten zur aktuellen Antennenrichtung passen,
|
||||
- wann ein Aircraft-Scatter-Fenster erwartet wird und
|
||||
- welche Station gerade in eine für die eigene Station brauchbare Richtung arbeitet.
|
||||
|
||||
Diese Angaben bleiben Entscheidungshilfen. Ein hoher Prioritätsscore ist keine QSO-Wahrscheinlichkeit. Auch eine von AirScout mit 100 % bewertete Reflexionsgeometrie garantiert kein QSO. Ob eine QRG tatsächlich frei ist, die Gegenstation zuhört und der Funkweg unter den aktuellen Bedingungen funktioniert, muss der Operator weiterhin selbst beurteilen.
|
||||
|
||||
---
|
||||
|
||||
## Vor dem Contest
|
||||
|
||||
Die wesentlichen Einstellungen sollten nicht erst unmittelbar vor dem ersten interessanten Sked geprüft werden.
|
||||
|
||||
### Grundkonfiguration
|
||||
|
||||
Prüfe mindestens:
|
||||
|
||||
- eigenes Rufzeichen, Passwort und Locator,
|
||||
- primäre Chat-Kategorie,
|
||||
- Login und Einstellungen der zweiten Kategorie, falls sie verwendet wird,
|
||||
- lokal aktive Bänder,
|
||||
- Antennenöffnungswinkel,
|
||||
- maximale sinnvolle Entfernung,
|
||||
- `MYQRG` und gegebenenfalls `SECONDQRG`,
|
||||
- Log-Synchronisation und
|
||||
- benötigte Shortcuts, Snippets und Nachrichtenvariablen.
|
||||
|
||||
Antennenöffnungswinkel und maximale Entfernung sind stationsabhängig. Bei DM5M wird die reale Antennenanlage beispielsweise mit einem Öffnungswinkel von 69° und einer maximalen Entfernung von 900 km abgebildet. Das sind keine allgemeinen Vorgabewerte.
|
||||
|
||||
Speichere dauerhafte Änderungen mit **Save Settings**. Nach dem Verbindungsaufbau sollte der `LINK`-Indikator grün sein. Erst dann sind Anmeldung und Benutzerlistensynchronisation vollständig abgeschlossen.
|
||||
|
||||
### Automatische Antworten
|
||||
|
||||
Die automatische QRG-Antwort gehört zum aktiven Contest-Workflow. Sie beantwortet wiederkehrende QRG-Anfragen und nimmt dem Chatter damit einen Teil der Routinearbeit ab.
|
||||
|
||||
Davon zu unterscheiden ist die allgemeine automatische Antwort. Sie kann auf sämtliche eingehenden Anfragen reagieren und ist vor allem dann sinnvoll, wenn die Station vorübergehend nicht QRV ist oder nicht am Sked-Betrieb teilnehmen möchte. Sie erspart sowohl der eigenen Station als auch den anfragenden Stationen unnötige Folgefragen.
|
||||
|
||||
### Optionale Anbindungen
|
||||
|
||||
Aktiviere nur die Schnittstellen, die tatsächlich verwendet und vorher getestet wurden:
|
||||
|
||||
- Logprogramm beziehungsweise Simplelogfile,
|
||||
- TRX-Synchronisation,
|
||||
- AirScout,
|
||||
- PSTRotator,
|
||||
- Win-Test-Skedübergabe und
|
||||
- lokaler DX-Cluster-Server.
|
||||
|
||||
Ein Contest ist ein ungünstiger Zeitpunkt, um gleichzeitig die Funkbedingungen und eine erstmals aktivierte Netzwerkschnittstelle zu untersuchen.
|
||||
|
||||
---
|
||||
|
||||
## Grundablauf während des Contests
|
||||
|
||||
Der typische Ablauf wiederholt sich:
|
||||
|
||||
1. CQ rufen oder einen vereinbarten Sked durchführen.
|
||||
2. Chat, Prioritätsliste, Karte und AP-Timeline beobachten.
|
||||
3. Einen geeigneten Kandidaten auswählen.
|
||||
4. Eigene oder fremde QRG festlegen.
|
||||
5. QSO versuchen.
|
||||
6. Erfolgreiches QSO sofort loggen.
|
||||
7. Eine weitere Bandmöglichkeit prüfen.
|
||||
8. Einen erfolglosen, aussagekräftigen Versuch mit **Sked fail** kennzeichnen.
|
||||
9. Zum CQ-Betrieb oder zum nächsten Kandidaten zurückkehren.
|
||||
|
||||
KST4Contest hält die benötigten Informationen zwischen diesen Schritten zusammen. Das eigentliche Umschalten, Rufen, Hören und Entscheiden bleibt bewusst beim Operator.
|
||||
|
||||
---
|
||||
|
||||
## CQ-Betrieb
|
||||
|
||||
Bei einer weitgehend festen CQ-QRG sollten `MYQRG` beziehungsweise `SECONDQRG` den tatsächlich verwendeten Frequenzen entsprechen. Eine aktivierte TRX-Synchronisation kann `MYQRG` automatisch aktualisieren. Ohne automatische Quelle muss der Wert von Hand gepflegt werden.
|
||||
|
||||
Der Beacon kann die aktuelle QRG, den Locator und die Antennenrichtung regelmäßig im Chat veröffentlichen. Seine Variablen werden bei jedem Sendedurchlauf erneut ausgewertet.
|
||||
|
||||
Wird während des CQ-Betriebs über mehrere Frequenzen gescannt, sollte der Beacon deaktiviert werden. Eine automatisch veröffentlichte QRG ist nur hilfreich, solange sie noch stimmt.
|
||||
|
||||
Shortcuts und Snippets sollten die regelmäßig benötigten Nachrichten abdecken, beispielsweise:
|
||||
|
||||
- Bitte auf der eigenen QRG hören,
|
||||
- QRG der Gegenstation erfragen,
|
||||
- Wechsel zur QRG der Gegenstation ankündigen,
|
||||
- Antennenrichtung bestätigen und
|
||||
- einen Sked vorschlagen.
|
||||
|
||||
Einzelheiten stehen unter [Makros und Variablen](de-Makros-und-Variablen).
|
||||
|
||||
---
|
||||
|
||||
## Kandidaten auswählen
|
||||
|
||||
Die Benutzerliste kann mit QTF-, QRB-, Worked-, Band-, Aktivitäts-, New-Bands-, Tropo- und AirScout-Filtern auf den aktuellen Betriebszustand begrenzt werden.
|
||||
|
||||
Die Prioritätsliste und die AP-Timeline ergänzen diese Auswahl:
|
||||
|
||||
- Der Prioritätsscore fasst mehrere bekannte Kriterien zusammen.
|
||||
- Die AP-Timeline ordnet Skeds und erwartete Aircraft-Scatter-Möglichkeiten zeitlich ein.
|
||||
- Die Stationskarte zeigt die geografische Lage, Antennenrichtung und den Funkweg.
|
||||
- Der Worked- und Bandstatus verhindert unnötige Doppelarbeit.
|
||||
|
||||
|
||||
|
||||
Der Score ist eine Sortierhilfe. Prüfe vor einem Versuch weiterhin Rufzeichen, Kategorie, Band, QRG, Richtung, Entfernung und die Aktualität der zugrunde liegenden Informationen.
|
||||
|
||||
Eine bewusste Auswahl in Benutzerliste, Prioritätsliste, Timeline oder Karte übernimmt den konkreten Chatmember. Dabei bleiben das vollständige sichtbare Rufzeichen und die zugehörige Chat-Kategorie erhalten. KST4Contest bereitet anschließend `/cq RUFZEICHEN` im Sendfeld vor.
|
||||
|
||||
---
|
||||
|
||||
## Eigene oder fremde QRG verwenden
|
||||
|
||||
Wenn eine gute Ausbreitungsrichtung erkannt wird und ein passendes Flugzeug für einen Kandidaten vorhanden ist, wird die Gegenstation zunächst häufig auf die eigene QRG gebeten. Das ist besonders sinnvoll, wenn dort bereits CQ gerufen wird und die Station ohne weiteren Umbau sofort empfangen kann.
|
||||
|
||||
Reagiert die Gegenstation nicht, ist ihre eigene QRG geeigneter oder kann sie die angefragte QRG nicht verwenden, wird gewechselt. KST4Contest hält die zuletzt erkannten QRGs bereit, damit der Operator nicht erneut den gesamten Chatverlauf durchsuchen muss.
|
||||
|
||||
Auch ein gezielter Versuch auf der QRG eines Sked-Partners ist Teil des normalen Workflows. Entscheidend ist nicht, grundsätzlich auf der eigenen QRG zu bleiben, sondern die vorhandene Möglichkeit mit möglichst wenig Verzögerung zu nutzen.
|
||||
|
||||
Vor dem Wechsel sollten mindestens geprüft werden:
|
||||
|
||||
- korrektes Band,
|
||||
- vollständiges Zielrufzeichen,
|
||||
- QRG der Gegenstation,
|
||||
- Antennenrichtung,
|
||||
- erwartetes Aircraft-Scatter-Fenster und
|
||||
- Belegung der QRG.
|
||||
|
||||
---
|
||||
|
||||
## Richtungsgelegenheiten nutzen
|
||||
|
||||
Eine gerichtete Nachricht zwischen zwei anderen Stationen kann zeigen, dass der Absender seine Antenne ungefähr in Richtung des Empfängers ausgerichtet hat. Passt diese Richtung auch zur eigenen Station, markiert KST4Contest den Absender vorübergehend grün und fett.
|
||||
|
||||
|
||||
|
||||
Die Markierung erscheint in der Benutzerliste und den zugehörigen Ansichten. Bei geeigneter Cluster-Konfiguration und bekannter QRG kann die Gelegenheit zusätzlich über den lokalen DX-Cluster ausgegeben werden.
|
||||
|
||||
Damit stehen im entscheidenden Moment bereits mehrere Informationen zur Verfügung:
|
||||
|
||||
- vollständiges Rufzeichen,
|
||||
- Locator und Richtung,
|
||||
- zuletzt erkannte QRG,
|
||||
- Bandinformationen,
|
||||
- AirScout-Daten und
|
||||
- die aktuelle Reachability- beziehungsweise Tropo-Auswertung.
|
||||
|
||||
Der Operator muss diese Daten nicht erst zusammensuchen. Er muss lediglich entscheiden, ob die Gelegenheit den laufenden CQ-Betrieb kurz unterbrechen darf.
|
||||
|
||||
Bei DM5M lag die Erfolgsquote solcher opportunistischen Versuche nach der bisherigen praktischen Auswertung ungefähr bei 35–40 %. Dieser Wert beschreibt die Erfahrung einer konkreten Station. Er ist keine allgemeine Erfolgsprognose und hängt unter anderem von Band, Entfernung, Stationsausrüstung, Reaktionszeit und Ausbreitungsbedingungen ab.
|
||||
|
||||
Nach dem Versuch kann unmittelbar weiter CQ gerufen oder mit dem nächsten Sked fortgefahren werden.
|
||||
|
||||
---
|
||||
|
||||
## Skeds planen und auswerten
|
||||
|
||||
Ein Sked sollte mit dem tatsächlich vorgesehenen Band und einer realistischen Uhrzeit eingetragen werden. KST4Contest übernimmt ihn in die eigene Sked-Verwaltung und berücksichtigt ihn bei Erinnerungen, Timeline und Prioritätsberechnung.
|
||||
|
||||
Die Skeds werden nur für die laufende Programmsitzung verwaltet. Sie sind kein dauerhafter Ersatz für Contestlog oder Notizen.
|
||||
|
||||
Ist die Win-Test-Anbindung aktiviert, versucht KST4Contest den Sked zusätzlich an Win-Test zu übergeben. Fehlt eine verwendbare QRG oder passt das Band nicht, bleibt der interne Sked trotzdem erhalten. Lediglich die zusätzliche Übergabe kann dann entfallen.
|
||||
|
||||
### Fehlgeschlagene 100-%-Airplane-Skeds
|
||||
|
||||
Scheitert ein sorgfältig vorbereiteter Versuch trotz einer von AirScout mit 100 % bewerteten Reflexionsgeometrie, sollte die Station mit **Sked fail** gekennzeichnet werden.
|
||||
|
||||
Die 100-%-Anzeige ist keine Erfolgswahrscheinlichkeit. Ein Fehlschlag unter diesen Bedingungen ist aber ein brauchbarer betrieblicher Hinweis darauf, dass der Funkweg mit der aktuellen Stationskonfiguration und den aktuellen Bedingungen nicht funktioniert hat.
|
||||
|
||||
Die Kennzeichnung reduziert die Priorität der Station für den Rest der laufenden Sitzung. Dadurch können zunächst Kandidaten bearbeitet werden, für die noch keine vergleichbar deutliche negative Betriebserfahrung vorliegt.
|
||||
|
||||
**Sked fail** darf nicht als dauerhafte Aussage verstanden werden, dass die Station grundsätzlich nicht erreichbar ist. Andere Bedingungen, ein anderes Band oder eine geänderte Stationskonfiguration können zu einem anderen Ergebnis führen. Die Kennzeichnung kann zurückgesetzt werden und bleibt nicht über einen Programmneustart erhalten.
|
||||
|
||||
---
|
||||
|
||||
## Nach jedem QSO: Log und weiteres Band
|
||||
|
||||
Ein erfolgreiches QSO sollte sofort im angebundenen Logprogramm eingetragen werden. Nur dann können Worked-Status, Bandstatus, Filter und Prioritätsbewertung zeitnah aktualisiert werden.
|
||||
|
||||
Welche Details übernommen werden können, hängt von der Logquelle ab. Einige Schnittstellen liefern Band, QRG und Locator, während einfachere Quellen nur einen globalen Worked-Status melden.
|
||||
|
||||
Unmittelbar nach jedem Logeintrag sollte geprüft werden, ob für dieselbe Station ein weiteres gemeinsames, lokal aktiviertes und noch nicht gearbeitetes Band vorhanden ist. KST4Contest weist darauf mit `BAND+` und den Bandinformationen der Station hin, soweit die vorhandenen Daten eine solche Bewertung erlauben.
|
||||
|
||||
Diese Prüfung ist in allen Multiband-Betriebsarten sinnvoll. Die Gegenstation kann direkt mit einer konkreten Band- und Frequenzangabe weiterkoordiniert werden, bevor sie ihre Antenne wieder wegdreht oder einen anderen Sked beginnt.
|
||||
|
||||
Im Klartext: Das nächste mögliche QSO sollte geprüft werden, solange die Gegenstation noch erreichbar und der gemeinsame Kontext noch vorhanden ist.
|
||||
|
||||
Ist die Station auf einem angezeigten Band tatsächlich nicht QRV, sollte das Band als NOT QRV markiert werden. Dadurch verschwindet die unbrauchbare Möglichkeit aus Filtern und Bewertung, statt bei jeder Aktualisierung erneut aufzutauchen.
|
||||
|
||||
---
|
||||
|
||||
## Mehrkategorien- und Multibandbetrieb
|
||||
|
||||
Der Mehrkategorienbetrieb ist bei Multibandstationen keine Nebenfunktion. Sein wesentlicher Vorteil besteht darin, dass Informationen aus zwei Chat-Kategorien in einem gemeinsamen Arbeitsablauf ausgewertet werden.
|
||||
|
||||
Besonders groß ist der Vorteil bei:
|
||||
|
||||
- Einmann-Multibandstationen,
|
||||
- Multi-Operator-Multibandstationen mit einem zentralen Chat-Koordinator und
|
||||
- Stationen, die nach einem QSO regelmäßig direkt ein weiteres Band versuchen.
|
||||
|
||||
Worked-Status, bekannte Bandaktivitäten und Band Opportunities können gemeinsam bewertet werden. Das konkrete Nachrichtenziel behält trotzdem sein vollständiges Rufzeichen und seine Chat-Kategorie.
|
||||
|
||||
Dadurch kann der Chatter eine Station unmittelbar vom ersten QSO auf das nächste Band koordinieren, ohne Rufzeichen, QRG und Bandstatus erneut zusammensuchen zu müssen. Im praktischen Betrieb kann daraus eine sehr schnelle Folge nutzbarer QSO-Möglichkeiten entstehen. Genau an dieser Stelle entfaltet der Mehrkategorienbetrieb seinen größten Workflow-Vorteil.
|
||||
|
||||
Auch im Einmannbetrieb bleibt diese Arbeitsweise wirksam. Der Operator muss den Bandwechsel zwar selbst durchführen, erhält aber die nächste sinnvolle Möglichkeit bereits vorbereitet.
|
||||
|
||||
Multi-Multi-Stationen mit mehreren gleichzeitig arbeitenden Chattern profitieren ebenfalls. Dort müssen Zuständigkeiten, Bandwechsel und bereits laufende Anfragen allerdings klar koordiniert werden. Mehrere Chatter mit denselben Informationen sind hilfreich; mehrere widersprüchliche Sked-Anfragen an dieselbe Station eher nicht.
|
||||
|
||||
---
|
||||
|
||||
## Praxisbeispiele
|
||||
|
||||
### DM5M: Erst CQ, später mehr Skeds
|
||||
|
||||
Bei DM5M wird während der ersten vier bis fünf Stunden eines VHF-/UHF-Contests überwiegend CQ gerufen. Der Chat wird beobachtet, aber nur für wenige gezielte Eingriffe verwendet.
|
||||
|
||||
Später nimmt der Sked-Betrieb deutlich zu. Gute Ausbreitungsrichtungen, passende Aircraft-Scatter-Fenster, noch nicht gearbeitete Stationen und zusätzliche Bandmöglichkeiten werden dann gezielt miteinander kombiniert.
|
||||
|
||||
Eine geeignete Station wird zunächst auf die eigene QRG gebeten. Reagiert sie nicht oder ist die QRG bei der Gegenstation nicht verwendbar, wechselt DM5M auf deren QRG. Auch geplante Versuche direkt auf der QRG eines Sked-Partners gehören dazu.
|
||||
|
||||
Eine grün und fett markierte Richtungsgelegenheit kann den CQ-Betrieb kurzfristig unterbrechen. Nach dem Versuch wird unmittelbar weitergerufen oder der nächste Sked bearbeitet.
|
||||
|
||||
Dieser Ablauf ist ein Praxisbeispiel und keine verpflichtende Betriebsart. Andere Stationen können wesentlich früher skedden, dauerhaft zwischen QRGs wechseln oder den Chat von Beginn an intensiver nutzen.
|
||||
|
||||
### G1YBB: Richtungsgelegenheiten systematisch abarbeiten
|
||||
|
||||
G1YBB verwendet die Richtungsanzeige besonders konsequent. Grün markierte Stationen werden systematisch geprüft und nach Möglichkeit gearbeitet, während parallel der normale CQ-Betrieb weiterläuft.
|
||||
|
||||
KST4Contest automatisiert dabei nicht das QSO. Der Vorteil besteht darin, dass QRG, Richtung, Aircraft-Scatter-Informationen und weitere Bewertungsdaten bereits vorliegen, wenn die Gelegenheit entsteht. Die verbleibende Aufgabe ist eine schnelle betriebliche Entscheidung.
|
||||
|
||||
---
|
||||
|
||||
## Optionale Schnittstellen im Workflow
|
||||
|
||||
| Schnittstelle | Aufgabe im Contest |
|
||||
|---|---|
|
||||
| [Log-Synchronisation](de-Log-Synchronisation) | Aktualisiert Worked- und Bandstatus nach dem QSO |
|
||||
| [AirScout](de-AirScout-Integration) | Liefert Aircraft-Scatter-Kandidaten und erwartete Zeitfenster |
|
||||
| [PSTRotator](de-Konfiguration) | Übernimmt oder setzt die Antennenrichtung |
|
||||
| [Win-Test](de-Log-Synchronisation) | Kann angelegte Skeds zusätzlich an Win-Test übergeben |
|
||||
| [DX-Cluster-Server](de-DX-Cluster-Server) | Übergibt erkannte Möglichkeiten an verbundene Logprogramme |
|
||||
| [Stationskarte](de-Benutzeroberflaeche) | Zeigt Stationen, Richtungen, Auswahl und Funkweg |
|
||||
|
||||
Keine dieser Schnittstellen ist für den grundlegenden Chatbetrieb zwingend erforderlich. Ihr Wert entsteht dann, wenn sie zuverlässig eingerichtet ist und eine konkrete manuelle Aufgabe verkürzt.
|
||||
|
||||
---
|
||||
|
||||
## Was KST4Contest nicht entscheidet
|
||||
|
||||
KST4Contest entscheidet nicht:
|
||||
|
||||
- ob eine QRG tatsächlich frei ist,
|
||||
- ob die Gegenstation gerade hören kann,
|
||||
- ob ein Flugzeug ein QSO ermöglicht,
|
||||
- ob eine berechnete Funkstrecke unter den aktuellen Bedingungen funktioniert,
|
||||
- ob ein laufender CQ-Ruf für eine Gelegenheit unterbrochen werden sollte oder
|
||||
- welcher Kandidat für die aktuelle Conteststrategie den größten Wert besitzt.
|
||||
|
||||
Das Programm stellt die vorhandenen Informationen zusammen und hält sie aktuell. Die letzte Entscheidung bleibt beim Operator. Das ist keine Einschränkung des Workflows, sondern der Teil, für den weiterhin Funkbetrieb statt Tabellenkalkulation betrieben wird.
|
||||
@@ -68,6 +68,7 @@ Für einen Contest ist grundsätzlich die Stable-Version zu empfehlen. Nightly-B
|
||||
|---|---|
|
||||
| [Installation](de-Installation) | ON4KST-Account, Download, Installation und Updates |
|
||||
| [Konfiguration](de-Konfiguration) | Login, Station, Bänder, Benutzeroberfläche und externe Schnittstellen |
|
||||
| [Contest-Workflow](de-Contest-Workflow) | Vorstartprüfung, CQ-Betrieb, Kandidatenauswahl, Skeds, Logeintrag und Bandwechsel |
|
||||
| [Log-Synchronisation](de-Log-Synchronisation) | Simplelogfile, UCXLog, N1MM+, QARTest, DXLog.net und Win-Test |
|
||||
| [AirScout-Integration](de-AirScout-Integration) | Verbindung zu AirScout und Auswertung von Aircraft-Scatter-Zeiten |
|
||||
| [DX-Cluster-Server](de-DX-Cluster-Server) | Übergabe erkannter Möglichkeiten an das Logprogramm |
|
||||
|
||||
@@ -361,4 +361,10 @@ Dabei ist insbesondere zu beachten:
|
||||
- Stationsbezogene Variablen bleiben sichtbar, wenn keine Station ausgewählt ist.
|
||||
- Der eingefügte Text wird nicht automatisch auf seine betriebliche Richtigkeit geprüft.
|
||||
|
||||
Das Sendfeld bleibt deshalb nach dem Einfügen eines Shortcuts oder Snippets bearbeitbar. Die Variablen vermeiden wiederholte Eingaben; die abschließende Prüfung bleibt beim Operator.
|
||||
Das Sendfeld bleibt deshalb nach dem Einfügen eines Shortcuts oder Snippets bearbeitbar. Die Variablen vermeiden wiederholte Eingaben; die abschließende Prüfung bleibt beim Operator.
|
||||
|
||||
---
|
||||
|
||||
## Verwendung im Contest
|
||||
|
||||
Shortcuts, Snippets und Variablen sind einzelne Werkzeuge innerhalb des laufenden Betriebs. Ihr Zusammenspiel mit CQ-Betrieb, Stationsauswahl, Skeds, QRG-Wechseln und Log-Synchronisation ist unter [Contest-Workflow mit KST4Contest](de-Contest-Workflow) beschrieben.
|
||||
|
||||
@@ -765,7 +765,7 @@ Data handling and QRG selection: [Log Synchronisation – Win-Test](en-Log-Sync#
|
||||
|
||||
---
|
||||
|
||||
## PSTRotator Settings (from v1.31)## PSTRotator Settings (from v1.31, fully configurable from v1.40)
|
||||
## PSTRotator Settings (from v1.31, fully configurable from v1.40)
|
||||
|
||||
KST4Contest can set an antenna direction through the PSTRotator UDP interface and use the current position reported by PSTRotator as the local QTF.
|
||||
|
||||
|
||||
@@ -0,0 +1,277 @@
|
||||
# Contest Workflow with KST4Contest
|
||||
|
||||
> You are reading the English version | [Deutsche Version](de-Contest-Workflow)
|
||||
|
||||
KST4Contest brings chat activity, station selection, known QRGs, worked status, skeds, aircraft scatter timing and other station data together in one interface. Its value does not come from one individual indicator, but from the way this information works together during an active contest.
|
||||
|
||||
This page describes a complete operating workflow. Individual functions and their technical limitations remain documented under [Features](en-Features), [User Interface](en-User-Interface), [Log Synchronisation](en-Log-Sync) and [AirScout Integration](en-AirScout-Integration).
|
||||
|
||||
---
|
||||
|
||||
## Purpose and Limitations
|
||||
|
||||
KST4Contest is intended to reduce the time between recognising an opportunity and attempting the actual QSO.
|
||||
|
||||
The programme can show, among other things:
|
||||
|
||||
- which stations are active,
|
||||
- on which bands and QRGs they were most recently detected,
|
||||
- which stations have already been worked,
|
||||
- which additional bands may still be available,
|
||||
- which candidates match the current antenna direction,
|
||||
- when an aircraft scatter window is expected, and
|
||||
- which station is currently working in a direction useful to the local station.
|
||||
|
||||
These remain decision aids. A high priority score is not a QSO probability. An aircraft geometry rated at 100% by AirScout does not guarantee a contact either. The operator must still decide whether a QRG is actually clear, whether the remote station is listening and whether the path works under the current conditions.
|
||||
|
||||
---
|
||||
|
||||
## Before the Contest
|
||||
|
||||
The important settings should be checked before the first interesting sked appears.
|
||||
|
||||
### Basic Configuration
|
||||
|
||||
Check at least:
|
||||
|
||||
- the local callsign, password and locator,
|
||||
- the primary chat category,
|
||||
- login and settings for the second category if it is used,
|
||||
- locally enabled bands,
|
||||
- antenna beamwidth,
|
||||
- maximum useful distance,
|
||||
- `MYQRG` and, where applicable, `SECONDQRG`,
|
||||
- log synchronisation, and
|
||||
- the required shortcuts, snippets and message variables.
|
||||
|
||||
Antenna beamwidth and maximum distance depend on the station. At DM5M, for example, the actual antenna system is represented by a beamwidth of 69° and a maximum distance of 900 km. These are not general recommended values.
|
||||
|
||||
Use **Save Settings** for permanent changes. After connecting, the `LINK` indicator should be green. Only then have login and user-list synchronisation been completed.
|
||||
|
||||
### Automatic Replies
|
||||
|
||||
The automatic QRG reply is part of the active contest workflow. It answers repeated QRG requests and removes some routine work from the chat operator.
|
||||
|
||||
This is different from the general automatic reply. The general reply can react to all incoming requests and is mainly useful while the station is temporarily not QRV or does not want to take part in sked operation. It avoids unnecessary follow-up work for both the local and requesting stations.
|
||||
|
||||
### Optional Connections
|
||||
|
||||
Enable only interfaces which are actually required and have already been tested:
|
||||
|
||||
- logging software or Simplelogfile,
|
||||
- TRX synchronisation,
|
||||
- AirScout,
|
||||
- PSTRotator,
|
||||
- Win-Test sked handover, and
|
||||
- the local DX Cluster server.
|
||||
|
||||
A contest is not an ideal time to investigate radio conditions and a newly enabled network interface at the same time.
|
||||
|
||||
---
|
||||
|
||||
## Basic Contest Cycle
|
||||
|
||||
The normal operating cycle repeats:
|
||||
|
||||
1. Call CQ or run an agreed sked.
|
||||
2. Monitor chat activity, the priority list, map and AP timeline.
|
||||
3. Select a suitable candidate.
|
||||
4. Decide between the local and remote QRG.
|
||||
5. Attempt the QSO.
|
||||
6. Log a successful contact immediately.
|
||||
7. Check for another band opportunity.
|
||||
8. Mark a meaningful failed attempt with **Sked fail**.
|
||||
9. Return to CQ operation or continue with the next candidate.
|
||||
|
||||
KST4Contest keeps the required information together between these steps. Changing frequency, calling, listening and making the actual decision deliberately remain operator tasks.
|
||||
|
||||
---
|
||||
|
||||
## CQ Operation
|
||||
|
||||
During operation on a mainly fixed CQ frequency, `MYQRG` and `SECONDQRG` should match the frequencies actually in use. Enabled TRX synchronisation can update `MYQRG` automatically. Without an automatic source, the value must be maintained manually.
|
||||
|
||||
The beacon can publish the current QRG, locator and antenna direction in the chat at regular intervals. Its variables are evaluated again for every transmission.
|
||||
|
||||
Disable the beacon while scanning across several frequencies. An automatically published QRG is useful only while it is still correct.
|
||||
|
||||
Shortcuts and snippets should cover the messages required regularly, for example:
|
||||
|
||||
- asking a station to listen on the local QRG,
|
||||
- asking for the remote QRG,
|
||||
- announcing a move to the remote QRG,
|
||||
- confirming antenna direction, and
|
||||
- proposing a sked.
|
||||
|
||||
Further details are available under [Macros and Variables](en-Macros-and-Variables).
|
||||
|
||||
---
|
||||
|
||||
## Selecting Candidates
|
||||
|
||||
The user list can be reduced to the current operating situation by combining QTF, QRB, Worked, band, activity, New Bands, Tropo and AirScout filters.
|
||||
|
||||
The priority list and AP timeline add further context:
|
||||
|
||||
- The priority score combines several known criteria.
|
||||
- The AP timeline arranges skeds and expected aircraft scatter opportunities by time.
|
||||
- The station map shows geographical position, antenna direction and radio path.
|
||||
- Worked and band status help prevent unnecessary duplicate work.
|
||||
|
||||
|
||||
|
||||
The score is a sorting aid. Before attempting a contact, continue to check the callsign, category, band, QRG, direction, distance and age of the underlying information.
|
||||
|
||||
A deliberate selection in the user list, priority list, timeline or map selects the concrete chat member. The complete visible callsign and its chat category are retained. KST4Contest then prepares `/cq CALLSIGN` in the send field.
|
||||
|
||||
---
|
||||
|
||||
## Using the Local or Remote QRG
|
||||
|
||||
When a useful propagation direction is detected and a suitable aircraft is available for a candidate, the remote station is often first asked to listen on the local QRG. This is particularly useful while CQ operation is already running there and the station can receive immediately without another change.
|
||||
|
||||
If the remote station does not respond, its own QRG is more suitable or it cannot use the requested frequency, the local station changes frequency. KST4Contest keeps the most recently detected QRGs available, so the operator does not have to search the complete chat history again.
|
||||
|
||||
A deliberate attempt on the QRG of a sked partner is also part of the normal workflow. The objective is not to remain on the local QRG at all costs, but to use the available opportunity with as little delay as possible.
|
||||
|
||||
Before changing frequency, check at least:
|
||||
|
||||
- the correct band,
|
||||
- the complete target callsign,
|
||||
- the remote station’s QRG,
|
||||
- antenna direction,
|
||||
- the expected aircraft scatter window, and
|
||||
- whether the QRG is clear.
|
||||
|
||||
---
|
||||
|
||||
## Using Directional Opportunities
|
||||
|
||||
A directed message between two other stations may indicate that the sender’s antenna is pointing approximately towards the receiver. If this direction is also useful for the local station, KST4Contest temporarily displays the sender in green and bold.
|
||||
|
||||
|
||||
|
||||
The indication appears in the user list and associated views. With an appropriate cluster configuration and a known QRG, the opportunity may additionally be made available through the local DX Cluster.
|
||||
|
||||
Several relevant details are therefore already available when the opportunity appears:
|
||||
|
||||
- complete callsign,
|
||||
- locator and direction,
|
||||
- most recently detected QRG,
|
||||
- band information,
|
||||
- AirScout data, and
|
||||
- the current Reachability or Tropo assessment.
|
||||
|
||||
The operator does not have to collect this information first. The remaining decision is whether the opportunity justifies briefly interrupting ongoing CQ operation.
|
||||
|
||||
At DM5M, practical evaluation of these opportunistic attempts has so far produced a success rate of approximately 35–40%. This value describes the experience of one particular station. It is not a general prediction and depends on factors such as band, distance, station equipment, response time and propagation conditions.
|
||||
|
||||
CQ operation or the next sked can continue immediately after the attempt.
|
||||
|
||||
---
|
||||
|
||||
## Planning and Evaluating Skeds
|
||||
|
||||
Enter a sked with the band actually intended for the contact and a realistic time. KST4Contest adds it to its internal sked management and takes it into account for reminders, the timeline and priority calculation.
|
||||
|
||||
Skeds are maintained only for the current programme session. They are not a persistent replacement for the contest log or operating notes.
|
||||
|
||||
If the Win-Test connection is enabled, KST4Contest additionally attempts to pass the sked to Win-Test. If no usable QRG exists or the band does not match, the internal sked remains available. Only the additional handover may be skipped.
|
||||
|
||||
### Failed 100% Aircraft Skeds
|
||||
|
||||
If a carefully prepared attempt fails despite an aircraft geometry rated at 100% by AirScout, mark the station with **Sked fail**.
|
||||
|
||||
The 100% indication is not a probability of completing the QSO. A failure under these conditions is nevertheless useful operating evidence that the path did not work with the current station configuration and current conditions.
|
||||
|
||||
The mark reduces that station’s priority for the remainder of the current session. This allows candidates without comparable negative operating evidence to be handled first.
|
||||
|
||||
**Sked fail** must not be treated as a permanent statement that the station cannot be worked. Different conditions, another band or a changed station configuration may produce a different result. The mark can be reset and is not retained after restarting the programme.
|
||||
|
||||
---
|
||||
|
||||
## After Every QSO: Logging and the Next Band
|
||||
|
||||
Enter a successful QSO in the connected logging programme immediately. Only then can worked status, band status, filters and priority evaluation be updated in time.
|
||||
|
||||
The available detail depends on the log source. Some interfaces provide band, QRG and locator, while simpler sources report only a global worked state.
|
||||
|
||||
Immediately after every log entry, check whether another common, locally enabled and unworked band is available for the same station. KST4Contest indicates this through `BAND+` and the station’s band information where the available data permits such an evaluation.
|
||||
|
||||
This check is useful in every form of multiband operation. The remote station can be coordinated directly to another band with a specific band and frequency before it turns its antenna away or starts another sked.
|
||||
|
||||
In plain terms: check the next possible QSO while the remote station is still available and the common context still exists.
|
||||
|
||||
If the station is not actually QRV on an indicated band, mark that band as NOT QRV. This removes the unusable opportunity from filters and evaluation instead of allowing it to reappear after every update.
|
||||
|
||||
---
|
||||
|
||||
## Multi-Category and Multiband Operation
|
||||
|
||||
Multi-category operation is not a secondary feature for multiband stations. Its main advantage is that information from two chat categories can be evaluated within one operating workflow.
|
||||
|
||||
The benefit is particularly large for:
|
||||
|
||||
- single-operator multiband stations,
|
||||
- multi-operator multiband stations using one central chat coordinator, and
|
||||
- stations which regularly attempt another band immediately after a QSO.
|
||||
|
||||
Worked state, known band activity and band opportunities can be evaluated together. The concrete message target still retains its complete callsign and chat category.
|
||||
|
||||
This allows the chat operator to coordinate a station directly from the first QSO to another band without searching again for callsign, QRG and band status. In practical operation, this can produce a very rapid sequence of usable QSO opportunities. This is where multi-category operation provides its greatest workflow advantage.
|
||||
|
||||
The same approach remains effective in single-operator operation. The operator still has to change bands personally, but the next useful opportunity is already prepared.
|
||||
|
||||
Multi-multi stations with several active chat operators benefit as well. Responsibilities, band changes and requests already in progress must then be coordinated clearly. Several operators having the same information is useful; several contradictory sked requests sent to the same station are not.
|
||||
|
||||
---
|
||||
|
||||
## Practical Examples
|
||||
|
||||
### DM5M: CQ First, More Skeds Later
|
||||
|
||||
During the first four to five hours of a VHF/UHF contest, DM5M operates mainly by calling CQ. The chat is monitored, but used only for a small number of deliberate interventions.
|
||||
|
||||
Sked activity increases later. Useful propagation directions, suitable aircraft scatter windows, unworked stations and additional band opportunities are then combined deliberately.
|
||||
|
||||
A suitable station is first asked to listen on the local QRG. If it does not respond or cannot use that QRG, DM5M moves to the remote station’s frequency. Planned attempts directly on a sked partner’s QRG are also part of the process.
|
||||
|
||||
A green and bold directional opportunity may briefly interrupt CQ operation. Calling or sked operation continues immediately after the attempt.
|
||||
|
||||
This is a practical example, not a required operating method. Other stations may start arranging skeds considerably earlier, change QRG continuously or make more intensive use of the chat from the beginning.
|
||||
|
||||
### G1YBB: Working Directional Opportunities Systematically
|
||||
|
||||
G1YBB uses the directional indication particularly consistently. Stations highlighted in green are checked systematically and worked where possible while normal CQ operation continues in parallel.
|
||||
|
||||
KST4Contest does not automate the QSO. Its advantage is that QRG, direction, aircraft scatter information and other evaluation data are already available when the opportunity appears. The remaining task is a quick operating decision.
|
||||
|
||||
---
|
||||
|
||||
## Optional Interfaces in the Workflow
|
||||
|
||||
| Interface | Contest task |
|
||||
|---|---|
|
||||
| [Log Synchronisation](en-Log-Sync) | Updates worked and band status after a QSO |
|
||||
| [AirScout](en-AirScout-Integration) | Supplies aircraft scatter candidates and expected time windows |
|
||||
| [PSTRotator](en-Configuration) | Receives or sets the antenna direction |
|
||||
| [Win-Test](en-Log-Sync) | Can additionally pass entered skeds to Win-Test |
|
||||
| [DX Cluster Server](en-DX-Cluster-Server) | Passes detected opportunities to connected logging programmes |
|
||||
| [Station Map](en-User-Interface) | Shows stations, directions, selection and radio path |
|
||||
|
||||
None of these interfaces is mandatory for basic chat operation. Their value appears when they are configured reliably and shorten a specific manual task.
|
||||
|
||||
---
|
||||
|
||||
## What KST4Contest Does Not Decide
|
||||
|
||||
KST4Contest does not decide:
|
||||
|
||||
- whether a QRG is actually clear,
|
||||
- whether the remote station can currently listen,
|
||||
- whether an aircraft will enable a QSO,
|
||||
- whether a calculated radio path works under the current conditions,
|
||||
- whether ongoing CQ operation should be interrupted for an opportunity, or
|
||||
- which candidate has the greatest value for the current contest strategy.
|
||||
|
||||
The programme assembles the available information and keeps it current. The final decision remains with the operator. This is not a limitation of the workflow; it is the part for which we are still operating radios rather than spreadsheets.
|
||||
@@ -68,6 +68,7 @@ The stable release is normally the appropriate choice for contest operation. Bet
|
||||
|---|---|
|
||||
| [Installation](en-Installation) | ON4KST account, downloads, installation and updates |
|
||||
| [Configuration](en-Configuration) | Login, station, bands, user interface and external connections |
|
||||
| [Contest Workflow](en-Contest-Workflow) | Pre-start checks, CQ operation, candidate selection, skeds, logging and band changes |
|
||||
| [Log Synchronisation](en-Log-Sync) | Simplelogfile, UCXLog, N1MM+, QARTest, DXLog.net and Win-Test |
|
||||
| [AirScout Integration](en-AirScout-Integration) | Connecting AirScout and evaluating aircraft scatter timing |
|
||||
| [DX Cluster Server](en-DX-Cluster-Server) | Passing detected opportunities to logging software |
|
||||
@@ -126,4 +127,4 @@ Special thanks go to:
|
||||
- Philipp (DN9APW) for further development of KST4Contest and the CI/CD infrastructure
|
||||
- all other testers and contributors who supplied reproducible reports, ideas and corrections
|
||||
|
||||
Not every suggestion can be implemented unchanged. Nevertheless, reports from real operation remain an important basis for deciding which problems should be solved first.
|
||||
Not every suggestion can be implemented unchanged. Nevertheless, reports from real operation remain an important basis for deciding which problems should be solved first.
|
||||
|
||||
@@ -2,186 +2,371 @@
|
||||
|
||||
> 🇬🇧 You are reading the English version | 🇩🇪 [Deutsche Version](de-Makros-und-Variablen)
|
||||
|
||||
KST4Contest offers a flexible system of text snippets, shortcuts and built-in variables that significantly speed up the chat workflow during contests.
|
||||
KST4Contest distinguishes between shortcut buttons, text snippets and variables. Shortcuts and snippets contain prepared text. Variables add information which may change during operation.
|
||||
|
||||
Inserted text remains visible in the send field and can be checked or edited before transmission.
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
| Type | Access | Purpose |
|
||||
| Mechanism | Access | Use |
|
||||
|---|---|---|
|
||||
| **Shortcuts** | Button in the toolbar | Quick text insert into the send field |
|
||||
| **Snippets** | Right-click / Ctrl+1..0 | Text building blocks, optional PM sending |
|
||||
| **Variables** | Usable in all text fields | Dynamic values (QRG, locator, AP data) |
|
||||
| **Shortcut** | Button above the send field | Inserts configured text into the send field |
|
||||
| **Snippet** | Context menu or `Ctrl+1` through `Ctrl+0` | Prepares text for the selected station |
|
||||
| **Variable** | Placeholder within message text | Inserts current QRG, locator, direction, station or AirScout information |
|
||||
|
||||
Shortcuts and snippets store text. Variables supply the corresponding current values.
|
||||
|
||||
A shortcut such as
|
||||
|
||||
```text
|
||||
pse sked?
|
||||
```
|
||||
|
||||
always inserts the same text. A shortcut containing
|
||||
|
||||
```text
|
||||
pse call me at MYQRGSHORT
|
||||
```
|
||||
|
||||
instead uses the QRG stored in KST4Contest when the button is pressed.
|
||||
|
||||
---
|
||||
|
||||
## Shortcuts (Quick-Access Buttons)
|
||||
## Shortcut Buttons
|
||||
|
||||
Configurable in Preferences → **Shortcut Settings**.
|
||||
Shortcuts are configured under **Preferences → Shortcut Settings**.
|
||||
|
||||
- Each configured text creates **one button** in the user interface.
|
||||
- Clicking a button inserts the text into the **send field**.
|
||||
- **All variables** can be used in shortcuts and are resolved immediately when inserted.
|
||||
- Longer texts are also possible.
|
||||
|
||||
|
||||
**Tip**: Set up frequently used abbreviations like "pse", "rrr", "tnx", "73" as shortcuts.
|
||||
Each entry creates one button in the main window. Pressing it appends the configured text to the existing contents of the send field. Text which has already been prepared is not removed.
|
||||
|
||||
If a shortcut contains a variable, the variable is resolved when the text is inserted. For example,
|
||||
|
||||
```text
|
||||
pse call me at MYQRGSHORT
|
||||
```
|
||||
|
||||
may become:
|
||||
|
||||
```text
|
||||
pse call me at 144.388
|
||||
```
|
||||
|
||||
The exact entries `MYQRG` and `SECONDQRG` are highlighted as QRG buttons. They insert the current QRG of the first or second chat category respectively.
|
||||
|
||||
The shortcut
|
||||
|
||||
```text
|
||||
/SETNAME MYQRG
|
||||
```
|
||||
|
||||
is highlighted as well. Pressing it resolves `MYQRG` and inserts the resulting server command into the send field. The command is not transmitted automatically.
|
||||
|
||||
The order of the entries in the settings determines the button order in the main window. Editing, sorting and saving are described under [Configuration – Shortcut Settings](en-Configuration#shortcut-settings).
|
||||
|
||||
---
|
||||
|
||||
## Snippets (Text Building Blocks)
|
||||
## Text Snippets
|
||||
|
||||
Configurable in Preferences → **Snippet Settings**.
|
||||
Snippets are configured under **Preferences → Snippet Settings**. They are intended primarily for recurring messages to a particular station.
|
||||
|
||||
### Access
|
||||
Snippets can be opened:
|
||||
|
||||
- **Right-click** on a callsign in the user list
|
||||
- **Right-click** in the CQ message table
|
||||
- **Right-click** in the PM message table
|
||||
- **Keyboard shortcuts**: `Ctrl+1` to `Ctrl+0` for the first 10 snippets
|
||||
- by right-clicking a station in the user list,
|
||||
- by right-clicking a public message,
|
||||
- by right-clicking a private message, or
|
||||
- with `Ctrl+1` through `Ctrl+0` for the first ten entries in the snippet list.
|
||||
|
||||
### Behaviour with a Selected Callsign
|
||||
### Using the Context Menu
|
||||
|
||||
When a callsign is selected in the user list, the snippet is addressed as a **private message**:
|
||||
Selecting a station or message will normally have prepared the corresponding `/cq` destination in the send field. A snippet subsequently chosen from the context menu is appended to this text.
|
||||
|
||||
```
|
||||
/CQ CALLSIGN <snippet text>
|
||||
Existing message text can therefore be extended deliberately.
|
||||
|
||||
### Using the Keyboard
|
||||
|
||||
A snippet invoked with `Ctrl+1` through `Ctrl+0` replaces the previous contents of the send field with a complete directed message:
|
||||
|
||||
```text
|
||||
/cq CALLSIGN snippet text
|
||||
```
|
||||
|
||||
Then **Enter** can be pressed to send directly – even if the send field does not have focus.
|
||||
The complete visible callsign, including any suffix, is retained. Selecting `9A0BB-70` may therefore produce:
|
||||
|
||||
### Hardware Macro Keyboard
|
||||
```text
|
||||
/cq 9A0BB-70 pse ur qrg?
|
||||
```
|
||||
|
||||
*(Idea by IU3OAR, Gianluca Costantino)*
|
||||
KST4Contest also retains the selected station's chat category internally. A snippet for `9A0BB-70` is therefore not accidentally transmitted through the other active chat category.
|
||||
|
||||
The key combinations `Ctrl+1` to `Ctrl+0` can be assigned to a programmable macro keyboard. One key press triggers the snippet, another press (mapped to Enter) sends it immediately. In contest operation this saves considerable time.
|
||||
If no station is selected, or no snippet exists for the selected key combination, nothing is inserted.
|
||||
|
||||
### Predefined Default Snippets
|
||||
The prepared text is not sent automatically:
|
||||
|
||||
On first start, some snippets are pre-configured, e.g.:
|
||||
- `Enter` or **TX** sends the message.
|
||||
- `Esc` clears the send field.
|
||||
|
||||
- `Hi OM, try sked?`
|
||||
- `I am calling cq ur dir, pse lsn to me at MYQRG`
|
||||
- `pse ur qrg?`
|
||||
- `rrr, I move to your qrg nw, pse ant dir me`
|
||||
### Keyboard Mapping
|
||||
|
||||
These can be customised or deleted in the Preferences.
|
||||
The mapping follows the order of the snippet list:
|
||||
|
||||
| Key combination | Entry used |
|
||||
|---|---:|
|
||||
| `Ctrl+1` | first entry |
|
||||
| `Ctrl+2` | second entry |
|
||||
| … | … |
|
||||
| `Ctrl+9` | ninth entry |
|
||||
| `Ctrl+0` | tenth entry |
|
||||
|
||||
The key combinations can also be assigned to a programmable macro keyboard. The idea for this method came from IU3OAR, Gianluca Costantino.
|
||||
|
||||
KST4Contest does not define a mandatory set of default snippets. The useful texts depend on the station's own contest operation and operating method.
|
||||
|
||||
Editing, sorting and saving are described under [Configuration – Snippet Settings](en-Configuration#snippet-settings).
|
||||
|
||||
---
|
||||
|
||||
## Variables
|
||||
|
||||
Variables in written texts (snippets, shortcuts, beacon, send field) are replaced by their current values at runtime. Simply type the variable name in **uppercase** in the text.
|
||||
Variables are reserved placeholders within message text. They must be written in uppercase and are case-sensitive.
|
||||
|
||||
### MYQRG
|
||||
Variables can be used in:
|
||||
|
||||
Replaced by the current transceiver frequency.
|
||||
- shortcuts,
|
||||
- snippets,
|
||||
- beacon texts, and
|
||||
- message text entered or pasted directly into the send field.
|
||||
|
||||
- Source: TRX sync via UDP from the logging software (if enabled)
|
||||
- Fallback: Manually entered value in the MYQRG text field to the right of the send button
|
||||
- Format: `144.388.03`
|
||||
Variables in a shortcut or snippet are resolved when the text is inserted into the send field. Variables entered or pasted directly into the send field are resolved immediately before the message is placed in the transmission queue.
|
||||
|
||||
**Example**: `calling cq at MYQRG` → `calling cq at 144.388.03`
|
||||
Station-specific variables always use the currently selected station. KST4Contest does not derive this station from a `/cq` destination entered manually in the message text.
|
||||
|
||||
### MYQRGSHORT
|
||||
---
|
||||
|
||||
Like MYQRG, but only the first 7 characters.
|
||||
## Global Variables
|
||||
|
||||
- Format: `144.388`
|
||||
Global variables do not require a selected remote station.
|
||||
|
||||
**Example**: `qrg: MYQRGSHORT` → `qrg: 144.388`
|
||||
| Variable | Replacement value |
|
||||
|---|---|
|
||||
| `MYQRG` | current QRG of the first or primary chat category |
|
||||
| `MYQRGSHORT` | first seven characters of `MYQRG` |
|
||||
| `SECONDQRG` | current QRG of the second chat category |
|
||||
| `MYLOCATOR` | complete locator configured for the local station |
|
||||
| `MYLOCATORSHORT` | first four characters of the local locator |
|
||||
| `MYCALL` | configured local callsign |
|
||||
| `MYQTF` | current antenna direction as a numeric value in degrees |
|
||||
|
||||
### MYLOCATOR
|
||||
For example,
|
||||
|
||||
Replaced by your own Maidenhead locator (6 characters).
|
||||
```text
|
||||
cq at MYQRGSHORT, qtf MYQTF, loc MYLOCATOR
|
||||
```
|
||||
|
||||
- Format: `JO51IJ`
|
||||
may be resolved to:
|
||||
|
||||
**Example**: `my loc: MYLOCATOR` → `my loc: JO51IJ`
|
||||
```text
|
||||
cq at 144.388, qtf 135, loc JO51IJ
|
||||
```
|
||||
|
||||
### MYLOCATORSHORT
|
||||
### QRG Variables
|
||||
|
||||
Like MYLOCATOR, but only the first 4 characters.
|
||||
`MYQRG` contains the QRG of the first chat category. The value may come from TRX synchronisation with the logging software or from the manually edited QRG field.
|
||||
|
||||
- Format: `JO51`
|
||||
`MYQRGSHORT` uses the same value, but limits it to the first seven characters:
|
||||
|
||||
**Example**: `loc: MYLOCATORSHORT` → `loc: JO51`
|
||||
```text
|
||||
144.388.03 → 144.388
|
||||
```
|
||||
|
||||
`SECONDQRG` contains the QRG of the second chat category. Selecting a station from the second chat does not change the meaning of `MYQRG`. Use `SECONDQRG` explicitly when the QRG of the second category is required.
|
||||
|
||||
### Locator Variables
|
||||
|
||||
`MYLOCATOR` inserts the complete configured locator of the local station:
|
||||
|
||||
```text
|
||||
JO51IJ
|
||||
```
|
||||
|
||||
`MYLOCATORSHORT` uses only the first four characters:
|
||||
|
||||
```text
|
||||
JO51
|
||||
```
|
||||
|
||||
### MYQTF
|
||||
|
||||
`MYQTF` inserts the current antenna direction stored in KST4Contest as a numeric angle in degrees.
|
||||
|
||||
For example,
|
||||
|
||||
```text
|
||||
ant MYQTF deg
|
||||
```
|
||||
|
||||
may become:
|
||||
|
||||
```text
|
||||
ant 135 deg
|
||||
```
|
||||
|
||||
The direction is not converted into compass terms such as `north`, `north-east` or `south-west`.
|
||||
|
||||
---
|
||||
|
||||
## Variables for the Selected Station
|
||||
|
||||
These variables require a selected remote station:
|
||||
|
||||
| Variable | Replacement value |
|
||||
|---|---|
|
||||
| `QRZNAME` | name of the selected station, or its complete callsign if no name is available |
|
||||
| `FIRSTAP` | description and arrival time of the first aircraft reported by AirScout |
|
||||
| `SECONDAP` | description and arrival time of the second aircraft reported by AirScout |
|
||||
|
||||
For example,
|
||||
|
||||
```text
|
||||
Hi QRZNAME, FIRSTAP, pse lsn at MYQRGSHORT
|
||||
```
|
||||
|
||||
may become:
|
||||
|
||||
```text
|
||||
Hi David, a very big AP in 2 min, pse lsn at 144.388
|
||||
```
|
||||
|
||||
### QRZNAME
|
||||
|
||||
Replaced by the **name** of the currently selected station from the chat name field.
|
||||
|
||||
**Example**: `Hi QRZNAME, sked?` → `Hi Gianluca, sked?`
|
||||
KST4Contest uses the name from the selected station's name field. If that field does not contain a usable name, the complete visible callsign is inserted instead.
|
||||
|
||||
### FIRSTAP
|
||||
|
||||
Replaced by data of the first reflectable aircraft to the selected station (if available).
|
||||
If an AirScout candidate is available, `FIRSTAP` contains its description and the expected time until the reflection window.
|
||||
|
||||
- Condition: AirScout is active and an aircraft is available.
|
||||
- Example format: `a very big AP in 1 min`
|
||||
For example:
|
||||
|
||||
**Example**: `AP info: FIRSTAP` → `AP info: a very big AP in 1 min`
|
||||
```text
|
||||
a very big AP in 2 min
|
||||
```
|
||||
|
||||
If no aircraft is available for the selected station, KST4Contest inserts:
|
||||
|
||||
```text
|
||||
no ap available
|
||||
```
|
||||
|
||||
### SECONDAP
|
||||
|
||||
Like FIRSTAP, but for the second available aircraft.
|
||||
`SECONDAP` uses the second available AirScout candidate.
|
||||
|
||||
- Example format: `Next big AP in 9 min`
|
||||
For example:
|
||||
|
||||
**Example**: `also: SECONDAP` → `also: Next big AP in 9 min`
|
||||
```text
|
||||
Next big AP in 9 min
|
||||
```
|
||||
|
||||
### MYQTF *(planned for v1.3)*
|
||||
If there is no second candidate, `SECONDAP` is replaced with an empty string.
|
||||
|
||||
Replaced by the current antenna direction in words (e.g. `north`, `north east`, `east`, …).
|
||||
Further information about the aircraft data is available under [AirScout Integration](en-AirScout-Integration#ap-variables-in-messages).
|
||||
|
||||
- Source: Degree value in the MYQTF input field (to the right of the MYQRG field)
|
||||
### Behaviour Without a Selected Station
|
||||
|
||||
If no station is selected, `QRZNAME`, `FIRSTAP` and `SECONDAP` remain visible in the text. KST4Contest does not remove these placeholders automatically.
|
||||
|
||||
A visible unresolved placeholder is clearer than a formally complete message which silently lacks important information. Before transmission, check that the intended station is selected and that all required variables have been resolved.
|
||||
|
||||
---
|
||||
|
||||
## Variables in the Beacon
|
||||
|
||||
A public beacon has no selected remote station. It can therefore make meaningful use only of variables which depend on the local station and its current configuration:
|
||||
A public beacon has no selected remote station. It can therefore use only global variables:
|
||||
|
||||
| Variable | Value used in the beacon |
|
||||
|---|---|
|
||||
| `MYQRG` | current QRG of the primary chat category |
|
||||
| `MYQRGSHORT` | first seven characters of the primary QRG |
|
||||
| `SECONDQRG` | current QRG of the second chat category |
|
||||
| `MYLOCATOR` | complete configured locator of the local station |
|
||||
| `MYLOCATORSHORT` | four-character locator of the local station |
|
||||
| `MYCALL` | configured local callsign |
|
||||
| `MYQTF` | current antenna heading |
|
||||
- `MYQRG`
|
||||
- `MYQRGSHORT`
|
||||
- `SECONDQRG`
|
||||
- `MYLOCATOR`
|
||||
- `MYLOCATORSHORT`
|
||||
- `MYCALL`
|
||||
- `MYQTF`
|
||||
|
||||
`QRZNAME`, `FIRSTAP` and `SECONDAP` require a selected remote station. They are therefore not resolved in a public beacon.
|
||||
`QRZNAME`, `FIRSTAP` and `SECONDAP` are not resolved in a beacon and should not be used there.
|
||||
|
||||
A suitable configuration for the primary category is:
|
||||
A possible template for the first chat category is:
|
||||
|
||||
```text
|
||||
calling cq at MYQRGSHORT, ant MYQTF deg, loc MYLOCATOR
|
||||
```
|
||||
|
||||
For the second category, use `SECONDQRG` if that category should publish a different frequency:
|
||||
If the second chat category uses a different QRG, its template must contain `SECONDQRG`:
|
||||
|
||||
```text
|
||||
calling cq at SECONDQRG, ant MYQTF deg, loc MYLOCATOR
|
||||
```
|
||||
|
||||
Global variables are evaluated again on every timer run. A QRG updated by the logging software can therefore appear in the next beacon message.
|
||||
Global variables are evaluated again on every timer run. A QRG updated by the logging software can therefore already appear in the next beacon message.
|
||||
|
||||
The completely resolved text must contain at least one valid character and must not exceed 120 characters. The protocol separator `|` and line breaks are not permitted. If the text is still empty or invalid when transmission is due, that beacon run is skipped.
|
||||
The fully resolved beacon text:
|
||||
|
||||
The common interval and the behaviour of both chat categories are described under [Configuration – Beacon Settings](en-Configuration#beacon-settings).
|
||||
- must contain at least one valid character,
|
||||
- must not exceed 120 characters,
|
||||
- must not contain the protocol separator `|`, and
|
||||
- must not contain line breaks.
|
||||
|
||||
If the text is empty or invalid when transmission is due, that beacon run is skipped.
|
||||
|
||||
The interval, activation and behaviour of both categories are described under [Configuration – Beacon Settings](en-Configuration#beacon-settings).
|
||||
|
||||
---
|
||||
|
||||
## Example Snippet Workflow
|
||||
|
||||
## Example Contest Workflow with Macros
|
||||
For example, the first configured snippet may contain:
|
||||
|
||||
1. Select a station in the user list → callsign is now pre-selected.
|
||||
2. Press `Ctrl+1` → Snippet "Hi OM, try sked?" is addressed as a PM.
|
||||
3. Press Enter → Message sent.
|
||||
4. Station replies with frequency → QRG column is automatically filled.
|
||||
5. Press `Ctrl+2` → Snippet "I am calling cq ur dir, pse lsn to me at 144.388" (MYQRG resolved).
|
||||
6. Press Enter → Sent.
|
||||
```text
|
||||
Hi QRZNAME, pse sked? I call at MYQRGSHORT
|
||||
```
|
||||
|
||||
No manual typing, no errors, no interruption to CQ calling.
|
||||
The workflow can then look like this:
|
||||
|
||||
1. Select `DL1ABC-432` in the user list.
|
||||
2. Press `Ctrl+1`.
|
||||
3. KST4Contest prepares the directed message and resolves its variables.
|
||||
4. Check the complete text in the send field.
|
||||
5. If the remote station has proposed another QRG, edit the text accordingly.
|
||||
6. Press `Enter` or **TX** to send the message.
|
||||
|
||||
The result may be:
|
||||
|
||||
```text
|
||||
/cq DL1ABC-432 Hi Peter, pse sked? I call at 432.088
|
||||
```
|
||||
|
||||
The complete callsign determines the recipient. The selected chat category determines the transmission path. Variables reduce repeated typing, but they do not decide whether the inserted information still matches the current operating situation.
|
||||
|
||||
---
|
||||
|
||||
## Limits of Variable Resolution
|
||||
|
||||
Variables reflect the information available to KST4Contest at the time they are resolved.
|
||||
|
||||
In particular:
|
||||
|
||||
- A QRG supplied by the logging software may have changed in the meantime.
|
||||
- A manually entered QRG remains active until it is changed again.
|
||||
- `MYQRG` remains the QRG of the primary category even if a station from the second category is selected.
|
||||
- The selected station may differ from a `/cq` destination entered manually.
|
||||
- AirScout may not provide current aircraft data for the path in question.
|
||||
- Station-specific variables remain visible when no station is selected.
|
||||
- Inserted text is not checked automatically for operational correctness.
|
||||
|
||||
The send field therefore remains editable after a shortcut or snippet has been inserted. Variables avoid repeated input; the final check remains the operator's responsibility.
|
||||
|
||||
---
|
||||
|
||||
## Use During a Contest
|
||||
|
||||
Shortcuts, snippets and variables are individual tools within the operating workflow. Their interaction with CQ operation, station selection, skeds, QRG changes and log synchronisation is described under [Contest Workflow with KST4Contest](en-Contest-Workflow).
|
||||
|
||||
@@ -30,9 +30,7 @@ The main window consists of several areas:
|
||||
|
||||
The status bar is located at the top of the main window next to the menu.
|
||||
|
||||
<!-- TODO: Screenshot connection_status_indicator.png is missing from the repository. Uncomment the image after the file has been added to github_docs/.
|
||||
|
||||
-->
|
||||
|
||||
The permanently visible `LINK` indicator shows the actual state of the ON4KST connection:
|
||||
|
||||
@@ -352,9 +350,7 @@ It:
|
||||
|
||||
The map itself remains at the previously selected position and zoom level. This function is therefore not a geographical reset to the local station.
|
||||
|
||||
<!-- TODO: Screenshot station_map_reset.png is missing from the repository. Uncomment the image after the file has been added to github_docs/.
|
||||
|
||||
-->
|
||||
|
||||
Selecting another individual marker restores the station selection and analysis panel.
|
||||
|
||||
@@ -447,21 +443,6 @@ Derivation and limitations: [Global Message Views](en-Features#global-message-vi
|
||||
|
||||
---
|
||||
|
||||
|
||||
### Separate monitor window
|
||||
|
||||
The DX cluster and QSO-of-the-other tables can also be displayed together in a separate window.
|
||||
|
||||
|
||||
|
||||
The separate window and the tabs use the same underlying messages. Hiding the window does not stop message processing or remove messages from the tabs.
|
||||
|
||||
Use **Windows → Hide cluster / stranger QSOs** to hide the window and **Windows → Show cluster / stranger QSOs** to restore it.
|
||||
|
||||
If a message is too long for its table cell, moving the mouse over the cell displays the complete text in a tooltip. Links beginning with `http://`, `https://` or `www.` can be opened in the system browser.
|
||||
|
||||
---
|
||||
|
||||
## Menu
|
||||
|
||||
### File
|
||||
@@ -509,4 +490,4 @@ If the layout has become inconvenient, first move the dividers back to usable po
|
||||
- **Keep the settings window open**: This provides quick access to the beacon controls.
|
||||
- **Right-click in the user list**: Opens the snippet menu and additional actions, including QRZ.com profiles and NOT-QRV marks.
|
||||
- **Press Enter while working in the chat**: If the send field contains text, Enter sends it directly even when another control has focus.
|
||||
- **Stop the beacon while scanning**: Disable the beacon while moving through frequencies to avoid flooding the chat with unnecessary messages.
|
||||
- **Stop the beacon while scanning**: Disable the beacon while moving through frequencies to avoid flooding the chat with unnecessary messages.
|
||||
|
||||
@@ -8,6 +8,7 @@ const MANUAL_PAGE_ORDER = {
|
||||
"home",
|
||||
"installation",
|
||||
"konfiguration",
|
||||
"contest-workflow",
|
||||
"log-synchronisation",
|
||||
"airscout-integration",
|
||||
"dx-cluster-server",
|
||||
@@ -20,6 +21,7 @@ const MANUAL_PAGE_ORDER = {
|
||||
"home",
|
||||
"installation",
|
||||
"configuration",
|
||||
"contest-workflow",
|
||||
"log-sync",
|
||||
"airscout-integration",
|
||||
"dx-cluster-server",
|
||||
|
||||
@@ -72,6 +72,18 @@ description: Technisches Benutzerhandbuch für Installation, Konfiguration, ON4K
|
||||
<a class="button ghost" href="/manual/de/benutzeroberflaeche/">Benutzeroberfläche</a>
|
||||
</div>
|
||||
</article>
|
||||
|
||||
<article class="card">
|
||||
<h3>Contestbetrieb vorbereiten und durchführen</h3>
|
||||
<p>
|
||||
Der vollständige Arbeitsablauf von der Vorstartprüfung über CQ-Betrieb,
|
||||
Kandidatenauswahl und Skeds bis zum Logeintrag und direkten Wechsel auf
|
||||
ein weiteres Band.
|
||||
</p>
|
||||
<div class="actions">
|
||||
<a class="button secondary" href="/manual/de/contest-workflow/">Contest-Workflow öffnen</a>
|
||||
</div>
|
||||
</article>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
@@ -105,4 +117,4 @@ description: Technisches Benutzerhandbuch für Installation, Konfiguration, ON4K
|
||||
{% endif %}
|
||||
{% endfor %}
|
||||
</div>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
@@ -72,6 +72,18 @@ description: Technical user manual covering installation, configuration, ON4KST
|
||||
<a class="button ghost" href="/manual/en/user-interface/">User interface</a>
|
||||
</div>
|
||||
</article>
|
||||
|
||||
<article class="card">
|
||||
<h3>Prepare and run contest operation</h3>
|
||||
<p>
|
||||
Follow the complete workflow from pre-start checks and CQ operation
|
||||
through candidate selection and skeds to logging and an immediate move
|
||||
to another band.
|
||||
</p>
|
||||
<div class="actions">
|
||||
<a class="button secondary" href="/manual/en/contest-workflow/">Open the contest workflow</a>
|
||||
</div>
|
||||
</article>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
@@ -105,4 +117,4 @@ description: Technical user manual covering installation, configuration, ON4KST
|
||||
{% endif %}
|
||||
{% endfor %}
|
||||
</div>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
@@ -66,6 +66,19 @@ description: Technical user manual for KST4Contest, covering installation, stati
|
||||
<a class="button ghost" href="/manual/de/funktionen/">Deutsche Funktionen</a>
|
||||
</div>
|
||||
</article>
|
||||
|
||||
<article class="card">
|
||||
<h3>Prepare and run contest operation</h3>
|
||||
<p>
|
||||
Follow the complete workflow from pre-start checks and CQ operation
|
||||
through candidate selection and skeds to logging and an immediate move
|
||||
to another band.
|
||||
</p>
|
||||
<div class="actions">
|
||||
<a class="button secondary" href="/manual/en/contest-workflow/">English workflow</a>
|
||||
<a class="button ghost" href="/manual/de/contest-workflow/">German workflow</a>
|
||||
</div>
|
||||
</article>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
@@ -87,4 +100,4 @@ description: Technical user manual for KST4Contest, covering installation, stati
|
||||
<a class="button secondary" href="/roadmap/">View roadmap</a>
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
Reference in New Issue
Block a user