mirror of
https://github.com/praktimarc/kst4contest.git
synced 2026-08-24 02:57:43 +02:00
Compare commits
1
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 Rsclub2_2
|
a96d9ef1c3
|
@@ -1,60 +0,0 @@
|
||||
---
|
||||
name: Bug Report
|
||||
about: Report a problem with KST4Contest / Ein Problem mit KST4Contest melden
|
||||
title: "[BUG] "
|
||||
labels: bug
|
||||
---
|
||||
|
||||
**DE:** Bitte fülle alle Felder so vollständig wie möglich aus. Das hilft, den Fehler schneller zu finden.
|
||||
**EN:** Please fill in all fields as completely as possible. This helps to find the bug faster.
|
||||
|
||||
## Description / Beschreibung
|
||||
|
||||
<!-- EN: A clear and concise description of the bug. -->
|
||||
<!-- DE: Eine klare und präzise Beschreibung des Problems. -->
|
||||
|
||||
## Steps to reproduce / Schritte zum Reproduzieren
|
||||
|
||||
<!-- EN: Step-by-step instructions to reproduce the bug. -->
|
||||
<!-- DE: Schritt-für-Schritt-Anleitung, um den Fehler zu reproduzieren. -->
|
||||
|
||||
1.
|
||||
2.
|
||||
3.
|
||||
|
||||
## Expected behaviour / Erwartetes Verhalten
|
||||
|
||||
<!-- EN: What did you expect to happen? / DE: Was hätte passieren sollen? -->
|
||||
|
||||
## Actual behaviour / Tatsächliches Verhalten
|
||||
|
||||
<!-- EN: What actually happened? / DE: Was ist stattdessen passiert? -->
|
||||
|
||||
## Log file content / Inhalt der Logdatei
|
||||
|
||||
**EN:** Please paste the content of the error log file here. It is written automatically and contains error messages only — no personal data.
|
||||
**DE:** Bitte füge hier den Inhalt der Fehler-Logdatei ein. Sie wird automatisch geschrieben und enthält nur Fehlermeldungen — keine persönlichen Daten.
|
||||
|
||||
| OS | Path / Pfad |
|
||||
|----|-------------|
|
||||
| Linux / macOS | `~/.praktiKST/kst4contest-errors.log` |
|
||||
| Windows | `C:\Users\<YourName>\.praktiKST\kst4contest-errors.log` |
|
||||
|
||||
```
|
||||
Paste log content here / Loginhalt hier einfügen
|
||||
```
|
||||
|
||||
## Version
|
||||
|
||||
**KST4Contest version / Version** (e.g. 1.41.0):
|
||||
|
||||
**Java version / Java-Version** (`java -version`, e.g. 17.0.9):
|
||||
|
||||
**Operating system / Betriebssystem:** <!-- Linux / Windows / macOS -->
|
||||
|
||||
**Logging software / Logprogramm** (if applicable / falls relevant, e.g. UCXLog, N1MM+, WinTest):
|
||||
|
||||
## Checklist / Checkliste
|
||||
|
||||
- [ ] I have attached the log file / Ich habe die Logdatei angehängt
|
||||
- [ ] I have checked that this issue has not been reported before / Ich habe geprüft, dass dieses Problem noch nicht gemeldet wurde
|
||||
@@ -1 +0,0 @@
|
||||
blank_issues_enabled: false
|
||||
@@ -1,33 +0,0 @@
|
||||
---
|
||||
name: Feature Request
|
||||
about: Suggest a new feature or improvement / Neue Funktion oder Verbesserung vorschlagen
|
||||
title: "[FEATURE] "
|
||||
labels: enhancement
|
||||
---
|
||||
|
||||
**DE:** Bitte beschreibe deine Idee so genau wie möglich.
|
||||
**EN:** Please describe your idea as precisely as possible.
|
||||
|
||||
## Summary / Zusammenfassung
|
||||
|
||||
<!-- EN: A short summary of the feature you'd like. -->
|
||||
<!-- DE: Eine kurze Zusammenfassung der gewünschten Funktion. -->
|
||||
|
||||
## Motivation / Begründung
|
||||
|
||||
<!-- EN: Why would this feature be useful? What problem does it solve? -->
|
||||
<!-- DE: Warum wäre diese Funktion nützlich? Welches Problem löst sie? -->
|
||||
|
||||
## Detailed description / Detaillierte Beschreibung
|
||||
|
||||
<!-- EN: Describe the feature in detail. How should it work? -->
|
||||
<!-- DE: Beschreibe die Funktion im Detail. Wie soll sie funktionieren? -->
|
||||
|
||||
## Alternatives considered / Geprüfte Alternativen
|
||||
|
||||
<!-- EN: Have you considered any alternative solutions or workarounds? -->
|
||||
<!-- DE: Hast du alternative Lösungen oder Workarounds in Betracht gezogen? -->
|
||||
|
||||
## Checklist / Checkliste
|
||||
|
||||
- [ ] I have checked that this feature has not been requested before / Ich habe geprüft, dass diese Funktion noch nicht angefragt wurde
|
||||
@@ -95,8 +95,7 @@ $endif$
|
||||
belowskip = 8pt,
|
||||
literate = {→}{{\ensuremath{\rightarrow}}}1
|
||||
{←}{{\ensuremath{\leftarrow}}}1
|
||||
{↔}{{\ensuremath{\leftrightarrow}}}1
|
||||
{…}{{\ldots}}1,
|
||||
{↔}{{\ensuremath{\leftrightarrow}}}1,
|
||||
}
|
||||
|
||||
%% ─── Blockquotes ──────────────────────────────────────────────────────────
|
||||
|
||||
@@ -1,155 +0,0 @@
|
||||
name: AUR Nightly (kst4contest-git)
|
||||
|
||||
on:
|
||||
workflow_run:
|
||||
workflows: ["Nightly Runtime Artifacts"]
|
||||
types: [completed]
|
||||
workflow_dispatch:
|
||||
|
||||
permissions:
|
||||
contents: read
|
||||
|
||||
env:
|
||||
AUR_SSH_DIR: /tmp/aur-ssh
|
||||
|
||||
jobs:
|
||||
update-aur-git:
|
||||
if: >-
|
||||
github.event_name == 'workflow_dispatch' ||
|
||||
github.event.workflow_run.conclusion == 'success'
|
||||
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
container:
|
||||
image: archlinux:latest
|
||||
|
||||
steps:
|
||||
- name: Install dependencies
|
||||
run: |
|
||||
pacman -Sy --noconfirm git openssh base-devel
|
||||
useradd -m builder
|
||||
|
||||
- name: Checkout repository
|
||||
uses: actions/checkout@v7
|
||||
with:
|
||||
fetch-depth: 0
|
||||
|
||||
- name: Mark workspace as safe Git directory
|
||||
run: |
|
||||
git config --global --add safe.directory "$GITHUB_WORKSPACE"
|
||||
|
||||
- name: Compute pkgver
|
||||
id: ver
|
||||
run: |
|
||||
BASE=$(grep -m1 '<version>' pom.xml \
|
||||
| sed 's/.*<version>\(.*\)<\/version>.*/\1/' \
|
||||
| sed 's/[-.]nightly//')
|
||||
|
||||
GIT_PKGVER="${BASE}.r$(git rev-list --count HEAD).g$(git rev-parse --short HEAD)"
|
||||
|
||||
echo "Computed pkgver: ${GIT_PKGVER}"
|
||||
echo "pkgver=${GIT_PKGVER}" >> "$GITHUB_OUTPUT"
|
||||
|
||||
- name: Update PKGBUILD
|
||||
env:
|
||||
PKGVER: ${{ steps.ver.outputs.pkgver }}
|
||||
run: |
|
||||
sed -i "s/^pkgver=.*/pkgver=${PKGVER}/" \
|
||||
packaging/aur/kst4contest-git/PKGBUILD
|
||||
|
||||
- name: Generate .SRCINFO
|
||||
run: |
|
||||
cp -r packaging/aur/kst4contest-git /tmp/kst4contest-git
|
||||
chown -R builder:builder /tmp/kst4contest-git
|
||||
|
||||
su builder -c \
|
||||
"cd /tmp/kst4contest-git && makepkg --printsrcinfo > .SRCINFO"
|
||||
|
||||
cp /tmp/kst4contest-git/.SRCINFO \
|
||||
packaging/aur/kst4contest-git/.SRCINFO
|
||||
|
||||
echo "Generated .SRCINFO:"
|
||||
cat packaging/aur/kst4contest-git/.SRCINFO
|
||||
|
||||
- name: Set up and verify AUR SSH
|
||||
env:
|
||||
AUR_SSH_PRIVATE_KEY: ${{ secrets.AUR_SSH_PRIVATE_KEY }}
|
||||
run: |
|
||||
mkdir -p "${AUR_SSH_DIR}"
|
||||
|
||||
printf '%s\n' "${AUR_SSH_PRIVATE_KEY}" \
|
||||
> "${AUR_SSH_DIR}/aur_ed25519"
|
||||
|
||||
sed -i 's/\r$//' "${AUR_SSH_DIR}/aur_ed25519"
|
||||
chmod 600 "${AUR_SSH_DIR}/aur_ed25519"
|
||||
|
||||
ssh-keygen -y \
|
||||
-f "${AUR_SSH_DIR}/aur_ed25519" \
|
||||
> /dev/null
|
||||
|
||||
ssh-keyscan \
|
||||
-T 10 \
|
||||
-t ed25519 \
|
||||
aur.archlinux.org \
|
||||
> "${AUR_SSH_DIR}/known_hosts"
|
||||
|
||||
if [ ! -s "${AUR_SSH_DIR}/known_hosts" ]; then
|
||||
echo "::error::No SSH host key was received from aur.archlinux.org."
|
||||
exit 1
|
||||
fi
|
||||
|
||||
echo "Received AUR host-key fingerprint:"
|
||||
ssh-keygen -lf "${AUR_SSH_DIR}/known_hosts"
|
||||
|
||||
if ! ssh-keygen -lf "${AUR_SSH_DIR}/known_hosts" \
|
||||
| grep -Fq "SHA256:RFzBCUItH9LZS0cKB5UE6ceAYhBD5C8GeOBip8Z11+4"; then
|
||||
echo "::error::The AUR SSH host-key fingerprint does not match the official fingerprint."
|
||||
exit 1
|
||||
fi
|
||||
|
||||
printf '%s\n' \
|
||||
"Host aur.archlinux.org" \
|
||||
" HostName aur.archlinux.org" \
|
||||
" User aur" \
|
||||
" IdentityFile ${AUR_SSH_DIR}/aur_ed25519" \
|
||||
" IdentitiesOnly yes" \
|
||||
" StrictHostKeyChecking yes" \
|
||||
" UserKnownHostsFile ${AUR_SSH_DIR}/known_hosts" \
|
||||
> "${AUR_SSH_DIR}/config"
|
||||
|
||||
chmod 600 "${AUR_SSH_DIR}/config"
|
||||
chmod 600 "${AUR_SSH_DIR}/known_hosts"
|
||||
|
||||
- name: Push package metadata to AUR
|
||||
env:
|
||||
GIT_SSH_COMMAND: ssh -F /tmp/aur-ssh/config
|
||||
run: |
|
||||
git config --global user.email "philipp@wagnersnetz.de"
|
||||
git config --global user.name "Philipp Wagner"
|
||||
|
||||
AUR_DIR="/tmp/aur/kst4contest-git"
|
||||
|
||||
mkdir -p "$(dirname "${AUR_DIR}")"
|
||||
|
||||
git -c init.defaultBranch=master clone \
|
||||
"ssh://aur@aur.archlinux.org/kst4contest-git.git" \
|
||||
"${AUR_DIR}"
|
||||
|
||||
cp packaging/aur/kst4contest-git/PKGBUILD \
|
||||
"${AUR_DIR}/PKGBUILD"
|
||||
|
||||
cp packaging/aur/kst4contest-git/.SRCINFO \
|
||||
"${AUR_DIR}/.SRCINFO"
|
||||
|
||||
git -C "${AUR_DIR}" add PKGBUILD .SRCINFO
|
||||
|
||||
if git -C "${AUR_DIR}" diff --cached --quiet; then
|
||||
echo "kst4contest-git: package metadata is already current."
|
||||
else
|
||||
git -C "${AUR_DIR}" commit \
|
||||
-m "Update pkgver to ${{ steps.ver.outputs.pkgver }}"
|
||||
|
||||
git -C "${AUR_DIR}" push origin HEAD:master
|
||||
|
||||
echo "kst4contest-git: successfully pushed to AUR."
|
||||
fi
|
||||
@@ -1,181 +0,0 @@
|
||||
name: Publish AUR Packages
|
||||
|
||||
on:
|
||||
workflow_run:
|
||||
workflows: ["Tagged Release Build"]
|
||||
types: [completed]
|
||||
workflow_dispatch:
|
||||
inputs:
|
||||
version:
|
||||
description: "Release tag (e.g. v1.41.1) — defaults to latest stable release"
|
||||
required: false
|
||||
default: ""
|
||||
dry_run:
|
||||
description: "Dry run — skip AUR push and repo commit (for testing)"
|
||||
type: choice
|
||||
options: ["false", "true"]
|
||||
default: "false"
|
||||
|
||||
env:
|
||||
FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true
|
||||
|
||||
jobs:
|
||||
publish-aur:
|
||||
if: >-
|
||||
github.event_name == 'workflow_dispatch' ||
|
||||
github.event.workflow_run.conclusion == 'success'
|
||||
runs-on: ubuntu-latest
|
||||
container:
|
||||
image: archlinux:latest
|
||||
|
||||
steps:
|
||||
- name: Install dependencies
|
||||
run: |
|
||||
pacman -Sy --noconfirm git openssh curl base-devel nodejs
|
||||
useradd -m builder
|
||||
|
||||
- name: Checkout
|
||||
uses: actions/checkout@v4.1.7
|
||||
with:
|
||||
fetch-depth: 0
|
||||
|
||||
- name: Resolve release version
|
||||
id: ver
|
||||
env:
|
||||
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
INPUT_VERSION: ${{ inputs.version }}
|
||||
run: |
|
||||
if [[ -n "${INPUT_VERSION}" ]]; then
|
||||
TAG="${INPUT_VERSION}"
|
||||
else
|
||||
TAG=$(curl -sf \
|
||||
-H "Authorization: Bearer ${GH_TOKEN}" \
|
||||
-H "Accept: application/vnd.github+json" \
|
||||
"https://api.github.com/repos/${{ github.repository }}/releases/latest" \
|
||||
| grep '"tag_name"' | sed 's/.*"tag_name": *"\([^"]*\)".*/\1/')
|
||||
fi
|
||||
PKGVER="${TAG#v}"
|
||||
echo "tag=${TAG} → pkgver=${PKGVER}"
|
||||
echo "tag=${TAG}" >> "$GITHUB_OUTPUT"
|
||||
echo "pkgver=${PKGVER}" >> "$GITHUB_OUTPUT"
|
||||
|
||||
- name: Compute SHA256 checksums
|
||||
id: sha
|
||||
run: |
|
||||
TAG="${{ steps.ver.outputs.tag }}"
|
||||
REPO="${{ github.repository }}"
|
||||
|
||||
echo "Hashing pre-built Arch package..."
|
||||
SHA_BIN=$(curl -sfL \
|
||||
"https://github.com/${REPO}/releases/download/${TAG}/KST4Contest-${TAG}-archlinux-x86_64.pkg.tar.zst" \
|
||||
| sha256sum | awk '{print $1}')
|
||||
echo "bin: ${SHA_BIN}"
|
||||
|
||||
echo "Hashing source tarball..."
|
||||
SHA_SRC=$(curl -sfL \
|
||||
"https://github.com/${REPO}/archive/refs/tags/${TAG}.tar.gz" \
|
||||
| sha256sum | awk '{print $1}')
|
||||
echo "src: ${SHA_SRC}"
|
||||
|
||||
echo "bin=${SHA_BIN}" >> "$GITHUB_OUTPUT"
|
||||
echo "src=${SHA_SRC}" >> "$GITHUB_OUTPUT"
|
||||
|
||||
- name: Update PKGBUILDs
|
||||
env:
|
||||
PKGVER: ${{ steps.ver.outputs.pkgver }}
|
||||
SHA_BIN: ${{ steps.sha.outputs.bin }}
|
||||
SHA_SRC: ${{ steps.sha.outputs.src }}
|
||||
run: |
|
||||
# kst4contest-bin
|
||||
sed -i "s/^pkgver=.*/pkgver=${PKGVER}/" packaging/aur/kst4contest-bin/PKGBUILD
|
||||
sed -i "s/^sha256sums=.*/sha256sums=('${SHA_BIN}')/" packaging/aur/kst4contest-bin/PKGBUILD
|
||||
|
||||
# kst4contest (source build)
|
||||
sed -i "s/^pkgver=.*/pkgver=${PKGVER}/" packaging/aur/kst4contest/PKGBUILD
|
||||
sed -i "s/^sha256sums=.*/sha256sums=('${SHA_SRC}')/" packaging/aur/kst4contest/PKGBUILD
|
||||
|
||||
# A new pkgver supersedes any rebuild-only pkgrel bumps made in between.
|
||||
sed -i "s/^pkgrel=.*/pkgrel=1/" packaging/aur/kst4contest-bin/PKGBUILD
|
||||
sed -i "s/^pkgrel=.*/pkgrel=1/" packaging/aur/kst4contest/PKGBUILD
|
||||
|
||||
# kst4contest-git: Basis aus pom.xml, Suffix aus git
|
||||
BASE_VER=$(grep -m1 '<version>' pom.xml \
|
||||
| sed 's/.*<version>\(.*\)<\/version>.*/\1/' | sed 's/[-.]nightly//')
|
||||
GIT_PKGVER="${BASE_VER}.r$(git rev-list --count HEAD).g$(git rev-parse --short HEAD)"
|
||||
sed -i "s/^pkgver=.*/pkgver=${GIT_PKGVER}/" packaging/aur/kst4contest-git/PKGBUILD
|
||||
|
||||
echo "=== Updated PKGBUILD versions ==="
|
||||
grep -H '^pkgver=\|^sha256sums=' packaging/aur/*/PKGBUILD
|
||||
|
||||
- name: Generate .SRCINFO files
|
||||
run: |
|
||||
for pkg in kst4contest-bin kst4contest kst4contest-git; do
|
||||
cp -r "packaging/aur/${pkg}" "/tmp/${pkg}"
|
||||
chown -R builder:builder "/tmp/${pkg}"
|
||||
su builder -c "cd /tmp/${pkg} && makepkg --printsrcinfo > .SRCINFO"
|
||||
cp "/tmp/${pkg}/.SRCINFO" "packaging/aur/${pkg}/.SRCINFO"
|
||||
echo "=== ${pkg}/.SRCINFO ==="
|
||||
cat "packaging/aur/${pkg}/.SRCINFO"
|
||||
done
|
||||
|
||||
- name: Commit updated PKGBUILDs to repo
|
||||
if: inputs.dry_run != 'true'
|
||||
env:
|
||||
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
run: |
|
||||
git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
|
||||
git config user.name "github-actions[bot]"
|
||||
git remote set-url origin "https://x-access-token:${GITHUB_TOKEN}@github.com/${{ github.repository }}.git"
|
||||
git add packaging/aur/
|
||||
git diff --cached --quiet && echo "No PKGBUILD changes to commit." && exit 0
|
||||
git commit -m "chore: update AUR packages to ${{ steps.ver.outputs.tag }} [skip ci]"
|
||||
git push
|
||||
|
||||
- name: Set up AUR SSH
|
||||
if: inputs.dry_run != 'true'
|
||||
env:
|
||||
AUR_SSH_PRIVATE_KEY: ${{ secrets.AUR_SSH_PRIVATE_KEY }}
|
||||
run: |
|
||||
mkdir -p ~/.ssh
|
||||
printf '%s\n' "${AUR_SSH_PRIVATE_KEY}" > ~/.ssh/aur_ed25519
|
||||
chmod 600 ~/.ssh/aur_ed25519
|
||||
ssh-keyscan -t ed25519 aur.archlinux.org >> ~/.ssh/known_hosts
|
||||
cat >> ~/.ssh/config << 'EOF'
|
||||
Host aur.archlinux.org
|
||||
IdentityFile ~/.ssh/aur_ed25519
|
||||
User aur
|
||||
EOF
|
||||
|
||||
- name: Push to AUR
|
||||
if: inputs.dry_run != 'true'
|
||||
env:
|
||||
TAG: ${{ steps.ver.outputs.tag }}
|
||||
run: |
|
||||
git config --global user.email "philipp@wagnersnetz.de"
|
||||
git config --global user.name "Philipp Wagner"
|
||||
|
||||
push_to_aur() {
|
||||
local pkg="$1"
|
||||
local msg="$2"
|
||||
local aur_dir="/tmp/aur/${pkg}"
|
||||
|
||||
git clone "ssh://aur@aur.archlinux.org/${pkg}.git" "${aur_dir}" 2>/dev/null || {
|
||||
mkdir -p "${aur_dir}"
|
||||
git -C "${aur_dir}" init
|
||||
git -C "${aur_dir}" remote add origin "ssh://aur@aur.archlinux.org/${pkg}.git"
|
||||
}
|
||||
|
||||
cp "packaging/aur/${pkg}/PKGBUILD" "${aur_dir}/"
|
||||
cp "packaging/aur/${pkg}/.SRCINFO" "${aur_dir}/"
|
||||
git -C "${aur_dir}" add PKGBUILD .SRCINFO
|
||||
git -C "${aur_dir}" diff --cached --quiet \
|
||||
&& echo "${pkg}: no changes, skipping push" && return 0
|
||||
git -C "${aur_dir}" commit -m "${msg}"
|
||||
git -C "${aur_dir}" push origin HEAD:master
|
||||
echo "${pkg}: pushed to AUR"
|
||||
}
|
||||
|
||||
push_to_aur kst4contest-bin "Update to ${TAG}"
|
||||
push_to_aur kst4contest "Update to ${TAG}"
|
||||
push_to_aur kst4contest-git \
|
||||
"Update pkgver to $(grep '^pkgver=' packaging/aur/kst4contest-git/PKGBUILD | cut -d= -f2)"
|
||||
@@ -4,23 +4,13 @@ on:
|
||||
push:
|
||||
branches:
|
||||
- main
|
||||
paths:
|
||||
- "src/**"
|
||||
- "packaging/icons/**"
|
||||
- "packaging/macos/**"
|
||||
- "pom.xml"
|
||||
- "mvnw"
|
||||
- "mvnw.cmd"
|
||||
- ".github/workflows/nightly-artifacts.yml"
|
||||
schedule:
|
||||
- cron: "20 2 * * *"
|
||||
workflow_dispatch:
|
||||
|
||||
env:
|
||||
FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true
|
||||
|
||||
permissions:
|
||||
contents: write
|
||||
packages: write
|
||||
|
||||
jobs:
|
||||
build-windows-zip:
|
||||
name: Build Windows ZIP
|
||||
@@ -40,11 +30,11 @@ jobs:
|
||||
Add-Content -Path $env:GITHUB_ENV -Value "SHORT_SHA=$shortSha"
|
||||
Add-Content -Path $env:GITHUB_ENV -Value "ASSET_BASENAME=praktiKST-$version-$shortSha"
|
||||
|
||||
- name: Set up Java 21
|
||||
- name: Set up Java 17
|
||||
uses: actions/setup-java@v4.1.0
|
||||
with:
|
||||
distribution: temurin
|
||||
java-version: "21"
|
||||
java-version: "17"
|
||||
|
||||
- name: Install WiX Toolset
|
||||
shell: pwsh
|
||||
@@ -64,18 +54,7 @@ jobs:
|
||||
shell: pwsh
|
||||
run: |
|
||||
New-Item -ItemType Directory -Force -Path dist | Out-Null
|
||||
$addModules = & java packaging/AddModules.java
|
||||
if ($LASTEXITCODE -ne 0) { throw "Failed to resolve --add-modules from module-info.java" }
|
||||
jpackage `
|
||||
--type app-image `
|
||||
--name praktiKST `
|
||||
--icon packaging/icons/kst4contest.ico `
|
||||
--input target/dist-libs `
|
||||
--main-jar app.jar `
|
||||
--main-class kst4contest.view.Kst4ContestApplication `
|
||||
--module-path target/dist-libs `
|
||||
--add-modules $addModules `
|
||||
--dest dist
|
||||
jpackage --type app-image --name praktiKST --input target/dist-libs --main-jar app.jar --main-class kst4contest.view.Kst4ContestApplication --module-path target/dist-libs --add-modules javafx.controls,javafx.graphics,javafx.fxml,javafx.web,javafx.media,java.sql --dest dist
|
||||
|
||||
- name: Create Windows ZIP
|
||||
shell: pwsh
|
||||
@@ -104,13 +83,15 @@ jobs:
|
||||
run: |
|
||||
VERSION=$(grep -m1 '<version>' pom.xml | sed 's/.*<version>\(.*\)<\/version>.*/\1/')
|
||||
SHORT_SHA="${GITHUB_SHA::7}"
|
||||
echo "VERSION=$VERSION" >> "$GITHUB_ENV"
|
||||
echo "SHORT_SHA=$SHORT_SHA" >> "$GITHUB_ENV"
|
||||
echo "ASSET_BASENAME=KST4Contest-${VERSION}-${SHORT_SHA}" >> "$GITHUB_ENV"
|
||||
|
||||
- name: Set up Java 21
|
||||
- name: Set up Java 17
|
||||
uses: actions/setup-java@v4.1.0
|
||||
with:
|
||||
distribution: temurin
|
||||
java-version: "21"
|
||||
java-version: "17"
|
||||
|
||||
- name: Ensure mvnw is executable
|
||||
run: chmod +x mvnw
|
||||
@@ -123,16 +104,14 @@ jobs:
|
||||
- name: Build app-image with jpackage
|
||||
run: |
|
||||
mkdir -p dist
|
||||
ADD_MODULES="$(java packaging/AddModules.java)"
|
||||
jpackage \
|
||||
--type app-image \
|
||||
--name KST4Contest \
|
||||
--icon packaging/icons/kst4contest.png \
|
||||
--input target/dist-libs \
|
||||
--main-jar app.jar \
|
||||
--main-class kst4contest.view.Kst4ContestApplication \
|
||||
--module-path target/dist-libs \
|
||||
--add-modules "$ADD_MODULES" \
|
||||
--add-modules javafx.controls,javafx.graphics,javafx.fxml,javafx.web,javafx.media,java.sql \
|
||||
--dest dist
|
||||
|
||||
- name: Create AppDir metadata
|
||||
@@ -174,442 +153,10 @@ jobs:
|
||||
path: dist/KST4Contest-*-linux-x86_64.AppImage
|
||||
retention-days: 14
|
||||
|
||||
build-linux-deb:
|
||||
name: Build Debian package
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
steps:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@v4.1.7
|
||||
|
||||
- name: Resolve nightly version info
|
||||
run: |
|
||||
VERSION=$(grep -m1 '<version>' pom.xml | sed 's/.*<version>\(.*\)<\/version>.*/\1/')
|
||||
SHORT_SHA="${GITHUB_SHA::7}"
|
||||
echo "ASSET_BASENAME=KST4Contest-${VERSION}-${SHORT_SHA}" >> "$GITHUB_ENV"
|
||||
|
||||
- name: Set up Java 21
|
||||
uses: actions/setup-java@v4.1.0
|
||||
with:
|
||||
distribution: temurin
|
||||
java-version: "21"
|
||||
|
||||
- name: Install packaging dependencies
|
||||
run: |
|
||||
sudo apt-get update -qq
|
||||
sudo apt-get install -y --no-install-recommends fakeroot
|
||||
|
||||
- name: Ensure mvnw is executable
|
||||
run: chmod +x mvnw
|
||||
|
||||
- name: Build JAR and copy runtime dependencies
|
||||
run: |
|
||||
./mvnw -B -DskipTests package dependency:copy-dependencies -DincludeScope=runtime -DoutputDirectory=target/dist-libs
|
||||
cp "$(ls -t target/praktiKST-*.jar | head -n 1)" target/dist-libs/app.jar
|
||||
|
||||
- name: Build Debian package
|
||||
run: |
|
||||
mkdir -p dist
|
||||
ADD_MODULES="$(java packaging/AddModules.java)"
|
||||
jpackage \
|
||||
--type deb \
|
||||
--name KST4Contest \
|
||||
--icon packaging/icons/kst4contest.png \
|
||||
--input target/dist-libs \
|
||||
--main-jar app.jar \
|
||||
--main-class kst4contest.view.Kst4ContestApplication \
|
||||
--module-path target/dist-libs \
|
||||
--add-modules "$ADD_MODULES" \
|
||||
--linux-package-deps "libgstreamer1.0-0,libgstreamer-plugins-base1.0-0,gstreamer1.0-plugins-good" \
|
||||
--dest dist
|
||||
DEB="$(ls dist/*.deb | head -n 1)"
|
||||
if [ -z "$DEB" ]; then
|
||||
echo "No DEB produced by jpackage" && exit 1
|
||||
fi
|
||||
mv "$DEB" "dist/${ASSET_BASENAME}-debian-amd64.deb"
|
||||
|
||||
- name: Upload Debian artifact
|
||||
uses: actions/upload-artifact@v4.3.4
|
||||
with:
|
||||
name: linux-debian
|
||||
path: dist/KST4Contest-*-debian-amd64.deb
|
||||
retention-days: 14
|
||||
|
||||
build-linux-rpm:
|
||||
name: Build Fedora package
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
steps:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@v4.1.7
|
||||
|
||||
- name: Resolve nightly version info
|
||||
run: |
|
||||
VERSION=$(grep -m1 '<version>' pom.xml | sed 's/.*<version>\(.*\)<\/version>.*/\1/')
|
||||
SHORT_SHA="${GITHUB_SHA::7}"
|
||||
echo "ASSET_BASENAME=KST4Contest-${VERSION}-${SHORT_SHA}" >> "$GITHUB_ENV"
|
||||
|
||||
- name: Set up Java 21
|
||||
uses: actions/setup-java@v4.1.0
|
||||
with:
|
||||
distribution: temurin
|
||||
java-version: "21"
|
||||
|
||||
- name: Install packaging dependencies
|
||||
run: |
|
||||
sudo apt-get update -qq
|
||||
sudo apt-get install -y --no-install-recommends rpm
|
||||
|
||||
- name: Ensure mvnw is executable
|
||||
run: chmod +x mvnw
|
||||
|
||||
- name: Build JAR and copy runtime dependencies
|
||||
run: |
|
||||
./mvnw -B -DskipTests package dependency:copy-dependencies -DincludeScope=runtime -DoutputDirectory=target/dist-libs
|
||||
cp "$(ls -t target/praktiKST-*.jar | head -n 1)" target/dist-libs/app.jar
|
||||
|
||||
- name: Build Fedora package
|
||||
run: |
|
||||
mkdir -p dist
|
||||
ADD_MODULES="$(java packaging/AddModules.java)"
|
||||
jpackage \
|
||||
--type rpm \
|
||||
--name KST4Contest \
|
||||
--icon packaging/icons/kst4contest.png \
|
||||
--input target/dist-libs \
|
||||
--main-jar app.jar \
|
||||
--main-class kst4contest.view.Kst4ContestApplication \
|
||||
--module-path target/dist-libs \
|
||||
--add-modules "$ADD_MODULES" \
|
||||
--linux-package-deps "gstreamer1,gstreamer1-plugins-base,gstreamer1-plugins-good" \
|
||||
--dest dist
|
||||
RPM="$(ls dist/*.rpm | head -n 1)"
|
||||
if [ -z "$RPM" ]; then
|
||||
echo "No RPM produced by jpackage" && exit 1
|
||||
fi
|
||||
mv "$RPM" "dist/${ASSET_BASENAME}-fedora-x86_64.rpm"
|
||||
|
||||
- name: Upload Fedora artifact
|
||||
uses: actions/upload-artifact@v4.3.4
|
||||
with:
|
||||
name: linux-fedora
|
||||
path: dist/KST4Contest-*-fedora-x86_64.rpm
|
||||
retention-days: 14
|
||||
|
||||
build-linux-arch:
|
||||
name: Build Arch Linux package
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
steps:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@v4.1.7
|
||||
|
||||
- name: Resolve nightly version info
|
||||
run: |
|
||||
VERSION=$(grep -m1 '<version>' pom.xml | sed 's/.*<version>\(.*\)<\/version>.*/\1/')
|
||||
SHORT_SHA="${GITHUB_SHA::7}"
|
||||
echo "VERSION=$VERSION" >> "$GITHUB_ENV"
|
||||
echo "SHORT_SHA=$SHORT_SHA" >> "$GITHUB_ENV"
|
||||
echo "ASSET_BASENAME=KST4Contest-${VERSION}-${SHORT_SHA}" >> "$GITHUB_ENV"
|
||||
|
||||
- name: Set up Java 21
|
||||
uses: actions/setup-java@v4.1.0
|
||||
with:
|
||||
distribution: temurin
|
||||
java-version: "21"
|
||||
|
||||
- name: Install packaging dependencies
|
||||
run: |
|
||||
sudo apt-get update -qq
|
||||
sudo apt-get install -y --no-install-recommends zstd
|
||||
|
||||
- name: Ensure mvnw is executable
|
||||
run: chmod +x mvnw
|
||||
|
||||
- name: Build JAR and copy runtime dependencies
|
||||
run: |
|
||||
./mvnw -B -DskipTests package dependency:copy-dependencies -DincludeScope=runtime -DoutputDirectory=target/dist-libs
|
||||
cp "$(ls -t target/praktiKST-*.jar | head -n 1)" target/dist-libs/app.jar
|
||||
|
||||
- name: Build app-image with jpackage
|
||||
run: |
|
||||
mkdir -p dist
|
||||
ADD_MODULES="$(java packaging/AddModules.java)"
|
||||
jpackage \
|
||||
--type app-image \
|
||||
--name KST4Contest \
|
||||
--icon packaging/icons/kst4contest.png \
|
||||
--input target/dist-libs \
|
||||
--main-jar app.jar \
|
||||
--main-class kst4contest.view.Kst4ContestApplication \
|
||||
--module-path target/dist-libs \
|
||||
--add-modules "$ADD_MODULES" \
|
||||
--dest dist
|
||||
|
||||
- name: Build Arch Linux package artifact
|
||||
run: |
|
||||
ARCH=$(uname -m)
|
||||
PKGVER=$(printf '%s' "${VERSION}-${SHORT_SHA}" | sed 's/[^[:alnum:].+_]/_/g')
|
||||
PKGROOT="target/archpkg"
|
||||
rm -rf "$PKGROOT"
|
||||
mkdir -p "$PKGROOT/usr/lib/KST4Contest" "$PKGROOT/usr/bin"
|
||||
cp -a dist/KST4Contest/. "$PKGROOT/usr/lib/KST4Contest/"
|
||||
cat > "$PKGROOT/usr/bin/KST4Contest" << 'EOF'
|
||||
#!/bin/sh
|
||||
exec /usr/lib/KST4Contest/bin/KST4Contest "$@"
|
||||
EOF
|
||||
chmod 755 "$PKGROOT/usr/bin/KST4Contest"
|
||||
mkdir -p "$PKGROOT/usr/share/applications" "$PKGROOT/usr/share/icons/hicolor/256x256/apps"
|
||||
cat > "$PKGROOT/usr/share/applications/KST4Contest.desktop" << 'EOF'
|
||||
[Desktop Entry]
|
||||
Type=Application
|
||||
Name=KST4Contest
|
||||
Comment=ON4KST Chat Client for VHF/UHF contest operation
|
||||
Exec=KST4Contest
|
||||
Icon=KST4Contest
|
||||
Categories=Network;HamRadio;
|
||||
Terminal=false
|
||||
EOF
|
||||
if [ -f "$PKGROOT/usr/lib/KST4Contest/lib/KST4Contest.png" ]; then
|
||||
cp "$PKGROOT/usr/lib/KST4Contest/lib/KST4Contest.png" "$PKGROOT/usr/share/icons/hicolor/256x256/apps/KST4Contest.png"
|
||||
fi
|
||||
INSTALLED_SIZE=$(du -sb "$PKGROOT" | cut -f1)
|
||||
BUILDDATE=$(date +%s)
|
||||
WORKFLOW_SHA256=$(sha256sum "$GITHUB_WORKSPACE/.github/workflows/nightly-artifacts.yml" | awk '{print $1}')
|
||||
{
|
||||
echo "pkgname = kst4contest"
|
||||
echo "pkgbase = kst4contest"
|
||||
echo "xdata = pkgtype=pkg"
|
||||
echo "pkgver = ${PKGVER}-1"
|
||||
echo "pkgdesc = KST4Contest amateur radio contest logger"
|
||||
echo "url = https://github.com/${{ github.repository }}"
|
||||
echo "builddate = ${BUILDDATE}"
|
||||
echo "packager = GitHub Actions"
|
||||
echo "size = ${INSTALLED_SIZE}"
|
||||
echo "arch = ${ARCH}"
|
||||
echo "license = custom"
|
||||
echo "depend = java-runtime"
|
||||
echo "depend = gst-plugins-base"
|
||||
echo "depend = gst-plugins-good"
|
||||
} > "$PKGROOT/.PKGINFO"
|
||||
{
|
||||
echo "format = 2"
|
||||
echo "pkgname = kst4contest"
|
||||
echo "pkgbase = kst4contest"
|
||||
echo "pkgver = ${PKGVER}-1"
|
||||
echo "pkgarch = ${ARCH}"
|
||||
echo "pkgbuild_sha256sum = ${WORKFLOW_SHA256}"
|
||||
echo "packager = GitHub Actions"
|
||||
echo "builddate = ${BUILDDATE}"
|
||||
echo "builddir = /build"
|
||||
echo "startdir = /build"
|
||||
echo "buildtool = makepkg"
|
||||
echo "buildtoolver = 7.0.0-1-x86_64"
|
||||
echo "buildenv = !distcc !color !ccache check !sign"
|
||||
echo "options = !strip docs libtool staticlibs emptydirs zipman purge !debug !lto"
|
||||
} > "$PKGROOT/.BUILDINFO"
|
||||
tar --zstd --transform 's|^\./||' -cf "dist/${ASSET_BASENAME}-archlinux-${ARCH}.pkg.tar.zst" -C "$PKGROOT" .
|
||||
|
||||
- name: Upload Arch Linux artifact
|
||||
uses: actions/upload-artifact@v4.3.4
|
||||
with:
|
||||
name: linux-arch
|
||||
path: dist/KST4Contest-*-archlinux-*.pkg.tar.zst
|
||||
retention-days: 14
|
||||
|
||||
build-flatpak:
|
||||
name: Build Flatpak
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
steps:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@v4.1.7
|
||||
|
||||
- name: Resolve nightly version info
|
||||
run: |
|
||||
VERSION=$(grep -m1 '<version>' pom.xml | sed 's/.*<version>\(.*\)<\/version>.*/\1/')
|
||||
SHORT_SHA="${GITHUB_SHA::7}"
|
||||
echo "VERSION=$VERSION" >> "$GITHUB_ENV"
|
||||
echo "SHORT_SHA=$SHORT_SHA" >> "$GITHUB_ENV"
|
||||
echo "ASSET_BASENAME=KST4Contest-${VERSION}-${SHORT_SHA}" >> "$GITHUB_ENV"
|
||||
|
||||
- name: Set up Java 21
|
||||
uses: actions/setup-java@v4.1.0
|
||||
with:
|
||||
distribution: temurin
|
||||
java-version: "21"
|
||||
|
||||
- name: Ensure mvnw is executable
|
||||
run: chmod +x mvnw
|
||||
|
||||
- name: Install Flatpak tooling
|
||||
run: |
|
||||
sudo apt-get update -qq
|
||||
sudo apt-get install -y --no-install-recommends flatpak flatpak-builder elfutils
|
||||
flatpak remote-add --user --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
|
||||
flatpak --user install -y flathub org.freedesktop.Platform//24.08 org.freedesktop.Sdk//24.08
|
||||
|
||||
- name: Build app-image with jpackage
|
||||
run: |
|
||||
./mvnw -B -DskipTests package dependency:copy-dependencies -DincludeScope=runtime -DoutputDirectory=target/dist-libs
|
||||
cp "$(ls -t target/praktiKST-*.jar | head -n 1)" target/dist-libs/app.jar
|
||||
mkdir -p target/flatpak-src
|
||||
ADD_MODULES="$(java packaging/AddModules.java)"
|
||||
jpackage \
|
||||
--type app-image \
|
||||
--name KST4Contest \
|
||||
--icon packaging/icons/kst4contest.png \
|
||||
--input target/dist-libs \
|
||||
--main-jar app.jar \
|
||||
--main-class kst4contest.view.Kst4ContestApplication \
|
||||
--module-path target/dist-libs \
|
||||
--add-modules "$ADD_MODULES" \
|
||||
--dest target/flatpak-src
|
||||
|
||||
- name: Create Flatpak manifest
|
||||
run: |
|
||||
mkdir -p dist
|
||||
cat > target/de.x08.KST4Contest.yml << 'EOF'
|
||||
app-id: de.x08.KST4Contest
|
||||
runtime: org.freedesktop.Platform
|
||||
runtime-version: "24.08"
|
||||
sdk: org.freedesktop.Sdk
|
||||
command: KST4Contest
|
||||
finish-args:
|
||||
- --socket=wayland
|
||||
- --socket=x11
|
||||
- --socket=pulseaudio
|
||||
- --share=network
|
||||
- --share=ipc
|
||||
- --device=dri
|
||||
- --filesystem=~/.praktiKST
|
||||
- --env=ALSA_CONFIG_PATH=/app/share/alsa/asound.conf
|
||||
modules:
|
||||
- name: kst4contest
|
||||
buildsystem: simple
|
||||
build-commands:
|
||||
- install -d /app/lib/KST4Contest /app/bin /app/share/applications /app/share/alsa
|
||||
- printf '@include /usr/share/alsa/alsa.conf\npcm.!default { type pulse }\nctl.!default { type pulse }\n' > /app/share/alsa/asound.conf
|
||||
- cp -a . /app/lib/KST4Contest/
|
||||
- printf '#!/bin/sh\nexec /app/lib/KST4Contest/bin/KST4Contest "$@"\n' > /app/bin/KST4Contest
|
||||
- chmod 755 /app/bin/KST4Contest
|
||||
- echo '[Desktop Entry]' > /app/share/applications/de.x08.KST4Contest.desktop
|
||||
- echo 'Type=Application' >> /app/share/applications/de.x08.KST4Contest.desktop
|
||||
- echo 'Name=KST4Contest' >> /app/share/applications/de.x08.KST4Contest.desktop
|
||||
- echo 'Comment=ON4KST Chat Client for VHF/UHF contest operation' >> /app/share/applications/de.x08.KST4Contest.desktop
|
||||
- echo 'Exec=KST4Contest' >> /app/share/applications/de.x08.KST4Contest.desktop
|
||||
- echo 'Icon=de.x08.KST4Contest' >> /app/share/applications/de.x08.KST4Contest.desktop
|
||||
- printf 'Categories=Network;HamRadio;\n' >> /app/share/applications/de.x08.KST4Contest.desktop
|
||||
- echo 'Terminal=false' >> /app/share/applications/de.x08.KST4Contest.desktop
|
||||
- test -f /app/lib/KST4Contest/lib/KST4Contest.png && install -Dm644 /app/lib/KST4Contest/lib/KST4Contest.png /app/share/icons/hicolor/256x256/apps/de.x08.KST4Contest.png || true
|
||||
sources:
|
||||
- type: dir
|
||||
path: flatpak-src/KST4Contest
|
||||
EOF
|
||||
|
||||
- name: Import Flatpak signing key
|
||||
run: |
|
||||
echo "${{ secrets.FLATPAK_GPG_PRIVATE_KEY }}" | gpg --batch --import
|
||||
FLATPAK_GPG_KEY_ID=$(gpg --list-secret-keys --with-colons | awk -F: '/^fpr/{print $10; exit}')
|
||||
echo "FLATPAK_GPG_KEY_ID=$FLATPAK_GPG_KEY_ID" >> "$GITHUB_ENV"
|
||||
|
||||
- name: Build Flatpak repo (nightly)
|
||||
run: |
|
||||
flatpak-builder --force-clean target/flatpak-build target/de.x08.KST4Contest.yml
|
||||
flatpak build-export --gpg-sign="$FLATPAK_GPG_KEY_ID" target/flatpak-repo target/flatpak-build nightly
|
||||
flatpak build-update-repo --gpg-sign="$FLATPAK_GPG_KEY_ID" target/flatpak-repo
|
||||
|
||||
- name: Create flatpakref (nightly)
|
||||
run: |
|
||||
REPO_NAME="${GITHUB_REPOSITORY#*/}"
|
||||
PAGES_URL="https://${GITHUB_REPOSITORY_OWNER}.github.io/${REPO_NAME}/"
|
||||
GPG_KEY_B64=$(gpg --export "$FLATPAK_GPG_KEY_ID" | base64 -w 0)
|
||||
cat > "dist/de.x08.KST4Contest.nightly.flatpakref" << EOF
|
||||
[Flatpak Ref]
|
||||
Name=de.x08.KST4Contest
|
||||
Branch=nightly
|
||||
Title=KST4Contest (Nightly) – ON4KST Chat Client
|
||||
Url=${PAGES_URL}
|
||||
RuntimeRepo=https://flathub.org/repo/flathub.flatpakrepo
|
||||
GPGKey=${GPG_KEY_B64}
|
||||
IsRuntime=false
|
||||
EOF
|
||||
|
||||
- name: Upload flatpakref
|
||||
uses: actions/upload-artifact@v4.3.4
|
||||
with:
|
||||
name: flatpakref
|
||||
path: dist/de.x08.KST4Contest.nightly.flatpakref
|
||||
|
||||
- name: Upload Flatpak OSTree repo
|
||||
uses: actions/upload-artifact@v4.3.4
|
||||
with:
|
||||
name: flatpak-ostree-repo
|
||||
path: target/flatpak-repo/
|
||||
|
||||
publish-flatpak-repo:
|
||||
name: Publish Flatpak OSTree Repo (nightly)
|
||||
runs-on: ubuntu-latest
|
||||
needs: build-flatpak
|
||||
|
||||
steps:
|
||||
- name: Install Flatpak tooling
|
||||
run: |
|
||||
sudo apt-get update -qq
|
||||
sudo apt-get install -y --no-install-recommends flatpak
|
||||
|
||||
- name: Import Flatpak signing key
|
||||
run: |
|
||||
echo "${{ secrets.FLATPAK_GPG_PRIVATE_KEY }}" | gpg --batch --import
|
||||
echo "FLATPAK_GPG_KEY_ID=$(gpg --list-secret-keys --with-colons | awk -F: '/^fpr/{print $10; exit}')" >> "$GITHUB_ENV"
|
||||
|
||||
- name: Download OSTree repo artifact
|
||||
uses: actions/download-artifact@v4.1.3
|
||||
with:
|
||||
name: flatpak-ostree-repo
|
||||
path: flatpak-ostree-repo/
|
||||
|
||||
- name: Checkout existing flatpak-repo branch
|
||||
uses: actions/checkout@v4.1.7
|
||||
with:
|
||||
ref: flatpak-repo
|
||||
path: existing-flatpak-repo
|
||||
|
||||
- name: Merge nightly build into flatpak-repo
|
||||
run: |
|
||||
cd existing-flatpak-repo
|
||||
git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
|
||||
git config user.name "github-actions[bot]"
|
||||
# Copy the new OSTree build into the repo
|
||||
rsync -a ../flatpak-ostree-repo/ ./
|
||||
# Regenerate summary with all branches
|
||||
flatpak build-update-repo --gpg-sign="$FLATPAK_GPG_KEY_ID" .
|
||||
# Generate .flatpakrepo with embedded GPG key so users can do remote-add without errors
|
||||
REPO_NAME="${GITHUB_REPOSITORY#*/}"
|
||||
PAGES_URL="https://${GITHUB_REPOSITORY_OWNER}.github.io/${REPO_NAME}/"
|
||||
GPG_KEY_B64=$(gpg --export "$FLATPAK_GPG_KEY_ID" | base64 -w 0)
|
||||
cat > kst4contest.flatpakrepo << EOF
|
||||
[Flatpak Repo]
|
||||
Title=KST4Contest
|
||||
Url=${PAGES_URL}
|
||||
Homepage=https://github.com/${GITHUB_REPOSITORY}
|
||||
Comment=KST4Contest – ON4KST Chat Client for VHF/UHF contests
|
||||
GPGKey=${GPG_KEY_B64}
|
||||
EOF
|
||||
# Stage all changes (new/updated refs, summary, objects in OSTree)
|
||||
git add -A
|
||||
if git diff --cached --quiet; then
|
||||
echo "No changes to commit"
|
||||
else
|
||||
git commit -m "Nightly flatpak: $(echo ${{ github.sha }} | cut -c1-7)"
|
||||
git push https://x-access-token:${{ secrets.GITHUB_TOKEN }}@github.com/${{ github.repository }}.git HEAD:flatpak-repo
|
||||
fi
|
||||
|
||||
build-macos-dmg:
|
||||
name: Build macOS DMG (${{ matrix.os }})
|
||||
runs-on: ${{ matrix.os }}
|
||||
strategy:
|
||||
fail-fast: false
|
||||
matrix:
|
||||
os: [macos-latest, macos-15-intel]
|
||||
|
||||
@@ -627,47 +174,41 @@ jobs:
|
||||
echo "ASSET_BASENAME=KST4Contest-${VERSION}-${SHORT_SHA}" >> "$GITHUB_ENV"
|
||||
echo "ARCH=$ARCH" >> "$GITHUB_ENV"
|
||||
|
||||
- name: Set up Java 21
|
||||
- name: Set up Java 17
|
||||
uses: actions/setup-java@v4.1.0
|
||||
with:
|
||||
distribution: temurin
|
||||
java-version: "21"
|
||||
java-version: "17"
|
||||
|
||||
- name: Ensure mvnw is executable
|
||||
run: chmod +x mvnw
|
||||
|
||||
- name: Import signing certificate
|
||||
env:
|
||||
MACOS_CERT_P12: ${{ secrets.MACOS_CERT_P12 }}
|
||||
MACOS_CERT_PASSWORD: ${{ secrets.MACOS_CERT_PASSWORD }}
|
||||
run: ./packaging/macos/ci-import-cert.sh
|
||||
|
||||
# Builds the jar, signs the app bundle and every native library inside it,
|
||||
# wraps it into a DMG and has Apple notarize the result. Same script the
|
||||
# local Mac uses, so the two cannot drift apart.
|
||||
- name: Build signed and notarized DMG
|
||||
env:
|
||||
MACOS_NOTARY_KEY: ${{ secrets.MACOS_NOTARY_KEY }}
|
||||
NOTARY_KEY_ID: ${{ secrets.MACOS_NOTARY_KEY_ID }}
|
||||
NOTARY_ISSUER: ${{ secrets.MACOS_NOTARY_ISSUER }}
|
||||
- name: Build JAR and copy runtime dependencies
|
||||
run: |
|
||||
printf '%s' "$MACOS_NOTARY_KEY" | base64 --decode > "$RUNNER_TEMP/notary.p8"
|
||||
export NOTARY_KEY="$RUNNER_TEMP/notary.p8"
|
||||
./packaging/macos/build-signed-dmg.sh
|
||||
./mvnw -B -DskipTests package dependency:copy-dependencies -DincludeScope=runtime -DoutputDirectory=target/dist-libs
|
||||
cp "$(ls -t target/praktiKST-*.jar | head -n 1)" target/dist-libs/app.jar
|
||||
|
||||
- name: Remove signing credentials
|
||||
if: always()
|
||||
- name: Build macOS DMG with jpackage
|
||||
run: |
|
||||
rm -f "$RUNNER_TEMP/notary.p8"
|
||||
if [ -n "${SIGNING_KEYCHAIN:-}" ]; then
|
||||
security delete-keychain "$SIGNING_KEYCHAIN" || true
|
||||
fi
|
||||
mkdir -p dist
|
||||
jpackage \
|
||||
--type dmg \
|
||||
--name KST4Contest \
|
||||
--input target/dist-libs \
|
||||
--main-jar app.jar \
|
||||
--main-class kst4contest.view.Kst4ContestApplication \
|
||||
--module-path target/dist-libs \
|
||||
--add-modules javafx.controls,javafx.graphics,javafx.fxml,javafx.web,javafx.media,java.sql \
|
||||
--dest dist
|
||||
|
||||
env:
|
||||
MACOSX_DEPLOYMENT_TARGET: "13.0"
|
||||
|
||||
- name: Rename DMG artifact
|
||||
run: |
|
||||
DMG=$(ls dist/*.dmg | head -n 1)
|
||||
if [ -z "$DMG" ]; then
|
||||
echo "No DMG produced by the build" && exit 1
|
||||
echo "No DMG produced by jpackage" && exit 1
|
||||
fi
|
||||
mv "$DMG" "dist/${ASSET_BASENAME}-macos-${ARCH}.dmg"
|
||||
|
||||
|
||||
@@ -11,24 +11,21 @@ env:
|
||||
|
||||
jobs:
|
||||
compile:
|
||||
name: Compile (Java 21)
|
||||
name: Compile (Java 17)
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
steps:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@v4.1.7
|
||||
|
||||
- name: Set up Java 21
|
||||
- name: Set up Java 17
|
||||
uses: actions/setup-java@v4.1.0
|
||||
with:
|
||||
distribution: temurin
|
||||
java-version: "21"
|
||||
java-version: "17"
|
||||
|
||||
- name: Ensure mvnw is executable
|
||||
run: chmod +x mvnw
|
||||
|
||||
- name: Verify packaging module list matches module-info.java
|
||||
run: java packaging/AddModules.java --verify-pom
|
||||
|
||||
- name: Compile
|
||||
run: ./mvnw -B -DskipTests compile
|
||||
|
||||
@@ -7,10 +7,7 @@ on:
|
||||
workflow_dispatch:
|
||||
|
||||
permissions:
|
||||
actions: read
|
||||
contents: write
|
||||
issues: read
|
||||
packages: write
|
||||
|
||||
env:
|
||||
FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true
|
||||
@@ -24,11 +21,11 @@ jobs:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@v4.1.7
|
||||
|
||||
- name: Set up Java 21
|
||||
- name: Set up Java 17
|
||||
uses: actions/setup-java@v4.1.0
|
||||
with:
|
||||
distribution: temurin
|
||||
java-version: "21"
|
||||
java-version: "17"
|
||||
|
||||
- name: Install WiX Toolset
|
||||
shell: pwsh
|
||||
@@ -48,18 +45,7 @@ jobs:
|
||||
shell: pwsh
|
||||
run: |
|
||||
New-Item -ItemType Directory -Force -Path dist | Out-Null
|
||||
$addModules = & java packaging/AddModules.java
|
||||
if ($LASTEXITCODE -ne 0) { throw "Failed to resolve --add-modules from module-info.java" }
|
||||
jpackage `
|
||||
--type app-image `
|
||||
--name praktiKST `
|
||||
--icon packaging/icons/kst4contest.ico `
|
||||
--input target/dist-libs `
|
||||
--main-jar app.jar `
|
||||
--main-class kst4contest.view.Kst4ContestApplication `
|
||||
--module-path target/dist-libs `
|
||||
--add-modules $addModules `
|
||||
--dest dist
|
||||
jpackage --type app-image --name praktiKST --input target/dist-libs --main-jar app.jar --main-class kst4contest.view.Kst4ContestApplication --module-path target/dist-libs --add-modules javafx.controls,javafx.graphics,javafx.fxml,javafx.web,javafx.media,java.sql --dest dist
|
||||
|
||||
- name: Create Windows ZIP
|
||||
shell: pwsh
|
||||
@@ -83,11 +69,11 @@ jobs:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@v4.1.7
|
||||
|
||||
- name: Set up Java 21
|
||||
- name: Set up Java 17
|
||||
uses: actions/setup-java@v4.1.0
|
||||
with:
|
||||
distribution: temurin
|
||||
java-version: "21"
|
||||
java-version: "17"
|
||||
|
||||
- name: Ensure mvnw is executable
|
||||
run: chmod +x mvnw
|
||||
@@ -100,16 +86,14 @@ jobs:
|
||||
- name: Build app-image with jpackage
|
||||
run: |
|
||||
mkdir -p dist
|
||||
ADD_MODULES="$(java packaging/AddModules.java)"
|
||||
jpackage \
|
||||
--type app-image \
|
||||
--name KST4Contest \
|
||||
--icon packaging/icons/kst4contest.png \
|
||||
--input target/dist-libs \
|
||||
--main-jar app.jar \
|
||||
--main-class kst4contest.view.Kst4ContestApplication \
|
||||
--module-path target/dist-libs \
|
||||
--add-modules "$ADD_MODULES" \
|
||||
--add-modules javafx.controls,javafx.graphics,javafx.fxml,javafx.web,javafx.media,java.sql \
|
||||
--dest dist
|
||||
|
||||
- name: Create AppDir metadata
|
||||
@@ -150,363 +134,10 @@ jobs:
|
||||
name: linux-appimage
|
||||
path: dist/KST4Contest-${{ github.ref_name }}-linux-x86_64.AppImage
|
||||
|
||||
build-linux-deb:
|
||||
name: Build Debian package
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
steps:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@v4.1.7
|
||||
|
||||
- name: Set up Java 21
|
||||
uses: actions/setup-java@v4.1.0
|
||||
with:
|
||||
distribution: temurin
|
||||
java-version: "21"
|
||||
|
||||
- name: Install packaging dependencies
|
||||
run: |
|
||||
sudo apt-get update -qq
|
||||
sudo apt-get install -y --no-install-recommends fakeroot
|
||||
|
||||
- name: Ensure mvnw is executable
|
||||
run: chmod +x mvnw
|
||||
|
||||
- name: Build JAR and copy runtime dependencies
|
||||
run: |
|
||||
./mvnw -B -DskipTests package dependency:copy-dependencies -DincludeScope=runtime -DoutputDirectory=target/dist-libs
|
||||
cp "$(ls -t target/praktiKST-*.jar | head -n 1)" target/dist-libs/app.jar
|
||||
|
||||
- name: Build Debian package
|
||||
run: |
|
||||
mkdir -p dist
|
||||
ADD_MODULES="$(java packaging/AddModules.java)"
|
||||
jpackage \
|
||||
--type deb \
|
||||
--name KST4Contest \
|
||||
--icon packaging/icons/kst4contest.png \
|
||||
--input target/dist-libs \
|
||||
--main-jar app.jar \
|
||||
--main-class kst4contest.view.Kst4ContestApplication \
|
||||
--module-path target/dist-libs \
|
||||
--add-modules "$ADD_MODULES" \
|
||||
--linux-package-deps "libgstreamer1.0-0,libgstreamer-plugins-base1.0-0,gstreamer1.0-plugins-good" \
|
||||
--dest dist
|
||||
DEB="$(ls dist/*.deb | head -n 1)"
|
||||
if [ -z "$DEB" ]; then
|
||||
echo "No DEB produced by jpackage" && exit 1
|
||||
fi
|
||||
mv "$DEB" "dist/KST4Contest-${{ github.ref_name }}-debian-amd64.deb"
|
||||
|
||||
- name: Upload Debian artifact
|
||||
uses: actions/upload-artifact@v4.3.4
|
||||
with:
|
||||
name: linux-debian
|
||||
path: dist/KST4Contest-${{ github.ref_name }}-debian-amd64.deb
|
||||
|
||||
build-linux-rpm:
|
||||
name: Build Fedora package
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
steps:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@v4.1.7
|
||||
|
||||
- name: Set up Java 21
|
||||
uses: actions/setup-java@v4.1.0
|
||||
with:
|
||||
distribution: temurin
|
||||
java-version: "21"
|
||||
|
||||
- name: Install packaging dependencies
|
||||
run: |
|
||||
sudo apt-get update -qq
|
||||
sudo apt-get install -y --no-install-recommends rpm
|
||||
|
||||
- name: Ensure mvnw is executable
|
||||
run: chmod +x mvnw
|
||||
|
||||
- name: Build JAR and copy runtime dependencies
|
||||
run: |
|
||||
./mvnw -B -DskipTests package dependency:copy-dependencies -DincludeScope=runtime -DoutputDirectory=target/dist-libs
|
||||
cp "$(ls -t target/praktiKST-*.jar | head -n 1)" target/dist-libs/app.jar
|
||||
|
||||
- name: Build Fedora package
|
||||
run: |
|
||||
mkdir -p dist
|
||||
ADD_MODULES="$(java packaging/AddModules.java)"
|
||||
jpackage \
|
||||
--type rpm \
|
||||
--name KST4Contest \
|
||||
--icon packaging/icons/kst4contest.png \
|
||||
--input target/dist-libs \
|
||||
--main-jar app.jar \
|
||||
--main-class kst4contest.view.Kst4ContestApplication \
|
||||
--module-path target/dist-libs \
|
||||
--add-modules "$ADD_MODULES" \
|
||||
--linux-package-deps "gstreamer1,gstreamer1-plugins-base,gstreamer1-plugins-good" \
|
||||
--dest dist
|
||||
RPM="$(ls dist/*.rpm | head -n 1)"
|
||||
if [ -z "$RPM" ]; then
|
||||
echo "No RPM produced by jpackage" && exit 1
|
||||
fi
|
||||
mv "$RPM" "dist/KST4Contest-${{ github.ref_name }}-fedora-x86_64.rpm"
|
||||
|
||||
- name: Upload Fedora artifact
|
||||
uses: actions/upload-artifact@v4.3.4
|
||||
with:
|
||||
name: linux-fedora
|
||||
path: dist/KST4Contest-${{ github.ref_name }}-fedora-x86_64.rpm
|
||||
|
||||
build-linux-arch:
|
||||
name: Build Arch Linux package
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
steps:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@v4.1.7
|
||||
|
||||
- name: Set up Java 21
|
||||
uses: actions/setup-java@v4.1.0
|
||||
with:
|
||||
distribution: temurin
|
||||
java-version: "21"
|
||||
|
||||
- name: Install packaging dependencies
|
||||
run: |
|
||||
sudo apt-get update -qq
|
||||
sudo apt-get install -y --no-install-recommends zstd
|
||||
|
||||
- name: Ensure mvnw is executable
|
||||
run: chmod +x mvnw
|
||||
|
||||
- name: Build JAR and copy runtime dependencies
|
||||
run: |
|
||||
./mvnw -B -DskipTests package dependency:copy-dependencies -DincludeScope=runtime -DoutputDirectory=target/dist-libs
|
||||
cp "$(ls -t target/praktiKST-*.jar | head -n 1)" target/dist-libs/app.jar
|
||||
|
||||
- name: Build app-image with jpackage
|
||||
run: |
|
||||
mkdir -p dist
|
||||
ADD_MODULES="$(java packaging/AddModules.java)"
|
||||
jpackage \
|
||||
--type app-image \
|
||||
--name KST4Contest \
|
||||
--icon packaging/icons/kst4contest.png \
|
||||
--input target/dist-libs \
|
||||
--main-jar app.jar \
|
||||
--main-class kst4contest.view.Kst4ContestApplication \
|
||||
--module-path target/dist-libs \
|
||||
--add-modules "$ADD_MODULES" \
|
||||
--dest dist
|
||||
|
||||
- name: Build Arch Linux package artifact
|
||||
run: |
|
||||
ARCH=$(uname -m)
|
||||
PKGVER=$(printf '%s' "${{ github.ref_name }}" | sed 's/[^[:alnum:].+_]/_/g')
|
||||
PKGROOT="target/archpkg"
|
||||
rm -rf "$PKGROOT"
|
||||
mkdir -p "$PKGROOT/usr/lib/KST4Contest" "$PKGROOT/usr/bin"
|
||||
cp -a dist/KST4Contest/. "$PKGROOT/usr/lib/KST4Contest/"
|
||||
cat > "$PKGROOT/usr/bin/KST4Contest" << 'EOF'
|
||||
#!/bin/sh
|
||||
exec /usr/lib/KST4Contest/bin/KST4Contest "$@"
|
||||
EOF
|
||||
chmod 755 "$PKGROOT/usr/bin/KST4Contest"
|
||||
mkdir -p "$PKGROOT/usr/share/applications" "$PKGROOT/usr/share/icons/hicolor/256x256/apps"
|
||||
cat > "$PKGROOT/usr/share/applications/KST4Contest.desktop" << 'EOF'
|
||||
[Desktop Entry]
|
||||
Type=Application
|
||||
Name=KST4Contest
|
||||
Comment=ON4KST Chat Client for VHF/UHF contest operation
|
||||
Exec=KST4Contest
|
||||
Icon=KST4Contest
|
||||
Categories=Network;HamRadio;
|
||||
Terminal=false
|
||||
EOF
|
||||
if [ -f "$PKGROOT/usr/lib/KST4Contest/lib/KST4Contest.png" ]; then
|
||||
cp "$PKGROOT/usr/lib/KST4Contest/lib/KST4Contest.png" "$PKGROOT/usr/share/icons/hicolor/256x256/apps/KST4Contest.png"
|
||||
fi
|
||||
INSTALLED_SIZE=$(du -sb "$PKGROOT" | cut -f1)
|
||||
BUILDDATE=$(date +%s)
|
||||
WORKFLOW_SHA256=$(sha256sum "$GITHUB_WORKSPACE/.github/workflows/tagged-release.yml" | awk '{print $1}')
|
||||
{
|
||||
echo "pkgname = kst4contest"
|
||||
echo "pkgbase = kst4contest"
|
||||
echo "xdata = pkgtype=pkg"
|
||||
echo "pkgver = ${PKGVER}-1"
|
||||
echo "pkgdesc = KST4Contest amateur radio contest logger"
|
||||
echo "url = https://github.com/${{ github.repository }}"
|
||||
echo "builddate = ${BUILDDATE}"
|
||||
echo "packager = GitHub Actions"
|
||||
echo "size = ${INSTALLED_SIZE}"
|
||||
echo "arch = ${ARCH}"
|
||||
echo "license = custom"
|
||||
echo "depend = java-runtime"
|
||||
echo "depend = gst-plugins-base"
|
||||
echo "depend = gst-plugins-good"
|
||||
} > "$PKGROOT/.PKGINFO"
|
||||
{
|
||||
echo "format = 2"
|
||||
echo "pkgname = kst4contest"
|
||||
echo "pkgbase = kst4contest"
|
||||
echo "pkgver = ${PKGVER}-1"
|
||||
echo "pkgarch = ${ARCH}"
|
||||
echo "pkgbuild_sha256sum = ${WORKFLOW_SHA256}"
|
||||
echo "packager = GitHub Actions"
|
||||
echo "builddate = ${BUILDDATE}"
|
||||
echo "builddir = /build"
|
||||
echo "startdir = /build"
|
||||
echo "buildtool = makepkg"
|
||||
echo "buildtoolver = 7.0.0-1-x86_64"
|
||||
echo "buildenv = !distcc !color !ccache check !sign"
|
||||
echo "options = !strip docs libtool staticlibs emptydirs zipman purge !debug !lto"
|
||||
} > "$PKGROOT/.BUILDINFO"
|
||||
tar --zstd --transform 's|^\./||' -cf "dist/KST4Contest-${{ github.ref_name }}-archlinux-${ARCH}.pkg.tar.zst" -C "$PKGROOT" .
|
||||
|
||||
- name: Upload Arch Linux artifact
|
||||
uses: actions/upload-artifact@v4.3.4
|
||||
with:
|
||||
name: linux-arch
|
||||
path: dist/KST4Contest-${{ github.ref_name }}-archlinux-*.pkg.tar.zst
|
||||
|
||||
build-flatpak:
|
||||
name: Build Flatpak
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
steps:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@v4.1.7
|
||||
|
||||
- name: Set up Java 21
|
||||
uses: actions/setup-java@v4.1.0
|
||||
with:
|
||||
distribution: temurin
|
||||
java-version: "21"
|
||||
|
||||
- name: Ensure mvnw is executable
|
||||
run: chmod +x mvnw
|
||||
|
||||
- name: Install Flatpak tooling
|
||||
run: |
|
||||
sudo apt-get update -qq
|
||||
sudo apt-get install -y --no-install-recommends flatpak flatpak-builder elfutils
|
||||
flatpak remote-add --user --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
|
||||
flatpak --user install -y flathub org.freedesktop.Platform//24.08 org.freedesktop.Sdk//24.08
|
||||
|
||||
- name: Build app-image with jpackage
|
||||
run: |
|
||||
./mvnw -B -DskipTests package dependency:copy-dependencies -DincludeScope=runtime -DoutputDirectory=target/dist-libs
|
||||
cp "$(ls -t target/praktiKST-*.jar | head -n 1)" target/dist-libs/app.jar
|
||||
mkdir -p target/flatpak-src
|
||||
ADD_MODULES="$(java packaging/AddModules.java)"
|
||||
jpackage \
|
||||
--type app-image \
|
||||
--name KST4Contest \
|
||||
--icon packaging/icons/kst4contest.png \
|
||||
--input target/dist-libs \
|
||||
--main-jar app.jar \
|
||||
--main-class kst4contest.view.Kst4ContestApplication \
|
||||
--module-path target/dist-libs \
|
||||
--add-modules "$ADD_MODULES" \
|
||||
--dest target/flatpak-src
|
||||
|
||||
- name: Create Flatpak manifest
|
||||
run: |
|
||||
mkdir -p dist
|
||||
cat > target/de.x08.KST4Contest.yml << 'EOF'
|
||||
app-id: de.x08.KST4Contest
|
||||
runtime: org.freedesktop.Platform
|
||||
runtime-version: "24.08"
|
||||
sdk: org.freedesktop.Sdk
|
||||
command: KST4Contest
|
||||
finish-args:
|
||||
- --socket=wayland
|
||||
- --socket=x11
|
||||
- --socket=pulseaudio
|
||||
- --share=network
|
||||
- --share=ipc
|
||||
- --device=dri
|
||||
- --filesystem=~/.praktiKST
|
||||
- --env=ALSA_CONFIG_PATH=/app/share/alsa/asound.conf
|
||||
modules:
|
||||
- name: kst4contest
|
||||
buildsystem: simple
|
||||
build-commands:
|
||||
- install -d /app/lib/KST4Contest /app/bin /app/share/applications /app/share/alsa
|
||||
- printf '@include /usr/share/alsa/alsa.conf\npcm.!default { type pulse }\nctl.!default { type pulse }\n' > /app/share/alsa/asound.conf
|
||||
- cp -a . /app/lib/KST4Contest/
|
||||
- printf '#!/bin/sh\nexec /app/lib/KST4Contest/bin/KST4Contest "$@"\n' > /app/bin/KST4Contest
|
||||
- chmod 755 /app/bin/KST4Contest
|
||||
- echo '[Desktop Entry]' > /app/share/applications/de.x08.KST4Contest.desktop
|
||||
- echo 'Type=Application' >> /app/share/applications/de.x08.KST4Contest.desktop
|
||||
- echo 'Name=KST4Contest' >> /app/share/applications/de.x08.KST4Contest.desktop
|
||||
- echo 'Comment=ON4KST Chat Client for VHF/UHF contest operation' >> /app/share/applications/de.x08.KST4Contest.desktop
|
||||
- echo 'Exec=KST4Contest' >> /app/share/applications/de.x08.KST4Contest.desktop
|
||||
- echo 'Icon=de.x08.KST4Contest' >> /app/share/applications/de.x08.KST4Contest.desktop
|
||||
- printf 'Categories=Network;HamRadio;\n' >> /app/share/applications/de.x08.KST4Contest.desktop
|
||||
- echo 'Terminal=false' >> /app/share/applications/de.x08.KST4Contest.desktop
|
||||
- test -f /app/lib/KST4Contest/lib/KST4Contest.png && install -Dm644 /app/lib/KST4Contest/lib/KST4Contest.png /app/share/icons/hicolor/256x256/apps/de.x08.KST4Contest.png || true
|
||||
sources:
|
||||
- type: dir
|
||||
path: flatpak-src/KST4Contest
|
||||
EOF
|
||||
|
||||
- name: Import Flatpak signing key
|
||||
run: |
|
||||
echo "${{ secrets.FLATPAK_GPG_PRIVATE_KEY }}" | gpg --batch --import
|
||||
FLATPAK_GPG_KEY_ID=$(gpg --list-secret-keys --with-colons | awk -F: '/^fpr/{print $10; exit}')
|
||||
echo "FLATPAK_GPG_KEY_ID=$FLATPAK_GPG_KEY_ID" >> "$GITHUB_ENV"
|
||||
|
||||
- name: Determine OSTree branch and flatpakref filename
|
||||
run: |
|
||||
if [[ "${{ github.ref_name }}" == beta-* ]]; then
|
||||
echo "OSTREE_BRANCH=beta" >> "$GITHUB_ENV"
|
||||
echo "FLATPAKREF_NAME=de.x08.KST4Contest.beta.flatpakref" >> "$GITHUB_ENV"
|
||||
else
|
||||
echo "OSTREE_BRANCH=stable" >> "$GITHUB_ENV"
|
||||
echo "FLATPAKREF_NAME=de.x08.KST4Contest.flatpakref" >> "$GITHUB_ENV"
|
||||
fi
|
||||
|
||||
- name: Build Flatpak repo
|
||||
run: |
|
||||
flatpak-builder --force-clean target/flatpak-build target/de.x08.KST4Contest.yml
|
||||
flatpak build-export --gpg-sign="$FLATPAK_GPG_KEY_ID" target/flatpak-repo target/flatpak-build "$OSTREE_BRANCH"
|
||||
flatpak build-update-repo --gpg-sign="$FLATPAK_GPG_KEY_ID" target/flatpak-repo
|
||||
|
||||
- name: Create flatpakref
|
||||
run: |
|
||||
REPO_NAME="${GITHUB_REPOSITORY#*/}"
|
||||
PAGES_URL="https://${GITHUB_REPOSITORY_OWNER}.github.io/${REPO_NAME}/"
|
||||
GPG_KEY_B64=$(gpg --export "$FLATPAK_GPG_KEY_ID" | base64 -w 0)
|
||||
cat > "dist/${FLATPAKREF_NAME}" << EOF
|
||||
[Flatpak Ref]
|
||||
Name=de.x08.KST4Contest
|
||||
Branch=${OSTREE_BRANCH}
|
||||
Title=KST4Contest (${{ startsWith(github.ref_name, 'beta-') && 'Beta' || 'Release' }}) – ON4KST Chat Client
|
||||
Url=${PAGES_URL}
|
||||
RuntimeRepo=https://flathub.org/repo/flathub.flatpakrepo
|
||||
GPGKey=${GPG_KEY_B64}
|
||||
IsRuntime=false
|
||||
EOF
|
||||
|
||||
- name: Upload flatpakref
|
||||
uses: actions/upload-artifact@v4.3.4
|
||||
with:
|
||||
name: flatpakref
|
||||
path: dist/*.flatpakref
|
||||
|
||||
- name: Upload Flatpak OSTree repo
|
||||
uses: actions/upload-artifact@v4.3.4
|
||||
with:
|
||||
name: flatpak-ostree-repo
|
||||
path: target/flatpak-repo/
|
||||
|
||||
build-macos-dmg:
|
||||
name: Build macOS DMG (${{ matrix.os }})
|
||||
runs-on: ${{ matrix.os }}
|
||||
strategy:
|
||||
fail-fast: false
|
||||
matrix:
|
||||
os: [macos-latest, macos-15-intel]
|
||||
|
||||
@@ -514,48 +145,42 @@ jobs:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@v4.1.7
|
||||
|
||||
- name: Set up Java 21
|
||||
- name: Set up Java 17
|
||||
uses: actions/setup-java@v4.1.0
|
||||
with:
|
||||
distribution: temurin
|
||||
java-version: "21"
|
||||
java-version: "17"
|
||||
|
||||
- name: Ensure mvnw is executable
|
||||
run: chmod +x mvnw
|
||||
|
||||
- name: Import signing certificate
|
||||
env:
|
||||
MACOS_CERT_P12: ${{ secrets.MACOS_CERT_P12 }}
|
||||
MACOS_CERT_PASSWORD: ${{ secrets.MACOS_CERT_PASSWORD }}
|
||||
run: ./packaging/macos/ci-import-cert.sh
|
||||
|
||||
# Builds the jar, signs the app bundle and every native library inside it,
|
||||
# wraps it into a DMG and has Apple notarize the result. Same script the
|
||||
# local Mac uses, so the two cannot drift apart.
|
||||
- name: Build signed and notarized DMG
|
||||
env:
|
||||
MACOS_NOTARY_KEY: ${{ secrets.MACOS_NOTARY_KEY }}
|
||||
NOTARY_KEY_ID: ${{ secrets.MACOS_NOTARY_KEY_ID }}
|
||||
NOTARY_ISSUER: ${{ secrets.MACOS_NOTARY_ISSUER }}
|
||||
- name: Build JAR and copy runtime dependencies
|
||||
run: |
|
||||
printf '%s' "$MACOS_NOTARY_KEY" | base64 --decode > "$RUNNER_TEMP/notary.p8"
|
||||
export NOTARY_KEY="$RUNNER_TEMP/notary.p8"
|
||||
./packaging/macos/build-signed-dmg.sh
|
||||
./mvnw -B -DskipTests package dependency:copy-dependencies -DincludeScope=runtime -DoutputDirectory=target/dist-libs
|
||||
cp "$(ls -t target/praktiKST-*.jar | head -n 1)" target/dist-libs/app.jar
|
||||
|
||||
- name: Remove signing credentials
|
||||
if: always()
|
||||
- name: Build macOS DMG with jpackage
|
||||
run: |
|
||||
rm -f "$RUNNER_TEMP/notary.p8"
|
||||
if [ -n "${SIGNING_KEYCHAIN:-}" ]; then
|
||||
security delete-keychain "$SIGNING_KEYCHAIN" || true
|
||||
fi
|
||||
mkdir -p dist
|
||||
jpackage \
|
||||
--type dmg \
|
||||
--name KST4Contest \
|
||||
--input target/dist-libs \
|
||||
--main-jar app.jar \
|
||||
--main-class kst4contest.view.Kst4ContestApplication \
|
||||
--module-path target/dist-libs \
|
||||
--add-modules javafx.controls,javafx.graphics,javafx.fxml,javafx.web,javafx.media,java.sql \
|
||||
--dest dist
|
||||
|
||||
env:
|
||||
MACOSX_DEPLOYMENT_TARGET: "13.0"
|
||||
|
||||
- name: Rename DMG artifact
|
||||
run: |
|
||||
ARCH=$(uname -m)
|
||||
DMG=$(ls dist/*.dmg | head -n 1)
|
||||
if [ -z "$DMG" ]; then
|
||||
echo "No DMG produced by the build" && exit 1
|
||||
echo "No DMG produced by jpackage" && exit 1
|
||||
fi
|
||||
mv "$DMG" "dist/KST4Contest-${{ github.ref_name }}-macos-${ARCH}.dmg"
|
||||
|
||||
@@ -642,80 +267,16 @@ jobs:
|
||||
name: docs-pdf
|
||||
path: dist/KST4Contest-${{ github.ref_name }}-manual-*.pdf
|
||||
|
||||
publish-flatpak-repo:
|
||||
name: Publish Flatpak OSTree Repo (${{ github.ref_name }})
|
||||
runs-on: ubuntu-latest
|
||||
needs: build-flatpak
|
||||
|
||||
steps:
|
||||
- name: Install Flatpak tooling
|
||||
run: |
|
||||
sudo apt-get update -qq
|
||||
sudo apt-get install -y --no-install-recommends flatpak
|
||||
|
||||
- name: Import Flatpak signing key
|
||||
run: |
|
||||
echo "${{ secrets.FLATPAK_GPG_PRIVATE_KEY }}" | gpg --batch --import
|
||||
echo "FLATPAK_GPG_KEY_ID=$(gpg --list-secret-keys --with-colons | awk -F: '/^fpr/{print $10; exit}')" >> "$GITHUB_ENV"
|
||||
|
||||
- name: Download OSTree repo artifact
|
||||
uses: actions/download-artifact@v4.1.3
|
||||
with:
|
||||
name: flatpak-ostree-repo
|
||||
path: flatpak-ostree-repo/
|
||||
|
||||
- name: Checkout existing flatpak-repo branch
|
||||
uses: actions/checkout@v4.1.7
|
||||
with:
|
||||
ref: flatpak-repo
|
||||
path: existing-flatpak-repo
|
||||
|
||||
- name: Merge build into flatpak-repo
|
||||
run: |
|
||||
cd existing-flatpak-repo
|
||||
git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
|
||||
git config user.name "github-actions[bot]"
|
||||
rsync -a ../flatpak-ostree-repo/ ./
|
||||
# Regenerate summary with all branches (not just the one just built)
|
||||
flatpak build-update-repo --gpg-sign="$FLATPAK_GPG_KEY_ID" .
|
||||
# Generate .flatpakrepo with embedded GPG key so users can do remote-add without errors
|
||||
REPO_NAME="${GITHUB_REPOSITORY#*/}"
|
||||
PAGES_URL="https://${GITHUB_REPOSITORY_OWNER}.github.io/${REPO_NAME}/"
|
||||
GPG_KEY_B64=$(gpg --export "$FLATPAK_GPG_KEY_ID" | base64 -w 0)
|
||||
cat > kst4contest.flatpakrepo << EOF
|
||||
[Flatpak Repo]
|
||||
Title=KST4Contest
|
||||
Url=${PAGES_URL}
|
||||
Homepage=https://github.com/${GITHUB_REPOSITORY}
|
||||
Comment=KST4Contest – ON4KST Chat Client for VHF/UHF contests
|
||||
GPGKey=${GPG_KEY_B64}
|
||||
EOF
|
||||
git add -A
|
||||
if git diff --cached --quiet; then
|
||||
echo "No changes to commit"
|
||||
else
|
||||
git commit -m "Flatpak repo: ${{ github.ref_name }}"
|
||||
git push https://x-access-token:${{ secrets.GITHUB_TOKEN }}@github.com/${{ github.repository }}.git HEAD:flatpak-repo
|
||||
fi
|
||||
|
||||
release-tag:
|
||||
name: Publish Tagged Release
|
||||
runs-on: ubuntu-latest
|
||||
needs:
|
||||
- build-windows-zip
|
||||
- build-linux-appimage
|
||||
- build-linux-deb
|
||||
- build-linux-rpm
|
||||
- build-linux-arch
|
||||
- build-macos-dmg
|
||||
- build-flatpak
|
||||
- build-docs-pdf
|
||||
- publish-flatpak-repo
|
||||
|
||||
steps:
|
||||
- name: Checkout release source
|
||||
uses: actions/checkout@v4.1.7
|
||||
|
||||
- name: Download Windows artifact
|
||||
uses: actions/download-artifact@v4.1.3
|
||||
with:
|
||||
@@ -735,30 +296,6 @@ jobs:
|
||||
merge-multiple: true
|
||||
path: release-assets/macos
|
||||
|
||||
- name: Download Debian artifact
|
||||
uses: actions/download-artifact@v4.1.3
|
||||
with:
|
||||
name: linux-debian
|
||||
path: release-assets/debian
|
||||
|
||||
- name: Download Fedora artifact
|
||||
uses: actions/download-artifact@v4.1.3
|
||||
with:
|
||||
name: linux-fedora
|
||||
path: release-assets/fedora
|
||||
|
||||
- name: Download Arch Linux artifact
|
||||
uses: actions/download-artifact@v4.1.3
|
||||
with:
|
||||
name: linux-arch
|
||||
path: release-assets/archlinux
|
||||
|
||||
- name: Download flatpakref
|
||||
uses: actions/download-artifact@v4.1.3
|
||||
with:
|
||||
name: flatpakref
|
||||
path: release-assets/flatpakref
|
||||
|
||||
- name: Download PDF manuals
|
||||
uses: actions/download-artifact@v4.1.3
|
||||
with:
|
||||
@@ -779,52 +316,6 @@ jobs:
|
||||
artifacts: >-
|
||||
release-assets/windows/praktiKST-${{ github.ref_name }}-windows-x64.zip,
|
||||
release-assets/linux/KST4Contest-${{ github.ref_name }}-linux-x86_64.AppImage,
|
||||
release-assets/debian/KST4Contest-${{ github.ref_name }}-debian-amd64.deb,
|
||||
release-assets/fedora/KST4Contest-${{ github.ref_name }}-fedora-x86_64.rpm,
|
||||
release-assets/archlinux/KST4Contest-${{ github.ref_name }}-archlinux-*.pkg.tar.zst,
|
||||
release-assets/flatpakref/*.flatpakref,
|
||||
release-assets/macos/KST4Contest-${{ github.ref_name }}-macos-*.dmg,
|
||||
release-assets/docs/KST4Contest-${{ github.ref_name }}-manual-en.pdf,
|
||||
release-assets/docs/KST4Contest-${{ github.ref_name }}-manual-de.pdf
|
||||
|
||||
# The update feed is generated only after GitHub has published the
|
||||
# release. Otherwise the Releases API cannot return the release notes
|
||||
# belonging to the tag which triggered this workflow.
|
||||
- name: Set up Node.js for website build
|
||||
uses: actions/setup-node@v4
|
||||
with:
|
||||
node-version: "24"
|
||||
cache: npm
|
||||
cache-dependency-path: website/package-lock.json
|
||||
|
||||
- name: Build and validate website after release publication
|
||||
working-directory: website
|
||||
run: |
|
||||
npm ci
|
||||
npm test
|
||||
npm run build
|
||||
env:
|
||||
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
|
||||
- name: Verify Stable release in update feed
|
||||
if: ${{ !startsWith(github.ref_name, 'beta-') }}
|
||||
working-directory: website
|
||||
run: npm run validate:version-info
|
||||
env:
|
||||
EXPECTED_STABLE_VERSION: ${{ github.ref_name }}
|
||||
|
||||
- name: Attach verified version info to tagged release
|
||||
run: >-
|
||||
gh release upload "${GITHUB_REF_NAME}"
|
||||
website/_site/kst4ContestVersionInfo.xml
|
||||
--clobber
|
||||
env:
|
||||
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
|
||||
- name: Upload verified website artifact
|
||||
uses: actions/upload-artifact@v4.3.4
|
||||
with:
|
||||
name: kst4contest-website-${{ github.ref_name }}
|
||||
path: website/_site/
|
||||
if-no-files-found: error
|
||||
retention-days: 14
|
||||
-12
@@ -35,15 +35,3 @@ dist/
|
||||
|
||||
#zip files for local backups
|
||||
*.zip
|
||||
|
||||
# node Modules in website
|
||||
website/node_modules/
|
||||
|
||||
# built website output (rebuilt on the server)
|
||||
website/_site/
|
||||
|
||||
# Local secrets for act testing
|
||||
.secrets
|
||||
|
||||
# Apple notarization private keys - never commit these
|
||||
*.p8
|
||||
|
||||
@@ -1,98 +1,38 @@
|
||||
# KST4Contest
|
||||
|
||||
KST4Contest is a Java-based client for the [ON4KST chat](https://www.on4kst.org/chat/login.php), developed for coordinated VHF, UHF and microwave contest operation.
|
||||
|
||||
The application is developed by Marc Fröhlich (DO5AMF) and since 2026 Philipp Wagner (DN9APW).
|
||||
|
||||
## Start here
|
||||
|
||||
- [Project website](https://kst4contest.hamradioonline.de/)
|
||||
- [Download Stable, Beta and Nightly builds](https://kst4contest.hamradioonline.de/download/)
|
||||
- [Online manual](https://kst4contest.hamradioonline.de/manual/)
|
||||
- [GitHub wiki](https://github.com/praktimarc/kst4contest/wiki)
|
||||
- [Issues and bug reports](https://github.com/praktimarc/kst4contest/issues)
|
||||
- [Development roadmap](https://kst4contest.hamradioonline.de/roadmap/)
|
||||
|
||||
## What KST4Contest does
|
||||
|
||||
KST4Contest combines the ON4KST chat with information that is useful when coordinating contacts during a contest.
|
||||
|
||||
Among other things, it can:
|
||||
|
||||
- display and filter stations from the supported ON4KST chat categories;
|
||||
- derive band and frequency information from chat messages and station names;
|
||||
- maintain Worked and NOT QRV information for the available bands;
|
||||
- calculate station priorities from distance, activity and other available information;
|
||||
- manage internal skeds and received Win-Test skeds;
|
||||
- use AirScout information when evaluating possible aircraft-scatter contacts;
|
||||
- display stations, paths and additional propagation information on maps;
|
||||
- exchange information with supported logging programs, Win-Test, PSTRotator and a local DX Cluster interface;
|
||||
- provide configurable automatic replies for recurring chat requests.
|
||||
|
||||
Calculated scores, aircraft-scatter information and path assessments are operating aids. They depend on the available data and should not be treated as guarantees that a contact is possible.
|
||||
|
||||
## Installation
|
||||
|
||||
Ready-to-use packages are available for Windows, Linux and macOS. These packages include the required Java runtime, so a separate Java installation is normally not necessary.
|
||||
|
||||
Use the central download page to select the appropriate build:
|
||||
|
||||
- **Stable** is intended for normal contest operation.
|
||||
- **Beta** contains changes that are being prepared for a stable release.
|
||||
- **Nightly** contains the latest automated development build and is mainly intended for testing.
|
||||
|
||||
[Open the download page](https://kst4contest.hamradioonline.de/download/)
|
||||
KST4Contest (also known as pratiKST) is a Java-based chat client for ON4KST, focused on VHF/UHF/SHF contest operation.
|
||||
|
||||
## Documentation
|
||||
|
||||
The documentation is available in German and English:
|
||||
The full user documentation is maintained in the project wiki:
|
||||
|
||||
- [German manual](https://github.com/praktimarc/kst4contest/wiki/de-Home)
|
||||
- [English manual](https://github.com/praktimarc/kst4contest/wiki/en-Home)
|
||||
- [Online manual](https://kst4contest.hamradioonline.de/manual/)
|
||||
- https://github.com/praktimarc/kst4contest/wiki
|
||||
|
||||
The Markdown sources used for the wiki and the generated PDF manuals are stored in [`github_docs`](github_docs/).
|
||||
Direct entry points:
|
||||
|
||||
Changes to operating behaviour should be documented together with their purpose and limitations. This is especially important for functions whose result depends on external data, heuristics or information derived from chat messages.
|
||||
- German start page: https://github.com/praktimarc/kst4contest/wiki/de-Home
|
||||
- English start page: https://github.com/praktimarc/kst4contest/wiki/en-Home
|
||||
|
||||
## Building from source
|
||||
## Build
|
||||
|
||||
Building KST4Contest requires JDK 21. The Maven Wrapper included in the repository should be used, so a separate Maven installation is not required.
|
||||
|
||||
Linux and macOS:
|
||||
Compile locally with Maven Wrapper:
|
||||
|
||||
```bash
|
||||
./mvnw clean test
|
||||
./mvnw -B -DskipTests compile
|
||||
```
|
||||
|
||||
Windows:
|
||||
## Notes
|
||||
|
||||
```powershell
|
||||
mvnw.cmd clean test
|
||||
mvnw.cmd -B -DskipTests compile
|
||||
```
|
||||
- Source code is under `src/`.
|
||||
- Documentation markdown pages for wiki/PDF are under `github_docs/`.
|
||||
|
||||
## Repository structure
|
||||
|
||||
- `src/main/java/` – application source code
|
||||
- `src/test/` – automated tests
|
||||
- `github_docs/` – German and English manual sources
|
||||
- `website/` – project website sources
|
||||
- `packaging/` – platform-specific packaging files
|
||||
|
||||
## CI status
|
||||
|
||||
### Documentation
|
||||
## Status of the latest CI:
|
||||
Wiki Publishing:
|
||||
|
||||
[](https://github.com/praktimarc/kst4contest/actions/workflows/github-wiki.yml)
|
||||
|
||||
[](https://github.com/praktimarc/kst4contest/actions/workflows/docs-pdf.yml)
|
||||
|
||||
### Builds
|
||||
Builds:
|
||||
|
||||
[](https://github.com/praktimarc/kst4contest/actions/workflows/nightly-artifacts.yml)
|
||||
|
||||
## License
|
||||
|
||||
KST4Contest is distributed under the [GNU General Public License v3.0](LICENSE).
|
||||
@@ -0,0 +1,2 @@
|
||||
dr2x
|
||||
oe3cin
|
||||
+15832
File diff suppressed because it is too large
Load Diff
+38
-30
@@ -1,45 +1,53 @@
|
||||
# KST4Contest Manual / Handbuch
|
||||
# KST4Contest – Wiki
|
||||
|
||||
KST4Contest is a desktop client for the [ON4KST Chat](https://www.on4kst.org/chat/login.php), developed for VHF, UHF and SHF contest operation. It combines chat, candidate selection, sked planning, aircraft-scatter information, station mapping and connections to logging and station software.
|
||||
**KST4Contest** (auch bekannt als *PraktiKST*) ist ein Java-basierter Chat-Client für den [ON4KST-Chat](http://www.on4kst.info/chat/), speziell entwickelt für den Contest-Betrieb auf den VHF/UHF/SHF-Bändern.
|
||||
|
||||
KST4Contest ist ein Desktop-Client für den [ON4KST-Chat](https://www.on4kst.org/chat/login.php), der für den Contest-Betrieb auf den VHF-, UHF- und SHF-Bändern entwickelt wurde. Er verbindet Chat, Stationsauswahl, Sked-Planung, Aircraft-Scatter-Daten, Stationskarte sowie die Anbindung an Log- und Stationssoftware.
|
||||
|
||||
Developed by / Entwickelt von:
|
||||
|
||||
- **DO5AMF (Marc Fröhlich)**, operator at / Operator bei **DM5M**
|
||||
- **DN9APW (Philipp Wagner)**, developer since / Entwickler seit Mai 2025
|
||||
Entwickelt von **DO5AMF (Marc Fröhlich)**, Operator bei DM5M.
|
||||
|
||||
---
|
||||
|
||||
## Language / Sprache
|
||||
## 🌐 Sprache / Language
|
||||
|
||||
| Deutsch | English |
|
||||
| 🇩🇪 Deutsch | 🇬🇧 English |
|
||||
|---|---|
|
||||
| [Deutsches Handbuch](de-Home) | [English manual](en-Home) |
|
||||
|
||||
Both versions follow the same structure and describe the same application state.
|
||||
Beide Sprachfassungen verwenden dieselbe Struktur und beschreiben denselben Programmstand.
|
||||
| [Startseite (Deutsch)](de-Home) | [Home (English)](en-Home) |
|
||||
|
||||
---
|
||||
|
||||
## Start here / Hier beginnen
|
||||
## 🇩🇪 Inhalt (Deutsch)
|
||||
|
||||
- [Download Stable, Beta or Nightly / Stable, Beta oder Nightly herunterladen](https://kst4contest.hamradioonline.de/download/)
|
||||
- [Online manual / Online-Handbuch](https://kst4contest.hamradioonline.de/manual/)
|
||||
- [Installation](de-Installation) / [Installation](en-Installation)
|
||||
- [Configuration](en-Configuration) / [Konfiguration](de-Konfiguration)
|
||||
|
||||
The Stable version is the normal choice for contest operation. Beta and Nightly builds are intended for testing particular changes and may contain functions which have not yet been released as Stable.
|
||||
|
||||
Für den normalen Contestbetrieb ist die Stable-Version vorgesehen. Beta- und Nightly-Builds dienen dem gezielten Test neuer Änderungen und können Funktionen enthalten, die noch nicht als Stable veröffentlicht wurden.
|
||||
| Seite | Inhalt |
|
||||
|---|---|
|
||||
| [Installation](de-Installation) | Download, Java-Voraussetzungen, Update |
|
||||
| [Konfiguration](de-Konfiguration) | Alle Einstellungen im Detail |
|
||||
| [Log-Synchronisation](de-Log-Synchronisation) | UCXLog, N1MM+, QARTest, DXLog.net, WinTest |
|
||||
| [AirScout-Integration](de-AirScout-Integration) | Flugzeug-Scatter-Erkennung |
|
||||
| [DX-Cluster-Server](de-DX-Cluster-Server) | Integrierter DX-Cluster für das Log-Programm |
|
||||
| [Funktionen](de-Funktionen) | Alle Features im Überblick |
|
||||
| [Makros und Variablen](de-Makros-und-Variablen) | Text-Snippets, Shortcuts, Variablen |
|
||||
| [Benutzeroberfläche](de-Benutzeroberflaeche) | UI-Erklärung und Bedienung |
|
||||
| [Changelog](de-Changelog) | Versionsgeschichte |
|
||||
|
||||
---
|
||||
|
||||
## Project links / Projektlinks
|
||||
## 🇬🇧 Contents (English)
|
||||
|
||||
- [Project website / Projektwebseite](https://kst4contest.hamradioonline.de/)
|
||||
- [Downloads](https://kst4contest.hamradioonline.de/download/)
|
||||
- [Source code / Quellcode](https://github.com/praktimarc/kst4contest)
|
||||
- [GitHub Releases](https://github.com/praktimarc/kst4contest/releases)
|
||||
- [Bug reports and feature requests / Fehler und Funktionswünsche](https://github.com/praktimarc/kst4contest/issues)
|
||||
- [Development roadmap / Entwicklungsstand](https://kst4contest.hamradioonline.de/roadmap/)
|
||||
| Page | Contents |
|
||||
|---|---|
|
||||
| [Installation](en-Installation) | Download, Java requirements, updates |
|
||||
| [Configuration](en-Configuration) | All settings in detail |
|
||||
| [Log Synchronisation](en-Log-Sync) | UCXLog, N1MM+, QARTest, DXLog.net, WinTest |
|
||||
| [AirScout Integration](en-AirScout-Integration) | Aircraft scatter detection |
|
||||
| [DX Cluster Server](en-DX-Cluster-Server) | Built-in DX cluster for your logging software |
|
||||
| [Features](en-Features) | All features at a glance |
|
||||
| [Macros and Variables](en-Macros-and-Variables) | Text snippets, shortcuts, variables |
|
||||
| [User Interface](en-User-Interface) | UI explained and how to operate it |
|
||||
| [Changelog](en-Changelog) | Version history |
|
||||
|
||||
---
|
||||
|
||||
## Schnellinfo / Quick Info
|
||||
|
||||
- **Download**: https://github.com/praktimarc/kst4contest/releases
|
||||
- **GitHub**: https://github.com/praktimarc/kst4contest
|
||||
- **Kontakt / Contact**: praktimarc+kst4contest@gmail.com
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 63 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 49 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 52 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 84 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 89 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 36 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 86 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 36 KiB |
@@ -107,7 +107,7 @@ Die Flugzeugdaten können direkt in 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)
|
||||
Details: [Makros und Variablen](Makros-und-Variablen#variablen)
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -4,22 +4,11 @@
|
||||
|
||||
## Verbinden mit dem Chat
|
||||
|
||||
Vor dem ersten Verbindungsaufbau müssen im Einstellungsfenster mindestens Rufzeichen, Passwort, Locator und primäre Chat-Kategorie konfiguriert werden. Soll zusätzlich eine zweite Kategorie verwendet werden, muss auch deren Login aktiviert und vollständig eingerichtet sein.
|
||||
1. Im Einstellungsfenster eine **Chat-Kategorie** auswählen (z. B. 144 MHz VHF, 432 MHz UHF, …).
|
||||
2. **Connect**-Button klicken.
|
||||
3. Warten bis die Verbindung aufgebaut ist.
|
||||
|
||||
Die Verbindung kann auf zwei Wegen aufgebaut werden:
|
||||
|
||||
- Mit **Connect to …** im Einstellungsfenster werden die dort eingetragenen Werte übernommen und die Verbindung gestartet.
|
||||
- **File → Connect to …** verwendet die bereits in KST4Contest übernommenen Einstellungen.
|
||||
|
||||
Geänderte Einstellungen müssen mit **Save Settings** gespeichert werden, wenn sie auch beim nächsten Programmstart verwendet werden sollen.
|
||||
|
||||
Eine bestehende Verbindung kann über **File → Disconnect** oder über **Disconnect** im Einstellungsfenster beendet werden. **Exit + disconnect** beendet zusätzlich das Programm.
|
||||
|
||||
Bei einem unerwarteten Verbindungsverlust versucht KST4Contest nach einer begrenzten Wartezeit, die ON4KST-Verbindung kontrolliert neu aufzubauen. Ein fehlgeschlagener Erstaufbau blockiert die Benutzeroberfläche nicht mehr.
|
||||
|
||||
Ob die Verbindung lediglich als TCP-Verbindung besteht oder bereits vollständig angemeldet und synchronisiert ist, zeigt der [`LINK`-Status](#statusleiste-und-hinweise) im Hauptfenster.
|
||||
|
||||
---
|
||||
> Trennen und Neu-Verbinden ist nur über das Einstellungsfenster möglich. Es empfiehlt sich daher, das Einstellungsfenster geöffnet zu lassen.
|
||||
|
||||
---
|
||||
|
||||
@@ -27,457 +16,84 @@ Ob die Verbindung lediglich als TCP-Verbindung besteht oder bereits vollständig
|
||||
|
||||
Das Hauptfenster besteht aus mehreren Bereichen:
|
||||
|
||||
|
||||
### Statusleiste und Hinweise
|
||||
|
||||
Die Statusleiste befindet sich am oberen Rand des Hauptfensters neben dem Menü.
|
||||
|
||||
|
||||
|
||||
Der dauerhaft sichtbare `LINK`-Indikator zeigt den tatsächlichen Zustand der ON4KST-Verbindung:
|
||||
|
||||
| Anzeige | Bedeutung |
|
||||
|---|---|
|
||||
| grünes `LINK` | Login und Synchronisation der konfigurierten Chat-Kategorien sind vollständig abgeschlossen |
|
||||
| gelbes `LINK…` | Verbindung, Anmeldung, Benutzerlistensynchronisation oder kontrolliertes Beenden läuft |
|
||||
| rotes `LINK!` | keine Verbindung oder Wartezeit vor einem automatischen Neuaufbau |
|
||||
|
||||
Der Tooltip enthält den internen Verbindungsstatus und eine genauere Beschreibung des aktuellen Schritts. Der Indikator ist keine Schaltfläche.
|
||||
|
||||
`ONLINE` wird erst gemeldet, nachdem die Anmeldung bestätigt und die Benutzerlisten der konfigurierten Kategorien vollständig empfangen wurden. Während die Verbindung noch aufgebaut oder neu synchronisiert wird, bleiben Sendfeld und **TX** deaktiviert.
|
||||
|
||||
Bei bestimmten Ereignissen erscheinen vorübergehend weitere Hinweise:
|
||||
|
||||
- `SKED` weist auf eine fällige Sked-Erinnerung hin. Der Text enthält das vollständige Zielrufzeichen und die verbleibende Zeit.
|
||||
- `BAND+` erscheint nach einem Logeintrag, wenn für die gearbeitete Station noch mindestens ein gemeinsames, aktiviertes und nicht gearbeitetes Band erkannt wurde.
|
||||
|
||||
Beide Hinweise blinken ungefähr zwölf Sekunden und verschwinden anschließend wieder. Der vollständige Inhalt beziehungsweise die Herleitung steht im jeweiligen Tooltip. Die Anzeigen sind nicht anklickbar.
|
||||
|
||||
|
||||
### PM-Fenster (oben links)
|
||||
|
||||
Das PM-Fenster zeigt die an die eigenen Chat-Logins gerichteten Privatnachrichten und die zugehörigen ausgehenden Antworten.
|
||||
Zeigt alle empfangenen **Privatnachrichten** sowie abgefangene öffentliche Nachrichten, die das eigene Rufzeichen enthalten. Neue Nachrichten erscheinen in **Rot** und faden alle 30 Sekunden über Gelb bis Weiß ab.
|
||||
|
||||
Ist das [QSO-Monitoring](de-Funktionen#qso-monitoring-ab-v131) aktiviert, erscheinen dort zusätzlich die erfassten Nachrichten der überwachten Basisrufzeichen. Diese Einträge erhalten eine `Sniffed:`-Kennzeichnung mit dem vollständigen sichtbaren Absender und Empfänger.
|
||||
|
||||
Neue Nachrichten werden zunächst auffällig dargestellt und wechseln anschließend schrittweise zur normalen Tabellenfarbe. Die farbliche Hervorhebung dient nur als zeitlicher Hinweis; sie verändert weder Inhalt noch Routing der Nachricht.
|
||||
### Benutzerliste (Chat Members)
|
||||
|
||||
Die zentrale Tabelle aller aktuell aktiven Chat-Nutzer. Spalten (je nach Konfiguration):
|
||||
|
||||
| Spalte | Inhalt |
|
||||
|---|---|
|
||||
| Callsign | Rufzeichen der Station |
|
||||
| Name | Name beziehungsweise Zusatzinformationen aus dem Chat-Namensfeld |
|
||||
| QRA | Maidenhead-Locator |
|
||||
| Call | Rufzeichen der Station |
|
||||
| Name | Name aus dem Chat-Namenfeld |
|
||||
| Loc | Maidenhead-Locator |
|
||||
| QRB | Entfernung in km |
|
||||
| QTF | Richtung in Grad |
|
||||
| QRG | Zuletzt aus einer Chat-Nachricht erkannte Frequenz |
|
||||
| Tropo | Ergebnis der bandbezogenen Tropo- beziehungsweise Streckenbewertung |
|
||||
| Score | Aktueller, numerisch sortierbarer Prioritätswert des normalisierten Basisrufzeichens |
|
||||
| Act | Minuten seit der letzten Aktivität |
|
||||
| AP | AirScout-Flugzeugdaten, sofern aktiviert |
|
||||
| worked | Bandbezogener Worked-, Bandmöglichkeits- und Großfeldstatus sowie `wkdany` |
|
||||
| NOT QRV @ | Bänder, auf denen die Station manuell als nicht QRV markiert wurde |
|
||||
| Category | Chat-Kategorie des Eintrags |
|
||||
|
||||
Die QRG-Spalte zeigt die zuletzt für eine Station erkannte Frequenz. Fehlende Nullen werden für die Anzeige ergänzt, sodass beispielsweise `144.21` als `144.210` erscheint. Erkennt KST4Contest nacheinander Frequenzen auf mehreren Bändern, zeigt die Spalte den letzten Treffer; die internen Bandinformationen können trotzdem mehrere aktuelle Bänder der Station enthalten.
|
||||
|
||||
Relative Angaben werden zunächst mit einem höchstens 30 Minuten alten Bandkontext desselben Absenders kombiniert. Nur wenn dieser fehlt, verwendet KST4Contest das globale Fallback-Band. Erkennungsregeln, Beispiele und Grenzen: [QRG-Erkennung](de-Funktionen#qrg-erkennung).
|
||||
|
||||
### Worked-, Band- und Großfeldstatus
|
||||
|
||||
Die Unterspalten unter **worked** sind kompakt, weil bei mehreren aktivierten Bändern kaum Platz für ausgeschriebene Zustände bleibt. `X` kennzeichnet ein auf diesem Band gearbeitetes Rufzeichen. `a` und `B+` weisen auf ein angebotenes, noch nicht gearbeitetes Band hin. Ein angehängtes `o` bedeutet, dass das vierstellige Großfeld auf diesem Band bereits gearbeitet wurde.
|
||||
|
||||
Die Unterspalte **wkdany** ist bandunabhängig: `x` steht für ein bereits gearbeitetes Rufzeichen, `o` für ein auf irgendeinem Band gearbeitetes Großfeld und `xo` für beides.
|
||||
|
||||
Jede Statuszelle besitzt einen Tooltip mit der Legende und dem für die betreffende Station ermittelten Zustand. Die vollständige Herleitung einschließlich NOT-QRV-Vorrang: [Gearbeitete Rufzeichen, neue Bänder und neue Großfelder](de-Funktionen#gearbeitete-rufzeichen-neue-bänder-und-neue-großfelder).
|
||||
|
||||
|
||||
| QRG | Automatisch erkannte Frequenz |
|
||||
| AP | AirScout-Flugzeugdaten (wenn aktiv) |
|
||||
| Band-Farben | Worked/NOT-QRV-Status pro Band |
|
||||
|
||||
**Sortierung**: Klick auf Spaltenköpfe. QRB-Sortierung arbeitet numerisch (ab v1.22 korrigiert).
|
||||
|
||||
|
||||
Ein grün und fett dargestelltes Rufzeichen kennzeichnet eine aus einer gerichteten Nachricht hergeleitete Richtungsgelegenheit. Die Markierung bezieht sich auf den Absender der Nachricht und bleibt höchstens fünf Minuten sichtbar. Herleitung und Grenzen: [Richtungsgelegenheiten aus gerichteten Nachrichten](de-Funktionen#richtungsgelegenheiten-aus-gerichteten-nachrichten).
|
||||
### Sendfeld
|
||||
|
||||
Das Sendfeld enthält den vorbereiteten Text für die nächste ausgehende Nachricht.
|
||||
Texteingabe für ausgehende Nachrichten. Nach Klick auf ein Rufzeichen in der Benutzerliste erhält das Sendfeld automatisch den Fokus – sofort tippen ohne Doppelklick (ab v1.22).
|
||||
|
||||
Wird eine Station bewusst per Maus oder Tastatur in der Benutzerliste ausgewählt, bereitet KST4Contest eine gerichtete Nachricht vor:
|
||||
### MYQRG-Feld
|
||||
|
||||
```text
|
||||
/cq RUFZEICHEN
|
||||
```
|
||||
Rechts neben dem Sendbutton. Zeigt die aktuelle eigene QRG an, kann auch manuell eingetragen werden.
|
||||
|
||||
Dabei werden das vollständige sichtbare Rufzeichen einschließlich eines vorhandenen Suffixes und die Chat-Kategorie der ausgewählten Station beibehalten. Ein Ziel wie `9A0BB-70` wird nicht auf `9A0BB` verkürzt.
|
||||
### MYQTF-Feld *(für v1.3)*
|
||||
|
||||
Eine Hintergrundaktualisierung, Neusortierung oder Filteränderung darf einen bereits bearbeiteten Nachrichtentext nicht überschreiben. Nur eine tatsächliche Auswahl durch den Operator bereitet den `/cq`-Empfänger erneut vor.
|
||||
|
||||
- **TX** oder `Enter` sendet den vorbereiteten Text.
|
||||
- `Esc` leert das Sendfeld.
|
||||
- Während KST4Contest nicht vollständig mit ON4KST verbunden ist, bleiben Sendfeld und **TX** deaktiviert.
|
||||
|
||||
Shortcuts, Snippets und Variablen sind unter [Makros und Variablen](de-Makros-und-Variablen) beschrieben.
|
||||
|
||||
### MYQRG- und SECONDQRG-Feld
|
||||
|
||||
Die beiden QRG-Felder enthalten die eigenen Frequenzen der primären und sekundären Chat-Kategorie.
|
||||
|
||||
`MYQRG` kann von einer aktivierten TRX-Synchronisation aktualisiert oder – bei deaktivierten automatischen QRG-Quellen – von Hand eingetragen werden. `SECONDQRG` bleibt davon unabhängig und enthält die QRG der zweiten Kategorie.
|
||||
|
||||
Die Auswahl einer Station aus dem zweiten Chat verändert die Bedeutung der beiden Werte nicht: `MYQRG` gehört weiterhin zur primären, `SECONDQRG` zur sekundären Kategorie.
|
||||
|
||||
Weitere Einzelheiten: [TRX-Sync-Einstellungen](de-Konfiguration#trx-sync-einstellungen).
|
||||
|
||||
### MYQTF-Feld
|
||||
|
||||
Das MYQTF-Feld zeigt die aktuelle Antennenrichtung als numerischen Winkel in Grad.
|
||||
|
||||
Ist PSTRotator aktiviert, wird der Wert automatisch übernommen und das Feld ist nicht manuell bearbeitbar. Ohne aktive Rotatorsynchronisation kann die Antennenrichtung direkt eingetragen werden. Die Änderung wird beim Verlassen des Feldes übernommen.
|
||||
|
||||
Der Wert beeinflusst unter anderem:
|
||||
|
||||
- die QTF-Filterung,
|
||||
- die Darstellung des Antennensektors auf der Stationskarte,
|
||||
- die Prioritätsberechnung,
|
||||
- die AP-Timeline und
|
||||
- die Variable `MYQTF`.
|
||||
Eingabefeld für die aktuelle Antennenrichtung. Wird für die geplante `MYQTF`-Variable verwendet.
|
||||
|
||||
---
|
||||
|
||||
## Nachrichtentabellen
|
||||
## Filter
|
||||
|
||||
KST4Contest zeigt Nachrichtentexte bewusst einzeilig an. So bleiben auch bei hohem Chat-Aufkommen viele Einträge gleichzeitig sichtbar. Der Nachteil liegt auf der Hand: Bei einer schmalen **Message**-Spalte passt nicht jede Nachricht vollständig in die Zeile.
|
||||
Die Filter-Leiste (ab v1.21 als Flowpane für kleine Bildschirme):
|
||||
|
||||
Ist ein Nachrichtentext breiter als die sichtbare Zelle, zeigt KST4Contest den vollständigen Inhalt als Tooltip an. Dazu die Maus kurz über die betreffende **Message**-Zelle halten. Passt der Text vollständig in die Spalte, wird kein zusätzlicher Volltext-Tooltip eingeblendet.
|
||||
|
||||
Webadressen mit `http://`, `https://` oder dem Präfix `www.` werden innerhalb des Nachrichtentextes als Links dargestellt. Ein Klick öffnet die Adresse im Standardbrowser des Betriebssystems. Andere Protokolle werden nicht als Link behandelt.
|
||||
|
||||
|
||||
|
||||
Damit muss der Divider nicht allein deshalb verschoben werden, um eine einzelne längere Nachricht zu lesen. Für einen dauerhaft breiteren Nachrichtenbereich kann er selbstverständlich weiterhin angepasst werden.
|
||||
|
||||
---
|
||||
|
||||
## Filter und Reachability-Steuerung
|
||||
|
||||
Die Filterleiste befindet sich oberhalb der Chatmember-Tabelle. Filter können miteinander kombiniert werden; eine Station bleibt nur sichtbar, wenn sie alle aktiven Bedingungen erfüllt.
|
||||
|
||||
|
||||
|
||||
### Stationsfilter
|
||||
|
||||
| Bedienelement | Wirkung |
|
||||
|---|---|
|
||||
| **Show only QTF** | Zeigt nur Stationen innerhalb der gewählten Antennenrichtung und des konfigurierten Öffnungswinkels |
|
||||
| **Show only QRB [km] <=** | Begrenzt die Liste auf die eingetragene maximale Entfernung |
|
||||
| **Find** | Filtert nach einem vollständigen oder teilweisen Rufzeichen |
|
||||
| **wkd** | Blendet Basisrufzeichen aus, die bereits auf mindestens einem unterstützten Band gearbeitet wurden |
|
||||
| einzelne Band-Schaltflächen | Blenden Stationen aus, die auf dem betreffenden Band bereits gearbeitet oder dort als NOT QRV markiert wurden |
|
||||
| **Inactive stations** | Blendet Stationen aus, deren letzte Chataktivität mehr als 20 Minuten zurückliegt |
|
||||
| **Only new grids** | Zeigt nur Stationen aus vierstelligen Großfeldern, die bisher auf keinem Band gearbeitet wurden |
|
||||
| **New bands** | Zeigt Stationen mit mindestens einer erkannten, lokal aktivierten und noch nicht gearbeiteten Bandmöglichkeit |
|
||||
| **Tropo >=0dB** | Zeigt Stationen mit einer berechneten, nicht negativen SSB-Marge |
|
||||
| **AS next 5m** | Zeigt Stationen mit einem aktuellen oder innerhalb der nächsten fünf Minuten erwarteten AirScout-Fenster |
|
||||
|
||||
Bei **New bands** werden aktuelle QRGs, Bandangaben im Namensfeld und aktive Rufzeichenvarianten gemeinsam ausgewertet. Manuelle NOT-QRV-Markierungen haben Vorrang.
|
||||
|
||||
Der Filter **Tropo >=0dB** entfernt nur Stationen, für die eine abgeschlossene Berechnung eine negative Marge ergeben hat. Noch nicht berechnete oder fehlgeschlagene Auswertungen bleiben sichtbar. Andernfalls würde ein fehlender API-Wert wie ein nachgewiesen ungeeigneter Funkweg behandelt.
|
||||
|
||||
### Grid color
|
||||
|
||||
**Grid color** ist kein Filter. Die Funktion verändert ausschließlich die Darstellung des QRA-Feldes und kennzeichnet bereits gearbeitete vierstellige Großfelder.
|
||||
|
||||
Die Station bleibt unabhängig von der Farbmarkierung in der Tabelle sichtbar. **Reset filters** deaktiviert diese Anzeige deshalb nicht.
|
||||
|
||||
### Reachability und Calc selected
|
||||
|
||||
Das Dropdown **Reachability** bestimmt das Band, auf das sich die Tropo-Spalte, der Tropo-Filter und eine ausdrücklich gestartete Streckenberechnung beziehen.
|
||||
|
||||
- **Auto** leitet das Band aus der aktuellen Stations-QRG, Bandangaben im Namensfeld und der unterstützten Chat-Kategorie her.
|
||||
- Ein ausdrücklich gewähltes Band übersteuert diese automatische Auswahl für die Reachability-Auswertung.
|
||||
|
||||
Eine Änderung des Dropdowns startet keine Berechnung für die gesamte Benutzerliste. Das wäre bei einer Online-Höhendatenquelle unnötig langsam und würde externe API-Abfragen vervielfachen.
|
||||
|
||||
**Calc selected** berechnet ausschließlich die aktuell ausgewählte Station auf dem gewählten beziehungsweise automatisch hergeleiteten Band. Das Ergebnis wird anschließend in der Tropo-Spalte und den zugehörigen Ansichten verwendet.
|
||||
|
||||
### Filter zurücksetzen
|
||||
|
||||
**Reset filters** entfernt:
|
||||
|
||||
- den QTF-Filter,
|
||||
- den QRB-Filter,
|
||||
- den Inhalt des Rufzeichen-Suchfeldes,
|
||||
- alle Worked- und Bandfilter,
|
||||
- **Inactive stations**,
|
||||
- **Only new grids**,
|
||||
- **New bands**,
|
||||
- **Tropo >=0dB** und
|
||||
- **AS next 5m**.
|
||||
|
||||
Die internen Filterprädikate werden dabei ausdrücklich geleert. Es genügt nicht, lediglich die sichtbaren Toggle-Buttons zurückzusetzen.
|
||||
|
||||
Nicht verändert werden:
|
||||
|
||||
- **Grid color**, weil es sich um eine Darstellungsoption handelt, und
|
||||
- die Auswahl im **Reachability**-Dropdown, weil sie das Berechnungsband festlegt und nicht unmittelbar die Tabelle filtert.
|
||||
|
||||
### Verhalten bei schmaler Ansicht
|
||||
|
||||
Die Filterleiste besitzt keine feste Breite. QTF-, Worked- und Reachability-Controls nutzen zunächst den verfügbaren Platz ihrer jeweiligen Zeile.
|
||||
|
||||
Wird der mittlere Divider nach rechts verschoben und die Chatmember-Ansicht dadurch schmaler, wechseln Bedienelemente erst dann in die nächste Zeile, wenn ihre tatsächlich benötigte Breite nicht mehr ausreicht. Wird der Bereich wieder breiter, ordnen sie sich unmittelbar neu an.
|
||||
|
||||
Im Klartext: Die Filter bestimmen den Tabelleninhalt, aber nicht mehr die Mindestbreite der gesamten rechten Programmseite.
|
||||
- **Show only QTF**: Richtungsfilter aktivieren (Buttons N/NE/E/… oder Grad-Eingabe)
|
||||
- **Show only QRB [km] <=**: Entfernungsfilter aktivieren (Toggle-Button)
|
||||
- **Hide Worked [Band]**: Gearbeitete Stationen pro Band ausblenden (je ein Toggle pro Band)
|
||||
- **Hide NOT-QRV [Band]**: NOT-QRV-markierte Stationen pro Band ausblenden
|
||||
|
||||
---
|
||||
|
||||
## Stationsinfo-Panel (Further Info)
|
||||
|
||||
Rechts unten werden die Nachrichten der ausgewählten Station zusammengeführt. Dazu gehören öffentliche Nachrichten, Privatnachrichten an die eigene Station und – soweit im Chat sichtbar – Privatnachrichten an andere Stationen.
|
||||
Rechts unten: Zeigt alle Nachrichten einer ausgewählten Station (CQ-Nachrichten und PMs in einem Panel). Ein Nachrichtenfilter lässt sich über den Standard-Filter in den Preferences vorbelegen.
|
||||
|
||||
Der im Panel gewählte Filter bestimmt, welche dieser Nachrichten angezeigt werden. Unter **Settings → GUI** lässt sich festlegen, welcher Filter beim Öffnen einer Stationsinformation vorausgewählt ist:
|
||||
|
||||
- alle Nachrichten,
|
||||
- Privatnachrichten an die eigene Station,
|
||||
- Privatnachrichten an andere Stationen oder
|
||||
- öffentliche Nachrichten.
|
||||
|
||||
Die Einstellung verändert nur die Darstellung im Stationsinfo-Panel. Nachrichten werden dadurch weder verworfen noch aus den übrigen Nachrichtentabellen entfernt. Der Filter kann im Panel jederzeit für die aktuell betrachtete Station gewechselt werden.
|
||||
|
||||
Im unteren Bereich können für die ausgewählte Station bandbezogene **Not QRV**-Markierungen gesetzt werden. Sichtbar sind die Bänder, die in den Stationseinstellungen für die eigene Station aktiviert wurden. **tag not qrv all** setzt beziehungsweise entfernt die Markierung für alle unterstützten Bänder gemeinsam, einschließlich momentan nicht eingeblendeter Bänder.
|
||||
|
||||
Die Änderung wirkt sofort auf die Spalte **NOT QRV @**, die Bandmöglichkeiten und die zugehörigen Filter. Sie wird in der internen Datenbank gespeichert und nach einem Neustart wiederhergestellt.
|
||||
|
||||
|
||||
|
||||
Im selben Bereich wird der aktuelle **Priority score** der ausgewählten Station angezeigt.
|
||||
|
||||
Mit **Sked fail** lässt sich ein fehlgeschlagener Versuch markieren. Der Score des normalisierten Basisrufzeichens wird dadurch stark reduziert. **Reset fail** entfernt diese Markierung wieder. Die Markierung gilt für alle aktiven Suffix- und Kategorievarianten der Station und bleibt innerhalb der laufenden Programmsitzung erhalten.
|
||||
|
||||
Darunter befinden sich die Bedienelemente zum Anlegen eines Skeds:
|
||||
|
||||
| Bedienelement | Bedeutung |
|
||||
|---|---|
|
||||
| **Sked in** | Zeit bis zum Sked |
|
||||
| **Band** | vereinbartes Band aus den eigenen aktivierten Bändern |
|
||||
| **Mode** | `SSB` oder `CW` für eine mögliche Win-Test-Übergabe |
|
||||
| **Create sked** | internen Sked anlegen |
|
||||
| **Remind-PM in** | automatische Reminder-PMs aktivieren |
|
||||
| **2+1**, **5+2+1**, **10+5+2+1** | Zeitpunkte der Reminder-PMs vor dem Termin |
|
||||
|
||||
|
||||
|
||||
Das vorgeschlagene Band wird aus aktuellen QRG- und Namensinformationen der Station hergeleitet. Vor dem Anlegen kann es ausdrücklich geändert werden. Die Mode-Auswahl betrifft nur die Übergabe an Win-Test; der interne Sked und die Reminder-PMs funktionieren unabhängig davon.
|
||||
|
||||
**Create sked** legt den Termin immer zuerst in KST4Contest an. Ist der Win-Test-Netzwerk-Listener aktiv, wird anschließend zusätzlich eine Übergabe an Win-Test versucht. Kann keine zum ausgewählten Band passende QRG ermittelt werden oder ist Win-Test nicht erreichbar, bleiben der interne Sked, seine Priorisierung und gegebenenfalls angelegte Reminder erhalten.
|
||||
|
||||
Die vollständige Herleitung und die Grenzen der Funktion sind unter [Skeds und Sked-Erinnerungen](de-Funktionen#skeds-und-sked-erinnerungen) beschrieben.
|
||||
Hier können auch **Sked-Erinnerungen** aktiviert werden.
|
||||
|
||||
---
|
||||
|
||||
## Prioritätsliste
|
||||
|
||||
Die kompakte Prioritätsleiste befindet sich rechts zwischen Benutzerliste und Further-Info-Bereich. Sie zeigt die beiden derzeit höchstbewerteten Kandidaten unmittelbar im Hauptfenster:
|
||||
|
||||
```text
|
||||
Priority: 1 RUFZEICHEN SCORE 2 RUFZEICHEN SCORE more
|
||||
```
|
||||
|
||||
Ein Klick auf einen der beiden Kandidaten wählt den dazugehörigen aktiven Chatmember aus. Dabei werden das vollständige Rufzeichen einschließlich Suffix und die zugehörige Chat-Kategorie verwendet.
|
||||
|
||||
Die Schaltfläche **more** öffnet ein separates Fenster mit bis zu 15 Kandidaten. Die Liste ist nach absteigendem Score sortiert. Ein Doppelklick wählt den betreffenden Kandidaten aus und schließt das Fenster.
|
||||
|
||||
|
||||
|
||||
Stationen mit einem Score von `0` werden nicht in die Prioritätsliste aufgenommen. In der Benutzerliste bleiben sie sichtbar, sodass der Ausschluss nachvollzogen und beispielsweise durch eine geänderte NOT-QRV-Markierung korrigiert werden kann.
|
||||
|
||||
Der Score wird für das normalisierte Basisrufzeichen berechnet. Mehrere aktive Varianten wie `9A0BB-2` und `9A0BB-70` können daher in der Benutzerliste denselben Wert anzeigen. Die Chatmember bleiben trotzdem getrennte Nachrichtenziele.
|
||||
|
||||
Neue Nachrichten, AirScout-Daten, Skeds und Statusänderungen lösen eine Neuberechnung aus. Zusätzlich erfolgt eine regelmäßige Aktualisierung im Hintergrund. Eine kurzzeitig noch nicht angepasste Reihenfolge ist deshalb kein Fehler.
|
||||
|
||||
Herleitung und Grenzen: [Prioritätsscore und Prioritätsliste](de-Funktionen#prioritätsscore-und-prioritätsliste-ab-v140).
|
||||
Zeigt die vom Score-Service berechneten Top-Kandidaten. Aktualisiert sich automatisch im Hintergrund basierend auf Richtung, Entfernung und AP-Verfügbarkeit.
|
||||
|
||||
---
|
||||
|
||||
## Stationskarte
|
||||
## Cluster & QSO der anderen
|
||||
|
||||
Die Stationskarte kann auf zwei Wegen geöffnet werden:
|
||||
|
||||
- **Windows → Show / hide station map** öffnet oder schließt das Kartenfenster.
|
||||
- **Show on map** im **Further Info**-Bereich öffnet die Karte und fokussiert die ausgewählte Station.
|
||||
|
||||
Die Karte verwendet die Stationen, die nach Anwendung der aktuellen Benutzerlistenfilter noch sichtbar sind. Die Kopfzeile zeigt die Anzahl der dargestellten Stationen und weist mit `filtered view active` auf eine gefilterte Ansicht hin.
|
||||
|
||||
|
||||
|
||||
### Station auswählen
|
||||
|
||||
Ein einzelner Stationsmarker kann direkt angeklickt werden. KST4Contest:
|
||||
|
||||
1. übernimmt den konkreten Chatmember als aktuelle Auswahl,
|
||||
2. scrollt die Benutzerliste zum entsprechenden Eintrag,
|
||||
3. aktualisiert den **Further Info**-Bereich und
|
||||
4. bereitet das vollständige sichtbare Rufzeichen als `/cq`-Empfänger vor.
|
||||
|
||||
Marker, die bei der aktuellen Zoomstufe zu dicht beieinanderliegen, werden als Cluster mit einer Stationsanzahl dargestellt. Ein Klick auf einen Cluster vergrößert den betreffenden Kartenausschnitt. Erst ein anschließend sichtbarer einzelner Marker wählt eine konkrete Station aus.
|
||||
|
||||
Die Kopfzeile ergänzt bei ausgewählter Station:
|
||||
|
||||
- vollständiges Rufzeichen,
|
||||
- Locator,
|
||||
- QRB und QTF,
|
||||
- erkannte aktive Bänder,
|
||||
- eine gegebenenfalls vorhandene `B+`-Bandmöglichkeit und
|
||||
- die zuletzt bekannten QRGs.
|
||||
|
||||
Lange Inhalte werden in der Kopfzeile gekürzt. Der vollständige Text steht im Tooltip.
|
||||
|
||||
### Auswahl mit Reset view löschen
|
||||
|
||||
**Reset view** löscht die Stationsauswahl, ohne die Kartenposition oder den Zoomlevel zu verändern.
|
||||
|
||||
Dabei werden:
|
||||
|
||||
- die ausgewählte Station zurückgesetzt,
|
||||
- die Auswahl in der Benutzerliste aufgehoben,
|
||||
- die Verbindungslinie zur Gegenstation entfernt,
|
||||
- eine noch laufende Auswertung der vorherigen Station verworfen und
|
||||
- der rechte Analysebereich entfernt.
|
||||
|
||||
Die Karte selbst bleibt im zuvor gewählten Ausschnitt. Die Funktion ist deshalb kein geografischer Reset auf den eigenen Standort.
|
||||
|
||||
|
||||
|
||||
Wird anschließend wieder ein einzelner Marker gewählt, erscheinen Stationsauswahl und Analysebereich erneut.
|
||||
|
||||
### DX-Cluster-Spot auslösen
|
||||
|
||||
**Trigger cluster spot** erscheint nur bei ausgewählter Station. Die Schaltfläche sendet einen einzelnen Spot an die mit dem integrierten DX-Cluster-Server verbundenen Logprogramme.
|
||||
|
||||
Vorausgesetzt werden:
|
||||
|
||||
- ein aktivierter lokaler DX-Cluster-Server,
|
||||
- mindestens ein verbundener Cluster-Client und
|
||||
- eine für die ausgewählte Station verwendbare QRG.
|
||||
|
||||
Der Spot wird nicht an einen öffentlichen Internet-Cluster gesendet.
|
||||
|
||||
### Streckenanalyse
|
||||
|
||||
Unterhalb der Karte befindet sich das Höhenprofil. Der rechte Analysebereich zeigt unter anderem:
|
||||
|
||||
- verwendete Datenquelle und Anzahl der Höhenpunkte,
|
||||
- Analysefrequenz,
|
||||
- Erdkrümmungs- beziehungsweise Refraktionsmodell,
|
||||
- Radio- und Geländehorizont,
|
||||
- Fresnel-Freiheit,
|
||||
- erkannte Hindernisse,
|
||||
- Link-Budget,
|
||||
- geschätzten Empfangspegel und
|
||||
- eine zusammenfassende Pfadbewertung.
|
||||
|
||||
Die Auswertung verwendet dasselbe zentral hergeleitete Band wie die Reachability-Funktionen. Ein im **Reachability**-Dropdown ausdrücklich gewähltes Band wird berücksichtigt.
|
||||
|
||||
Die Werte bleiben technische Abschätzungen. Gebäude, Bewuchs, lokale Abschattungen, aktuelle Ausbreitungsbedingungen und nicht bekannte Stationsparameter können das reale Ergebnis deutlich verändern.
|
||||
|
||||
### Streckenanalyse ausblenden
|
||||
|
||||
Mit **Hide path analysis** werden Höhenprofil und rechter Analysebereich gemeinsam ausgeblendet. Der Kartenbereich erhält dadurch mehr Platz.
|
||||
|
||||
|
||||
|
||||
Der Hinweis **Path analysis is hidden** und die Schaltfläche **Show path analysis** bleiben sichtbar. Die Funktion kann daher ohne Umweg wieder eingeschaltet werden.
|
||||
|
||||
Ist beim Wiedereinblenden keine Station ausgewählt, erscheint kein leerer rechter Bereich. Er wird erst wieder aufgebaut, nachdem eine konkrete Station gewählt wurde.
|
||||
|
||||
Die Auswahl wird gespeichert und beim nächsten Programmstart wiederhergestellt.
|
||||
|
||||
Der Divider zwischen Karte und Detailbereich lässt sich horizontal verschieben. Bei einem schmalen Detailbereich werden längere Angaben umgebrochen; reicht die verfügbare Höhe nicht aus, erscheint eine vertikale Scrollleiste.
|
||||
|
||||
Ausführliche Herleitung und Grenzen: [Stationskarte und Streckenanalyse](de-Funktionen#stationskarte-und-streckenanalyse-ab-v141).
|
||||
|
||||
---
|
||||
|
||||
## Globale Nachrichtentabs und Monitorfenster
|
||||
|
||||
Der untere Bereich des Hauptfensters enthält drei globale Nachrichtentabs. Ihr Inhalt ist nicht von der aktuell in der Benutzerliste ausgewählten Station abhängig.
|
||||
|
||||
| Tab | Inhalt |
|
||||
|---|---|
|
||||
| **Public messages** | Öffentliche Chatnachrichten, CQ-Rufe und Beacons |
|
||||
| **DXCluster messages** | Über ON4KST empfangene DX-Cluster-Meldungen |
|
||||
| **QSO of the other** | Gerichtete Nachrichten zwischen zwei anderen Stationen |
|
||||
|
||||
|
||||
|
||||
Im Tab **QSO of the other** werden Absender und Empfänger getrennt dargestellt. Die Spalten **Last QRG TX** und **Last QRG RX** enthalten die zuletzt für beide Stationen bekannten Frequenzen. Sie geben nicht zwingend die QRG der angezeigten Unterhaltung wieder.
|
||||
|
||||
**wkd TX?** und **wkd RX?** zeigen den globalen Worked-Status der beiden Basisrufzeichen. Die Angaben sind nicht bandbezogen.
|
||||
|
||||
Der Tab **DXCluster messages** zeigt den meldenden und den gemeldeten Teilnehmer, deren Locator, die QRG, den Meldungstext und den globalen Worked-Status der gemeldeten Station. Welche Felder tatsächlich gefüllt sind, hängt von der vom ON4KST-Server übertragenen Meldung ab.
|
||||
|
||||
Nachrichtentexte bleiben einzeilig. Ist eine Zelle zu schmal, erscheint der vollständige Inhalt als Tooltip. Webadressen im Meldungstext lassen sich anklicken.
|
||||
|
||||
### Separates Monitorfenster
|
||||
|
||||
Zusätzlich öffnet KST4Contest das Fenster **Cluster & QSO of the other**. Es zeigt oben die DX-Cluster-Meldungen und darunter die gerichteten Nachrichten zwischen anderen Stationen.
|
||||
|
||||
|
||||
|
||||
Die Position des vertikalen Dividers sowie die Fenstergröße werden zusammen mit den übrigen UI-Einstellungen gespeichert. Nach einer Änderung **Save Settings** verwenden.
|
||||
|
||||
Das Fenster lässt sich über das Menü aus- und wieder einblenden:
|
||||
|
||||
```text
|
||||
Windows → Hide cluster / stranger QSOs
|
||||
Windows → Show cluster / stranger QSOs
|
||||
```
|
||||
|
||||
Die Tabellen im Hauptfenster und im Monitorfenster greifen auf dieselben Daten zu. Das Ausblenden des Monitorfensters beendet daher weder den Empfang noch die Darstellung in den unteren Tabs.
|
||||
|
||||
Herleitung und Grenzen: [Globale Nachrichtenansichten](de-Funktionen#globale-nachrichtenansichten).
|
||||
Separates Fenster (kann miniaturisiert werden). Zeigt den Kommunikationsfluss zwischen anderen Stationen – interessant in ruhigeren Phasen.
|
||||
|
||||
---
|
||||
|
||||
## Menü
|
||||
|
||||
### File
|
||||
|
||||
- **Connect to …** startet die Verbindung mit den bereits übernommenen Einstellungen.
|
||||
- **Disconnect** beendet die aktuelle ON4KST-Verbindung, ohne KST4Contest zu schließen.
|
||||
- **Exit + disconnect** beendet die Verbindung und anschließend das Programm.
|
||||
|
||||
Die Connect- und Disconnect-Einträge werden entsprechend dem aktuellen Verbindungszustand aktiviert oder deaktiviert.
|
||||
|
||||
### Options
|
||||
|
||||
- **Set QRG as name in Chat (main category)** sendet `/SETNAME` mit der aktuellen `MYQRG` an die primäre Chat-Kategorie.
|
||||
- **Show me as away in chat** sendet `/AWAY`.
|
||||
- **Show me as active in chat** sendet `/BACK`.
|
||||
- **Show options** blendet das Einstellungsfenster ein beziehungsweise aus.
|
||||
|
||||
Die serverbezogenen Funktionen sind nur bei vollständig aufgebauter ON4KST-Verbindung verfügbar.
|
||||
|
||||
### Windows
|
||||
|
||||
- **Hide cluster / stranger QSOs** beziehungsweise **Show cluster / stranger QSOs** blendet das zusätzliche Cluster- und QSO-Monitorfenster aus oder wieder ein.
|
||||
- **hide options** beziehungsweise **show options** blendet das Einstellungsfenster aus oder wieder ein.
|
||||
- **Use dark mode design** aktiviert das dunkle Farbschema.
|
||||
- **Use default mode design** aktiviert das normale helle Farbschema.
|
||||
- **Show / hide station map** öffnet beziehungsweise schließt das separate Fenster mit Stationskarte und Streckenanalyse.
|
||||
### Window
|
||||
- **Use Dark Mode** (ab v1.26): Dunkles Farbschema aktivieren/deaktivieren.
|
||||
|
||||
---
|
||||
|
||||
## Fenstergrößen und Divider
|
||||
|
||||
Beim Klick auf **Save Settings** speichert KST4Contest die Größen der Programmfenster und die Positionen der relevanten Divider in der Konfigurationsdatei. Diese Werte werden beim nächsten Programmstart wiederverwendet.
|
||||
Ab **v1.21** werden beim Klick auf **„Save Settings"** auch Fenstergrößen und Divider-Positionen aller Panels in der Konfigurationsdatei gespeichert und beim nächsten Start wiederhergestellt.
|
||||
|
||||
Das Hauptfenster wird beim Start zusätzlich gegen den sichtbaren Bereich des primären Bildschirms geprüft. Ist die gespeicherte Größe zu groß, verkleinert und verschiebt KST4Contest das Fenster so, dass es wieder erreichbar bleibt. Die genaue Herleitung ist unter [Bildschirmgerechte Größe des Hauptfensters](de-Funktionen#bildschirmgerechte-größe-des-hauptfensters-ab-v141) beschrieben.
|
||||
|
||||
Für die übrigen Programmfenster gilt diese zusätzliche Größenbegrenzung derzeit nicht. Wird beispielsweise das separate Monitorfenster nach einem Wechsel auf einen kleineren Bildschirm zu groß dargestellt, muss seine Größe manuell korrigiert und anschließend erneut mit **Save Settings** gespeichert werden.
|
||||
|
||||
Bei einer ungünstigen Aufteilung sollten zuerst die Divider an eine brauchbare Position verschoben und die Einstellungen erneut gespeichert werden. Das Löschen der Konfigurationsdatei setzt zwar die UI-Werte zurück, entfernt aber auch die übrigen gespeicherten Programmeinstellungen und sollte deshalb nur verwendet werden, wenn sich die Oberfläche auf anderem Weg nicht mehr herstellen lässt.
|
||||
Bei Problemen mit der Darstellung: Konfigurationsdatei löschen → KST4Contest erstellt neue Standardwerte.
|
||||
|
||||
---
|
||||
|
||||
|
||||
+1
-182
@@ -4,190 +4,9 @@
|
||||
|
||||
Versionsverlauf von KST4Contest / PraktiKST.
|
||||
|
||||
Die veröffentlichten Stable-Versionen und ihre Programmpakete stehen unter [GitHub Releases](https://github.com/praktimarc/kst4contest/releases). Zusätzlich enthält diese Seite die Änderungen des aktuellen Entwicklungsstands, soweit sie bereits implementiert und geprüft wurden.
|
||||
|
||||
---
|
||||
|
||||
## v1.42 – Nightly / in Entwicklung
|
||||
|
||||
> Stand dieses Abschnitts: 14. August 2026.
|
||||
> v1.42 ist noch kein veröffentlichtes Stable-Release. Bis zur Freigabe können weitere Änderungen hinzukommen.
|
||||
|
||||
v1.42 führt mehrere bisher getrennte Auswertungen zusammen. Bandinformationen, Worked-Status, NOT-QRV-Markierungen, Rufzeichensuffixe und Frequenzen werden dadurch konsistenter in der Benutzerliste, der Stationskarte, der Prioritätsberechnung und den externen Schnittstellen verwendet.
|
||||
|
||||
### Neu
|
||||
|
||||
- **Sichtbarer ON4KST-Verbindungsstatus:** Ein kompakter `LINK`-Indicator im Hauptfenster zeigt den tatsächlichen Zustand der ON4KST-Verbindung an. Grün bedeutet vollständig angemeldet und synchronisiert, Gelb kennzeichnet Verbindungsaufbau und Synchronisation, Rot eine unterbrochene Verbindung, einen Fehler oder die Wartezeit vor dem nächsten Verbindungsversuch.
|
||||
|
||||
- **Gemeinsame Herleitung verfügbarer Bänder:** Ein zentraler `BandOpportunityResolver` wertet aktuelle QRGs, Bandangaben im Namensfeld, aktive Rufzeichenvarianten, Worked-Informationen und NOT-QRV-Markierungen gemeinsam aus. Benutzerliste, **New bands**, Band-Upgrade-Hinweis, Priority Score, Stationskarte und automatische Bandauswahl verwenden damit dieselbe Grundlage.
|
||||
|
||||
- **Erweiterte Bandanzeige:** Die Bandspalten unterscheiden jetzt:
|
||||
- `X` für auf diesem Band gearbeitet,
|
||||
- `a` für ein angebotenes, noch nicht gearbeitetes Band einer insgesamt neuen Station,
|
||||
- `B+` für ein angebotenes, noch nicht gearbeitetes Band einer bereits auf einem anderen Band gearbeiteten Station und
|
||||
- `o` für ein auf diesem Band bereits gearbeitetes Locator-Großfeld.
|
||||
|
||||
Die Anzeigen können kombiniert werden, beispielsweise als `ao` oder `B+o`. Die zusätzlichen Kennzeichnungen `a` und `o` lassen sich in den GUI-Einstellungen separat ausblenden.
|
||||
|
||||
- **Unterstützung für 50 und 70 MHz:** Beide Bänder stehen in der Stationskonfiguration, den Worked- und NOT-QRV-Funktionen, der Benutzerliste, den Filtern, der internen Datenbank, der UCXLog-Auswertung und dem Win-Test-Listener zur Verfügung. Bereits gespeicherte Datenbanken werden um die benötigten Spalten ergänzt.
|
||||
|
||||
- **Globale Nachrichtentabs:** Öffentliche Nachrichten, ON4KST-DX-Cluster-Meldungen und gerichtete Nachrichten zwischen anderen Stationen können direkt im Hauptfenster angezeigt werden. Das bisherige separate Monitorfenster bleibt zusätzlich verfügbar und verwendet dieselben Nachrichtenspeicher.
|
||||
|
||||
- **Manuelle QTF-Eingabe:** Die aktuelle Antennenrichtung kann auch ohne PSTRotator direkt in KST4Contest geändert 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.
|
||||
|
||||
- **Ausblendbare Streckenanalyse:** Geländeprofil und Analysebereich der Stationskarte können vollständig ausgeblendet werden. Die Auswahl wird gespeichert und beim nächsten Programmstart wiederhergestellt.
|
||||
|
||||
### Geändert
|
||||
|
||||
- **Sessionbezogene ON4KST-Verbindungssteuerung:** Socket, Reader, Writer, Messagebus und Warteschlangen gehören jetzt zu einer eindeutig identifizierten Verbindungssession. Veraltete Threads einer abgelösten Verbindung können dadurch keine Daten mehr verarbeiten oder die neue Verbindung schließen. `ONLINE` wird erst nach bestätigtem Login und vollständig empfangenen Benutzerlisten gemeldet. Verbindungsaufbau, Login und Synchronisation besitzen feste Zeitlimits; Heartbeats, ausbleibende Eingangsdaten, EOF sowie Lese- und Schreibfehler werden überwacht und lösen bei Bedarf einen kontrollierten Neuaufbau mit Backoff aus.
|
||||
|
||||
- **ON4KST-Protokollbefehle abgesichert:** Ausgehende Befehle werden zentral aufgebaut und auf gültige Kategorien, Locatoren und unerlaubte Frame-Trennzeichen geprüft. Da ON4KST pro TCP-Session nur einen Locator verwaltet, wird für beide Chat-Kategorien der Hauptlocator verwendet und eine abweichende zweite Konfiguration protokolliert, statt widersprüchliche Befehle an den Server zu senden.
|
||||
|
||||
- **QRG-Erkennung präzisiert:** Vollständige und relative Frequenzangaben werden weiterhin erkannt. Nackte dreistellige Zahlen gelten nur noch bei erkennbarem Frequenzkontext als QRG. Signalrapporte, Bandangaben und andere Zahlen erzeugen dadurch seltener falsche Frequenzen.
|
||||
|
||||
- **Stationsbezogener Frequenzkontext:** Bei relativen QRGs verwendet KST4Contest zuerst einen höchstens 30 Minuten alten Bandkontext derselben Station. Erst wenn dieser fehlt, wird das global konfigurierte Fallback-Band verwendet.
|
||||
|
||||
- **Fallback-Band als Dropdown:** Das globale Fallback kann nur noch aus unterstützten Bandwerten ausgewählt werden. Es betrifft die gesamte QRG-Erkennung und nicht nur DX-Cluster-Spots.
|
||||
|
||||
- **Einheitliche QRG-Darstellung:** Frequenzen werden in Benutzer- und Nachrichtentabellen mit mindestens drei Nachkommastellen dargestellt.
|
||||
|
||||
- **Bandabhängige AirScout- und Streckenberechnung:** KST4Contest leitet für jede Station eine möglichst realistische Frequenz aus der aktuellen QRG und den bekannten Bandinformationen ab. AirScout erhält kanonische Bandwerte. Die frühere Zwischenlösung mit 430 MHz wurde durch 432 MHz ersetzt.
|
||||
|
||||
- **Gemeinsame Frequenzherleitung:** AirScout, **Calc selected** und die Pfadanalyse der Stationskarte verwenden denselben `PropagationFrequencyResolver`. Ein im Reachability-Dropdown ausdrücklich gewähltes Band wird bei manuellen Berechnungen berücksichtigt.
|
||||
|
||||
- **Rufzeichenvarianten getrennt verarbeitet:** Aktive Chatmember werden durch das vollständige Rufzeichen einschließlich Suffix und die Chat-Kategorie unterschieden. `DN9APW`, `DN9APW-2` oder vergleichbare Logins bleiben dadurch getrennte Nachrichtenziele.
|
||||
|
||||
- **Gemeinsame Basisinformationen:** Worked-Flags, NOT-QRV-Informationen und der Priority Score werden weiterhin für Varianten desselben Basisrufzeichens gemeinsam ausgewertet. Getrennte Nachrichtenziele führen damit nicht zu widersprüchlichen Worked-Daten.
|
||||
|
||||
- **Priority Score korrigiert:** Stationen ohne gemeinsames verfügbares Band oder mit übersteuernder NOT-QRV-Markierung werden nicht mehr als Prioritätskandidaten angeboten. Bandgelegenheiten bereits gearbeiteter Stationen können einen eigenen Priority Boost erhalten.
|
||||
|
||||
- **Sked-Erstellung erweitert:** Das Band wird aus den lokal aktivierten Bändern gewählt. Für die Win-Test-Übergabe wird `SSB` oder `CW` ausdrücklich ausgewählt, statt den Mode unzuverlässig aus dem Band abzuleiten.
|
||||
|
||||
- **Win-Test-Sked-Übergabe präzisiert:** Die QRG muss zum gewählten Band passen. Sichtbare KST-Suffixe werden für das Logziel entfernt, portable Bestandteile bleiben erhalten und die Zeitangaben der `ADDSKED`-Pakete werden korrekt erzeugt. Ein Fehler bei der Übergabe entfernt den internen KST4Contest-Sked nicht.
|
||||
|
||||
- **Exakte Sked-Ziele:** Timeline und automatische Erinnerungen verwenden das vollständige sichtbare KST-Rufzeichen. Ein Sked für `DN9APW-2` wird nicht versehentlich an eine andere Variante desselben Basisrufzeichens gesendet.
|
||||
|
||||
- **Beacon und Autoantwort überarbeitet:** Beide Chat-Kategorien verwenden einen gemeinsamen Timer, behalten aber getrennte Aktivierungsschalter und Texte. Das zulässige Mindestintervall beträgt zwei Minuten; Nachrichtentexte sind auf 120 Zeichen begrenzt. Die gespeicherte Beacon-Aktivierung wird beim Start aus der Konfiguration übernommen.
|
||||
|
||||
- **Variablen zentral aufgelöst:** Nachrichtenvariablen für Beacons, Shortcuts, Snippets und andere automatisch erzeugte Texte werden über einen gemeinsamen Resolver verarbeitet.
|
||||
|
||||
- **Nachrichtentabellen verbessert:** Abgeschnittene Nachrichtentexte erhalten einen Tooltip mit dem vollständigen Inhalt. Erkannte Webadressen können im Systembrowser geöffnet werden.
|
||||
|
||||
- **Kompaktere Filterleiste:** Die Filter bleiben bei normaler Breite in einer kompakten Anordnung und werden erst dann umgebrochen, wenn der tatsächlich verfügbare Platz nicht mehr ausreicht. Der mittlere Divider kann dadurch weiter verschoben werden.
|
||||
|
||||
- **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.
|
||||
|
||||
- **Versionserkennung verbessert:** Versionsnummern werden semantisch verglichen, damit beispielsweise Patch-Versionen und Nightly-Stände nicht mehr durch eine einfache Fließkommazahl falsch eingeordnet werden.
|
||||
|
||||
### Behoben
|
||||
|
||||
- **Zuverlässige Benutzerliste beim Login:** Ungültige oder unvollständige `UA0`-Teilnehmerdatensätze werden einzeln verworfen und protokolliert, ohne die Verarbeitung der alphabetisch folgenden Teilnehmer abzubrechen. Die gültigen Einträge werden zunächst pro Kategorie gesammelt und erst mit dem ersten zugehörigen `UE`-Abschlussframe vollständig veröffentlicht.
|
||||
|
||||
- **Benutzerliste verschwindet nach dem Login:** ON4KST kann nach Namens-, Status- oder anderen Live-Änderungen weitere `UE`-Frames für dieselbe Kategorie senden. Wiederholte Abschlussframes werden jetzt erkannt und ignoriert, damit eine bereits gefüllte Benutzerliste nicht durch eine leere Momentaufnahme ersetzt wird.
|
||||
|
||||
- **Fehlgeschlagener Erstaufbau und Verbindungsverlust:** Wenn beim Programmstart keine Verbindung zum Server hergestellt werden kann, läuft KST4Contest nicht mehr in eine Endlos- oder Busy-Wait-Schleife. Die Oberfläche bleibt bedienbar und weitere Versuche erfolgen mit begrenztem Backoff. Auch ein vom Server geschlossener oder über längere Zeit stummer Socket wird zuverlässig erkannt.
|
||||
|
||||
- **Messagebus-Protokollierung:** Bereits korrekt verarbeitete ON4KST-Frames werden nicht mehr zusätzlich als `Critical, detected unhandled Chatmessage` gemeldet. Nur tatsächlich unbekannte Telegramme erreichen noch diesen Logzweig.
|
||||
|
||||
- **Passwort im Fehlerlog:** Das ON4KST-Passwort wird beim Verbindungsaufbau nicht mehr im Klartext in die Konsole oder Logdatei geschrieben.
|
||||
|
||||
- **Langzeitfehler der Stationsauswahl:** Die vom Message-Thread verwalteten Chatmember wurden von der JavaFX-Ansicht entkoppelt. Gleichzeitige Änderungen der Daten und Tabellenansicht führen dadurch nicht mehr nach längerer Laufzeit zu fehlerhaften Auswahlmodellen oder Concurrent-Modification-Problemen.
|
||||
|
||||
- **Keine Phantom-Chatmember durch UM3:** Historische oder zusätzliche Servermeldungen erzeugen keine Benutzerlisteneinträge für Stationen, die nicht tatsächlich im Chat angemeldet sind.
|
||||
|
||||
- **Nachrichten an Rufzeichen mit Suffix:** Mehrere gleichzeitig angemeldete Varianten desselben Basisrufzeichens überschreiben sich nicht mehr gegenseitig. Damit wurde [Issue #73](https://github.com/praktimarc/kst4contest/issues/73) behoben.
|
||||
|
||||
- **DX-Cluster-Locatoren:** Sender und gemeldete Station erhalten nicht mehr versehentlich denselben Locator. Damit wurde [Issue #48](https://github.com/praktimarc/kst4contest/issues/48) behoben.
|
||||
|
||||
- **Worked-Anzeige in „QSO of the other“:** Die Worked-Spalten verwenden wieder die jeweils richtige sendende beziehungsweise empfangende Station.
|
||||
|
||||
- **Fehlende SECONDAP-Daten:** Eine nicht vorhandene zweite Aircraft-Scatter-Gelegenheit führt beim Bearbeiten der Anzeige nicht mehr zu einer ungültigen Textauswahl und JavaFX-Exception.
|
||||
|
||||
- **Historische Rufzeichen:** Das Hervorheben oder Anklicken eines Rufzeichens, das nicht mehr in der aktuellen Benutzerliste vorhanden ist, läuft nicht mehr in eine Exception.
|
||||
|
||||
- **Win-Test-Sked-Zeit und Rufzeichen:** Zeitstempel, Band-QRG-Zuordnung sowie die Behandlung von KST-Suffixen und portablen Rufzeichen wurden korrigiert.
|
||||
|
||||
- **Filter-Reset:** Alle Filterprädikate werden tatsächlich entfernt; der sichtbare Zustand des Buttons entspricht wieder dem wirksamen Filterzustand.
|
||||
|
||||
### Dokumentation und Auslieferung
|
||||
|
||||
- Das deutsche und englische Handbuch wurde systematisch mit dem Quellcode abgeglichen, erweitert und mit aktuellen Screenshots versehen. Die Dokumentation erklärt nicht nur die Bedienelemente, sondern auch Herleitung, Datenquellen und Grenzen der Funktionen.
|
||||
|
||||
- Für Arch Linux stehen `kst4contest-bin`, `kst4contest` und `kst4contest-git` im AUR zur Verfügung.
|
||||
|
||||
- Die Downloadseite unterscheidet Stable, Beta und Nightly und bietet die jeweils tatsächlich vorhandenen Pakete für Windows, Linux und macOS an.
|
||||
|
||||
- Nightly-Pakete werden automatisiert aus dem aktuellen `main`-Branch gebaut. Stable- und Beta-Releases verwenden reproduzierbare Paketnamen für die unterstützten Plattformen.
|
||||
|
||||
- **Signierte und notarisierte macOS-Pakete:** Die DMG-Dateien für Apple Silicon und Intel sind mit einer Apple Developer ID signiert und von Apple notarisiert; das Notarisierungsticket ist in der DMG hinterlegt. Der erste Start funktioniert damit per Doppelklick, ohne den bisherigen Umweg über **Öffnen** im Kontextmenü, und die Prüfung gelingt auch ohne Internetverbindung. Betroffen sind Nightly-, Beta- und Stable-Pakete gleichermaßen. Die Windows-Pakete sind weiterhin nicht signiert.
|
||||
|
||||
- **Korrekte Bundle-Kennung und Version unter macOS:** Die Anwendung meldet sich jetzt als `de.x08.KST4Contest` statt als `kst4contest.view` und trägt die tatsächliche Versionsnummer im Bundle. Bisher wies jedes Release im Finder unter **Informationen** die Version `1.0` aus. Bestehende Einstellungen sind davon nicht betroffen, da KST4Contest seine Daten in `~/.praktiKST/` ablegt und nicht an der Bundle-Kennung festmacht.
|
||||
|
||||
### Bekannte Grenzen
|
||||
|
||||
- Die aktive Geländedatenquelle verwendet Open-Meteo mit Copernicus-GLO-90-Daten und höchstens 100 Höhenpunkten pro Strecke.
|
||||
|
||||
- Der atmosphärische K-Faktor ist derzeit fest auf `4/3` eingestellt.
|
||||
|
||||
- Für die Gegenstation wird eine Antennenhöhe von 10 Metern über Grund angenommen.
|
||||
|
||||
- Aircraft-Scatter-Daten aus AirScout und die Geländeanalyse der Stationskarte sind weiterhin getrennte Bewertungen.
|
||||
|
||||
- Eine genauere Konfiguration von Stationshöhe, Frequenz und K-Faktor wird in [Issue #74](https://github.com/praktimarc/kst4contest/issues/74) weiterverfolgt.
|
||||
|
||||
---
|
||||
|
||||
## v1.41.1 (2026-07-08)
|
||||
|
||||
**Hotfix für Texteingabe und Fokusverhalten**
|
||||
|
||||
### Behoben
|
||||
|
||||
- Das Nachrichteneingabefeld wurde nach einiger Zeit beziehungsweise bei bestimmten UI-Aktualisierungen unerwartet geleert.
|
||||
- Beim Filtern oder Auswählen einer Station wurde der Eingabefokus unbeabsichtigt wieder in das Sendefeld verschoben.
|
||||
|
||||
Die korrigierte Version ist als [Release v1.41.1](https://github.com/praktimarc/kst4contest/releases/tag/v1.41.1) verfügbar.
|
||||
|
||||
---
|
||||
|
||||
|
||||
## v1.41.0 (2026-07-01)
|
||||
|
||||
**Stationskarte, begrenzte Nachrichtenspeicher und bildschirmgerechtes Hauptfenster**
|
||||
|
||||
### Neu
|
||||
|
||||
- **Stationskarte:** Eine interaktive OpenStreetMap-Karte stellt aktive Chatmember mit brauchbarem Locator geografisch dar.
|
||||
|
||||
- **Antennensektor und Verbindungslinie:** Die Karte zeigt den aktuellen eigenen QTF, den konfigurierten Antennen-Öffnungswinkel, das maximale QRB und die Verbindung zur ausgewählten Station.
|
||||
|
||||
- **Maidenhead-Raster:** Ein an die Zoomstufe angepasstes Locator-Raster erleichtert die geografische Einordnung.
|
||||
|
||||
- **Geländeprofil:** Für ausgewählte Stationen kann ein Höhenprofil über die Open-Meteo Elevation API berechnet werden. Die aktive Datenquelle verwendet Copernicus GLO-90 und höchstens 100 gleichmäßig verteilte Abfragepunkte.
|
||||
|
||||
- **Geometrische Streckenanalyse:** Die Auswertung berücksichtigt Sichtlinie, Erdkrümmung mit `k = 4/3`, Radio- und Geländehorizont, erste Fresnel-Zone und eine grobe Hindernisabschätzung.
|
||||
|
||||
- **Lokaler Karten-Proxy:** Leaflet wird mit der Anwendung ausgeliefert. Kartenkacheln werden über einen lokalen Proxy geladen, damit keine externe JavaScript-Bibliothek zur Laufzeit nachgeladen werden muss. Für die OpenStreetMap-Kacheln und die Online-Höhendaten ist weiterhin eine Internetverbindung erforderlich.
|
||||
|
||||
### Geändert
|
||||
|
||||
- **Begrenzte Nachrichtenspeicher:** Die globale Chatnachrichtenliste wird oberhalb von 30.000 Einträgen auf 25.000 verkleinert. Der getrennte DX-Cluster-Speicher wird oberhalb von 10.000 Einträgen auf 8.000 verkleinert.
|
||||
|
||||
- **Bildschirmgerechte Startgröße:** Das Hauptfenster wird beim Start gegen den sichtbaren Bereich des primären Bildschirms geprüft und bei Bedarf verkleinert oder verschoben.
|
||||
|
||||
- **Kompaktere Benutzeroberfläche:** Mehrere Bereiche wurden für kleinere Bildschirme und verstellbare Divider angepasst.
|
||||
|
||||
### Einordnung der Kartenfunktion
|
||||
|
||||
Die Stationskarte und AirScout können dieselbe Gegenstation betreffen, führen aber getrennte Berechnungen durch. Aircraft-Scatter-Flugzeuge werden nicht in das Geländeprofil eingerechnet.
|
||||
|
||||
Im Quellcode vorhandene Klassen für Copernicus GLO-30, Offline-DEM-Import und weitere Terrain-Provider waren in v1.41 nicht Bestandteil der aktiv verwendeten Berechnungskette. Die tatsächlich verwendete Online-Höhenquelle ist Open-Meteo auf Basis von Copernicus GLO-90.
|
||||
|
||||
---
|
||||
letzter Changelog bitte aus GitHub entnehmen. Der bisherige Changelog
|
||||
|
||||
## v1.40 (2026-02-16)
|
||||
**Großes Feature-Release: Score-System, AP-Timeline, Win-Test, PSTRotator**
|
||||
|
||||
@@ -2,226 +2,75 @@
|
||||
|
||||
> 🇬🇧 [English version](en-DX-Cluster-Server) | 🇩🇪 Du liest gerade die deutsche Version
|
||||
|
||||
Seit Version 1.23 enthält KST4Contest einen lokalen DX-Cluster-Server. Er übergibt erkannte Richtungsgelegenheiten und die dazugehörige Frequenz an den DX-Cluster-Client eines Logprogramms.
|
||||
Ab **Version 1.23** enthält KST4Contest einen integrierten DX-Cluster-Server. Dieser sendet Spots direkt an das Logprogramm, wenn eine Richtungs-Warnung ausgelöst wird.
|
||||
|
||||
Die Idee dazu stammt von OM0AAO, Viliam Petrik. Vielen Dank!
|
||||
*(Idee von OM0AAO, Viliam Petrik – danke!)*
|
||||
|
||||
---
|
||||
|
||||
## Warum überhaupt ein eigener DX-Cluster-Server?
|
||||
## Wozu dient der integrierte DX-Cluster-Server?
|
||||
|
||||
Eine interessante Frequenz im Chat zu erkennen ist nur der erste Schritt. Im Contest muss diese Information dort ankommen, wo sie unmittelbar verwendet werden kann: im Logprogramm und dessen Bandmap.
|
||||
Wenn KST4Contest erkennt, dass eine Station aus der eigenen Richtung ein Sked anfragt und gleichzeitig eine QRG bekannt ist, wird **automatisch ein DX-Cluster-Spot generiert** und an den Cluster-Client des Logprogramms gesendet.
|
||||
|
||||
KST4Contest verbindet deshalb zwei bereits vorhandene Informationen:
|
||||
|
||||
1. Aus einer gerichteten Chat-Nachricht lässt sich abschätzen, in welche Richtung die sendende Station ihre Antenne wahrscheinlich ausgerichtet hat.
|
||||
2. Aus derselben oder einer vorherigen Nachricht kann eine Frequenz der Station bekannt sein.
|
||||
|
||||
Treffen beide Informationen zusammen, erzeugt KST4Contest einen lokalen DX-Cluster-Spot. Der Logger kann diesen Spot in seiner Bandmap anzeigen und – abhängig von seiner eigenen Konfiguration – den Transceiver nach einem Klick auf die entsprechende Frequenz einstellen.
|
||||
|
||||
Im Klartext: Die Information muss nicht erst im Chat gefunden, gelesen, gemerkt und anschließend erneut in den Logger eingetragen werden. Genau diese kleinen Unterbrechungen kosten im Contest überraschend viel Aufmerksamkeit.
|
||||
Das Logprogramm zeigt den Spot in der Bandkarte an. Ein Klick auf den Spot stellt Frequenz und Mode des Transceivers direkt ein – ohne manuelles Eintippen.
|
||||
|
||||
---
|
||||
|
||||
## Wie wird eine Richtungsgelegenheit hergeleitet?
|
||||
## Einrichtung
|
||||
|
||||
Angenommen, Station A schreibt eine gerichtete Nachricht an Station B. KST4Contest verwendet die Richtung von A zu B als Näherung für die aktuelle Antennenrichtung von Station A. Anschließend wird geprüft, ob die eigene Station aus Sicht von A innerhalb des angenommenen Antennenkorridors liegt.
|
||||
### In KST4Contest
|
||||
|
||||
Dafür werden zwei Richtungen verglichen:
|
||||
In den Preferences → **DX-Cluster-Server-Einstellungen**:
|
||||
|
||||
- die Richtung von Station A zu Station B,
|
||||
- die Richtung von Station A zur eigenen Station.
|
||||
1. **Port** des internen Servers eintragen (z. B. 7300 oder 8000 – muss mit dem Logprogramm übereinstimmen).
|
||||
2. **Spotter-Rufzeichen** eintragen – **unbedingt ein anderes Rufzeichen als das Contest-Rufzeichen verwenden!**
|
||||
- Grund: Logprogramme filtern Spots, die vom eigenen Rufzeichen stammen, als „gearbeitet" heraus. Wenn der Spotter dasselbe Rufzeichen hat, werden die Spots nicht angezeigt.
|
||||
3. **Angenommene MHz** eintragen: Bei Frequenzangaben wie „.205" im Chat muss KST4Contest entscheiden, ob 144.205, 432.205 oder 1296.205 gemeint ist. Bei Einband-Contests einfach die entsprechende Bandmitte eintragen. Vollständige Frequenzangaben wie „144.205" oder „1296.338" im Chat werden immer korrekt erkannt.
|
||||
|
||||
Der in den Station Settings konfigurierte Antennen-Öffnungswinkel ist der vollständige Winkel. Für die Prüfung wird jeweils die Hälfte links und rechts der Richtung A → B angesetzt. Bei `70°` sind das somit `±35°`.
|
||||
### In UCXLog
|
||||
|
||||
Da ON4KST keine Antennendaten der fremden Station überträgt, verwendet KST4Contest den Öffnungswinkel der eigenen Antenne zugleich als Näherung für Station A. Das ist keine Messung der tatsächlichen Antennenrichtung, sondern eine bewusst einfache geometrische Annahme.
|
||||
- Verbindung zu einem DX-Cluster-Server konfigurieren:
|
||||
- Host: `127.0.0.1` (oder IP des KST4Contest-Computers)
|
||||
- Port: Wie in KST4Contest konfiguriert
|
||||
- Passwort: kann leer bleiben
|
||||
- Über die Schaltfläche **„Send a test message to your log"** kann die Verbindung getestet werden.
|
||||
|
||||
Ein DX-Cluster-Spot wird nur erzeugt, wenn alle folgenden Bedingungen erfüllt sind:
|
||||
### In N1MM+
|
||||
|
||||
1. Eine gerichtete Nachricht wurde zwischen zwei anderen Stationen erkannt.
|
||||
2. Für Absender und Empfänger sind gültige Locator bekannt.
|
||||
3. Der Absender liegt innerhalb des konfigurierten maximalen QRB zur eigenen Station.
|
||||
4. Die eigene Station liegt aus Sicht des Absenders innerhalb des angenommenen Antennenkorridors.
|
||||
5. Für den Absender ist eine verwertbare Frequenz bekannt oder in der aktuellen Nachricht erkannt worden.
|
||||
6. Der lokale DX-Cluster-Server ist aktiviert.
|
||||
|
||||
Treffen die Bedingungen zu, wird der Spot unmittelbar beim Verarbeiten der Nachricht erzeugt. Die parallel angezeigte grüne Richtungsmarkierung bleibt dagegen fünf Minuten sichtbar und kann durch spätere Nachrichten verlängert oder vorzeitig entfernt werden.
|
||||
|
||||
Das Verfahren berücksichtigt weder Gelände noch aktuelle Ausbreitungsbedingungen und beweist keine tatsächliche Antennenstellung. Es erkennt eine plausible Gelegenheit. Die ausführliche Herleitung und ein Zahlenbeispiel stehen unter [Richtungsgelegenheiten aus gerichteten Nachrichten](de-Funktionen#richtungsgelegenheiten-aus-gerichteten-nachrichten).
|
||||
Ähnliche Einstellungen:
|
||||
- Host: `127.0.0.1` (oder IP des KST4Contest-Computers)
|
||||
- Port: Wie in KST4Contest konfiguriert
|
||||
|
||||
---
|
||||
|
||||
## Welche Frequenz wird verwendet?
|
||||
## Funktionsweise
|
||||
|
||||
Ein DX-Cluster-Spot benötigt eine eindeutige Frequenz. KST4Contest verwendet dafür dieselbe QRG-Erkennung wie die Benutzerliste und die übrigen bandbezogenen Funktionen.
|
||||
Ein Spot wird generiert, wenn **beide** Bedingungen erfüllt sind:
|
||||
|
||||
Vollständige Frequenzen bestimmen ihr Band direkt:
|
||||
1. Eine **Richtungs-Warnung** wurde ausgelöst (Station macht ein Sked in die eigene Richtung).
|
||||
2. **QRG der Station ist bekannt** (aus dem Chat ausgelesen oder manuell eingetragen).
|
||||
|
||||
```text
|
||||
144.205
|
||||
432,088
|
||||
1296.338
|
||||
10368.100
|
||||
```
|
||||
Der generierte Spot enthält:
|
||||
- Rufzeichen der Station
|
||||
- Frequenz
|
||||
- Spotterzeit
|
||||
|
||||
Relative Angaben enthalten dagegen nur den Frequenzanteil innerhalb eines Bandes:
|
||||
|
||||
```text
|
||||
.205
|
||||
,205
|
||||
qrg 205
|
||||
freq is 205
|
||||
on 205
|
||||
205 MHz
|
||||
```
|
||||
|
||||
Eine nackte dreistellige Zahl wie `205` wird ohne Frequenzkontext nicht ausgewertet. Dasselbe gilt für `599`, `144` oder Formulierungen wie `worked 210 stations`. So verhindert KST4Contest, dass Signalrapporte, Bandnamen oder Zählwerte als scheinbar plausible QRG gespeichert und später an den Logger weitergegeben werden.
|
||||
|
||||
Bei einer relativen QRG wird das Band in dieser Reihenfolge bestimmt:
|
||||
|
||||
1. KST4Contest prüft, ob für denselben Absender innerhalb der letzten 30 Minuten bereits ein passender Bandkontext bekannt wurde.
|
||||
2. Sind mehrere aktuelle Bänder bekannt, wird der zuletzt aktualisierte plausible Kontext verwendet.
|
||||
3. Erst wenn kein geeigneter Stationskontext vorhanden ist, verwendet KST4Contest das unter **Fallback band for relative QRG detection** ausgewählte Band.
|
||||
|
||||
Beispiel:
|
||||
|
||||
```text
|
||||
Globales Fallback: 144 MHz
|
||||
Letzte vollständige QRG der Station: 432.088 MHz
|
||||
Neue Chat-Angabe derselben Station: .100
|
||||
Erkannte QRG: 432.100 MHz
|
||||
DX-Cluster-Frequenz: 432100.0 kHz
|
||||
```
|
||||
|
||||
Ohne den aktuellen 432-MHz-Kontext würde dieselbe Angabe mit dem globalen Fallback zu `144.100 MHz` ergänzt.
|
||||
|
||||
Die QRG-Erkennung läuft vor der Richtungs- und Spotprüfung. Nennt eine Station ihre Frequenz erstmals in der gerichteten Nachricht, die zugleich eine Richtungsgelegenheit auslöst, kann bereits der daraus erzeugte Spot diese Frequenz enthalten. War zuvor eine andere QRG der Station bekannt, wird sie durch die neu erkannte Angabe aktualisiert.
|
||||
|
||||
Das Fallback-Band ist eine globale Einstellung der QRG-Erkennung. Seine Wirkung ist nicht auf den DX-Cluster beschränkt. Konfiguration, unterstützte Bänder und weitere Folgen sind unter [Fallback-Band für relative QRG-Erkennung](de-Konfiguration#fallback-band-für-relative-qrg-erkennung) beschrieben.
|
||||
Das Logprogramm kann den Spot dann in der Bandkarte anzeigen und den TRX per Mausklick auf die Frequenz abstimmen.
|
||||
|
||||
---
|
||||
|
||||
## Einrichtung in KST4Contest
|
||||
## Multi-Computer-Setup
|
||||
|
||||
Öffne den Reiter **Notification** in den Preferences.
|
||||
Wenn KST4Contest auf einem separaten Computer läuft (nicht auf dem Log-Computer):
|
||||
|
||||
|
||||
|
||||
Konfiguriere anschließend:
|
||||
|
||||
1. **Enable the local DX Cluster server …** aktivieren.
|
||||
2. Einen freien **TCP port** eintragen. Standard ist `8000`.
|
||||
3. Unter **Fallback band for relative QRG detection** das passende Band auswählen.
|
||||
4. Ein **Spotter callsign** festlegen.
|
||||
|
||||
Für das Spotter-Rufzeichen sollte nach Möglichkeit ein anderes Rufzeichen als das Contest-Rufzeichen verwendet werden. Einige Logger filtern Spots, die scheinbar von der eigenen Station stammen. Das Ergebnis wäre technisch korrekt erzeugt, aber in der Bandmap trotzdem unsichtbar – eine besonders unproduktive Art von Erfolg.
|
||||
|
||||
Änderungen am Aktivierungsstatus und am TCP-Port werden während einer laufenden Chat-Verbindung sofort angewendet. Bei einem Portwechsel werden vorhandene DX-Cluster-Verbindungen getrennt und müssen vom Logger neu aufgebaut werden.
|
||||
|
||||
Die Einstellungen werden erst mit **Save Settings** dauerhaft in der `preferences.xml` gespeichert.
|
||||
|
||||
---
|
||||
|
||||
## Einrichtung im Logprogramm
|
||||
|
||||
Das Logprogramm wird als DX-Cluster-Client mit KST4Contest verbunden.
|
||||
|
||||
| Einstellung | KST4Contest und Logger auf demselben Computer | Logger auf einem anderen Computer |
|
||||
|---|---|---|
|
||||
| Host | `127.0.0.1` | IP-Adresse des KST4Contest-Computers |
|
||||
| Port | In KST4Contest konfigurierter TCP-Port | In KST4Contest konfigurierter TCP-Port |
|
||||
| Login | Beliebiges Rufzeichen, falls der Logger eines verlangt | Beliebiges Rufzeichen, falls der Logger eines verlangt |
|
||||
| Passwort | Nicht erforderlich | Nicht erforderlich |
|
||||
|
||||
KST4Contest wertet den vom Logger gesendeten Login nicht zur Authentifizierung aus. Die Verbindung ist für ein lokales oder vertrauenswürdiges Stationsnetz vorgesehen.
|
||||
|
||||
Wenn der Logger auf einem anderen Computer läuft, muss dessen Verbindung durch die lokale Firewall des KST4Contest-Computers zugelassen werden. Der Port sollte nicht ohne weiteren Schutz aus dem Internet erreichbar sein.
|
||||
|
||||
Mehrere DX-Cluster-Clients können gleichzeitig verbunden werden. Ein erzeugter Spot wird an alle aktuell verbundenen Clients gesendet.
|
||||
|
||||
---
|
||||
|
||||
## Verbindung testen
|
||||
|
||||
Die Schaltfläche **Send test spot** erzeugt folgenden Testeintrag:
|
||||
|
||||
```text
|
||||
Spotted callsign: DO5AMF
|
||||
Comment: Testing DXC-Spot: Congrats, you donated $100!
|
||||
Frequency: .300 des konfigurierten Fallback-Bandes
|
||||
```
|
||||
|
||||
Bei einem Fallback-Band von `144 MHz` erscheint der Spot daher auf ungefähr `144.300 MHz`.
|
||||
|
||||
Der Kommentar ist ein bewusst beibehaltenes Easteregg. Er dient ausschließlich dazu, den Testspot im Logprogramm eindeutig wiederzuerkennen. Eine tatsächliche Spende oder sonstige externe Aktion wird dadurch selbstverständlich nicht ausgelöst.
|
||||
|
||||
Vor dem Test müssen drei Bedingungen erfüllt sein:
|
||||
|
||||
1. KST4Contest ist mit dem ON4KST-Chat verbunden.
|
||||
2. Der lokale DX-Cluster-Server ist aktiviert.
|
||||
3. Der DX-Cluster-Client des Logprogramms ist mit KST4Contest verbunden.
|
||||
|
||||
Fehlt die Client-Verbindung, zeigt KST4Contest eine entsprechende Meldung an. Ein erfolgreich ausgeführter Test bedeutet damit tatsächlich, dass mindestens ein Client den Spot erhalten hat.
|
||||
|
||||
---
|
||||
|
||||
## Inhalt eines erzeugten Spots
|
||||
|
||||
Ein Spot enthält:
|
||||
|
||||
- das konfigurierte Spotter-Rufzeichen,
|
||||
- die normalisierte Frequenz,
|
||||
- das Rufzeichen der erkannten Station,
|
||||
- den Locator,
|
||||
- Flugzeug-Scatter-Informationen, falls vorhanden,
|
||||
- die aktuelle UTC-Zeit.
|
||||
|
||||
Wenn für die Station aktuelle Aircraft-Scatter-Informationen vorliegen, kann KST4Contest diese als zusätzliche AP-Information in den Kommentar des Spots aufnehmen.
|
||||
|
||||
---
|
||||
|
||||
## Wenn kein Spot erscheint
|
||||
|
||||
### Der Testspot kommt nicht im Logger an
|
||||
|
||||
Prüfe:
|
||||
|
||||
- Ist KST4Contest mit dem Chat verbunden?
|
||||
- Ist der lokale DX-Cluster-Server aktiviert?
|
||||
- Verwendet der Logger denselben TCP-Port?
|
||||
- Verwendet der Logger bei lokalem Betrieb `127.0.0.1`?
|
||||
- Blockiert eine Firewall die Verbindung?
|
||||
- Ist im Logger das DX-Cluster-Fenster beziehungsweise die Bandmap aktiviert?
|
||||
|
||||
### Testspot funktioniert, aber reale Spots fehlen
|
||||
|
||||
Dann funktioniert die Verbindung grundsätzlich. Für die betreffende Chat-Situation war wahrscheinlich mindestens eine fachliche Bedingung nicht erfüllt:
|
||||
|
||||
- kein gerichteter Nachrichtenaustausch,
|
||||
- fehlender Locator,
|
||||
- Station außerhalb des maximalen QRB,
|
||||
- Richtung außerhalb des konfigurierten Öffnungswinkels,
|
||||
- keine erkannte Frequenz.
|
||||
|
||||
KST4Contest sendet absichtlich nicht jede gefundene Frequenz an den Logger. Andernfalls würde aus einer Arbeitserleichterung sehr schnell eine lokale Spot-Schleuder.
|
||||
|
||||
### Der Spot erscheint auf dem falschen Band
|
||||
|
||||
Prüfe zuerst, welche Frequenzen für die betreffende Station innerhalb der letzten 30 Minuten erkannt wurden. Bei einer relativen Angabe hat dieser Stationskontext Vorrang vor dem globalen Fallback.
|
||||
|
||||
Ist kein aktueller Stationskontext vorhanden, prüfe die Auswahl unter **Fallback band for relative QRG detection**. Das Fallback wird nur benötigt, wenn sich das Band weder aus einer vollständigen Frequenz noch aus dem aktuellen Kontext des Absenders ergibt.
|
||||
|
||||
### Der Spot wird vom Logger ausgeblendet
|
||||
|
||||
Verwende ein Spotter-Rufzeichen, das nicht mit dem eigenen Contest-Rufzeichen identisch ist. Abhängig vom Logger können eigene Spots gefiltert oder besonders behandelt werden.
|
||||
- Host im Logprogramm: IP des KST4Contest-Computers (nicht `127.0.0.1`)
|
||||
- Entspricht der Konfiguration der QSO-UDP-Broadcast-Pakete (siehe [Log-Synchronisation](de-Log-Synchronisation))
|
||||
|
||||
---
|
||||
|
||||
## Getestete Logprogramme
|
||||
|
||||
Die Schnittstelle wurde mit folgenden Logprogrammen verwendet:
|
||||
- **UCXLog** ✓
|
||||
- **N1MM+** ✓
|
||||
|
||||
- UCXLog
|
||||
- N1MM+
|
||||
|
||||
Weitere Logger können funktionieren, wenn sie eine normale TCP-Verbindung zu einem DX-Cluster-Server unterstützen.
|
||||
Weitere Testergebnisse sind willkommen – bitte per E-Mail an DO5AMF melden.
|
||||
|
||||
+78
-838
File diff suppressed because it is too large
Load Diff
+28
-105
@@ -1,64 +1,10 @@
|
||||
# KST4Contest – Handbuch
|
||||
# KST4Contest – Wiki
|
||||
|
||||
> [English version](en-Home) | Du liest gerade die deutsche Version
|
||||
> 🇬🇧 [English version](en-Home) | 🇩🇪 Du liest gerade die deutsche Version
|
||||
|
||||
KST4Contest ist ein Desktop-Client für den [ON4KST-Chat](https://www.on4kst.org/chat/login.php), der für den Contest-Betrieb auf den VHF-, UHF- und SHF-Bändern entwickelt wurde. Er verbindet Chat, Stationsauswahl, Sked-Planung, Aircraft-Scatter-Daten und die Anbindung an weitere Programme in einer gemeinsamen Arbeitsoberfläche.
|
||||
**KST4Contest** (auch bekannt als *PraktiKST*) ist ein Java-basierter Chat-Client für den [ON4KST-Chat](http://www.on4kst.info/chat/), der speziell für den Contest-Betrieb auf den VHF/UHF/SHF-Bändern (144 MHz und aufwärts) entwickelt wurde.
|
||||
|
||||
Entwickelt wird KST4Contest von **DO5AMF (Marc Fröhlich)**, Operator bei DM5M und (seit Mai 2025) **DN9APW (Philipp Wagner)**. Der Quellcode ist öffentlich auf [GitHub](https://github.com/praktimarc/kst4contest) verfügbar.
|
||||
|
||||
---
|
||||
|
||||
## Wozu braucht man einen eigenen ON4KST-Client?
|
||||
|
||||
Der ON4KST-Chat liefert während eines Contests eine große Menge an Informationen: aktive Stationen, Locator, Frequenzen, Sked-Anfragen und Hinweise auf aktuelle Aktivität. Das eigentliche Problem besteht nicht darin, diese Daten zu sehen. Man muss daraus rechtzeitig die nächste sinnvolle Verbindung ableiten.
|
||||
|
||||
KST4Contest wertet die verfügbaren Informationen aus, ordnet sie und stellt sie in einem contestgerechten Arbeitsablauf dar. Dabei werden unter anderem Antennenrichtung, Entfernung, bekannte Bänder und Frequenzen, bereits gearbeitete Stationen, Chat-Aktivität und Aircraft-Scatter-Zeiten berücksichtigt.
|
||||
|
||||
Das Programm entscheidet jedoch nicht, welches QSO tatsächlich möglich ist. Der Prioritätsscore, die AP-Timeline und die verschiedenen Hervorhebungen sind Entscheidungshilfen. Die endgültige Beurteilung bleibt beim Operator – schon deshalb, weil auch ein recht überzeugender Computerbildschirm noch keine Funkverbindung herstellt.
|
||||
|
||||
---
|
||||
|
||||
## Was KST4Contest im Contest unterstützt
|
||||
|
||||
- **Chat beobachten und einordnen:** KST4Contest kann zwei ON4KST-Chat-Kategorien gleichzeitig darstellen. Nachrichten, Frequenzangaben und bekannte Bandaktivitäten werden den jeweiligen Stationen zugeordnet.
|
||||
|
||||
- **Relevante Stationen herausfiltern:** Richtungs-, Entfernungs-, Worked- und NOT-QRV-Filter reduzieren die Benutzerliste auf die Stationen, die für den aktuellen Betriebszustand tatsächlich interessant sind.
|
||||
|
||||
- **Kandidaten priorisieren:** Das Score-System bewertet aktive Chatmember anhand mehrerer bekannter Kriterien. Die derzeit relevantesten Kandidaten erscheinen zusätzlich in einer eigenen Prioritätsliste.
|
||||
|
||||
- **Skeds vorbereiten und im Blick behalten:** Sked-Erinnerungen, automatische Vorwarnungen und die AP-Timeline helfen dabei, vereinbarte Verbindungen nicht zwischen Chat, Log und laufendem CQ-Betrieb zu verlieren.
|
||||
|
||||
- **Aircraft Scatter einbeziehen:** Über die AirScout-Schnittstelle werden geeignete Flugzeuge und erwartete Reflexionszeiten in die Stationsbewertung und Zeitplanung übernommen.
|
||||
|
||||
- **Log und Funkstation anbinden:** KST4Contest synchronisiert gearbeitete Stationen und Frequenzinformationen mit unterstützten Logprogrammen. Zusätzlich stehen Schnittstellen zu Win-Test, PSTRotator und ein integrierter DX-Cluster-Server zur Verfügung.
|
||||
|
||||
- **Stationen und Funkwege darstellen:** Die Stationskarte zeigt aktive Chatmember, Locator-Felder, Antennenrichtungen und den Weg zur ausgewählten Station. Für ausgewählte Verbindungen kann außerdem ein Geländeprofil berechnet werden.
|
||||
|
||||
Die Funktionen greifen ineinander. Eine erkannte Frequenz kann beispielsweise einem aktiven Band zugeordnet werden, der Worked-Status stammt aus dem Log, Aircraft-Scatter-Daten ergänzen die zeitliche Bewertung und der daraus berechnete Score beeinflusst die Prioritätsliste. Fehlende oder veraltete Eingangsdaten können deshalb auch das Ergebnis beeinflussen.
|
||||
|
||||
---
|
||||
|
||||
## Voraussetzungen
|
||||
|
||||
Für die Anmeldung ist ein registrierter ON4KST-Account erforderlich. Registrierung und Login sind über die [offizielle ON4KST-Anmeldeseite](https://www.on4kst.org/chat/login.php) erreichbar.
|
||||
|
||||
Die offizielle Sprache im ON4KST-Chat ist Englisch. Das gilt auch für Nachrichten an Stationen aus dem eigenen Land. Übliche Amateurfunk-Abkürzungen wie `pse`, `agn`, `qrg`, `dir`, `rrr`, `tnx` oder `73` sind dabei normal und meistens erheblich schneller als ausformulierte Prosa.
|
||||
|
||||
Download, unterstützte Betriebssysteme und Installationswege sind im Kapitel [Installation](de-Installation) beschrieben.
|
||||
|
||||
---
|
||||
|
||||
## Versionsstand dieses Handbuchs
|
||||
|
||||
Dieses Handbuch unterscheidet zwischen der veröffentlichten Stable-Version und dem aktuellen Entwicklungsstand.
|
||||
|
||||
Die derzeit veröffentlichte Stable-Version ist **v1.41.1**. Funktionen oder Änderungen, die erst im Entwicklungsstand für v1.42 enthalten sind, werden ausdrücklich als **Nightly / v1.42** gekennzeichnet. Fehlt eine solche Kennzeichnung, bezieht sich die Beschreibung auf die Stable-Version.
|
||||
|
||||
- [Stable, Beta und Nightly herunterladen](https://kst4contest.hamradioonline.de/download/)
|
||||
- [Veröffentlichte GitHub Releases](https://github.com/praktimarc/kst4contest/releases)
|
||||
- [Versionsgeschichte und aktueller Nightly-Stand](de-Changelog)
|
||||
|
||||
Für einen Contest ist grundsätzlich die Stable-Version zu empfehlen. Nightly-Builds enthalten neuere Korrekturen und Funktionen, können sich aber zwischen zwei Builds verändern. Sie sind sinnvoll, wenn eine konkrete Änderung getestet werden soll. Der erste Versuch zehn Minuten vor Contestbeginn ist dagegen meistens eine recht effiziente Methode, gleichzeitig Software und Operator zu testen.
|
||||
Entwickelt von **DO5AMF (Marc Fröhlich)**, Operator bei DM5M.
|
||||
|
||||
---
|
||||
|
||||
@@ -66,63 +12,40 @@ Für einen Contest ist grundsätzlich die Stable-Version zu empfehlen. Nightly-B
|
||||
|
||||
| Seite | Inhalt |
|
||||
|---|---|
|
||||
| [Installation](de-Installation) | ON4KST-Account, Download, Installation und Updates |
|
||||
| [Konfiguration](de-Konfiguration) | Login, Station, Bänder, Benutzeroberfläche und externe Schnittstellen |
|
||||
| [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 |
|
||||
| [Funktionen](de-Funktionen) | Arbeitsweise, Herleitung und Grenzen der einzelnen Funktionen |
|
||||
| [Makros und Variablen](de-Makros-und-Variablen) | Wiederverwendbare Texte, Shortcuts und automatisch ersetzte Werte |
|
||||
| [Benutzeroberfläche](de-Benutzeroberflaeche) | Aufbau der Oberfläche und Bedienung im Contest |
|
||||
| [Changelog](de-Changelog) | Releases, Nightly-Änderungen und behobene Fehler |
|
||||
| [Installation](de-Installation) | Download, Java-Voraussetzungen, Update |
|
||||
| [Konfiguration](de-Konfiguration) | Alle Einstellungen im Detail |
|
||||
| [Log-Synchronisation](de-Log-Synchronisation) | UCXLog, N1MM+, QARTest, DXLog.net, WinTest |
|
||||
| [AirScout-Integration](de-AirScout-Integration) | Flugzeug-Scatter-Erkennung |
|
||||
| [DX-Cluster-Server](de-DX-Cluster-Server) | Integrierter DX-Cluster für das Log-Programm |
|
||||
| [Funktionen](de-Funktionen) | Alle Features im Überblick |
|
||||
| [Makros und Variablen](de-Makros-und-Variablen) | Text-Snippets, Shortcuts, Variablen |
|
||||
| [Benutzeroberfläche](de-Benutzeroberflaeche) | UI-Erklärung und Bedienung |
|
||||
| [Changelog](de-Changelog) | Versionsgeschichte |
|
||||
|
||||
---
|
||||
|
||||
## Kontakt und Support
|
||||
## Was ist KST4Contest?
|
||||
|
||||
- **Download:** [Stable, Beta und Nightly](https://kst4contest.hamradioonline.de/download/)
|
||||
- **Quellcode:** [praktimarc/kst4contest](https://github.com/praktimarc/kst4contest)
|
||||
- **Fehler und Funktionswünsche:** [GitHub Issues](https://github.com/praktimarc/kst4contest/issues)
|
||||
- **E-Mail:** praktimarc+kst4contest@gmail.com
|
||||
Bitte nur für Themen verwenden, die KST4Contest betreffen.
|
||||
Der ON4KST-Chat ist der De-facto-Standard für Skeds auf den 144-MHz-und-höher-Bändern. KST4Contest erweitert die Chat-Nutzung um contest-spezifische Funktionen:
|
||||
|
||||
### Einen Fehler melden
|
||||
- **Worked-Markierung**: Bereits gearbeitete Stationen werden farblich markiert, direkt aus dem Logprogramm via UDP synchronisiert.
|
||||
- **Sked-Richtungs-Erkennung**: Wenn eine Station eine andere aus deiner Richtung anruft, wird sie grün und fett hervorgehoben.
|
||||
- **QRG-Erkennung**: KST4Contest liest Frequenzen automatisch aus dem Chat-Verkehr und zeigt sie in der Benutzerliste an.
|
||||
- **AirScout-Interface**: Anzeige reflektierbarer Flugzeuge direkt in der Benutzerliste.
|
||||
- **Integrierter DX-Cluster-Server**: Spots werden direkt an das Logprogramm gesendet.
|
||||
- **Dark Mode** (ab v1.26): Schont die Augen in der Nacht.
|
||||
- **Multi-Channel-Login** (ab v1.26): Gleichzeitig in zwei Chat-Kategorien einloggen.
|
||||
|
||||
Ein Fehler lässt sich wesentlich schneller nachvollziehen, wenn die Meldung mindestens folgende Angaben enthält:
|
||||
---
|
||||
|
||||
1. verwendete KST4Contest-Version,
|
||||
2. Betriebssystem und Installationsart,
|
||||
3. genaue Schritte bis zum Fehler,
|
||||
4. erwartetes und tatsächlich beobachtetes Verhalten,
|
||||
5. gegebenenfalls einen Screenshot,
|
||||
6. die Fehler-Logdatei.
|
||||
## Kontakt & Support
|
||||
|
||||
Die Fehler-Logdatei wird hier gespeichert:
|
||||
|
||||
| Betriebssystem | Pfad |
|
||||
|---|---|
|
||||
| Linux / macOS | `~/.praktiKST/kst4contest-errors.log` |
|
||||
| Windows | `C:\Users\<Benutzername>\.praktiKST\kst4contest-errors.log` |
|
||||
|
||||
Vor dem Hochladen sollte die Datei kurz geprüft werden. Ein Fehlerprotokoll enthält überwiegend technische Informationen, kann abhängig vom Fehler aber beispielsweise lokale Dateipfade oder weitere Kontextdaten enthalten.
|
||||
|
||||
In Datei- und Verzeichnisnamen wird teilweise noch der technische Name `praktiKST` verwendet. Gemeint ist dasselbe Programm.
|
||||
- **E-Mail**: praktimarc+kst4contest@gmail.com *(nur für kst4contest-Themen)*
|
||||
- **GitHub**: https://github.com/praktimarc/kst4contest
|
||||
- **Download**: https://github.com/praktimarc/kst4contest/releases/latest
|
||||
|
||||
---
|
||||
|
||||
## Danksagungen
|
||||
|
||||
KST4Contest wurde durch Rückmeldungen aus dem praktischen Contest-Betrieb wesentlich verbessert. Viele Funktionen entstanden nicht aus einer theoretischen Anforderungsliste, sondern aus Situationen, in denen während eines Contests eine Information fehlte, zu spät sichtbar wurde oder schlicht an der falschen Stelle stand.
|
||||
|
||||
Besonderer Dank gilt:
|
||||
|
||||
- Gianluca Costantino (IU3OAR),
|
||||
- Alessandro Murador (IZ3VTH),
|
||||
- Reczetár István (HA1FV),
|
||||
- Viliam Petrik (OM0AAO) für die Idee zum integrierten DX-Cluster,
|
||||
- Konrad Neitzel (DC9DJ) für Unterstützung bei der Projektstruktur,
|
||||
- Andreas (DO5ALF), Webmaster von funkerportal.de,
|
||||
- Franz van Velzen (PE0WGA) für Tests sowie
|
||||
- DN9APW (Philipp Wagner), der seit Mai 2026 an der Entwicklung und den CI/CD-Pipelines mitarbeitet.
|
||||
|
||||
Ebenso wichtig sind die Fehlermeldungen, Tests und konkreten Betriebserfahrungen aller weiteren Nutzer. Eine genaue Beschreibung eines reproduzierbaren Problems hilft dem Projekt meistens mehr als ein allgemeines „läuft gut“ – auch wenn Letzteres natürlich angenehmer zu lesen ist.
|
||||
Besonderer Dank gilt: Gianluca Costantino (IU3OAR), Alessandro Murador (IZ3VTH), Reczetár István (HA1FV), OM0AAO (Viliam Petrik, DX-Cluster-Idee), DC9DJ (Konrad Neitzel, Projektstruktur), DO5ALF (Andreas, Webmaster funkerportal.de), PE0WGA (Franz van Velzen, Tester) sowie allen weiteren Testern und Ideengebern.
|
||||
|
||||
+84
-380
@@ -2,436 +2,140 @@
|
||||
|
||||
> 🇬🇧 [English version](en-Installation) | 🇩🇪 Du liest gerade die deutsche Version
|
||||
|
||||
KST4Contest wird für Windows, Linux und macOS als fertiges Programmpaket bereitgestellt. Für die offiziellen Release-Pakete muss Java nicht separat installiert werden: Die benötigte Java-Laufzeitumgebung ist bereits enthalten.
|
||||
|
||||
Benötigt werden damit im Wesentlichen ein unterstütztes Betriebssystem, eine Internetverbindung und ein ON4KST-Account. Das klingt zunächst überschaubar – und ist es normalerweise auch.
|
||||
|
||||
## Voraussetzungen
|
||||
|
||||
Es wird eine Mindestauflösung von 1200px mal 720px empfohlen
|
||||
|
||||
### ON4KST-Account
|
||||
|
||||
KST4Contest ist ein eigenständiger Client für den ON4KST-Chat, ersetzt aber nicht den dazugehörigen Benutzeraccount.
|
||||
Um den Chat zu nutzen, ist ein registrierter Account beim ON4KST-Chat-Dienst erforderlich:
|
||||
|
||||
Falls noch kein Account vorhanden ist, kann er über die offizielle ON4KST-Seite angelegt werden:
|
||||
- Registrierung unter: http://www.on4kst.info/chat/register.php
|
||||
|
||||
- [ON4KST-Anmeldung und Registrierung](https://www.on4kst.org/chat/login.php)
|
||||
### Verhaltensregeln im Chat
|
||||
|
||||
ON4KST gibt Englisch als gemeinsame Sprache im Chat vor. Das gilt auch dann, wenn beide beteiligten Stationen dieselbe Muttersprache sprechen. Im Contestbetrieb werden häufig die üblichen Amateurfunk-Abkürzungen wie `pse`, `agn`, `qrg`, `dir`, `rrr`, `tnx` oder `73` verwendet.
|
||||
Die offizielle Sprache im ON4KST-Chat ist **Englisch**. Auch bei Kommunikation mit Stationen aus dem eigenen Land bitte Englisch verwenden. Übliche HAM-Abkürzungen (agn, dir, pse, rrr, tnx, 73 …) sind gang und gäbe.
|
||||
|
||||
Die eigentliche Bedienung des Chats und das Senden persönlicher Nachrichten werden im Kapitel zur Benutzeroberfläche beschrieben. Für die Installation ist zunächst nur wichtig, dass der Account funktioniert.
|
||||
### Persönliche Nachrichten
|
||||
|
||||
### Bildschirmgröße
|
||||
Um eine Privatnachricht an eine andere Station zu senden, immer folgendes Format verwenden:
|
||||
|
||||
Eine nutzbare Bildschirmfläche von ungefähr **1200 × 720 Pixeln** oder mehr wird empfohlen.
|
||||
```
|
||||
/CQ RUFZEICHEN Nachrichtentext
|
||||
```
|
||||
|
||||
KST4Contest passt das Hauptfenster automatisch an die verfügbare Fläche des primären Bildschirms an. Das Programm kann deshalb auch auf kleineren Bildschirmen gestartet werden. Weniger Platz bleibt allerdings weniger Platz: In diesem Fall können nicht alle Tabellen, Filter und Zusatzinformationen gleichzeitig in sinnvoller Größe dargestellt werden.
|
||||
Beispiel: `/CQ DL5ASG pse sked 144.205?`
|
||||
|
||||
### Java
|
||||
|
||||
Für die fertigen Pakete aus den [GitHub Releases](https://github.com/praktimarc/kst4contest/releases/latest) ist keine separate Java-Installation erforderlich. Die benötigte Laufzeitumgebung wird zusammen mit KST4Contest ausgeliefert.
|
||||
|
||||
Eine Java-Entwicklungsumgebung wird nur benötigt, wenn KST4Contest selbst aus dem Quellcode gebaut werden soll. Bei den AUR-Paketen `kst4contest` und `kst4contest-git` werden Java 21 und Maven als Build-Abhängigkeiten durch den Paketmanager berücksichtigt.
|
||||
|
||||
---
|
||||
|
||||
## Stable, Beta oder Nightly?
|
||||
|
||||
KST4Contest wird in drei Entwicklungsständen bereitgestellt:
|
||||
|
||||
| Kanal | Geeignet für | Einordnung |
|
||||
|---|---|---|
|
||||
| **Stable** | Normaler Contestbetrieb | Veröffentlichte und für den regulären Einsatz vorgesehene Version |
|
||||
| **Beta** | Gezielte Tests vor einem Stable-Release | Vorabversion mit weitgehend festgelegtem Funktionsumfang |
|
||||
| **Nightly** | Frühe Tests neuer Funktionen | Aktueller Entwicklungsstand aus dem `main`-Branch |
|
||||
|
||||
Für den normalen Einsatz wird die **Stable-Version** empfohlen.
|
||||
|
||||
Beta- und Nightly-Versionen können Funktionen enthalten, die im Stable-Release noch nicht verfügbar sind. Sie können aber ebenso unfertige Bedienabläufe, geänderte Einstellungen oder neue Fehler enthalten. Das ist kein ungewöhnlicher Defekt im Veröffentlichungsverfahren, sondern der Zweck eines Entwicklungskanals.
|
||||
|
||||
Wenn in diesem Manual eine Funktion ausdrücklich mit **Nightly** gekennzeichnet ist, gehört sie noch nicht zwingend zum aktuellen Stable-Release.
|
||||
Bei starkem Chat-Verkehr (5–6 Nachrichten pro Sekunde im Contest) gehen öffentliche Nachrichten, die an ein bestimmtes Rufzeichen gerichtet sind, leicht unter. KST4Contest fängt solche Nachrichten aber auch dann ab, wenn sie fälschlicherweise öffentlich gepostet werden (siehe [Funktionen – PM-Abfang](Funktionen#catching-personal-messages)).
|
||||
|
||||
---
|
||||
|
||||
## Download
|
||||
|
||||
Die aktuelle Stable-Version ist hier verfügbar:
|
||||
### Windows
|
||||
|
||||
- [Aktuelles KST4Contest-Release](https://github.com/praktimarc/kst4contest/releases/latest)
|
||||
- [Alle veröffentlichten Versionen](https://github.com/praktimarc/kst4contest/releases)
|
||||
Die aktuelle Version kann als ZIP-Datei heruntergeladen werden:
|
||||
|
||||
Die Release-Seite enthält die Programmpakete sowie die deutschen und englischen PDF-Handbücher.
|
||||
**https://github.com/praktimarc/kst4contest/releases/latest**
|
||||
|
||||
### Welches Paket wird benötigt?
|
||||
Der Dateiname hat das Format `praktiKST-v<Versionsnummer>-windows-x64.zip `.
|
||||
|
||||
| Betriebssystem | Paket | Typischer Dateiname |
|
||||
|---|---|---|
|
||||
| Windows x64 | ZIP-Paket | `praktiKST-v<Version>-windows-x64.zip` |
|
||||
| Linux x86_64 | AppImage | `KST4Contest-v<Version>-linux-x86_64.AppImage` |
|
||||
| Debian/Ubuntu amd64 | DEB-Paket | `KST4Contest-v<Version>-debian-amd64.deb` |
|
||||
| Fedora/RPM x86_64 | RPM-Paket | `KST4Contest-v<Version>-fedora-x86_64.rpm` |
|
||||
| Arch Linux x86_64 | Arch-Paket | `KST4Contest-v<Version>-archlinux-x86_64.pkg.tar.zst` |
|
||||
| Linux mit Flatpak | Flatpak-Referenz | `de.x08.KST4Contest.flatpakref` |
|
||||
| macOS Apple Silicon | DMG für ARM64 | `KST4Contest-v<Version>-macos-arm64.dmg` |
|
||||
| macOS Intel | DMG für x86_64 | `KST4Contest-v<Version>-macos-x86_64.dmg` |
|
||||
### Linux
|
||||
|
||||
Die aktuelle Version kann als AppImage heruntergeladen werden:
|
||||
|
||||
**https://github.com/praktimarc/kst4contest/releases/latest**
|
||||
|
||||
Der Dateiname hat das Format `KST4Contest-v<Versionsnummer>-linux-x86_64.AppImage`.
|
||||
|
||||
### macOS
|
||||
|
||||
> ⚠️ **Best-Effort-Support:** macOS-Builds werden als zusätzliche Option bereitgestellt, sind aber **nicht umfassend getestet**. Wir bauen und veröffentlichen macOS-Binaries mit jedem Release, können allerdings nicht alle Szenarien unter macOS testen. Bei Problemen freuen wir uns über eine Rückmeldung – wir versuchen unser Bestes, können aber nicht den gleichen Support-Umfang wie für Windows und Linux garantieren.
|
||||
|
||||
Die aktuelle Version kann als DMG-Disk-Image heruntergeladen werden (für Apple-Silicon- und Intel-Macs verfügbar):
|
||||
|
||||
**https://github.com/praktimarc/kst4contest/releases/latest**
|
||||
|
||||
Der Dateiname hat das Format `KST4Contest-v<Versionsnummer>-macos-<Architektur>.dmg`, wobei `<Architektur>` entweder `arm64` (Apple Silicon) oder `x86_64` (Intel) ist.
|
||||
|
||||
Lade Programmpakete nur aus den offiziellen GitHub Releases, dem KST4Contest-Flatpak-Repository oder den verlinkten AUR-Paketen herunter. Dateien aus anderen Quellen können anders gebaut, veraltet oder verändert worden sein.
|
||||
|
||||
---
|
||||
|
||||
## Installation unter Windows
|
||||
## Installation
|
||||
|
||||
KST4Contest wird unter Windows als ZIP-Paket bereitgestellt. Ein klassischer Installer ist nicht erforderlich.
|
||||
### Windows
|
||||
|
||||
1. Lade `praktiKST-v<Version>-windows-x64.zip` aus dem aktuellen Release herunter.
|
||||
2. Entpacke die ZIP-Datei vollständig in einen eigenen Ordner.
|
||||
3. Öffne den entpackten Ordner.
|
||||
4. Starte `praktiKST.exe`.
|
||||
1. ZIP-Datei herunterladen.
|
||||
2. ZIP-Datei in einen gewünschten Ordner entpacken.
|
||||
3. `praktiKST.exe` ausführen.
|
||||
|
||||
Starte das Programm nicht direkt aus der noch komprimierten ZIP-Datei. KST4Contest besteht aus mehreren Dateien und einer mitgelieferten Laufzeitumgebung. Windows kann diese Struktur nur zuverlässig verwenden, wenn das Archiv vorher vollständig entpackt wurde.
|
||||
Die Einstellungen werden unter `%USERPROFILE%\.praktikst\preferences.xml` gespeichert.
|
||||
|
||||
Die Programmeinstellungen befinden sich nicht im entpackten Programmordner, sondern im Benutzerverzeichnis:
|
||||
### Linux
|
||||
1. AppImage herunterladen.
|
||||
2. AppImage in gewünschten Ordner entpacken.
|
||||
3. AppImage ausführbar machen (geht im Terminal mit `chmod +x KST4Contest-v<Versionsnummer>-linux-x86_64.AppImage`)
|
||||
4. AppImage ausführen.
|
||||
|
||||
```text
|
||||
%USERPROFILE%\.praktiKST\preferences.xml
|
||||
```
|
||||
Die Einstellungen werden unter `~/.praktikst/preferences.xml` gespeichert.
|
||||
|
||||
Dadurch können neue Programmversionen in einen anderen Ordner entpackt werden, ohne dass die vorhandenen Einstellungen verloren gehen.
|
||||
### macOS
|
||||
1. DMG-Datei für die eigene Architektur herunterladen (Apple Silicon oder Intel).
|
||||
2. DMG-Datei öffnen.
|
||||
3. `KST4Contest.app` in den **Programme**-Ordner ziehen.
|
||||
4. Beim ersten Start zeigt macOS ggf. eine Warnung, da die App nicht notarisiert ist. Zum Öffnen:
|
||||
- Rechtsklick (oder Ctrl-Klick) auf `KST4Contest.app` im Finder → **Öffnen** wählen.
|
||||
- Alternativ: **Systemeinstellungen → Datenschutz & Sicherheit** → **Trotzdem öffnen** klicken.
|
||||
5. KST4Contest aus dem Programme-Ordner oder dem Launchpad starten.
|
||||
|
||||
Die Einstellungen werden unter `~/.praktikst/preferences.xml` gespeichert.
|
||||
|
||||
---
|
||||
|
||||
## Installation unter Linux
|
||||
## Update
|
||||
|
||||
Unter Linux stehen mehrere Paketformate zur Verfügung. Welches davon sinnvoll ist, hängt weniger von KST4Contest als von der verwendeten Distribution und der gewünschten Update-Methode ab.
|
||||
KST4Contest enthält einen **automatischen Update-Hinweis-Dienst**: Sobald eine neue Version verfügbar ist, erscheint beim Start ein Fenster mit:
|
||||
- der Information, dass eine neue Version vorliegt,
|
||||
- einem Changelog,
|
||||
- dem Download-Link zur neuen Version.
|
||||
|
||||
| Installationsart | Sinnvoll, wenn … |
|
||||
|---|---|
|
||||
| **Flatpak** | Updates zentral verwaltet werden sollen und Flatpak bereits verwendet wird |
|
||||
| **AppImage** | KST4Contest ohne Installation als einzelne portable Datei gestartet werden soll |
|
||||
| **DEB/RPM** | die Paketverwaltung der Distribution verwendet werden soll |
|
||||
| **Arch-Paket/AUR** | Arch Linux, Manjaro oder EndeavourOS eingesetzt wird |
|
||||
|
||||
|
||||
### Flatpak
|
||||
### Update-Prozess
|
||||
|
||||
Flatpak ist für die meisten Linux-Anwender der einfachste Weg, KST4Contest installiert und aktualisierbar zu halten. Das KST4Contest-Repository ist GPG-signiert und enthält die Kanäle Stable, Beta und Nightly.
|
||||
#### Windows
|
||||
|
||||
#### Stable über die Release-Datei installieren
|
||||
Derzeit gibt es nur einen Weg zum Aktualisieren:
|
||||
|
||||
Lade `de.x08.KST4Contest.flatpakref` aus dem aktuellen Release herunter und öffne die Datei mit der Softwareverwaltung der verwendeten Desktop-Umgebung.
|
||||
1. Den alten Ordner löschen.
|
||||
2. Das neue ZIP entpacken.
|
||||
|
||||
Alternativ kann sie im Terminal installiert werden:
|
||||
Die Einstellungsdatei (`preferences.xml`) bleibt erhalten, da sie im Benutzerordner gespeichert ist – nicht im Programmordner.
|
||||
|
||||
```bash
|
||||
flatpak install ./de.x08.KST4Contest.flatpakref
|
||||
```
|
||||
#### Linux
|
||||
|
||||
#### KST4Contest-Repository hinzufügen
|
||||
Derzeit folgendermaßen:
|
||||
1. neues AppImage herunterladen
|
||||
2. neues AppImage ausführbar makieren
|
||||
3. (optional) altes AppImage löschen.
|
||||
|
||||
Das Repository muss nur einmal hinzugefügt werden:
|
||||
#### macOS
|
||||
|
||||
```bash
|
||||
flatpak remote-add --if-not-exists kst4contest \
|
||||
https://praktimarc.github.io/kst4contest/kst4contest.flatpakrepo
|
||||
```
|
||||
1. Neue DMG-Datei herunterladen.
|
||||
2. DMG öffnen.
|
||||
3. Die neue `KST4Contest.app` in den **Programme**-Ordner ziehen und die alte Version ersetzen.
|
||||
|
||||
Anschließend kann die Stable-Version installiert werden:
|
||||
|
||||
```bash
|
||||
flatpak install kst4contest de.x08.KST4Contest//stable
|
||||
```
|
||||
|
||||
#### Beta installieren
|
||||
|
||||
```bash
|
||||
flatpak install kst4contest de.x08.KST4Contest//beta
|
||||
```
|
||||
|
||||
#### Nightly installieren
|
||||
|
||||
```bash
|
||||
flatpak install kst4contest de.x08.KST4Contest//nightly
|
||||
```
|
||||
|
||||
KST4Contest verwendet für alle drei Kanäle dieselbe App-ID. Eine parallele Installation mehrerer KST4Contest-Kanäle ist deshalb nicht vorgesehen.
|
||||
|
||||
Zum Wechsel von Stable auf Nightly beispielsweise:
|
||||
|
||||
```bash
|
||||
flatpak uninstall de.x08.KST4Contest//stable
|
||||
flatpak install kst4contest de.x08.KST4Contest//nightly
|
||||
```
|
||||
|
||||
Die persönlichen Einstellungen im Verzeichnis `~/.praktiKST` werden dabei nicht automatisch gelöscht.
|
||||
|
||||
Installierte Flatpak-Anwendungen können mit folgendem Befehl aktualisiert werden:
|
||||
|
||||
```bash
|
||||
flatpak update de.x08.KST4Contest
|
||||
```
|
||||
|
||||
Je nach Desktop-Umgebung kann die grafische Softwareverwaltung verfügbare Flatpak-Updates ebenfalls anzeigen oder automatisch installieren. Der Befehl `flatpak update` selbst führt das Update aus; er verspricht nicht, irgendwann von allein vorbeizukommen.
|
||||
|
||||
### AppImage
|
||||
|
||||
Das AppImage benötigt keine klassische Installation.
|
||||
|
||||
1. Lade `KST4Contest-v<Version>-linux-x86_64.AppImage` herunter.
|
||||
2. Öffne ein Terminal im Download-Verzeichnis.
|
||||
3. Mache die Datei ausführbar:
|
||||
|
||||
```bash
|
||||
chmod +x KST4Contest-v<Version>-linux-x86_64.AppImage
|
||||
```
|
||||
|
||||
4. Starte KST4Contest:
|
||||
|
||||
```bash
|
||||
./KST4Contest-v<Version>-linux-x86_64.AppImage
|
||||
```
|
||||
|
||||
Das AppImage kann anschließend an einen anderen Ort verschoben werden, beispielsweise nach `~/Applications`.
|
||||
|
||||
### Debian und Ubuntu
|
||||
|
||||
Installiere das DEB-Paket mit:
|
||||
|
||||
```bash
|
||||
sudo apt install ./KST4Contest-v<Version>-debian-amd64.deb
|
||||
```
|
||||
|
||||
Alternativ kann die Datei in einer grafischen Paketverwaltung geöffnet werden.
|
||||
|
||||
### Fedora und kompatible RPM-Systeme
|
||||
|
||||
Installiere das RPM-Paket mit:
|
||||
|
||||
```bash
|
||||
sudo dnf install ./KST4Contest-v<Version>-fedora-x86_64.rpm
|
||||
```
|
||||
|
||||
### Arch Linux: fertiges Release-Paket
|
||||
|
||||
Das aus dem GitHub Release heruntergeladene Arch-Paket kann direkt installiert werden:
|
||||
|
||||
```bash
|
||||
sudo pacman -U KST4Contest-v<Version>-archlinux-x86_64.pkg.tar.zst
|
||||
```
|
||||
|
||||
### Arch Linux: Installation über den AUR
|
||||
|
||||
Im AUR stehen drei Varianten bereit:
|
||||
|
||||
| Paket | Inhalt |
|
||||
|---|---|
|
||||
| [`kst4contest-bin`](https://aur.archlinux.org/packages/kst4contest-bin) | Vorgefertigtes Paket des aktuellen Stable-Releases |
|
||||
| [`kst4contest`](https://aur.archlinux.org/packages/kst4contest) | Stable-Release, das lokal aus dem Quellcode gebaut wird |
|
||||
| [`kst4contest-git`](https://aur.archlinux.org/packages/kst4contest-git) | Aktueller Entwicklungsstand aus dem `main`-Branch |
|
||||
|
||||
Für die meisten Anwender ist `kst4contest-bin` die naheliegende Variante:
|
||||
|
||||
```bash
|
||||
yay -S kst4contest-bin
|
||||
```
|
||||
|
||||
Stable aus dem Quellcode bauen:
|
||||
|
||||
```bash
|
||||
yay -S kst4contest
|
||||
```
|
||||
|
||||
Aktuellen Entwicklungsstand bauen:
|
||||
|
||||
```bash
|
||||
yay -S kst4contest-git
|
||||
```
|
||||
|
||||
Die drei Pakete stellen dieselbe Anwendung bereit und sind deshalb als gegenseitige Konflikte definiert. Installiere nur eine Variante gleichzeitig.
|
||||
|
||||
AUR-Updates werden berücksichtigt, wenn der verwendete AUR-Helper nach Paketaktualisierungen sucht, beispielsweise mit:
|
||||
|
||||
```bash
|
||||
yay -Syu
|
||||
```
|
||||
|
||||
Sie erfolgen nicht allein deshalb automatisch, weil das Paket aus dem AUR stammt.
|
||||
|
||||
---
|
||||
|
||||
## Installation unter macOS
|
||||
## Bekannte Probleme beim Start
|
||||
|
||||
> **Best-Effort-Support:** Die macOS-Pakete werden zusammen mit den übrigen Releases gebaut, aber nicht in demselben Umfang getestet wie die Windows- und Linux-Versionen. Rückmeldungen sind willkommen; eine vollständig geprüfte Unterstützung aller macOS-Versionen und Hardwarevarianten kann derzeit jedoch nicht zugesagt werden.
|
||||
### Norton 360
|
||||
|
||||
Für Apple-Silicon-Macs wird das Paket mit `arm64` benötigt. Für Intel-Macs ist das Paket mit `x86_64` vorgesehen.
|
||||
Norton 360 stuft `praktiKST.exe` als gefährlich ein (Fehlalarm). Es muss eine Ausnahme für die Datei eingerichtet werden:
|
||||
|
||||
1. Lade die passende DMG-Datei herunter.
|
||||
2. Öffne die DMG-Datei.
|
||||
3. Ziehe `KST4Contest.app` in den Ordner **Programme**.
|
||||
4. Starte KST4Contest aus dem Programme-Ordner oder über das Launchpad.
|
||||
1. Norton 360 öffnen.
|
||||
2. Sicherheit → Verlauf → Das entsprechende Ereignis suchen.
|
||||
3. „Wiederherstellen & Ausnahme hinzufügen" wählen.
|
||||
|
||||
Ab Version 1.42 sind die macOS-Pakete mit einer Apple Developer ID signiert und von Apple notarisiert. Der erste Start funktioniert damit per Doppelklick, ohne Umweg über das Kontextmenü und ohne Sicherheitsabfrage. Das Notarisierungsticket liegt in der DMG-Datei selbst, sodass die Prüfung auch ohne Internetverbindung gelingt.
|
||||
|
||||
Wer nachsehen möchte, ob ein heruntergeladenes Paket wirklich signiert ist, kann das im Terminal prüfen:
|
||||
|
||||
```bash
|
||||
spctl --assess --type open --context context:primary-signature -v KST4Contest-v<Version>-macos-arm64.dmg
|
||||
```
|
||||
|
||||
Erwartet wird `accepted` zusammen mit `source=Notarized Developer ID`.
|
||||
|
||||
### Versionen bis einschließlich 1.41.1
|
||||
|
||||
Ältere Pakete sind nicht notarisiert. macOS blockiert den ersten Start deshalb.
|
||||
|
||||
Falls die Anwendung aus dem offiziellen GitHub Release stammt:
|
||||
|
||||
1. Öffne den Programme-Ordner im Finder.
|
||||
2. Klicke mit der rechten Maustaste oder mit gedrückter Ctrl-Taste auf `KST4Contest.app`.
|
||||
3. Wähle **Öffnen**.
|
||||
4. Bestätige den Start im angezeigten Dialog.
|
||||
|
||||
Alternativ kann macOS unter **Systemeinstellungen → Datenschutz & Sicherheit** die Schaltfläche **Trotzdem öffnen** anbieten.
|
||||
|
||||
---
|
||||
|
||||
## Wo werden die Einstellungen gespeichert?
|
||||
|
||||
KST4Contest speichert seine Einstellungen und weitere lokale Arbeitsdateien im Benutzerverzeichnis. Der Programmordner und das Datenverzeichnis sind voneinander getrennt.
|
||||
|
||||
| Betriebssystem | Datenverzeichnis | Einstellungsdatei |
|
||||
|---|---|---|
|
||||
| Windows | `%USERPROFILE%\.praktiKST\` | `%USERPROFILE%\.praktiKST\preferences.xml` |
|
||||
| Linux | `~/.praktiKST/` | `~/.praktiKST/preferences.xml` |
|
||||
| macOS | `~/.praktiKST/` | `~/.praktiKST/preferences.xml` |
|
||||
|
||||
Beachte die Schreibweise `.praktiKST` mit großem `KST`. Unter Linux und macOS wird zwischen Groß- und Kleinschreibung unterschieden. `.praktikst` wäre dort schlicht ein anderes Verzeichnis.
|
||||
|
||||
Ein Programmupdate entfernt dieses Verzeichnis nicht. Trotzdem ist es sinnvoll, vor größeren Versionswechseln oder umfangreichen Änderungen an der Konfiguration eine Sicherung davon anzulegen.
|
||||
|
||||
---
|
||||
|
||||
## Updates
|
||||
|
||||
KST4Contest prüft beim Start, ob ein neueres Stable-Release verfügbar ist. Wenn eine neuere Version gefunden wird, erscheint ein Informationsfenster mit:
|
||||
|
||||
- der installierten Version,
|
||||
- der aktuellen Stable-Version,
|
||||
- einer kurzen Übersicht wesentlicher Änderungen,
|
||||
- dem Changelog,
|
||||
- bekannten Problemen,
|
||||
- einem Link zur passenden GitHub-Release-Seite.
|
||||
|
||||
|
||||
|
||||
Der Update-Checker installiert nichts selbst. Er informiert über die neue Version und öffnet die plattformneutrale Release-Seite. Dort muss das passende Paket für Windows, Linux oder macOS ausgewählt werden.
|
||||
|
||||
### Windows aktualisieren
|
||||
|
||||
1. Beende KST4Contest.
|
||||
2. Lade das neue Windows-ZIP herunter.
|
||||
3. Entpacke es in einen neuen oder leeren Ordner.
|
||||
4. Starte die neue Version.
|
||||
5. Prüfe, ob die bisherigen Einstellungen geladen wurden.
|
||||
6. Entferne den alten Programmordner erst danach.
|
||||
|
||||
Die Einstellungen bleiben erhalten, weil sie unter `%USERPROFILE%\.praktiKST` und nicht im Programmordner gespeichert werden.
|
||||
|
||||
### AppImage aktualisieren
|
||||
|
||||
1. Lade das neue AppImage herunter.
|
||||
2. Mache es ausführbar.
|
||||
3. Starte die neue Datei.
|
||||
4. Entferne das bisherige AppImage erst, wenn die neue Version funktioniert.
|
||||
|
||||
### Debian und Ubuntu aktualisieren
|
||||
|
||||
```bash
|
||||
sudo apt install ./KST4Contest-v<Version>-debian-amd64.deb
|
||||
```
|
||||
|
||||
### Fedora aktualisieren
|
||||
|
||||
```bash
|
||||
sudo dnf upgrade ./KST4Contest-v<Version>-fedora-x86_64.rpm
|
||||
```
|
||||
|
||||
### Arch-Paket aktualisieren
|
||||
|
||||
```bash
|
||||
sudo pacman -U KST4Contest-v<Version>-archlinux-x86_64.pkg.tar.zst
|
||||
```
|
||||
|
||||
### AUR-Paket aktualisieren
|
||||
|
||||
Aktualisiere das installierte Paket über den verwendeten AUR-Helper, beispielsweise:
|
||||
|
||||
```bash
|
||||
yay -Syu
|
||||
```
|
||||
|
||||
### Flatpak aktualisieren
|
||||
|
||||
```bash
|
||||
flatpak update de.x08.KST4Contest
|
||||
```
|
||||
|
||||
### macOS aktualisieren
|
||||
|
||||
1. Lade die neue DMG-Datei für die vorhandene Architektur herunter.
|
||||
2. Beende KST4Contest.
|
||||
3. Öffne die DMG-Datei.
|
||||
4. Ersetze `KST4Contest.app` im Programme-Ordner.
|
||||
5. Starte die neue Version und prüfe die vorhandenen Einstellungen.
|
||||
|
||||
Die Konfiguration unter `~/.praktiKST` bleibt davon unberührt.
|
||||
|
||||
---
|
||||
|
||||
## Probleme beim ersten Start
|
||||
|
||||
### Windows meldet eine unbekannte Anwendung
|
||||
|
||||
KST4Contest ist derzeit nicht mit einem kommerziellen Windows-Code-Signing-Zertifikat signiert. Windows oder ein zusätzlich installiertes Sicherheitsprodukt kann deshalb vor einer unbekannten oder selten heruntergeladenen Anwendung warnen.
|
||||
|
||||
Prüfe in diesem Fall zuerst:
|
||||
|
||||
- Stammt die Datei aus dem [offiziellen KST4Contest-Release](https://github.com/praktimarc/kst4contest/releases/latest)?
|
||||
- Passt der Dateiname zum veröffentlichten Release?
|
||||
- Wurde die Datei vollständig heruntergeladen?
|
||||
- Nennt das Sicherheitsprogramm einen konkreten Erkennungsnamen oder nur eine allgemeine Reputationswarnung?
|
||||
|
||||
Ein Warnhinweis ist allein weder ein sicherer Beweis für Schadsoftware noch automatisch ein Fehlalarm. Wenn die Herkunft der Datei unklar ist, sollte sie nicht gestartet oder aus der Quarantäne wiederhergestellt werden.
|
||||
|
||||
Einige Anwender haben insbesondere Quarantäne-Meldungen von Norton 360 gemeldet. Wenn sich eine Meldung reproduzieren lässt, erstelle bitte einen [GitHub-Issue](https://github.com/praktimarc/kst4contest/issues) und nenne:
|
||||
|
||||
- die KST4Contest-Version,
|
||||
- den vollständigen Dateinamen,
|
||||
- das verwendete Sicherheitsprodukt und dessen Version,
|
||||
- den angezeigten Erkennungsnamen,
|
||||
- möglichst einen Screenshot der Meldung.
|
||||
|
||||
### Das AppImage startet nicht
|
||||
|
||||
Prüfe zuerst das Ausführungsrecht:
|
||||
|
||||
```bash
|
||||
chmod +x KST4Contest-v<Version>-linux-x86_64.AppImage
|
||||
```
|
||||
|
||||
Starte die Datei anschließend aus einem Terminal. Fehlermeldungen sind dort meist aussagekräftiger als ein Doppelklick, der lediglich nichts Sichtbares tut.
|
||||
|
||||
### macOS blockiert die Anwendung
|
||||
|
||||
Ab Version 1.42 sollte das nicht mehr vorkommen, da die Pakete signiert und notarisiert sind. Tritt die Blockade trotzdem auf, ist die DMG-Datei meist unvollständig heruntergeladen oder nachträglich verändert worden. Lade sie in dem Fall erneut aus dem offiziellen GitHub Release.
|
||||
|
||||
Bei älteren Versionen ist die Blockade zu erwarten. Verwende dort die unter [Installation unter macOS](#installation-unter-macos) beschriebene Funktion **Öffnen** im Kontextmenü.
|
||||
|
||||
### Das Problem bleibt bestehen
|
||||
|
||||
Prüfe zunächst, ob das Problem bereits unter [GitHub Issues](https://github.com/praktimarc/kst4contest/issues) beschrieben wurde. Falls nicht, erstelle einen neuen Issue mit:
|
||||
|
||||
- Betriebssystem und Version,
|
||||
- verwendeter KST4Contest-Version,
|
||||
- Installationsart,
|
||||
- genauer Fehlermeldung,
|
||||
- den Schritten, mit denen sich das Problem reproduzieren lässt.
|
||||
|
||||
„Geht nicht“ beschreibt den Zustand meistens korrekt, hilft bei der Fehlersuche aber nur begrenzt.
|
||||
*(Gemeldet von PE0WGA, Franz van Velzen – danke!)*
|
||||
|
||||
+62
-746
@@ -25,83 +25,31 @@ Eigenes Rufzeichen und Maidenhead-Locator (6-stellig, z. B. `JN49IJ`) eintragen.
|
||||
|
||||
### Aktivierte Bänder
|
||||
|
||||
Über die Checkboxen **My station uses …** wird festgelegt, auf welchen Bändern die eigene Station im aktuellen Setup arbeiten kann. Unterstützt werden 50 MHz, 70 MHz, 144 MHz, 432 MHz, 1296 MHz, 2320 MHz, 3400 MHz, 5760 MHz und 10 GHz.
|
||||
|
||||
Die Auswahl steuert nicht nur die sichtbaren Bandspalten. Sie wird außerdem verwendet für:
|
||||
|
||||
- die bandbezogenen Worked- und NOT-QRV-Filter,
|
||||
- die im **Further Info**-Bereich sichtbaren NOT-QRV-Schalter,
|
||||
- die Herleitung von `a`- und `B+`-Bandmöglichkeiten,
|
||||
- den Filter **New bands**,
|
||||
- den Band-Upgrade-Hinweis nach einem Logeintrag und
|
||||
- bandbezogene Prioritäts- und Reachability-Funktionen.
|
||||
|
||||
Nach einer Änderung **Save Settings** verwenden und KST4Contest neu starten. Die Bandspalten und mehrere zugehörige Bedienelemente werden beim Aufbau der Benutzeroberfläche erzeugt und deshalb nicht vollständig in der laufenden Sitzung ergänzt oder entfernt.
|
||||
Über die **„my station uses band"**-Checkboxen werden die aktiven Bänder ausgewählt. Nur für ausgewählte Bänder erscheinen Schaltflächen und Tabellenzeilen in der Benutzeroberfläche. Nach Änderungen muss die Software neu gestartet werden.
|
||||
|
||||
### Antennen-Öffnungswinkel (Antenna Beamwidth)
|
||||
|
||||
Trage den vollständigen horizontalen Öffnungswinkel der eigenen Antenne in Grad ein. KST4Contest verwendet jeweils die Hälfte dieses Werts links und rechts der gewählten beziehungsweise hergeleiteten Antennenrichtung. Ein eingetragener Wert von `70°` entspricht daher einem Korridor von `±35°`.
|
||||
Einen realistischen Wert für den Öffnungswinkel der eigenen Antenne eintragen (in Grad). Dieser Wert wird für die [Sked-Richtungs-Hervorhebung](Funktionen#sked-richtungs-hervorhebung) verwendet. Ein Testwert von 50° hat sich bewährt; DM5M nutzt Quads mit 69°.
|
||||
|
||||
Der Wert wird an mehreren Stellen verwendet:
|
||||
|
||||
- für den QTF-Filter der Benutzerliste,
|
||||
- für die Darstellung des eigenen Antennenkorridors,
|
||||
- als angenommener Öffnungswinkel einer fremden Station bei der [Herleitung von Richtungsgelegenheiten](de-Funktionen#richtungsgelegenheiten-aus-gerichteten-nachrichten).
|
||||
|
||||
Der letzte Punkt ist bewusst eine Näherung. ON4KST überträgt weder die verwendete Antenne noch deren Öffnungswinkel. KST4Contest verwendet deshalb den eigenen Wert als praktikable Annahme für die Gegenstation.
|
||||
|
||||
Wähle einen realistischen Wert. Ein zu großer Öffnungswinkel erzeugt viele geometrische Treffer, die praktisch kaum noch eine Aussage haben. Ein zu kleiner Wert kann dagegen brauchbare Richtungsgelegenheiten ausblenden.
|
||||
> **Keinesfalls** Fantasy-Werte eintragen – die Richtungsberechnungen werden sonst unbrauchbar.
|
||||
|
||||
### Standard-Maximum-QRB
|
||||
|
||||
Trage die maximale Entfernung in Kilometern ein, innerhalb der KST4Contest Richtungsgelegenheiten berücksichtigen soll. Maßgeblich ist die Entfernung zwischen der eigenen Station und dem Absender der gerichteten Nachricht – nicht die Entfernung zwischen Absender und Empfänger.
|
||||
|
||||
Liegt der Absender weiter entfernt, wird die Situation auch dann nicht hervorgehoben und nicht als Richtungsgelegenheit an den lokalen DX-Cluster-Server weitergegeben, wenn der berechnete Winkel passen würde.
|
||||
|
||||
Der Wert sollte zum eigenen Stationsaufbau und zum vorgesehenen Contestbetrieb passen. Ein unnötig großer Bereich erzeugt Hinweise für Stationen, die praktisch nicht mehr zum Arbeitsbereich gehören; ein zu kleiner Bereich blendet mögliche Kandidaten bereits vor der Richtungsbewertung aus.
|
||||
Maximale Entfernung (in km), für die Richtungs-Warnungen ausgelöst werden sollen. Realistischer Wert für DM5M: 900 km. Stationen, die weiter entfernt sind, werden für Highlighting-Zwecke ignoriert.
|
||||
|
||||
---
|
||||
|
||||
### Streckenanalyse und Link-Budget
|
||||
## Server-Einstellungen (ab v1.31)
|
||||
|
||||
Die Stationskarte verwendet mehrere Werte aus dem Reiter **Station**, um das Geländeprofil und das Link-Budget zur ausgewählten Gegenstation zu berechnen. Die Angaben zum eigenen Stationsaufbau sollten deshalb möglichst realistisch sein. Bei der Gegenstation handelt es sich dagegen um globale Annahmen, solange keine genaueren Daten vorliegen.
|
||||
Der Chat-Server-DNS und -Port sind in den Preferences konfigurierbar:
|
||||
|
||||
| Einstellung | Verwendung |
|
||||
|---|---|
|
||||
| **Own antenna height AGL** | Höhe der eigenen Antenne über dem lokalen Gelände in Metern |
|
||||
| **Own TX power W** | Eigene Sendeleistung in Watt |
|
||||
| **Own ant. gain dBi** | Gewinn der eigenen Antenne in dBi |
|
||||
| **DX OM TX power W** | Angenommene Sendeleistung der Gegenstation in Watt |
|
||||
| **DX OM ant. gain dBi** | Angenommener Antennengewinn der Gegenstation in dBi |
|
||||
- **Server-DNS**: Standard `www.on4kst.org` (ab v1.31 geändert von `www.on4kst.info`).
|
||||
- **Port**: Standardport des ON4KST-Servers.
|
||||
|
||||
**AGL** bedeutet *Above Ground Level*. Trage hier nicht die Höhe über dem Meeresspiegel ein. Die Geländehöhe am eigenen Standort stammt bereits aus dem Höhenprofil; KST4Contest addiert die konfigurierte Antennenhöhe zu diesem Wert.
|
||||
|
||||
Für die Gegenstation verwendet KST4Contest derzeit eine feste Antennenhöhe von 10 Metern über dem lokalen Gelände. Sendeleistung und Antennengewinn der Gegenstation stammen aus den beiden **DX OM**-Feldern. Diese Werte sind bewusst nur Annahmen: Der ON4KST-Chat überträgt weder die tatsächliche Antennenhöhe noch die vollständigen Stationsdaten der Gegenstation.
|
||||
|
||||
Antennengewinne müssen in `dBi` eingetragen werden. Liegt ein Wert in `dBd` vor, muss vor der Eingabe `2.15 dB` addiert werden:
|
||||
|
||||
```text
|
||||
dBi = dBd + 2.15 dB
|
||||
```
|
||||
|
||||
Die aktuelle QTF, der konfigurierte Antennen-Öffnungswinkel und das Standard-Maximum-QRB beeinflussen die Darstellung der Stationskarte. Die für die eigene Station aktivierten Bänder und die für die Gegenstation hergeleitete Frequenz wirken sich zusätzlich auf die Auswahl der Analysefrequenz aus.
|
||||
|
||||
Für das Geländeprofil berücksichtigt KST4Contest die Antennenhöhen, das Höhenmodell und die Erdkrümmung mit einem festen effektiven Erdradiusfaktor von `k = 4/3`. Das Link-Budget verwendet außerdem:
|
||||
|
||||
- die Entfernung und die aktuelle Analysefrequenz,
|
||||
- die Sendeleistungen und Antennengewinne beider Stationen,
|
||||
- frequenzabhängig geschätzte Speiseleitungsverluste,
|
||||
- die Freiraumdämpfung und
|
||||
- eine grobe zusätzliche Dämpfung durch das maßgebliche Hindernis im Geländeprofil.
|
||||
|
||||
Die Berechnung erfolgt für beide Übertragungsrichtungen. Für die gemeinsame SSB- beziehungsweise CW-Marge ist die ungünstigere Richtung maßgeblich. Zu optimistische Leistungs- oder Antennenwerte verbessern daher zwar das angezeigte Ergebnis, nicht aber den realen Funkweg.
|
||||
|
||||
Die Werte bleiben technische Abschätzungen. Aktuelle Ausbreitungsbedingungen, lokale Abschattungen, Bewuchs, Gebäude, Störungen und nicht bekannte Stationsparameter können das tatsächliche Ergebnis deutlich verändern. Bedienung, Frequenzauswahl und Grenzen der Berechnung sind unter [Stationskarte und Streckenanalyse](de-Funktionen#stationskarte-und-streckenanalyse-ab-v141) beschrieben.
|
||||
Eine Änderung ist nur notwendig, wenn der Server umzieht oder ein alternativer Endpunkt genutzt wird.
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
## Log-Sync-Einstellungen
|
||||
|
||||
Drei Methoden stehen zur Verfügung, um gearbeitete Stationen automatisch zu markieren. Details: [Log-Synchronisation](de-Log-Synchronisation).
|
||||
@@ -122,750 +70,118 @@ Dedizierter Netzwerk-Erkenner für Win-Test. KST4Contest empfängt und verarbeit
|
||||
|
||||
## TRX-Sync-Einstellungen
|
||||
|
||||
Die TRX-Synchronisation übernimmt die aktuelle Frequenz aus dem Logprogramm und stellt sie in KST4Contest als eigene QRG der ersten Chat-Kategorie bereit. QSO- und Frequenzsynchronisation verwenden teilweise denselben UDP-Empfänger, sind funktional aber voneinander getrennt: Ein empfangenes `RadioInfo`-Paket markiert keine Station als gearbeitet, und ein QSO-Paket ändert nicht automatisch die eigene QRG.
|
||||
Empfängt die aktuelle Frequenz des Transceivers vom Logprogramm via UDP. Ermöglicht die automatische Befüllung der Variable `MYQRG`. Nützlich für:
|
||||
|
||||
|
||||
- Schnelles Einfügen der eigenen QRG in Chat-Nachrichten.
|
||||
- Automatische CQ-Baken mit aktueller Frequenz.
|
||||
|
||||
### Verfügbare QRG-Quellen
|
||||
|
||||
| Quelle | Aktivierung | Verhalten |
|
||||
|---|---|---|
|
||||
| **Allgemeiner RadioInfo-Listener** | `Update MYQRG from RadioInfo messages received on the shared log-sync port` | Verarbeitet kompatible `RadioInfo`-Pakete auf dem gemeinsam mit der QSO-Synchronisation verwendeten UDP-Port. Der Standardport ist `12060`. |
|
||||
| **Win-Test STATUS** | `Win-Test STATUS QRG Sync` | Verarbeitet die Haupt- oder Pass-Frequenz aus nativen Win-Test-`STATUS`-Paketen. Der Win-Test-Listener verwendet seinen separat konfigurierten Port, standardmäßig `9871`. |
|
||||
| **Manuelle Eingabe** | Beide automatischen QRG-Quellen deaktivieren | Die eigene QRG kann im Hauptfenster von Hand eingetragen werden. |
|
||||
|
||||
Der allgemeine Listener ist für Logprogramme vorgesehen, die kompatible `RadioInfo`-Pakete senden. Dazu gehören – abhängig von deren jeweiliger Konfiguration – UCXLog, N1MM+, QARTest und DXLog.net. QSO- und `RadioInfo`-Pakete verwenden denselben unter **Log sync** konfigurierten Port. Dort wird jedoch getrennt festgelegt, ob KST4Contest QSO-Informationen, TRX-Informationen oder beide Paketarten verarbeitet.
|
||||
|
||||
Wird der gemeinsame UDP-Port geändert, muss KST4Contest neu gestartet werden. Eine reine Änderung der Checkboxen wird dagegen sofort berücksichtigt.
|
||||
|
||||
### Welche QRG wird aktualisiert?
|
||||
|
||||
Beide automatischen Quellen aktualisieren ausschließlich `MYQRG`. Das ist die eigene QRG der ersten beziehungsweise primären Chat-Kategorie.
|
||||
|
||||
Bei aktiviertem zweiten Chat bleibt dessen QRG davon unabhängig. Sie wird nicht aus den empfangenen TRX-Paketen abgeleitet und steht als `SECONDQRG` zur Verfügung. Dadurch kann beispielsweise die erste Kategorie automatisch der Frequenz des Logprogramms folgen, während für die zweite Kategorie eine eigene QRG von Hand eingetragen wird.
|
||||
|
||||
Sobald mindestens eine automatische QRG-Quelle aktiviert ist, wird das QRG-Feld der ersten Kategorie im Hauptfenster an den empfangenen Wert gebunden. Eine manuelle Eingabe in dieses Feld ist wieder möglich, wenn sowohl der allgemeine RadioInfo-Listener als auch die Win-Test-STATUS-Synchronisation deaktiviert sind.
|
||||
|
||||
### Haupt- oder Pass-Frequenz aus Win-Test
|
||||
|
||||
Standardmäßig verwendet KST4Contest die Hauptfrequenz des empfangenen Win-Test-`STATUS`-Pakets.
|
||||
|
||||
Die Option `Use pass frequency from Win-Test STATUS` verwendet stattdessen die im Paket enthaltene Pass-Frequenz. Das ist beispielsweise sinnvoll, wenn Win-Test im Split-Betrieb eine abweichende Frequenz führt und genau diese im Chat als Arbeitsfrequenz veröffentlicht werden soll.
|
||||
|
||||
Enthält das Paket keine gültige Pass-Frequenz, fällt KST4Contest automatisch auf die Hauptfrequenz zurück. Eine fehlende Pass-Frequenz löscht daher weder `MYQRG` noch ersetzt sie den Wert durch eine offensichtlich falsche Zahl.
|
||||
|
||||
Die Frequenzen werden einheitlich im KST4Contest-Format dargestellt, beispielsweise:
|
||||
|
||||
```text
|
||||
50.300.00
|
||||
144.300.00
|
||||
1296.100.00
|
||||
10368.100.00
|
||||
```
|
||||
|
||||
Die Werte werden erst beim Auflösen des Nachrichtentextes eingesetzt. Ändert das Logprogramm zwischen zwei Beacon-Läufen die Frequenz, verwendet die nächste Nachricht bereits den aktualisierten Wert.
|
||||
|
||||
Die eigene QRG kann außerdem als Fallback für die Übergabe eines Skeds an Win-Test verwendet werden. Das geschieht nur, wenn die QRG auswertbar ist und zum ausdrücklich ausgewählten Sked-Band gehört. Einzelheiten stehen unter [Log-Synchronisation](de-Log-Synchronisation#skeds-an-win-test-übergeben).
|
||||
|
||||
Weitere Informationen zu den Textvariablen: [Makros und Variablen](de-Makros-und-Variablen#variablen).
|
||||
|
||||
### Mehrere Logger oder Funkgeräte
|
||||
|
||||
Alle aktivierten QRG-Quellen schreiben in denselben Wert `MYQRG`. KST4Contest ordnet eingehende `RadioInfo`- oder `STATUS`-Pakete derzeit weder einem bestimmten Funkgerät noch einer Chat-Kategorie zu.
|
||||
|
||||
Sind der allgemeine RadioInfo-Listener und die Win-Test-Synchronisation gleichzeitig aktiviert, bestimmt deshalb das zuletzt verarbeitete Paket die angezeigte QRG. Dasselbe gilt, wenn mehrere Logger ihre Frequenzpakete an dieselbe KST4Contest-Instanz senden.
|
||||
|
||||
Für ein Setup mit mehreren Funkgeräten gilt daher:
|
||||
|
||||
- QSO-Pakete dürfen von mehreren Loggern empfangen werden.
|
||||
- Frequenzpakete sollten nur von der Quelle gesendet werden, die `MYQRG` tatsächlich steuern soll.
|
||||
- In einem Win-Test-Netzwerk sollte zusätzlich der Stationsfilter verwendet werden.
|
||||
- Werden zwei vollständig unabhängige QRG-Synchronisationen benötigt, sind zwei getrennte KST4Contest-Instanzen die eindeutigere Lösung.
|
||||
|
||||
Anders ausgedrückt: Mehrere Worked-Quellen lassen sich sinnvoll zusammenführen. Mehrere gleichzeitig sendende Frequenzquellen erzeugen dagegen keine zusätzliche Information, sondern lediglich einen Wettbewerb darum, welches Paket zuletzt angekommen ist.
|
||||
|
||||
Nach Abschluss der Konfiguration **Save Settings** verwenden.
|
||||
> **Hinweis für Multi-Setup**: Wenn zwei Logprogramme an zwei Computern betrieben werden, aber nur eine KST4Contest-Instanz, darf nur ein Logprogramm die Frequenzpakete senden. KST4Contest kann nicht zwischen den Quellen unterscheiden.
|
||||
|
||||
---
|
||||
|
||||
|
||||
## AirScout-Einstellungen
|
||||
|
||||
Im Reiter **AirScout** wird die UDP-Verbindung zwischen KST4Contest und AirScout eingerichtet. KST4Contest fordert dort keine allgemeinen Flugzeugdaten an, sondern übermittelt die aktuell relevanten Stationspfade. AirScout berechnet die dazu passenden Flugzeuge und sendet das Ergebnis an die anfragende KST4Contest-Instanz zurück.
|
||||
|
||||
Vorausgesetzt wird AirScout `0.9.9.5` oder neuer.
|
||||
|
||||
{ width=85% }
|
||||
|
||||
### Einstellungen der UDP-Verbindung
|
||||
|
||||
| Einstellung | Standardwert | Verwendung |
|
||||
|---|---:|---|
|
||||
| **Enable AirScout UDP integration** | deaktiviert | Aktiviert das Senden von AirScout-Anfragen und die Verarbeitung der Antworten |
|
||||
| **AirScout server identifier** | `AS` | Logischer Name der angesprochenen AirScout-Instanz |
|
||||
| **KST4Contest client identifier** | `KST` | Logischer Name dieser KST4Contest-Instanz |
|
||||
| **AirScout UDP port** | `9872` | Gemeinsamer UDP-Port für Anfragen und Antworten |
|
||||
| **Select AirScout frequency automatically per station** | aktiviert | Ermittelt Band und Frequenz für jede Gegenstation aus dem aktuellen Stationskontext |
|
||||
| **Forced AirScout band value** | `1440000` | Verwendet bei deaktivierter Automatik einen festen AirScout-Bandwert für alle Stationen |
|
||||
|
||||
Ist **Enable AirScout UDP integration** deaktiviert, sendet KST4Contest keine AirScout-Anfragen und verwirft eingehende AirScout-Antworten. Der UDP-Empfänger kann trotzdem gebunden bleiben, damit sich die Funktion während einer laufenden Verbindung wieder einschalten lässt.
|
||||
|
||||
KST4Contest verwendet für ausgehende AirScout-Pakete die Broadcast-Adresse `255.255.255.255`. Eine Ziel-IP wird deshalb nicht separat konfiguriert. AirScout und KST4Contest müssen den verwendeten UDP-Broadcast empfangen können; Router leiten einen solchen Broadcast normalerweise nicht in ein anderes Netz weiter. Bei Problemen sollten daher zuerst der UDP-Port, die lokale Firewall und die Netzzuordnung geprüft werden.
|
||||
|
||||
### Automatische Bandauswahl pro Station
|
||||
|
||||
**Auto per station** ist die empfohlene Einstellung. KST4Contest verwendet dann nicht einen festen Bandwert für alle Gegenstationen, sondern leitet eine geeignete Frequenz aus den verfügbaren Informationen ab.
|
||||
|
||||
Die Quellen werden in folgender Reihenfolge ausgewertet:
|
||||
|
||||
1. die zuletzt erkannte, höchstens 30 Minuten alte QRG der Gegenstation,
|
||||
2. eine eindeutige vollständige QRG im Namensfeld eines aktiven Chat-Eintrags,
|
||||
3. eindeutige Bandangaben im Namensfeld,
|
||||
4. 432 MHz, wenn dieselbe Station gleichzeitig in der VHF/UHF- und Microwave-Kategorie aktiv ist und 432 MHz für die eigene Station aktiviert wurde,
|
||||
5. das niedrigste für die eigene Station aktivierte Band, das zur unterstützten Chat-Kategorie passt.
|
||||
|
||||
Aktive Chat-Varianten desselben Basisrufzeichens werden gemeinsam ausgewertet. Die Einträge `CALLSIGN`, `CALLSIGN-2` und `CALLSIGN-432` können dadurch gemeinsam zur Bandherleitung beitragen, bleiben für die Nachrichtenverarbeitung aber getrennte Chat-Teilnehmer.
|
||||
|
||||
Nur Bänder, die unter **My station uses …** aktiviert wurden, kommen für die automatische Auswahl infrage. Ein manuell gesetztes NOT-QRV-Kennzeichen schließt das betreffende Band aus und hat Vorrang vor automatisch erkannten QRG- oder Namensinformationen.
|
||||
|
||||
Unterstützt werden die Chat-Kategorien für 50/70 MHz, VHF/UHF, Microwave und EME/JT65. Andere ON4KST-Kategorien werden für die AirScout-Bandherleitung ignoriert. Kann keine ausreichend belastbare Frequenz bestimmt werden, sendet KST4Contest für diese Station keine Anfrage. Ein beliebiger Rückfall auf 144 MHz würde zwar ein syntaktisch vollständiges Paket erzeugen, aber nicht zwangsläufig eine sinnvolle Berechnung.
|
||||
|
||||
Die automatische AirScout-Auswahl verwendet dieselbe Herleitung wie die interne Streckenanalyse. Damit bewerten beide Funktionen den Stationspfad auf derselben fachlichen Grundlage.
|
||||
|
||||
### Festes AirScout-Band
|
||||
|
||||
Wird **Auto per station** deaktiviert, verwendet KST4Contest den unter **Forced AirScout band value** eingetragenen Wert für alle Stationen.
|
||||
|
||||
Der Wert wird in der von der AirScout-UDP-Schnittstelle verwendeten Einheit eingetragen:
|
||||
|
||||
| Band | AirScout-Wert |
|
||||
|---|---:|
|
||||
| 50 MHz | `500000` |
|
||||
| 70 MHz | `700000` |
|
||||
| 144 MHz | `1440000` |
|
||||
| 432 MHz | `4320000` |
|
||||
| 1296 MHz | `12960000` |
|
||||
| 2320 MHz | `23200000` |
|
||||
| 3400 MHz | `34000000` |
|
||||
| 5760 MHz | `57600000` |
|
||||
| 10368 MHz | `103680000` |
|
||||
| 24048 MHz | `240480000` |
|
||||
|
||||
Im festen Modus wird weder die zuletzt erkannte QRG noch das im Namen genannte Band der Gegenstation berücksichtigt. Diese Einstellung ist deshalb hauptsächlich für einen eindeutig auf ein Band begrenzten Stationsbetrieb oder zur Fehlersuche sinnvoll.
|
||||
|
||||
### Server- und Client-Identifier
|
||||
|
||||
Die Identifier gehören zum AirScout-Protokoll und sind keine DNS-Namen oder IP-Adressen.
|
||||
|
||||
Ausgehende Anfragen enthalten zunächst den Client- und anschließend den Server-Identifier:
|
||||
|
||||
```text
|
||||
"KST" "AS"
|
||||
```
|
||||
|
||||
AirScout antwortet in umgekehrter Reihenfolge:
|
||||
|
||||
```text
|
||||
"AS" "KST"
|
||||
```
|
||||
|
||||
KST4Contest verarbeitet eine Antwort nur, wenn beide Identifier exakt mit der aktuellen Konfiguration übereinstimmen. Der Vergleich unterscheidet zwischen Groß- und Kleinschreibung.
|
||||
|
||||
Die Identifier dürfen nicht leer sein und keine Anführungszeichen oder Zeilenumbrüche enthalten.
|
||||
|
||||
Werden mehrere KST4Contest-Instanzen im selben Netz betrieben, sollte jede einen eigenen Client-Identifier erhalten, beispielsweise:
|
||||
|
||||
```text
|
||||
KST-144
|
||||
KST-432
|
||||
```
|
||||
|
||||
Bei mehreren AirScout-Instanzen müssen zusätzlich unterschiedliche Server-Identifier verwendet werden. Dadurch wird verhindert, dass die Antwort für einen Arbeitsplatz von einer anderen KST4Contest-Instanz verarbeitet wird.
|
||||
|
||||
### Welche Stationen werden angefragt?
|
||||
|
||||
KST4Contest startet die erste periodische AirScout-Abfrage ungefähr zehn Sekunden nach dem Aufbau der Chat-Verbindung. Weitere Abfragen folgen im Abstand von 60 Sekunden.
|
||||
|
||||
Eine aktive Station wird nur berücksichtigt, wenn:
|
||||
|
||||
- ein verwendbares Rufzeichen vorhanden ist,
|
||||
- ein Locator vorhanden ist,
|
||||
- die Entfernung berechnet werden konnte,
|
||||
- die Entfernung kleiner als das konfigurierte **Maximum-QRB** ist und
|
||||
- ein verwendbares Band bestimmt werden konnte.
|
||||
|
||||
Mehrere aktive Chat-Einträge desselben Basisrufzeichens erzeugen nicht für jeden Suffix eine eigene identische Pfadberechnung. Die zurückgegebenen AirScout-Informationen werden anschließend wieder den passenden aktiven Chat-Varianten zugeordnet.
|
||||
|
||||
Die Auswahl begrenzt nicht nur den Netzwerkverkehr. Sie verhindert außerdem, dass AirScout dauerhaft Pfade berechnet, die außerhalb des für die eigene Station vorgesehenen Arbeitsbereichs liegen.
|
||||
|
||||
### Übernahme geänderter Einstellungen
|
||||
|
||||
Folgende Änderungen werden nach Verlassen des Eingabefeldes beziehungsweise Betätigen der Checkbox sofort für neue Pakete verwendet:
|
||||
|
||||
- Aktivierung oder Deaktivierung der AirScout-Integration,
|
||||
- Server-Identifier,
|
||||
- Client-Identifier,
|
||||
- automatische oder feste Bandauswahl und
|
||||
- fester Bandwert.
|
||||
|
||||
Nach einer Änderung des UDP-Ports muss die Chat-Verbindung getrennt und neu aufgebaut oder KST4Contest neu gestartet werden. Der bereits laufende UDP-Empfänger bleibt sonst weiterhin an den vorherigen Port gebunden.
|
||||
|
||||
Zum dauerhaften Speichern anschließend **Save Settings** verwenden.
|
||||
|
||||
Die Einrichtung der AirScout-Seite, die Anzeige der Flugzeuge und die Bedeutung der AP-Daten sind unter [AirScout-Integration](de-AirScout-Integration) beschrieben.
|
||||
Konfiguration der Schnittstelle zu AirScout für die Flugzeug-Scatter-Erkennung. Details: [AirScout-Integration](de-AirScout-Integration).
|
||||
|
||||
---
|
||||
|
||||
## Notification Settings (Benachrichtigungen)
|
||||
|
||||
|
||||
Drei Benachrichtigungstypen stehen zur Wahl:
|
||||
|
||||
Im Reiter **Notification** werden nicht nur akustische Hinweise konfiguriert. Hier befinden sich auch die Einstellungen für den lokalen DX-Cluster-Server, den Band-Upgrade-Hinweis und das QSO-Monitoring.
|
||||
1. **Einfache Sounds**: TADA-Sound für eingehende Nachrichten, Tick für Sked-Richtungserkennung usw.
|
||||
2. **CW-Ansage**: Das Rufzeichen einer Station, die eine Privatnachricht sendet, wird als CW-Signal ausgegeben.
|
||||
3. **Phonetische Ansage**: Das Rufzeichen wird phonetisch ausgesprochen.
|
||||
|
||||
### Akustische Hinweise
|
||||
|
||||
Die drei Audiofunktionen arbeiten unabhängig voneinander:
|
||||
|
||||
- **Play notification sounds …** aktiviert kurze Hinweistöne für neue Privatnachrichten, erkannte Richtungsgelegenheiten, Sked-Erinnerungen und Band-Upgrade-Hinweise.
|
||||
- **Spell the sender's callsign in CW …** gibt das Rufzeichen des Absenders einer neuen Privatnachricht als CW-Signal aus.
|
||||
- **Speak the sender's callsign phonetically …** spricht das Rufzeichen des Absenders phonetisch aus.
|
||||
|
||||
CW- und Sprachausgabe können gleichzeitig aktiviert werden. Das ist technisch möglich, im Contest aber nicht zwingend hilfreich. In der Praxis sollte nur die Ausgabe eingeschaltet werden, die im eigenen Stationsbetrieb tatsächlich wahrgenommen werden kann, ohne den Operator dauerhaft zu beschäftigen.
|
||||
|
||||
### Fallback-Band für relative QRG-Erkennung
|
||||
|
||||
Das Dropdown **Fallback band for relative QRG detection** legt fest, welches Band KST4Contest verwendet, wenn eine relative QRG keinem aktuellen Stationskontext zugeordnet werden kann.
|
||||
|
||||
Zur Auswahl stehen ausschließlich die vom Frequenzparser unterstützten Bandpräfixe:
|
||||
|
||||
```text
|
||||
50 MHz
|
||||
70 MHz
|
||||
144 MHz
|
||||
432 MHz
|
||||
1296 MHz
|
||||
2320 MHz
|
||||
3400 MHz
|
||||
5760 MHz
|
||||
10368 MHz (10G)
|
||||
24048 MHz (24G)
|
||||
```
|
||||
|
||||
Das Dropdown ist kein Filter und keine Vorgabe für vollständig angegebene Frequenzen. `432.088` wird unabhängig von der Auswahl als Frequenz im 432-MHz-Band erkannt. Benötigt wird das Fallback bei relativen Angaben wie `.205`, `,205` oder `qrg 205`.
|
||||
|
||||
Bevor KST4Contest auf das Fallback zurückgreift, prüft es den Bandkontext des Absenders. Wurde für dieselbe Station innerhalb der letzten 30 Minuten bereits eine passende vollständige Frequenz erkannt, hat dieses Band Vorrang. Ein Fallback von `144 MHz` macht aus `.100` daher `432.100 MHz`, wenn die Station kurz zuvor beispielsweise `432.088` genannt hat.
|
||||
|
||||
Die Einstellung befindet sich im Notification-Bereich, wirkt aber auf die gesamte QRG-Erkennung. Damit beeinflusst sie nicht nur mögliche DX-Cluster-Spots, sondern auch die QRG-Spalte, erkannte aktive Bänder, Priorisierung, Band-Upgrade-Hinweise und Funktionen, die eine bekannte Stationsfrequenz verwenden.
|
||||
|
||||
Mehr zur Erkennungslogik und zu absichtlich ignorierten Zahlen: [QRG-Erkennung](de-Funktionen#qrg-erkennung).
|
||||
|
||||
### Local DX Cluster output
|
||||
|
||||
KST4Contest kann erkannte Richtungsgelegenheiten als DX-Cluster-Spots an ein Logprogramm weitergeben. Eine im Chat erkannte Frequenz erscheint dadurch direkt in der Bandmap des Logprogramms und muss nicht erst von Hand übertragen werden.
|
||||
|
||||
Die Checkbox **Enable the local DX Cluster server …** startet beziehungsweise beendet den lokalen TCP-Server. Bei einer laufenden Chat-Verbindung wird die Änderung sofort wirksam.
|
||||
|
||||
Folgende Einstellungen und Schaltflächen gehören zur lokalen DX-Cluster-Ausgabe:
|
||||
|
||||
- **TCP port**: Port, auf dem KST4Contest Verbindungen von DX-Cluster-Clients annimmt. Der Standardwert ist `8000`. Wird der Port während einer laufenden Verbindung geändert, startet KST4Contest den Server auf dem neuen Port neu. Der Logger muss sich anschließend ebenfalls mit dem neuen Port verbinden.
|
||||
- **Fallback band for relative QRG detection**: Das oben beschriebene globale Fallback-Band. Der Testspot verwendet `.300` dieses Bandes. Reale Spots verwenden dagegen die für den jeweiligen Absender erkannte QRG.
|
||||
- **Spotter callsign**: Rufzeichen, das im erzeugten DX-Cluster-Spot als Spotter erscheint. Hier sollte ein anderes Rufzeichen als das im Contest verwendete Stationsrufzeichen eingetragen werden. Einige Logprogramme filtern Spots des eigenen Rufzeichens oder behandeln sie anders als fremde Spots.
|
||||
- **Send test spot**: Sendet den folgenden Testspot an alle aktuell verbundenen DX-Cluster-Clients:
|
||||
|
||||
```text
|
||||
Spotted callsign: DO5AMF
|
||||
Comment: Testing DXC-Spot: Congrats, you donated $100!
|
||||
Frequency: .300 des ausgewählten Fallback-Bandes
|
||||
```
|
||||
|
||||
Bei einem Fallback-Band von `144 MHz` wird daraus beispielsweise eine Frequenz von ungefähr `144.300 MHz`.
|
||||
|
||||
Der Kommentar des Testspots ist ein bewusst beibehaltenes Easteregg. Er hat keine technische Bedeutung und löst – trotz seiner erfreulich konkreten Formulierung – keine Zahlung aus. Entscheidend ist, dass der Spot im verbundenen Logprogramm erscheint.
|
||||
|
||||
Der Test funktioniert nur, wenn
|
||||
|
||||
1. KST4Contest mit dem ON4KST-Chat verbunden ist,
|
||||
2. der lokale DX-Cluster-Server aktiviert ist und
|
||||
3. mindestens ein DX-Cluster-Client mit KST4Contest verbunden ist.
|
||||
|
||||
KST4Contest erzeugt nicht bei jeder im Chat gefundenen Frequenz automatisch einen Spot. Ein realer Spot entsteht nur dann, wenn eine gerichtete Nachricht zwischen zwei Stationen auf eine für die eigene Station interessante Antennenrichtung schließen lässt und für den Absender eine nutzbare Frequenz bekannt ist.
|
||||
|
||||
Die vollständige Herleitung und die Einrichtung des Logprogramms sind im Kapitel [Integrierter DX-Cluster-Server](de-DX-Cluster-Server) beschrieben.
|
||||
|
||||
### Band-Upgrade-Hinweis nach einem Logeintrag
|
||||
|
||||
Nach einem über UCXLog oder Win-Test empfangenen Logeintrag kann KST4Contest prüfen, ob die gerade gearbeitete Station noch ein weiteres gemeinsames, aber bisher nicht gearbeitetes Band anbietet.
|
||||
|
||||
Die Prüfung verwendet dieselbe Bandherleitung wie die `a`- und `B+`-Anzeige:
|
||||
|
||||
1. die in den Stationseinstellungen aktivierten eigenen Bänder,
|
||||
2. höchstens 30 Minuten alte QRG-Erkennungen der Gegenstation,
|
||||
3. eindeutige Bandangaben im Namensfeld ihrer aktiven Chat-Einträge,
|
||||
4. die pro Band gespeicherten Worked-Markierungen und
|
||||
5. manuell gesetzte NOT-QRV-Tags.
|
||||
|
||||
Aktive Chat-Varianten desselben normalisierten Rufzeichens werden gemeinsam ausgewertet. NOT-QRV hat Vorrang vor einer automatisch erkannten QRG oder Bandangabe.
|
||||
|
||||
Bleibt mindestens ein gemeinsames, noch nicht gearbeitetes Band übrig, erscheint im Hauptfenster für ungefähr zwölf Sekunden ein blinkender **BAND+**-Hinweis mit Rufzeichen und den noch offenen Bändern. Der Tooltip zeigt die vollständige Herleitung. Ist die allgemeine Soundausgabe aktiviert, wird zusätzlich ein kurzer Hinweiston abgespielt.
|
||||
|
||||
Die beiden Optionen haben unterschiedliche Aufgaben:
|
||||
|
||||
- **Blink + sound …** aktiviert den Hinweis nach einem passenden Logeintrag.
|
||||
- **Priority boost …** erhöht zusätzlich den Score von Stationen, die bereits auf mindestens einem Band gearbeitet wurden, aber noch ein weiteres gemeinsames und nicht gearbeitetes Band anbieten.
|
||||
|
||||
Der Priority Boost ist nur ein Faktor innerhalb der gesamten Berechnung. Entfernung, Antennenrichtung, aktuelle Aktivität, AirScout-Daten, Skeds und negative Hinweise können den endgültigen Listenplatz weiterhin verändern. Die aktivierte Option garantiert deshalb weder einen bestimmten Score noch einen bestimmten Platz in der Prioritätsliste.
|
||||
|
||||
Die übrigen Score-Gewichte besitzen derzeit keine eigenen Bedienelemente. Mehrere vorhandene Einstellungen liefern jedoch Eingangsdaten für die Berechnung, insbesondere die [aktivierten Bänder](#aktivierte-bänder), der [Antennen-Öffnungswinkel](#antennen-öffnungswinkel-antenna-beamwidth), der [Standard-Maximum-QRB](#standard-maximum-qrb) und die [AirScout-Einstellungen](#airscout-einstellungen).
|
||||
|
||||
Die vollständige Herleitung ist unter [Prioritätsscore und Prioritätsliste](de-Funktionen#prioritätsscore-und-prioritätsliste-ab-v140) beschrieben.
|
||||
|
||||
Der Hinweis setzt eine Log-Synchronisation mit Bandinformation voraus. Der einfache dateibasierte Callsign-Interpreter erkennt lediglich Rufzeichen und liefert deshalb keine sichere Information über das Band des gerade geloggten QSOs.
|
||||
|
||||
Weitere Hintergründe: [Band-Upgrade-Hinweis nach einem Logeintrag](de-Funktionen#band-upgrade-hinweis-nach-einem-logeintrag).
|
||||
|
||||
### Sniffer-Einstellungen (ab v1.31)
|
||||
|
||||
Das QSO-Monitoring ist für Stationen gedacht, deren Kommunikation man gezielt verfolgen möchte. Das kann beispielsweise eine seltene Station, eine DXpedition oder eine andere Station des eigenen Contest-Teams sein, deren Sked-Absprachen im allgemeinen Chatverkehr nicht untergehen sollen.
|
||||
|
||||
Die Rufzeichen werden im Reiter **Notification** unter **QSO monitoring** verwaltet.
|
||||
|
||||
Für jedes eingetragene Basisrufzeichen zeigt KST4Contest Nachrichten zusätzlich in der PM-Tabelle an, wenn eine Variante dieses Rufzeichens entweder Absender oder Empfänger der Nachricht ist. Berücksichtigt werden beide verbundenen Chat-Kategorien.
|
||||
|
||||
Die Liste arbeitet bewusst mit dem normalisierten Basisrufzeichen. Folgende Eingaben erzeugen deshalb denselben Monitoring-Eintrag:
|
||||
|
||||
```text
|
||||
DN9APW
|
||||
DN9APW-2
|
||||
DN9APW-70
|
||||
DN9APW-144
|
||||
```
|
||||
|
||||
In allen Fällen speichert und zeigt KST4Contest den Eintrag als:
|
||||
|
||||
```text
|
||||
DN9APW
|
||||
```
|
||||
|
||||
Damit müssen die verschiedenen KST-Suffixe einer Station nicht einzeln eingetragen werden. Wird später eine Nachricht von `DN9APW-2` gesendet oder an `DN9APW-70` adressiert, wird sie durch denselben Eintrag erfasst.
|
||||
|
||||
Diese Zusammenführung gilt ausschließlich für das QSO-Monitoring. Die aktiven ChatMember-Objekte, vollständigen Nachrichtenempfänger und Chat-Kategorien bleiben getrennt. Eine an `DN9APW-70` gerichtete Nachricht wird deshalb nicht an `DN9APW-2` umgeleitet.
|
||||
|
||||
Überwachte Nachrichten werden in der PM-Tabelle mit den vollständigen sichtbaren Rufzeichen von Absender und Empfänger gekennzeichnet:
|
||||
|
||||
```text
|
||||
Sniffed: (DN9APW-2 > DL0ABC-70) Nachrichtentext
|
||||
```
|
||||
|
||||
Die ursprüngliche Nachricht bleibt gleichzeitig in ihrer normalen Tabelle erhalten. Das Monitoring verändert weder den Nachrichteninhalt noch dessen Routing.
|
||||
|
||||
Erfasst werden Nachrichten, bei denen das überwachte Rufzeichen tatsächlich Absender oder Empfänger ist. Eine bloße Erwähnung des Rufzeichens im Nachrichtentext reicht nicht aus. Öffentliche Nachrichten einer überwachten Station werden ebenfalls angezeigt; als Empfänger erscheint dabei `ALL`.
|
||||
|
||||
Ist eine Nachricht bereits direkt an das eigene Rufzeichen gerichtet, erscheint sie als normale Privatnachricht und erhält keine zusätzliche `Sniffed:`-Kennzeichnung.
|
||||
|
||||
Rufzeichen werden folgendermaßen verwaltet:
|
||||
|
||||
1. Mit **Add monitored callsign** ein neues Rufzeichen hinzufügen.
|
||||
2. Ein vorhandenes Rufzeichen per Doppelklick bearbeiten und die Änderung mit `Enter` übernehmen.
|
||||
3. Zum Entfernen den Inhalt einer Tabellenzelle löschen und mit `Enter` bestätigen.
|
||||
|
||||
Die Eingabe darf ein sichtbares KST-Suffix oder portable Bestandteile enthalten. KST4Contest normalisiert sie vor dem Speichern auf das Basisrufzeichen. Mehrere Varianten desselben Basisrufzeichens gelten deshalb als Duplikat.
|
||||
|
||||
Die Änderung der Liste wirkt sofort. Zum dauerhaften Speichern anschließend **Save Settings** verwenden. Die Basisrufzeichen werden in der `preferences.xml` gespeichert und beim nächsten Programmstart wiederhergestellt.
|
||||
|
||||
> Die Zusammenführung der KST-Suffixe über das Basisrufzeichen ist im Nightly beziehungsweise ab v1.42 enthalten.
|
||||
|
||||
Weitere Hintergründe und die Abgrenzung zum Nachrichtenrouting: [QSO-Monitoring](de-Funktionen#qso-monitoring-ab-v131).
|
||||
---
|
||||
|
||||
## Shortcut Settings (Schnellzugriff-Schaltflächen)
|
||||
|
||||
|
||||
|
||||
Jeder Eintrag im oberen Bereich des Reiters **Shortcuts** erzeugt eine Schaltfläche oberhalb des Nachrichteneingabefeldes im Hauptfenster. Ein Klick hängt den konfigurierten Text an den bereits vorhandenen Inhalt des Sendfeldes an.
|
||||
|
||||
Enthält der Shortcut eine [Variable](de-Makros-und-Variablen#variablen), wird sie beim Einfügen durch ihren aktuellen Wert ersetzt. Ein Shortcut wie
|
||||
|
||||
```text
|
||||
pse call me at MYQRGSHORT
|
||||
```
|
||||
|
||||
kann dadurch beispielsweise folgenden Text einfügen:
|
||||
|
||||
```text
|
||||
pse call me at 144.388
|
||||
```
|
||||
|
||||
Die exakten Einträge `MYQRG` und `SECONDQRG` werden zusätzlich als QRG-Schaltflächen hervorgehoben. Sie fügen die aktuelle QRG der ersten beziehungsweise zweiten Chat-Kategorie ein.
|
||||
|
||||
Auch der Shortcut `/SETNAME MYQRG` wird hervorgehoben. Beim Anklicken löst KST4Contest `MYQRG` auf und übernimmt den vollständigen Serverbefehl in das Sendfeld. Der Befehl wird nicht automatisch versendet und kann vor dem Senden mit `Enter` oder **TX** noch geprüft werden.
|
||||
|
||||
|
||||
Die Reihenfolge der Tabelle entspricht der Reihenfolge der Schaltflächen im Hauptfenster. Die Einträge werden folgendermaßen verwaltet:
|
||||
|
||||
1. Mit **Add shortcut** wird am Anfang der Liste ein neuer Eintrag angelegt und sofort zur Bearbeitung geöffnet.
|
||||
2. Ein vorhandener Eintrag kann per Doppelklick bearbeitet werden. `Enter` übernimmt die Änderung.
|
||||
3. Wird der Inhalt vollständig gelöscht und anschließend mit `Enter` bestätigt, entfernt KST4Contest den Eintrag.
|
||||
4. Mit **Move selected up** und **Move selected down** wird der markierte Eintrag innerhalb der Liste verschoben.
|
||||
|
||||
Änderungen werden sofort im Hauptfenster sichtbar. Damit sie auch nach dem nächsten Programmstart erhalten bleiben, anschließend **Save Settings** verwenden.
|
||||
Konfiguration von Schnellzugriff-Schaltflächen, die direkt im Hauptfenster erscheinen. Ein Klick auf eine Schaltfläche fügt den konfigurierten Text in das Sendfeld ein. Alle [Variablen](Makros-und-Variablen#variablen) können verwendet werden.
|
||||
|
||||
---
|
||||
|
||||
## Snippet Settings (Text-Snippets)
|
||||
|
||||
Snippets sind längere Textbausteine, die vor allem für Nachrichten an eine ausgewählte Station vorgesehen sind. Sie können über folgende Wege aufgerufen werden:
|
||||
Text-Snippets sind über folgende Wege abrufbar:
|
||||
|
||||
- per Rechtsklick auf eine Station in der Benutzerliste,
|
||||
- per Rechtsklick auf eine Nachricht in der öffentlichen Chat-Tabelle,
|
||||
- per Rechtsklick auf eine Nachricht in der PM-Tabelle oder
|
||||
- mit `Ctrl+1` bis `Ctrl+0` für die ersten zehn Einträge der Snippet-Liste.
|
||||
- **Rechtsklick** auf ein Rufzeichen in der Benutzerliste
|
||||
- **Rechtsklick** in der CQ-Nachrichtentabelle
|
||||
- **Rechtsklick** in der PM-Nachrichtentabelle
|
||||
- **Tastenkombinationen**: `Ctrl+1` bis `Ctrl+0` für die ersten 10 Snippets
|
||||
|
||||
Bei den Tastenkombinationen entspricht die Zuordnung der Tabellenreihenfolge:
|
||||
|
||||
| Tastenkombination | Snippet |
|
||||
|---|---:|
|
||||
| `Ctrl+1` | erster Eintrag |
|
||||
| `Ctrl+2` | zweiter Eintrag |
|
||||
| … | … |
|
||||
| `Ctrl+9` | neunter Eintrag |
|
||||
| `Ctrl+0` | zehnter Eintrag |
|
||||
|
||||
Ein über das Kontextmenü ausgewähltes Snippet wird an den bereits vorbereiteten Nachrichtentext angehängt. Die Auswahl einer Station oder Nachricht hat das Sendfeld zuvor normalerweise bereits mit dem passenden `/cq`-Empfänger vorbereitet.
|
||||
|
||||
Eine Tastenkombination verhält sich etwas anders: Sie ersetzt den bisherigen Inhalt des Sendfeldes durch eine vollständig adressierte Privatnachricht:
|
||||
|
||||
```text
|
||||
/cq RUFZEICHEN Snippet-Text
|
||||
```
|
||||
|
||||
Dabei wird das vollständige sichtbare Rufzeichen einschließlich eines vorhandenen Suffixes verwendet. Für `9A0BB-70` entsteht daher beispielsweise:
|
||||
|
||||
```text
|
||||
/cq 9A0BB-70 pse ur qrg?
|
||||
```
|
||||
|
||||
Die Chat-Kategorie der ausgewählten Station bleibt für den späteren Versand erhalten. Ist keine Station ausgewählt oder ist für die gedrückte Tastenkombination kein Snippet vorhanden, wird nichts eingefügt.
|
||||
|
||||
Variablen werden beim Einfügen des Snippets aufgelöst. Stationsbezogene Variablen wie `QRZNAME`, `FIRSTAP` oder `SECONDAP` verwenden die aktuell ausgewählte Station. Der vorbereitete Text wird nicht automatisch gesendet und kann deshalb noch geprüft oder geändert werden. `Enter` oder **TX** sendet die Nachricht; `Esc` leert das Sendfeld.
|
||||
|
||||
Die Snippet-Liste wird genauso bearbeitet wie die Shortcut-Liste:
|
||||
|
||||
1. **Add new snippet** legt am Anfang der Liste einen neuen Eintrag an.
|
||||
2. Ein Doppelklick öffnet einen vorhandenen Eintrag zur Bearbeitung.
|
||||
3. `Enter` übernimmt die Änderung.
|
||||
4. Ein leer bestätigter Eintrag wird entfernt.
|
||||
5. **Move selected up** und **Move selected down** ändern die Reihenfolge und damit auch die Zuordnung zu `Ctrl+1` bis `Ctrl+0`.
|
||||
|
||||
Die Kontextmenüs und Tastenkombinationen werden nach einer Änderung sofort aktualisiert. Für die dauerhafte Speicherung anschließend **Save Settings** verwenden.
|
||||
|
||||
Eine vollständige Übersicht der verfügbaren Platzhalter und ihrer Grenzen steht unter [Makros und Variablen](de-Makros-und-Variablen).
|
||||
Wenn in der Benutzerliste ein Rufzeichen ausgewählt ist, wird der Snippet als Direktnachricht adressiert:
|
||||
`/CQ RUFZEICHEN <Snippet-Text>`
|
||||
|
||||
---
|
||||
|
||||
## Beacon Settings (Automatischer Beacon)
|
||||
|
||||
|
||||
Konfiguration eines automatischen Intervall-Beacons im öffentlichen Chat-Kanal. Empfohlen: Variable `MYQRG` im Text verwenden, damit die aktuelle Frequenz immer aktuell ist. Intervall und Text sind frei konfigurierbar.
|
||||
|
||||
Ein Beacon sendet in regelmäßigen Abständen eine öffentliche CQ-Nachricht. Er ist für Betriebssituationen gedacht, in denen die eigene Station über längere Zeit auf einer festen Frequenz ruft. Andere Stationen erhalten dadurch eine aktuelle QRG-Information, ohne dass der Operator denselben Text immer wieder von Hand in den Chat schreiben muss.
|
||||
|
||||
KST4Contest verwendet einen gemeinsamen Timer für beide Chat-Kategorien. Aktivierung und Nachrichtentext werden trotzdem getrennt konfiguriert:
|
||||
|
||||
- **Enable CQ beacon** aktiviert den Beacon der betreffenden Kategorie.
|
||||
- **Beacon message** enthält den öffentlichen Nachrichtentext dieser Kategorie.
|
||||
- **Shared beacon interval** legt das gemeinsame Intervall für beide Kategorien fest.
|
||||
|
||||
Sind beide Beacons aktiviert, werden sie beim selben Timer-Lauf nacheinander in ihren jeweiligen Kategorien gesendet. Der zweite Beacon wird nur berücksichtigt, wenn auch der zweite Chat aktiviert und verbunden ist.
|
||||
|
||||
### Intervall und Timer-Verhalten
|
||||
|
||||
Das Intervall wird in ganzen Minuten angegeben. Der kleinste zulässige Wert ist eine Minute.
|
||||
|
||||
Nach dem Aufbau der Chat-Verbindung prüft KST4Contest die Beacons erstmals nach ungefähr zehn Sekunden. Anschließend gilt das eingestellte Intervall.
|
||||
|
||||
Wird das Intervall während einer laufenden Verbindung geändert, beginnt der Countdown mit dem neuen Wert erneut. Die Änderung selbst löst keine sofortige Beacon-Nachricht aus.
|
||||
|
||||
Beide Kategorien verwenden denselben Timer. Unterschiedliche Intervalle für den ersten und zweiten Chat können deshalb nicht eingestellt werden.
|
||||
|
||||
### Nachrichtentext und Variablen
|
||||
|
||||
Ein Beacon darf die [globalen Variablen](de-Makros-und-Variablen#variablen-im-beacon) verwenden, die sich ausschließlich auf die eigene Station beziehen:
|
||||
|
||||
- `MYQRG`
|
||||
- `MYQRGSHORT`
|
||||
- `SECONDQRG`
|
||||
- `MYLOCATOR`
|
||||
- `MYLOCATORSHORT`
|
||||
- `MYCALL`
|
||||
- `MYQTF`
|
||||
|
||||
Eine mögliche Nachricht für die erste Chat-Kategorie ist:
|
||||
|
||||
```text
|
||||
calling cq at MYQRGSHORT, ant MYQTF deg, loc MYLOCATOR
|
||||
```
|
||||
|
||||
Für den zweiten Chat muss `SECONDQRG` verwendet werden, wenn dessen Frequenz von der ersten Kategorie abweicht:
|
||||
|
||||
```text
|
||||
calling cq at SECONDQRG, ant MYQTF deg, loc MYLOCATOR
|
||||
```
|
||||
|
||||
Die Variablen werden bei jedem Timer-Lauf neu aufgelöst. Ändert die Logsoftware zwischenzeitlich die in `MYQRG` gespeicherte Frequenz, verwendet bereits der nächste Beacon den aktualisierten Wert. Das Template selbst muss dafür nicht geändert werden.
|
||||
|
||||
`MYQRG` und `MYQRGSHORT` beziehen sich immer auf die erste Chat-Kategorie. Die Auswahl oder Aktivierung des zweiten Chats ändert diese Zuordnung nicht.
|
||||
|
||||
Stationsbezogene Variablen wie `QRZNAME`, `FIRSTAP` oder `SECONDAP` benötigen eine ausgewählte Gegenstation. Da ein öffentlicher Beacon keine bestimmte Station adressiert, werden diese Variablen im Beacon nicht aufgelöst.
|
||||
|
||||
### Prüfung des Nachrichtentextes
|
||||
|
||||
KST4Contest prüft sowohl das eingetragene Template als auch den nach der Variablenauflösung tatsächlich zu sendenden Text.
|
||||
|
||||
Für Beacon-Nachrichten gelten folgende Bedingungen:
|
||||
|
||||
- Der endgültige Nachrichtentext darf nicht leer sein.
|
||||
- Er darf höchstens 120 Zeichen enthalten.
|
||||
- Das Protokoll-Trennzeichen `|` ist nicht zulässig.
|
||||
- Zeilenumbrüche sind nicht zulässig.
|
||||
|
||||
Eine ungültige Eingabe wird nicht als neue Beacon-Konfiguration übernommen. Wird ein Template erst durch eine spätere Variablenauflösung ungültig, beispielsweise weil der aufgelöste Text länger als 120 Zeichen ist, wird dieser Beacon-Lauf ausgelassen.
|
||||
|
||||
Ein Template, das ausschließlich aus einer momentan noch leeren globalen Variable besteht, kann gespeichert werden. Das ist beispielsweise beim Start möglich, bevor die erste QRG vom Logprogramm empfangen wurde. Solange die Variable keinen verwendbaren Inhalt liefert, sendet KST4Contest jedoch keine leere Nachricht.
|
||||
|
||||
### Wann sollte der Beacon ausgeschaltet werden?
|
||||
|
||||
Der Beacon ist nur dann hilfreich, wenn seine QRG-Angabe zum tatsächlichen Betrieb passt. Bleibt er beim Absuchen oder häufigen Wechseln von Frequenzen aktiviert, können andere Stationen auf einer inzwischen falschen Frequenz nach der eigenen Station suchen.
|
||||
|
||||
Im Klartext: Solange auf einer festen QRG CQ gerufen wird, spart der Beacon Arbeit. Beim „Schleichen“ über das Band sollte er ausgeschaltet werden.
|
||||
|
||||
Änderungen wirken während der laufenden Verbindung. Damit Aktivierung, Texte und Intervall auch nach dem nächsten Programmstart erhalten bleiben, anschließend **Save Settings** verwenden.
|
||||
> **Tipp**: Beacon beim CQ-Rufen aktivieren und im Einstellungsfenster schnell deaktivieren, wenn kein CQ gerufen wird.
|
||||
|
||||
---
|
||||
|
||||
## Messagehandling Settings (ab v1.25)
|
||||
|
||||
|
||||
Neuer Einstellungsbereich mit folgenden Optionen:
|
||||
|
||||
Die wichtigste Anwendung der allgemeinen automatischen Antwort betrifft Stationen, die zwar im ON4KST-Chat eingeloggt sind, den laufenden Contest aber nicht mitfunken. Gerade während größerer Contests werden Sked-Anfragen teilweise unkoordiniert und in großer Zahl an eingeloggte Stationen verteilt, ohne vorher zu prüfen, ob sie überhaupt teilnehmen. Die Empfänger müssten sonst immer wieder dieselbe Absage schreiben.
|
||||
|
||||
KST4Contest kann darauf mit einem vorher festgelegten Text reagieren. Davon getrennt steht eine gezielte QRG-Auskunft zur Verfügung. Beide Funktionen können unabhängig voneinander aktiviert werden.
|
||||
|
||||
### Allgemeine automatische Antwort
|
||||
|
||||
**Enable automatic reply to all private messages** beantwortet eingehende Privatnachrichten mit dem Text im Feld rechts daneben. Es gibt einen gemeinsamen Text für beide Chat-Kategorien. Die beim Eingeben verwendete Groß- und Kleinschreibung bleibt erhalten.
|
||||
|
||||
Eine zweckmäßige Nachricht ist beispielsweise:
|
||||
|
||||
```text
|
||||
Sri, I am not taking part in this contest. No skeds.
|
||||
```
|
||||
|
||||
Das Präfix `[KST4C Automsg]` muss nicht in das Eingabefeld geschrieben werden. KST4Contest ergänzt es automatisch.
|
||||
|
||||
Die beim Empfänger sichtbare Nachricht lautet daher beispielsweise:
|
||||
|
||||
```text
|
||||
[KST4C Automsg] Sri, I am not taking part in this contest. No skeds.
|
||||
```
|
||||
|
||||
Die eingegangene Privatnachricht bleibt sichtbar. Die Funktion blockiert oder verwirft keine Anfrage, sondern erspart lediglich die wiederholte manuelle Antwort.
|
||||
|
||||
Die Antwort wird an das vollständige Rufzeichen des Absenders einschließlich eines vorhandenen Suffixes und in derselben Chat-Kategorie gesendet, in der die Privatnachricht eingegangen ist. Das ist bei einem parallelen Login in zwei Kategorien entscheidend: Eine Nachricht aus dem Microwave-Chat darf nicht versehentlich im VHF/UHF-Chat beantwortet werden.
|
||||
|
||||
Ein leerer oder ausschließlich aus Leerzeichen bestehender Antworttext erzeugt keine automatische Nachricht. Enthält der Text ein Protokoll-Trennzeichen wie `|` oder einen Zeilenumbruch, wird die Antwort ebenfalls verworfen.
|
||||
|
||||
### Automatische QRG-Antwort
|
||||
|
||||
**Enable automatic QRG replies** reagiert auf typische QRG-Anfragen. Die Erkennung unterscheidet nicht zwischen Groß- und Kleinschreibung und sucht nach folgenden Textbestandteilen:
|
||||
|
||||
```text
|
||||
ur qrg?
|
||||
your qrg?
|
||||
qrg?
|
||||
freq?
|
||||
pse qrg
|
||||
```
|
||||
|
||||
Die Antwort enthält ausschließlich die QRG der Kategorie, in der die Anfrage eingegangen ist:
|
||||
|
||||
| Eingegangene Privatnachricht | Verwendete QRG |
|
||||
|---|---|
|
||||
| Hauptkategorie | aktuelle QRG der Hauptkategorie |
|
||||
| zweite Chat-Kategorie | aktuelle QRG der zweiten Kategorie |
|
||||
|
||||
Eine mögliche Antwort lautet:
|
||||
|
||||
```text
|
||||
[KST4C Automsg] QRG is: 144.300.00
|
||||
```
|
||||
|
||||
Die Werte stammen aus denselben QRG-Feldern, die auch von `MYQRG` und `SECONDQRG` verwendet werden. Die Haupt-QRG kann manuell eingetragen oder durch die [TRX-Synchronisation](#trx-sync-einstellungen) aktualisiert werden. Für die zweite Kategorie wird der dort konfigurierte beziehungsweise manuell eingetragene Wert verwendet.
|
||||
|
||||
Ist für die betreffende Kategorie keine QRG vorhanden, sendet KST4Contest keine unvollständige Antwort. Eine Nachricht wie `QRG is:` ohne Frequenz würde zwar auf die Frage reagieren, dem Anfragenden aber keine Information liefern. Sie wird deshalb bereits vor der Übergabe an die Sendequeue verworfen.
|
||||
|
||||
Sind die allgemeine und die QRG-bezogene Antwort gleichzeitig aktiviert, hat die QRG-Antwort Vorrang. Eine erkannte QRG-Anfrage erzeugt daher nicht zusätzlich den allgemeinen Antworttext. Fehlt die benötigte QRG, fällt KST4Contest auch nicht auf die allgemeine Antwort zurück.
|
||||
|
||||
### Schutz vor wiederholten Antworten
|
||||
|
||||
Jede automatisch erzeugte Nachricht trägt das feste Präfix:
|
||||
|
||||
```text
|
||||
[KST4C Automsg]
|
||||
```
|
||||
|
||||
Die allgemeine und die QRG-bezogene Antwort reagieren nicht auf Nachrichten, die dieses Präfix bereits enthalten. Dadurch beantworten sich zwei entsprechend arbeitende Clients nicht gegenseitig in einer Schleife.
|
||||
|
||||
Zusätzlich gilt eine gemeinsame Sperrzeit von zwei Minuten für beide Antwortarten. Die Sperre wird getrennt nach vollständigem Rufzeichen und Chat-Kategorie geführt.
|
||||
|
||||
Daraus folgt:
|
||||
|
||||
- `CALLSIGN-2` und `CALLSIGN-70` besitzen getrennte Sperrzeiten.
|
||||
- Dasselbe vollständige Rufzeichen kann in einer anderen Chat-Kategorie unabhängig beantwortet werden.
|
||||
- Eine allgemeine Antwort sperrt für zwei Minuten auch eine QRG-Antwort an dasselbe Rufzeichen in derselben Kategorie.
|
||||
- Eine QRG-Antwort sperrt entsprechend auch die allgemeine Antwort.
|
||||
|
||||
Die Sperrzeit beginnt nur, wenn KST4Contest eine vollständige und lokal gültige Antwort in die Sendequeue übernimmt. Eine fehlende QRG, ein leerer allgemeiner Antworttext oder ein wegen ungültiger Zeichen verworfener Text startet keine Sperrzeit. Sobald die fehlende Information korrigiert wurde, kann daher unmittelbar eine gültige Antwort erzeugt werden.
|
||||
|
||||
> **Hinweis**: Der Antworttext sollte den tatsächlichen Status eindeutig benennen. Wer den Contest nur beobachtet und keine Skeds fahren möchte, sollte genau das mitteilen. Eine vage Nachricht erzeugt im Zweifel nur die nächste Rückfrage – und damit exakt die Arbeit, welche die Funktion vermeiden soll.
|
||||
|
||||
Änderungen wirken während der laufenden Verbindung. Damit Aktivierung und Text nach dem nächsten Programmstart erhalten bleiben, anschließend **Save Settings** verwenden.
|
||||
|
||||
Weitere Hintergründe: [Automatische Antworten auf Privatnachrichten](de-Funktionen#automatische-antworten-auf-privatnachrichten-ab-v125).
|
||||
- **Auto-Antwort auf alle eingehenden Nachrichten**: Automatische Antwort auf Privatnachrichten konfigurierbar.
|
||||
- **Auto-Antwort mit eigener CQ-QRG**: Wenn jemand nach der eigenen QRG fragt, antwortet KST4Contest automatisch mit dem Inhalt der `MYQRG`-Variable.
|
||||
- **Standard-Filter für das Userinfo-Fenster**: Voreingestellter Nachrichtenfilter für das Stationsinfo-Fenster konfigurierbar *(für Gianluca :-) )*.
|
||||
|
||||
---
|
||||
|
||||
## Win-Test-Netzwerk-Listener (ab v1.31)
|
||||
|
||||
Der Win-Test-Netzwerk-Listener verarbeitet das native Win-Test-UDP-Protokoll. Er ist vom allgemeinen QSO-UDP-Listener auf Port `12060` unabhängig und übernimmt drei Aufgaben:
|
||||
Dedizierter Empfänger für Win-Test-spezifische UDP-Pakete. Ermöglicht:
|
||||
|
||||
- QSOs einschließlich Band- und Locatorinformation auswerten,
|
||||
- STATUS-Pakete für die eigene QRG verarbeiten und
|
||||
- Skeds an das Win-Test-Netzwerk übergeben.
|
||||
- **Log-Synchronisation**: Gearbeitete Stationen werden aus Win-Test übernommen und in der Benutzerliste markiert.
|
||||
- **Frequenz-Auswertung**: Die aktuelle TRX-Frequenz aus Win-Test befüllt die `MYQRG`-Variable.
|
||||
- **Sked-Übergabe (SKED Push)**: Skeds aus KST4Contest werden via UDP direkt an Win-Test übergeben. Der UDP-Broadcast-Standardport von Win-Test (9871) wird verwendet.
|
||||
|
||||
### Einstellungen unter Log sync
|
||||
Einstellungen:
|
||||
- **Aktivieren/Deaktivieren**: Checkbox in den Preferences (ab v1.40).
|
||||
- **Port**: Konfigurierbarer UDP-Port für den Win-Test-Listener.
|
||||
- **Sked-UDP-Adresse und Port**: Zieladresse und Port für die SKED-Übergabe an Win-Test.
|
||||
|
||||
| Einstellung | Funktion |
|
||||
|---|---|
|
||||
| **Receive Win-Test network based UDP log messages** | Aktiviert den Win-Test-Netzwerk-Listener. Bei aktiviertem Listener wird nach **Create sked** auch die Sked-Übergabe versucht. |
|
||||
| **UDP-Port for Win-Test listener** | Port des Win-Test-Netzwerks. Standard ist `9871`. Der Port wird auch für die Sked-Übergabe verwendet. |
|
||||
| **KST station name in Win-Test network (src of SKED packets)** | Stationsname, unter dem KST4Contest die Sked-Pakete sendet. In einem Netzwerk mit mehreren Clients sollte ein eindeutiger Name verwendet werden. |
|
||||
| **Win-Test network broadcast address** | Zieladresse für ausgehende Win-Test-Netzwerkpakete. Bei lokalem Netzwerkbetrieb muss hier eine vom Win-Test-Rechner erreichbare Broadcast-Adresse eingetragen sein. |
|
||||
|
||||
Die Broadcast-Adresse ist konfigurierbar, weil `255.255.255.255` nicht in jedem Stationsnetz und nicht über jede Netzwerkschnittstelle zuverlässig weitergeleitet wird. Bei mehreren Rechnern kann stattdessen die zum Stationsnetz gehörende gerichtete Broadcast-Adresse erforderlich sein.
|
||||
|
||||
### Einstellungen unter TRX sync
|
||||
|
||||
| Einstellung | Funktion |
|
||||
|---|---|
|
||||
| **Win-Test STATUS QRG Sync** | Übernimmt die aktuelle Frequenz aus Win-Test-STATUS-Paketen als eigene QRG. |
|
||||
| **Use pass frequency from Win-Test STATUS** | Verwendet die übertragene Pass-Frequenz anstelle der normalen TRX-QRG. |
|
||||
| **Win-Test station name filter** | Verarbeitet nur STATUS-Pakete der angegebenen Win-Test-Station. Ein leeres Feld akzeptiert alle Stationsnamen. |
|
||||
|
||||
Der Stationsfilter ist insbesondere bei mehreren Win-Test-Clients sinnvoll. Ohne Filter kann die zuletzt eingegangene STATUS-Meldung eines anderen Arbeitsplatzes die eigene QRG in KST4Contest überschreiben.
|
||||
|
||||
### Sked-Übergabe
|
||||
|
||||
Für die Sked-Übergabe gibt es keinen davon getrennten internen Sked-Modus. Ist der Listener aktiviert, versucht **Create sked** zusätzlich zur internen Anlage die Übertragung an Win-Test.
|
||||
|
||||
KST4Contest sendet nur dann ein `ADDSKED`-Paket, wenn eine QRG ermittelt wurde, die zum ausdrücklich ausgewählten Band gehört. Kann keine passende QRG gefunden werden, bleibt der interne Sked bestehen und die Win-Test-Übergabe wird ausgelassen.
|
||||
|
||||
Die Auswahl `SSB` oder `CW` erfolgt direkt im Further-Info-Bereich beim Anlegen des Skeds. Eine automatische Mode-Ableitung wird nicht verwendet.
|
||||
|
||||
Nach Änderungen **Save Settings** verwenden, damit Port, Stationsname, Broadcast-Adresse und TRX-Optionen beim nächsten Programmstart wiederhergestellt werden.
|
||||
|
||||
Datenbehandlung und QRG-Auswahl: [Log-Synchronisation – Win-Test](de-Log-Synchronisation#win-test)
|
||||
|
||||
|
||||
## PSTRotator-Einstellungen (ab v1.31, vollständig konfigurierbar ab v1.40)
|
||||
|
||||
KST4Contest kann eine ausgewählte Antennenrichtung über die UDP-Schnittstelle von [PSTRotator](https://www.pstrotator.com/) einstellen und die von PSTRotator gemeldete aktuelle Position als eigene QTF übernehmen.
|
||||
|
||||
Die Einstellungen befinden sich im Reiter **Station**:
|
||||
|
||||
| Einstellung | Standardwert | Verwendung |
|
||||
|---|---:|---|
|
||||
| **Enable PSTRotator** | deaktiviert | Startet die UDP-Kommunikation mit PSTRotator |
|
||||
| **PSTRotator host** | `127.0.0.1` | Hostname oder IP-Adresse des Rechners, auf dem PSTRotator läuft |
|
||||
| **PSTRotator UDP port** | `12000` | UDP-Port, auf dem PSTRotator die Steuerbefehle empfängt |
|
||||
|
||||
Bei Betrieb auf demselben Rechner ist `127.0.0.1` normalerweise die eindeutigste Einstellung. Läuft PSTRotator auf einem anderen Rechner im Stationsnetz, muss dessen erreichbare IP-Adresse oder DNS-Name eingetragen werden.
|
||||
|
||||
Der Port darf zwischen `1` und `65534` liegen. Port `65535` ist nicht möglich, weil PSTRotator seine Positionsmeldungen auf dem jeweils folgenden Port sendet.
|
||||
|
||||
### PSTRotator vorbereiten
|
||||
|
||||
In PSTRotator muss unter **Communication → UDP Control Port** derselbe UDP-Port eingetragen werden wie in KST4Contest. Anschließend muss **UDP Control** in PSTRotator aktiviert werden.
|
||||
|
||||
Bei der Standardeinstellung ergibt sich folgendes Portpaar:
|
||||
|
||||
| Richtung | UDP-Port |
|
||||
|---|---:|
|
||||
| KST4Contest → PSTRotator | `12000` |
|
||||
| PSTRotator → KST4Contest | `12001` |
|
||||
|
||||
KST4Contest bindet den Empfangsport automatisch. Er wird nicht separat konfiguriert.
|
||||
|
||||
Bei Betrieb auf zwei Rechnern müssen die lokale Firewall und das Stationsnetz UDP-Pakete in beiden Richtungen zulassen. Ist der Empfangsport bereits durch ein anderes Programm belegt, kann KST4Contest die Positionsmeldungen nicht empfangen.
|
||||
|
||||
Das vollständige UDP-Protokoll ist im [PSTRotatorAz User Manual](https://www.qsl.net/yo3dmu/ANT/PstRotatorAz%20User%20Manual.pdf) beschrieben.
|
||||
|
||||
### Übernahme der aktuellen QTF
|
||||
|
||||
KST4Contest fragt PSTRotator alle zwei Sekunden nach der aktuellen Azimutposition und dem Betriebsmodus. Die zurückgemeldete Azimutposition wird als `actualQTF` übernommen.
|
||||
|
||||
Bei aktivierter PSTRotator-Integration ist das QTF-Feld im Hauptfenster deshalb nicht manuell editierbar. Es zeigt die zuletzt von PSTRotator gemeldete Position.
|
||||
|
||||
Diese QTF wird unter anderem verwendet für:
|
||||
|
||||
- den Richtungsfilter,
|
||||
- die Bewertung von Richtungsgelegenheiten,
|
||||
- den Priority Score,
|
||||
- die Darstellung des Antennensektors auf der Stationskarte,
|
||||
- die AP- und Sked-Timeline und
|
||||
- die Variable `MYQTF`.
|
||||
|
||||
Eine empfangene Rotatorposition ist damit nicht nur eine Anzeige. Sie verändert mehrere Funktionen, die auf der aktuellen Antennenrichtung beruhen.
|
||||
|
||||
KST4Contest verwendet derzeit nur den Azimut. Eine Elevationssteuerung oder eine vollständige Azimut-/Elevationsnachführung ist nicht Bestandteil dieser Integration.
|
||||
|
||||
### Änderungen übernehmen
|
||||
|
||||
Aktivierung, Host und Port werden beim Start der Rotatorverbindung ausgewertet. Nach einer Änderung sollte die ON4KST-Verbindung getrennt und erneut aufgebaut oder KST4Contest neu gestartet werden.
|
||||
|
||||
Anschließend **Save Settings** verwenden, damit die Werte auch beim nächsten Programmstart wiederhergestellt werden.
|
||||
> **Hinweis**: Der Win-Test-Listener ist ein **zusätzlicher** Listener – der Standard-QSO-UDP-Broadcast-Listener auf Port 12060 bleibt davon unabhängig.
|
||||
|
||||
---
|
||||
|
||||
## GUI Settings: Hinweise in den Bandspalten
|
||||
## PSTRotator-Einstellungen (ab v1.31)
|
||||
|
||||
Im Reiter **GUI** lassen sich zwei Zusatzinformationen der Bandspalten ein- oder ausblenden:
|
||||
KST4Contest kann die Antennenrichtung über PSTRotator steuern.
|
||||
|
||||
- **Show "o" in band columns …** zeigt ein `o`, wenn das vierstellige Großfeld auf dem betreffenden Band bereits gearbeitet wurde. Das Abschalten entfernt keine Daten aus der Datenbank; nur die zusätzliche Anzeige in den Bandspalten wird ausgeblendet. `wkdany` bleibt davon unberührt.
|
||||
- **Show "a" in band columns …** unterscheidet ein vollständig neues Rufzeichen von einer Bandmöglichkeit mit einem bereits auf einem anderen Band gearbeiteten Rufzeichen. Ist die Option ausgeschaltet, werden beide Fälle als `B+` dargestellt. Die Bandherleitung selbst ändert sich dadurch nicht.
|
||||
Einstellungen:
|
||||
- **Aktivieren/Deaktivieren**: Checkbox in den Preferences (ab v1.40).
|
||||
- **IP-Adresse**: IP-Adresse des PSTRotator-Rechners (Standard: `127.0.0.1` bei Betrieb auf demselben PC).
|
||||
- **Port**: Kommunikationsport von PSTRotator.
|
||||
|
||||
Änderungen werden in der laufenden Benutzeroberfläche unmittelbar sichtbar. Damit sie nach dem nächsten Programmstart erhalten bleiben, anschließend **Save Settings** verwenden.
|
||||
> **Hinweis**: Nach einem Klick auf den Richtungs-Button wartet KST4Contest kurz auf die Rotatorantwort. Bei langsamen Rotoren (z. B. SPID) kann es zu einer kleinen Verzögerung kommen.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Sniffer-Einstellungen (ab v1.31)
|
||||
|
||||
Der QSO-Sniffer filtert Chat-Nachrichten von konfigurierbaren Rufzeichen und leitet sie ins PM-Fenster weiter.
|
||||
|
||||
Einstellungen:
|
||||
- **Rufzeichen-Liste**: Kommagetrennte Liste von Rufzeichen, deren Nachrichten immer in das PM-Fenster weitergeleitet werden sollen.
|
||||
|
||||
Anwendungsfall: Wichtige Stationen (z. B. DX-Peditionen oder feste Verbündete im Contest) im Auge behalten, ohne den Haupt-Chat ständig zu beobachten.
|
||||
|
||||
---
|
||||
|
||||
## Worked Station Database Settings (Gearbeitete-Stationen-Datenbank)
|
||||
|
||||
Die interne SQLite-Datenbank speichert die contestbezogenen Zustände unabhängig von der Datenbank des Logprogramms:
|
||||
Die interne Worked-Datenbank enthält:
|
||||
|
||||
- globaler Worked-Status eines Rufzeichens,
|
||||
- Worked-Status pro Band,
|
||||
- manuell gesetzte NOT-QRV-Tags pro Band und
|
||||
- gearbeitete vierstellige Großfelder pro Band.
|
||||
- Worked-Status aller Stationen (pro Band)
|
||||
- NOT-QRV-Tags (seit v1.2)
|
||||
|
||||
Als Schlüssel wird das normalisierte Rufzeichen ohne sichtbare Chat-Klammern oder Kategorieformatierung verwendet. Dadurch können aktive Varianten desselben Rufzeichens konsistent ausgewertet werden.
|
||||
|
||||
Worked- und NOT-QRV-Informationen laufen drei Tage nach ihrer letzten Änderung automatisch ab. Gespeicherte Großfelder laufen drei Tage nach dem zugehörigen Logeintrag ab. Ein manuelles Zurücksetzen vor jedem Contest ist deshalb normalerweise nicht erforderlich.
|
||||
|
||||
Die Schaltfläche **Reset worked, NOT-QRV and grid data...** entfernt sämtliche Worked-Markierungen, NOT-QRV-Tags und gespeicherten Großfelder. Vor dem Reset erscheint eine Sicherheitsabfrage. Die bekannten Rufzeichenzeilen bleiben erhalten; zurückgesetzt werden nur die contestbezogenen Zustände.
|
||||
|
||||
Ein Reset ist sinnvoll, wenn bewusst mit einem leeren Conteststand begonnen werden soll oder Testdaten eingelesen wurden. Als tägliche Wartungsmaßnahme ist er nicht vorgesehen.
|
||||
|
||||
Anzeige und Herleitung: [Gearbeitete Rufzeichen, neue Bänder und neue Großfelder](de-Funktionen#gearbeitete-rufzeichen-neue-bänder-und-neue-großfelder).
|
||||
**Ab v1.40**: Einträge haben eine automatische Lebensdauer von **3 Tagen** – ein manuelles Zurücksetzen vor jedem Contest ist nicht mehr zwingend notwendig. Für ein vollständiges Reset kann trotzdem die Schaltfläche **„Reinitialize"** verwendet werden.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
> 🇬🇧 [English version](en-Log-Sync) | 🇩🇪 Du liest gerade die deutsche Version
|
||||
|
||||
KST4Contest übernimmt gearbeitete Stationen aus dem Logprogramm und stellt daraus den globalen Worked-Status, bandbezogene Worked-Markierungen und – sofern ein Locator übertragen wurde – gearbeitete Großfelder bereit. Dafür gibt es drei Wege: den dateibasierten Simplelogfile-Interpreter, den allgemeinen QSO-UDP-Listener und den eigenen Win-Test-Netzwerk-Listener.
|
||||
KST4Contest markiert gearbeitete Stationen automatisch in der Chat-Benutzerliste. Dafür gibt es zwei grundlegende Methoden:
|
||||
|
||||
---
|
||||
|
||||
@@ -10,25 +10,24 @@ KST4Contest übernimmt gearbeitete Stationen aus dem Logprogramm und stellt dara
|
||||
|
||||
## Methode 1: Universal File Based Callsign Interpreter (Simplelogfile)
|
||||
|
||||
KST4Contest liest eine Logdatei und sucht mit einem konfigurierbaren regulären Ausdruck nach Rufzeichen. Die Datei wird ausschließlich gelesen und nicht verändert. Auch binäre Logdateien können verwendet werden; nicht als Text interpretierbare Inhalte werden übersprungen.
|
||||
KST4Contest liest eine Log-Datei und sucht mittels regulärem Ausdruck nach Rufzeichen-Mustern. Dabei werden auch binäre Logdateien unterstützt – unlesbarer Binärinhalt wird einfach ignoriert.
|
||||
|
||||
Der Vorteil liegt in der breiten Kompatibilität: Die Funktion benötigt keine besondere Netzwerkschnittstelle des Logprogramms.
|
||||
**Vorteil**: Funktioniert mit nahezu jedem Logprogramm, das eine Datei schreibt.
|
||||
**Nachteil**: Keine Bandinformation möglich – es wird nur „gearbeitet" markiert, nicht auf welchem Band.
|
||||
|
||||
Die Grenze ist ebenso eindeutig: Aus einem reinen Rufzeichentreffer lassen sich weder Band noch Locator zuverlässig ableiten. Der Simplelogfile-Interpreter kann deshalb nur den globalen Worked-Status setzen. Er erzeugt keine bandbezogene `X`-Markierung, kein Worked-Großfeld und keine belastbare Grundlage für den Band-Upgrade-Hinweis nach einem Logeintrag.
|
||||
Pfad der Log-Datei in den Preferences eintragen. Die Datei wird nur gelesen, nie verändert (read-only).
|
||||
|
||||
Den Pfad der Logdatei und den regulären Ausdruck im Reiter **Log sync** eintragen. Für bandbezogene Auswertungen sollte nach Möglichkeit eine der Netzwerkschnittstellen verwendet werden.
|
||||
> **Tipp**: Die Simplelogfile-Funktion kann auch genutzt werden, um Stationen zu markieren, die definitiv nicht erreichbar sind (z. B. eigene Notizen). Das wird in einer späteren Version durch ein besseres Tagging-System ersetzt.
|
||||
|
||||
---
|
||||
|
||||
## Methode 2: Netzwerk-Listener für QSO-UDP-Pakete – empfohlen
|
||||
## Methode 2: Netzwerk-Listener (UDP-Broadcast) – Empfohlen
|
||||
|
||||
UCXLog, QARTest, N1MM+ und DXLog.net können beim Speichern eines QSOs ein UDP-Paket senden. KST4Contest empfängt diese Pakete standardmäßig auf Port `12060` und übernimmt das Rufzeichen sowie die enthaltenen Band- und Locatorinformationen.
|
||||
Das Logprogramm sendet beim Speichern eines QSOs ein UDP-Paket an die Broadcast-Adresse des Heimnetzwerks. KST4Contest empfängt dieses Paket und markiert die Station inklusive **Bandinformation** in der internen SQLite-Datenbank.
|
||||
|
||||
Liegt eine Bandinformation vor, wird das Rufzeichen für dieses Band als gearbeitet markiert. Enthält das Paket zusätzlich einen gültigen Locator, speichert KST4Contest dessen vierstelliges Großfeld für das betreffende Band. Fehlende Informationen werden nicht aus anderen Feldern geraten.
|
||||
> **Wichtig**: KST4Contest muss **parallel zum Logprogramm laufen**. QSOs, die während einer Abwesenheit von KST4Contest geloggt werden, werden nicht erfasst – außer bei QARTest (kann das komplette Log senden).
|
||||
|
||||
KST4Contest muss zum Zeitpunkt der Übertragung laufen. Einige Logprogramme können jedoch das vorhandene Log erneut senden: QARTest bietet dafür **Invia log completo**; DXLog.net sendet beim Broadcast des vollständigen Logs `contactreplace`-Pakete, die KST4Contest ebenfalls verarbeitet.
|
||||
|
||||
**Standardport:** `12060`
|
||||
**Standard UDP-Port**: 12060 (entspricht dem Standard der meisten Logprogramme)
|
||||
|
||||
---
|
||||
|
||||
@@ -82,80 +81,34 @@ Für den integrierten DX-Cluster-Server: N1MM+ als DX-Cluster-Client konfigurier
|
||||
- IP des KST4Contest-Computers eintragen (grün markierte Felder)
|
||||
- Port: 12060
|
||||
|
||||
Beim Broadcast des vollständigen Logbuchs verwendet DXLog.net `contactreplace` anstelle von `contactinfo`. KST4Contest verarbeitet beide Pakettypen. Damit können auch ältere QSOs übernommen werden, wenn der vollständige Broadcast ausgelöst wird, während KST4Contest läuft.
|
||||
|
||||
### Win-Test
|
||||
|
||||
Win-Test wird über einen eigenen UDP-Listener für das native Win-Test-Netzwerkprotokoll angebunden. Dieser Listener ist vom allgemeinen QSO-UDP-Listener auf Port `12060` unabhängig.
|
||||
Win-Test wird mit einem dedizierten UDP-Netzwerk-Listener unterstützt, der das native Win-Test Netzwerkprotokoll versteht.
|
||||
|
||||
#### QSO- und Worked-Synchronisation
|
||||
**Vorteile der Win-Test Integration:**
|
||||
- Automatische QSO-Synchronisation zur Markierung gearbeiteter Stationen.
|
||||
- **Sked-Übergabe (ADDSKED):** Über den Button "Create sked" im Stationsinfo-Panel wird nicht nur in KST4Contest ein Sked angelegt, sondern dieser auch *direkt per UDP an das Win-Test Netzwerk als ADDSKED-Paket gesendet* – automatisch, sobald der Listener aktiv ist.
|
||||
- Es kann zwischen den Sked-Modi "AUTO", "SSB" oder "CW" gewählt werden.
|
||||
- **Automatische QRG-Auflösung für SKEDs:** KST4Contest wählt die Sked-Frequenz intelligent:
|
||||
1. Hat die Gegenstation in einer Chat-Nachricht ihre QRG genannt, wird diese verwendet.
|
||||
2. Sonst wird die eigene aktuelle QRG verwendet (aus Win-Test STATUS oder manueller Eingabe).
|
||||
|
||||
Bei einem neuen QSO übernimmt KST4Contest:
|
||||
**Einstellungen im Reiter „Log-Synchronisation":**
|
||||
- `Receive Win-Test network based UDP log messages` aktivieren.
|
||||
- `UDP-Port for Win-Test listener` (Standard: 9871).
|
||||
- `KST station name in Win-Test network (src of SKED packets)`: Legt fest, unter welchem Stationsnamen KST4Contest im WT-Netzwerk auftritt (z.B. "KST").
|
||||
- `Win-Test network broadcast address`: Wird i.d.R. automatisch erkannt; erforderlich für das Senden von Sked-Paketen.
|
||||
|
||||
- das geloggte Rufzeichen,
|
||||
- die native Win-Test-Band-ID und
|
||||
- einen gültigen Locator, sofern er im Paket enthalten ist.
|
||||
**Einstellungen im Reiter „TRX-Synchronisation":**
|
||||
- `Win-Test STATUS QRG Sync`: Wenn aktiviert, übernimmt KST4Contest die aktuelle Transceiverfrequenz aus dem Win-Test STATUS-Paket als eigene QRG (MYQRG).
|
||||
- `Use pass frequency from Win-Test STATUS`: Statt der eigenen TRX-QRG wird die im STATUS-Paket enthaltene Pass-Frequenz als MYQRG verwendet (für Multi-Op-Setups, bei denen mit einer Pass-QRG gearbeitet wird).
|
||||
- `Win-Test station name filter`: Wird hier ein Name eingetragen (z.B. "STN1"), verarbeitet KST4Contest nur Pakete dieser Win-Test-Instanz. Leer lassen, um alle zu akzeptieren.
|
||||
|
||||
Die Band-IDs für 50 und 70 MHz werden ebenso verarbeitet wie die VHF-, UHF- und SHF-Bänder. Das Rufzeichen wird global und auf dem erkannten Band als gearbeitet markiert. Liegt zusätzlich ein Locator vor, wird dessen vierstelliges Großfeld für dieses Band gespeichert.
|
||||
|
||||
Die Daten werden in derselben internen Datenbank abgelegt wie Worked-Informationen aus den übrigen QSO-UDP-Schnittstellen und nach einem Neustart wiederhergestellt.
|
||||
|
||||
#### Skeds an Win-Test übergeben
|
||||
|
||||
Mit **Create sked** wird zunächst ein interner KST4Contest-Sked angelegt. Ist der Win-Test-Netzwerk-Listener aktiviert, versucht KST4Contest anschließend automatisch, den Sked als `ADDSKED` an das Win-Test-Netzwerk zu übertragen.
|
||||
|
||||
Die QRG wird in folgender Reihenfolge bestimmt:
|
||||
|
||||
1. KST4Contest sucht die neueste, höchstens 30 Minuten alte QRG der Gegenstation auf dem ausdrücklich ausgewählten Band. Dabei werden aktive Varianten desselben Basisrufzeichens gemeinsam ausgewertet.
|
||||
2. Fehlt eine solche QRG, wird die eigene QRG der Chat-Kategorie geprüft, in der der Sked angelegt wurde. Sie wird nur verwendet, wenn sie sich auswerten lässt und tatsächlich zum ausgewählten Band gehört.
|
||||
3. Kann auf keinem dieser Wege eine passende QRG ermittelt werden, wird kein `ADDSKED` gesendet.
|
||||
|
||||
Eine feste Ersatzfrequenz wie `144.300` wird bewusst nicht verwendet. Eine technisch erfolgreiche Übergabe mit falschem Band oder falscher QRG wäre im Contestbetrieb schlechter als eine sichtbar ausgelassene Übergabe.
|
||||
|
||||
Der interne Sked bleibt in jedem Fall erhalten. Das gilt auch bei einer ungültigen Broadcast-Adresse, einem Netzwerkfehler oder einem nicht erreichbaren Win-Test-Client.
|
||||
|
||||
#### Behandlung von KST-Rufzeichensuffixen
|
||||
|
||||
KST-Suffixe kennzeichnen häufig den verwendeten Chat-Login oder ein Band. Sie gehören nicht in jedem Fall zum Logrufzeichen. Für Win-Test entfernt KST4Contest deshalb einen mit `-` abgetrennten KST-Suffix, erhält aber portable und internationale Rufzeichenbestandteile:
|
||||
|
||||
| Rufzeichen im KST-Chat | Übergabe an Win-Test |
|
||||
|---|---|
|
||||
| `DN9APW-2` | `DN9APW` |
|
||||
| `9A0BB-70` | `9A0BB` |
|
||||
| `EA5/G8MBI/P-70` | `EA5/G8MBI/P` |
|
||||
| `DN9APW-2/P` | `DN9APW/P` |
|
||||
|
||||
Innerhalb von KST4Contest bleibt das vollständige Rufzeichen erhalten. Timeline, Reminder-PMs und Chat-Kategorie beziehen sich weiterhin auf den konkret ausgewählten Login.
|
||||
|
||||
#### Mode, Zeitpunkt und Notizen
|
||||
|
||||
Der Mode wird beim Anlegen des Skeds ausdrücklich als `SSB` oder `CW` gewählt. Eine automatische Ableitung aus der QRG findet nicht statt, weil eine begrenzte Liste angenommener Bandsegmente nicht alle unterstützten VHF-, UHF- und SHF-Bänder zuverlässig abbilden kann.
|
||||
|
||||
KST4Contest überträgt den tatsächlichen Sked-Zeitpunkt ohne einen zusätzlichen Minutenversatz. Die Notizen enthalten – soweit bekannt – Locator und QTF sowie den Hinweis, dass der Sked über KST4Contest angelegt wurde.
|
||||
|
||||
Für die Übergabe sendet KST4Contest die Win-Test-Pakete `LOCKSKED`, `ADDSKED` und `UNLOCKSKED`.
|
||||
|
||||
|
||||
|
||||
#### Einstellungen
|
||||
|
||||
Im Reiter **Log sync**:
|
||||
|
||||
- `Receive Win-Test network based UDP log messages`
|
||||
- `UDP-Port for Win-Test listener`, standardmäßig `9871`
|
||||
- `KST station name in Win-Test network (src of SKED packets)`
|
||||
- `Win-Test network broadcast address`
|
||||
|
||||
Im Reiter **TRX sync**:
|
||||
|
||||
- `Win-Test STATUS QRG Sync`
|
||||
- `Use pass frequency from Win-Test STATUS`
|
||||
- `Win-Test station name filter`
|
||||
|
||||
Das Win-Test-Netzwerk muss in Win-Test aktiviert sein. Bei mehreren Computern muss die Broadcast-Adresse das betreffende lokale Netzwerk erreichen. Der Stationsname sollte die sendende KST4Contest-Instanz innerhalb des Win-Test-Netzwerks eindeutig erkennen lassen.
|
||||
|
||||
Ausführliche Beschreibung der Einstellungen: [Win-Test-Netzwerk-Listener](de-Konfiguration#win-test-netzwerk-listener-ab-v131)
|
||||
**Einstellungen in Win-Test:**
|
||||
- Das Netzwerk in Win-Test muss aktiv sein.
|
||||
- Win-Test muss so konfiguriert sein, dass es seine Broadcasts an den entsprechenden Port (Standard 9871) sendet bzw. empfängt.
|
||||
|
||||
---
|
||||
|
||||
## TRX-Frequenz-Synchronisation
|
||||
|
||||
@@ -191,16 +144,6 @@ Für DM5M-typische Setups (2 Radios, 2 Computer, eine KST4Contest-Instanz oder z
|
||||
|
||||
## Interne Datenbank
|
||||
|
||||
KST4Contest speichert Worked-, NOT-QRV- und Großfeldinformationen in einer eigenen SQLite-Datenbank. Sie ist von der Datenbank des Logprogramms unabhängig.
|
||||
KST4Contest speichert die Worked-Information in einer internen **SQLite-Datenbank**. Diese ist von der Logprogramm-Datenbank unabhängig und wird nur über den UDP-Broadcast befüllt.
|
||||
|
||||
Die Datenquellen liefern unterschiedlich genaue Informationen:
|
||||
|
||||
| Quelle | Rufzeichen global | Bandbezogen | Großfeld |
|
||||
|---|---:|---:|---:|
|
||||
| Simplelogfile | ja | nein | nein |
|
||||
| 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 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.
|
||||
|
||||
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).
|
||||
Vor jedem neuen Contest: Datenbank zurücksetzen! → [Konfiguration – Worked Station Database Settings](Konfiguration#worked-station-database-settings)
|
||||
|
||||
@@ -2,363 +2,161 @@
|
||||
|
||||
> 🇬🇧 [English version](en-Macros-and-Variables) | 🇩🇪 Du liest gerade die deutsche Version
|
||||
|
||||
KST4Contest unterscheidet zwischen Shortcut-Schaltflächen, Text-Snippets und Variablen. Shortcuts und Snippets enthalten vorbereitete Texte. Variablen ergänzen Informationen, die sich während des Betriebs ändern können.
|
||||
|
||||
Der eingefügte Text bleibt im Sendfeld sichtbar und kann vor dem Senden geprüft oder geändert werden.
|
||||
KST4Contest bietet ein flexibles System aus Text-Snippets, Shortcuts und eingebauten Variablen, die den Chat-Workflow im Contest erheblich beschleunigen.
|
||||
|
||||
---
|
||||
|
||||
## Überblick
|
||||
|
||||
| Mechanismus | Aufruf | Verwendung |
|
||||
| Typ | Aufruf | Zweck |
|
||||
|---|---|---|
|
||||
| **Shortcut** | Schaltfläche oberhalb des Sendfeldes | Fügt einen konfigurierten Text in das Sendfeld ein |
|
||||
| **Snippet** | Kontextmenü oder `Ctrl+1` bis `Ctrl+0` | Bereitet einen Text für die ausgewählte Station vor |
|
||||
| **Variable** | Platzhalter innerhalb eines Nachrichtentextes | Fügt aktuelle QRG-, Locator-, Richtungs-, Stations- oder AirScout-Informationen ein |
|
||||
|
||||
Shortcuts und Snippets speichern Texte. Variablen liefern die dazugehörigen aktuellen Werte.
|
||||
|
||||
Ein Shortcut wie
|
||||
|
||||
```text
|
||||
pse sked?
|
||||
```
|
||||
|
||||
fügt immer denselben Text ein. Ein Shortcut mit
|
||||
|
||||
```text
|
||||
pse call me at MYQRGSHORT
|
||||
```
|
||||
|
||||
verwendet dagegen die QRG, die beim Anklicken des Shortcuts aktuell in KST4Contest hinterlegt ist.
|
||||
| **Shortcuts** | Button in der Toolbar | Schneller Text-Insert ins Sendfeld |
|
||||
| **Snippets** | Rechtsklick / Ctrl+1..0 | Text-Bausteine, optionaler PM-Versand |
|
||||
| **Variablen** | In allen Text-Feldern verwendbar | Dynamische Werte (QRG, Locator, AP-Daten) |
|
||||
|
||||
---
|
||||
|
||||
## Shortcut-Schaltflächen
|
||||
## Shortcuts (Schnellzugriff-Schaltflächen)
|
||||
|
||||
Shortcuts werden unter **Preferences → Shortcut Settings** konfiguriert.
|
||||
Konfigurierbar in den Preferences → **Shortcut Settings**.
|
||||
|
||||
|
||||
- Jeder konfigurierte Text erzeugt **einen Button** in der Benutzeroberfläche.
|
||||
- Ein Klick fügt den Text in das **Sendfeld** ein.
|
||||
- **Alle Variablen** können in Shortcuts verwendet werden und werden beim Einfügen sofort aufgelöst.
|
||||
- Auch längere Texte möglich.
|
||||
|
||||
Jeder Eintrag erzeugt eine Schaltfläche im Hauptfenster. Ein Klick hängt den konfigurierten Text an den vorhandenen Inhalt des Sendfeldes an. Ein bereits vorbereiteter Nachrichtentext wird dabei nicht gelöscht.
|
||||
|
||||
Enthält der Shortcut eine Variable, wird sie beim Einfügen aufgelöst. Aus
|
||||
|
||||
```text
|
||||
pse call me at MYQRGSHORT
|
||||
```
|
||||
|
||||
kann beispielsweise werden:
|
||||
|
||||
```text
|
||||
pse call me at 144.388
|
||||
```
|
||||
|
||||
Die exakten Einträge `MYQRG` und `SECONDQRG` werden als QRG-Schaltflächen hervorgehoben. Sie fügen die aktuelle QRG der ersten beziehungsweise zweiten Chat-Kategorie ein.
|
||||
|
||||
Auch der Shortcut
|
||||
|
||||
```text
|
||||
/SETNAME MYQRG
|
||||
```
|
||||
|
||||
wird hervorgehoben. Beim Anklicken wird `MYQRG` aufgelöst und der daraus entstehende Serverbefehl in das Sendfeld übernommen. Der Befehl wird nicht automatisch gesendet.
|
||||
|
||||
Die Reihenfolge der Einträge in den Einstellungen bestimmt die Reihenfolge der Schaltflächen im Hauptfenster. Bearbeitung, Sortierung und Speicherung sind unter [Konfiguration – Shortcut Settings](de-Konfiguration#shortcut-settings-schnellzugriff-schaltflächen) beschrieben.
|
||||
**Tipp**: Häufig verwendete Abkürzungen wie „pse", „rrr", „tnx", „73" als Shortcuts anlegen.
|
||||
|
||||
---
|
||||
|
||||
## Text-Snippets
|
||||
## Snippets (Text-Bausteine)
|
||||
|
||||
Snippets werden unter **Preferences → Snippet Settings** konfiguriert. Sie sind vor allem für wiederkehrende Nachrichten an eine bestimmte Station vorgesehen.
|
||||
Konfigurierbar in den Preferences → **Snippet Settings**.
|
||||
|
||||
Snippets können aufgerufen werden:
|
||||
### Aufruf
|
||||
|
||||
- per Rechtsklick auf eine Station in der Benutzerliste,
|
||||
- per Rechtsklick auf eine öffentliche Nachricht,
|
||||
- per Rechtsklick auf eine Privatnachricht oder
|
||||
- mit `Ctrl+1` bis `Ctrl+0` für die ersten zehn Einträge der Snippet-Liste.
|
||||
- **Rechtsklick** auf ein Rufzeichen in der Benutzerliste
|
||||
- **Rechtsklick** in der CQ-Nachrichtentabelle
|
||||
- **Rechtsklick** in der PM-Nachrichtentabelle
|
||||
- **Tastaturkürzel**: `Ctrl+1` bis `Ctrl+0` für die ersten 10 Snippets
|
||||
|
||||
### Verwendung über das Kontextmenü
|
||||
### Verhalten mit ausgewähltem Rufzeichen
|
||||
|
||||
Die Auswahl einer Station oder Nachricht bereitet normalerweise bereits den passenden `/cq`-Empfänger im Sendfeld vor. Das anschließend im Kontextmenü ausgewählte Snippet wird an diesen Text angehängt.
|
||||
Wenn in der Benutzerliste ein Rufzeichen ausgewählt ist, wird der Snippet als **Privatnachricht** adressiert:
|
||||
|
||||
Ein bereits vorhandener Nachrichtentext kann dadurch gezielt erweitert werden.
|
||||
|
||||
### Verwendung über die Tastatur
|
||||
|
||||
Ein mit `Ctrl+1` bis `Ctrl+0` aufgerufenes Snippet ersetzt den bisherigen Inhalt des Sendfeldes durch eine vollständig adressierte Nachricht:
|
||||
|
||||
```text
|
||||
/cq RUFZEICHEN Snippet-Text
|
||||
```
|
||||
/CQ RUFZEICHEN <Snippet-Text>
|
||||
```
|
||||
|
||||
Das vollständige sichtbare Rufzeichen einschließlich eines vorhandenen Suffixes bleibt erhalten. Für die ausgewählte Station `9A0BB-70` kann beispielsweise entstehen:
|
||||
Anschließend kann mit **Enter** direkt gesendet werden – auch wenn das Sendfeld nicht den Fokus hat.
|
||||
|
||||
```text
|
||||
/cq 9A0BB-70 pse ur qrg?
|
||||
```
|
||||
### Hardware-Makro-Tastatur
|
||||
|
||||
KST4Contest behält intern auch die Chat-Kategorie der ausgewählten Station bei. Ein Snippet für `9A0BB-70` wird deshalb nicht versehentlich über die andere aktive Chat-Kategorie gesendet.
|
||||
*(Idee von IU3OAR, Gianluca Costantino)*
|
||||
|
||||
Ist keine Station ausgewählt oder existiert für die gedrückte Tastenkombination kein Snippet, wird nichts eingefügt.
|
||||
Die Tastenkombinationen `Ctrl+1` bis `Ctrl+0` können auf einer programmierbaren Makro-Tastatur belegt werden. Ein weiterer Tastendruck (auf eine „Enter"-Taste) sendet den Text sofort. Im Contest-Betrieb spart das erheblich Zeit.
|
||||
|
||||
Der vorbereitete Text wird nicht automatisch versendet:
|
||||
### Vordefinierte Standard-Snippets
|
||||
|
||||
- `Enter` oder **TX** sendet die Nachricht.
|
||||
- `Esc` leert das Sendfeld.
|
||||
Beim ersten Start werden einige Snippets vorbelegt, z. B.:
|
||||
|
||||
### Zuordnung der Tastenkombinationen
|
||||
- `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`
|
||||
|
||||
Die Zuordnung folgt der Reihenfolge in der Snippet-Liste:
|
||||
|
||||
| Tastenkombination | Verwendeter Eintrag |
|
||||
|---|---:|
|
||||
| `Ctrl+1` | erster Eintrag |
|
||||
| `Ctrl+2` | zweiter Eintrag |
|
||||
| … | … |
|
||||
| `Ctrl+9` | neunter Eintrag |
|
||||
| `Ctrl+0` | zehnter Eintrag |
|
||||
|
||||
Die Tastenkombinationen können auch einer programmierbaren Makro-Tastatur zugewiesen werden. Die Idee zu dieser Bedienung stammt von IU3OAR, Gianluca Costantino.
|
||||
|
||||
KST4Contest legt keine verbindliche Liste von Standard-Snippets fest. Welche Texte sinnvoll sind, hängt vom eigenen Contestbetrieb und der verwendeten Betriebsart ab.
|
||||
|
||||
Bearbeitung, Sortierung und Speicherung sind unter [Konfiguration – Snippet Settings](de-Konfiguration#snippet-settings-text-snippets) beschrieben.
|
||||
Diese können in den Preferences angepasst oder gelöscht werden.
|
||||
|
||||
---
|
||||
|
||||
## Variablen
|
||||
|
||||
Variablen sind reservierte Platzhalter innerhalb eines Nachrichtentextes. Sie müssen in Großbuchstaben geschrieben werden und unterscheiden zwischen Groß- und Kleinschreibung.
|
||||
Variablen werden in geschriebenen Texten (Snippets, Shortcuts, Beacon, Sendfeld) durch ihre aktuellen Werte ersetzt. Einfach den Variablennamen **großgeschrieben** in den Text einfügen.
|
||||
|
||||
Variablen können verwendet werden in:
|
||||
### MYQRG
|
||||
|
||||
- Shortcuts,
|
||||
- Snippets,
|
||||
- Beacon-Texten und
|
||||
- direkt eingegebenen oder eingefügten Nachrichtentexten.
|
||||
Wird durch die aktuelle Transceiverfrequenz ersetzt.
|
||||
|
||||
Bei einem Shortcut oder Snippet werden die Variablen bereits beim Einfügen in das Sendfeld aufgelöst. Direkt in das Sendfeld geschriebene oder eingefügte Variablen werden unmittelbar vor der Übernahme in die Sendewarteschlange aufgelöst.
|
||||
- Quelle: TRX-Sync via UDP vom Logprogramm (wenn aktiviert)
|
||||
- Fallback: Manuell eingetragener Wert im MYQRG-Textfeld rechts neben dem Sendbutton
|
||||
- Format: `144.388.03`
|
||||
|
||||
Stationsbezogene Variablen verwenden immer die aktuell ausgewählte Station. KST4Contest leitet diese Station nicht aus einem von Hand in den Nachrichtentext geschriebenen `/cq`-Empfänger ab.
|
||||
**Beispiel**: `calling cq at MYQRG` → `calling cq at 144.388.03`
|
||||
|
||||
---
|
||||
### MYQRGSHORT
|
||||
|
||||
## Globale Variablen
|
||||
Wie MYQRG, aber nur die ersten 7 Zeichen.
|
||||
|
||||
Globale Variablen benötigen keine ausgewählte Gegenstation.
|
||||
- Format: `144.388`
|
||||
|
||||
| Variable | Ersetzter Wert |
|
||||
|---|---|
|
||||
| `MYQRG` | aktuelle QRG der ersten beziehungsweise primären Chat-Kategorie |
|
||||
| `MYQRGSHORT` | erste sieben Zeichen von `MYQRG` |
|
||||
| `SECONDQRG` | aktuelle QRG der zweiten Chat-Kategorie |
|
||||
| `MYLOCATOR` | vollständiger Locator der eigenen Station |
|
||||
| `MYLOCATORSHORT` | erste vier Zeichen des eigenen Locators |
|
||||
| `MYCALL` | konfiguriertes eigenes Rufzeichen |
|
||||
| `MYQTF` | aktuelle Antennenrichtung als numerischer Wert in Grad |
|
||||
**Beispiel**: `qrg: MYQRGSHORT` → `qrg: 144.388`
|
||||
|
||||
Beispiel:
|
||||
### MYLOCATOR
|
||||
|
||||
```text
|
||||
cq at MYQRGSHORT, qtf MYQTF, loc MYLOCATOR
|
||||
```
|
||||
Wird durch den eigenen Maidenhead-Locator (6-stellig) ersetzt.
|
||||
|
||||
kann aufgelöst werden zu:
|
||||
- Format: `JO51IJ`
|
||||
|
||||
```text
|
||||
cq at 144.388, qtf 135, loc JO51IJ
|
||||
```
|
||||
**Beispiel**: `my loc: MYLOCATOR` → `my loc: JO51IJ`
|
||||
|
||||
### QRG-Variablen
|
||||
### MYLOCATORSHORT
|
||||
|
||||
`MYQRG` enthält die QRG der ersten Chat-Kategorie. Der Wert kann aus der TRX-Synchronisation des Logprogramms oder aus dem manuell bearbeiteten QRG-Feld stammen.
|
||||
Wie MYLOCATOR, aber nur die ersten 4 Zeichen.
|
||||
|
||||
`MYQRGSHORT` verwendet denselben Wert, beschränkt ihn aber auf die ersten sieben Zeichen:
|
||||
- Format: `JO51`
|
||||
|
||||
```text
|
||||
144.388.03 → 144.388
|
||||
```
|
||||
|
||||
`SECONDQRG` enthält die QRG der zweiten Chat-Kategorie. Die Auswahl einer Station aus dem zweiten Chat verändert die Bedeutung von `MYQRG` nicht. Soll ausdrücklich die QRG der zweiten Kategorie eingesetzt werden, muss `SECONDQRG` verwendet werden.
|
||||
|
||||
### Locator-Variablen
|
||||
|
||||
`MYLOCATOR` übernimmt den vollständigen konfigurierten Locator der eigenen Station:
|
||||
|
||||
```text
|
||||
JO51IJ
|
||||
```
|
||||
|
||||
`MYLOCATORSHORT` verwendet nur die ersten vier Zeichen:
|
||||
|
||||
```text
|
||||
JO51
|
||||
```
|
||||
|
||||
### MYQTF
|
||||
|
||||
`MYQTF` übernimmt die aktuelle, in KST4Contest hinterlegte Antennenrichtung als numerischen Winkel in Grad.
|
||||
|
||||
Beispiel:
|
||||
|
||||
```text
|
||||
ant MYQTF deg
|
||||
```
|
||||
|
||||
kann werden zu:
|
||||
|
||||
```text
|
||||
ant 135 deg
|
||||
```
|
||||
|
||||
Die Richtung wird nicht in Himmelsrichtungen wie `north`, `north-east` oder `south-west` umgewandelt.
|
||||
|
||||
---
|
||||
|
||||
## Variablen für die ausgewählte Station
|
||||
|
||||
Diese Variablen benötigen eine ausgewählte Gegenstation:
|
||||
|
||||
| Variable | Ersetzter Wert |
|
||||
|---|---|
|
||||
| `QRZNAME` | Name der ausgewählten Station oder deren vollständiges Rufzeichen, wenn kein Name verfügbar ist |
|
||||
| `FIRSTAP` | Beschreibung und Ankunftszeit des ersten von AirScout gemeldeten Flugzeugs |
|
||||
| `SECONDAP` | Beschreibung und Ankunftszeit des zweiten von AirScout gemeldeten Flugzeugs |
|
||||
|
||||
Beispiel:
|
||||
|
||||
```text
|
||||
Hi QRZNAME, FIRSTAP, pse lsn at MYQRGSHORT
|
||||
```
|
||||
|
||||
kann werden zu:
|
||||
|
||||
```text
|
||||
Hi David, a very big AP in 2 min, pse lsn at 144.388
|
||||
```
|
||||
**Beispiel**: `loc: MYLOCATORSHORT` → `loc: JO51`
|
||||
|
||||
### QRZNAME
|
||||
|
||||
KST4Contest verwendet den Namen aus dem Namensfeld der ausgewählten Station. Ist dort kein verwendbarer Name vorhanden, wird stattdessen das vollständige sichtbare Rufzeichen eingesetzt.
|
||||
Wird durch den **Namen** der aktuell ausgewählten Station aus dem Chat-Namenfeld ersetzt.
|
||||
|
||||
**Beispiel**: `Hi QRZNAME, sked?` → `Hi Gianluca, sked?`
|
||||
|
||||
### FIRSTAP
|
||||
|
||||
Ist ein AirScout-Kandidat verfügbar, enthält `FIRSTAP` dessen Beschreibung und die voraussichtliche Zeit bis zum Reflexionsfenster.
|
||||
Wird durch Daten des ersten reflektierbaren Flugzeugs zur ausgewählten Station ersetzt (sofern vorhanden).
|
||||
|
||||
Beispiel:
|
||||
- Bedingung: AirScout ist aktiv und ein Flugzeug ist verfügbar.
|
||||
- Format-Beispiel: `a very big AP in 1 min`
|
||||
|
||||
```text
|
||||
a very big AP in 2 min
|
||||
```
|
||||
|
||||
Ist für die ausgewählte Station kein Flugzeug verfügbar, wird eingesetzt:
|
||||
|
||||
```text
|
||||
no ap available
|
||||
```
|
||||
**Beispiel**: `AP info: FIRSTAP` → `AP info: a very big AP in 1 min`
|
||||
|
||||
### SECONDAP
|
||||
|
||||
`SECONDAP` verwendet den zweiten verfügbaren AirScout-Kandidaten.
|
||||
Wie FIRSTAP, aber für das zweite verfügbare Flugzeug.
|
||||
|
||||
Beispiel:
|
||||
- Format-Beispiel: `Next big AP in 9 min`
|
||||
|
||||
```text
|
||||
Next big AP in 9 min
|
||||
```
|
||||
**Beispiel**: `also: SECONDAP` → `also: Next big AP in 9 min`
|
||||
|
||||
Ist kein zweiter Kandidat vorhanden, wird `SECONDAP` durch einen leeren Text ersetzt.
|
||||
### MYQTF *(geplant für v1.3)*
|
||||
|
||||
### Verhalten ohne ausgewählte Station
|
||||
Wird durch die aktuelle Antennenrichtung in Worten ersetzt (z. B. `north`, `north east`, `east`, …).
|
||||
|
||||
Ist keine Station ausgewählt, bleiben `QRZNAME`, `FIRSTAP` und `SECONDAP` im Text sichtbar. KST4Contest entfernt diese Platzhalter nicht automatisch.
|
||||
|
||||
Ein sichtbarer, nicht aufgelöster Platzhalter ist eindeutiger als eine formal vollständige Nachricht, in der unbemerkt eine wichtige Information fehlt. Vor dem Senden sollte deshalb geprüft werden, ob die richtige Station ausgewählt ist und alle benötigten Variablen aufgelöst wurden.
|
||||
- Quelle: Winkelwert im MYQTF-Eingabefeld (rechts neben dem MYQRG-Feld)
|
||||
|
||||
---
|
||||
|
||||
## Variablen im Beacon
|
||||
|
||||
Ein öffentlicher Beacon besitzt keine ausgewählte Gegenstation. Deshalb können dort ausschließlich globale Variablen verwendet werden:
|
||||
Alle Variablen können auch im **automatischen Beacon** (Intervall-Nachrichten) verwendet werden. Empfohlene Beacon-Konfiguration:
|
||||
|
||||
- `MYQRG`
|
||||
- `MYQRGSHORT`
|
||||
- `SECONDQRG`
|
||||
- `MYLOCATOR`
|
||||
- `MYLOCATORSHORT`
|
||||
- `MYCALL`
|
||||
- `MYQTF`
|
||||
|
||||
`QRZNAME`, `FIRSTAP` und `SECONDAP` dürfen in einem Beacon nicht verwendet werden.
|
||||
|
||||
Eine mögliche Vorlage für die erste Chat-Kategorie ist:
|
||||
|
||||
```text
|
||||
calling cq at MYQRGSHORT, ant MYQTF deg, loc MYLOCATOR
|
||||
```
|
||||
calling cq at MYQRG, loc MYLOCATOR, GL all!
|
||||
```
|
||||
|
||||
Verwendet die zweite Chat-Kategorie eine andere QRG, muss deren Vorlage `SECONDQRG` enthalten:
|
||||
|
||||
```text
|
||||
calling cq at SECONDQRG, ant MYQTF deg, loc MYLOCATOR
|
||||
```
|
||||
|
||||
Die globalen Variablen werden bei jedem Timer-Lauf erneut ausgewertet. Eine inzwischen vom Logprogramm aktualisierte QRG kann dadurch bereits in der nächsten Beacon-Nachricht erscheinen.
|
||||
|
||||
Der vollständig aufgelöste Beacon-Text:
|
||||
|
||||
- muss mindestens ein gültiges Zeichen enthalten,
|
||||
- darf höchstens 120 Zeichen lang sein,
|
||||
- darf das Protokoll-Trennzeichen `|` nicht enthalten und
|
||||
- darf keine Zeilenumbrüche enthalten.
|
||||
|
||||
Ist der Text beim vorgesehenen Versand leer oder ungültig, wird der betreffende Beacon-Lauf ausgelassen.
|
||||
|
||||
Intervall, Aktivierung und Verhalten beider Kategorien sind unter [Konfiguration – Beacon Settings](de-Konfiguration#beacon-settings-automatischer-beacon) beschrieben.
|
||||
Da KST4Contest QRG-Daten automatisch aus Chat-Nachrichten ausliest: Wenn andere Stationen ebenfalls KST4Contest nutzen, sehen sie die eigene QRG sofort in der QRG-Spalte der Benutzerliste.
|
||||
|
||||
---
|
||||
|
||||
## Beispiel für einen Snippet-Workflow
|
||||
## Beispiel-Workflow mit Makros im Contest
|
||||
|
||||
Als erstes Snippet ist beispielsweise konfiguriert:
|
||||
1. Station in der Benutzerliste auswählen → Rufzeichen ist nun vorausgewählt.
|
||||
2. `Ctrl+1` drücken → Snippet „Hi OM, try sked?" wird als PM adressiert.
|
||||
3. Enter drücken → Nachricht wird gesendet.
|
||||
4. Station antwortet mit Frequenz → QRG-Spalte wird automatisch befüllt.
|
||||
5. `Ctrl+2` → Snippet „I am calling cq ur dir, pse lsn to me at 144.388" (MYQRG aufgelöst).
|
||||
6. Enter → Gesendet.
|
||||
|
||||
```text
|
||||
Hi QRZNAME, pse sked? I call at MYQRGSHORT
|
||||
```
|
||||
|
||||
Der Ablauf kann dann folgendermaßen aussehen:
|
||||
|
||||
1. In der Benutzerliste wird `DL1ABC-432` ausgewählt.
|
||||
2. `Ctrl+1` wird gedrückt.
|
||||
3. KST4Contest bereitet die adressierte Nachricht vor und löst die Variablen auf.
|
||||
4. Der vollständige Text wird im Sendfeld geprüft.
|
||||
5. Falls die Gegenstation eine andere QRG vorgeschlagen hat, wird der Text entsprechend angepasst.
|
||||
6. `Enter` oder **TX** sendet die Nachricht.
|
||||
|
||||
Das Ergebnis kann beispielsweise lauten:
|
||||
|
||||
```text
|
||||
/cq DL1ABC-432 Hi Peter, pse sked? I call at 432.088
|
||||
```
|
||||
|
||||
Das vollständige Rufzeichen bestimmt den Empfänger. Die ausgewählte Chat-Kategorie bestimmt den Versandweg. Die Variablen verringern die wiederholte Texteingabe, entscheiden aber nicht, ob die eingesetzten Informationen noch zur aktuellen Betriebssituation passen.
|
||||
|
||||
---
|
||||
|
||||
## Grenzen der Variablenauflösung
|
||||
|
||||
Variablen geben den Informationsstand wieder, den KST4Contest im Moment der Auflösung besitzt.
|
||||
|
||||
Dabei ist insbesondere zu beachten:
|
||||
|
||||
- Eine vom Logprogramm gelieferte QRG kann sich inzwischen geändert haben.
|
||||
- Eine manuell eingetragene QRG bleibt aktiv, bis sie erneut geändert wird.
|
||||
- `MYQRG` bleibt die QRG der primären Kategorie, auch wenn eine Station aus der zweiten Kategorie ausgewählt wurde.
|
||||
- Die ausgewählte Station kann von einem manuell eingegebenen `/cq`-Empfänger abweichen.
|
||||
- AirScout kann für die betreffende Strecke keine aktuellen Flugzeugdaten liefern.
|
||||
- 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.
|
||||
Ohne manuelle Tipparbeit, ohne Fehler, ohne Unterbrechung des CQ-Rufens.
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 961 KiB |
@@ -107,7 +107,7 @@ Aircraft data can be inserted directly into 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)
|
||||
Details: [Macros and Variables](Macros-and-Variables#variables)
|
||||
|
||||
---
|
||||
|
||||
|
||||
+1
-179
@@ -4,187 +4,9 @@
|
||||
|
||||
Version history of KST4Contest / PraktiKST.
|
||||
|
||||
Published Stable versions and their application packages are available under [GitHub Releases](https://github.com/praktimarc/kst4contest/releases). This page also lists changes from the current development version where they have already been implemented and tested.
|
||||
|
||||
---
|
||||
|
||||
## v1.42 – Nightly / in development
|
||||
|
||||
> Status of this section: 14 August 2026.
|
||||
> v1.42 is not a published Stable release yet. Further changes may be added before release.
|
||||
|
||||
v1.42 brings several previously separate calculations together. Band information, Worked status, NOT-QRV marks, callsign suffixes and frequencies are now used more consistently by the user list, station map, priority calculation and external interfaces.
|
||||
|
||||
### Added
|
||||
|
||||
- **Visible ON4KST connection state:** A compact `LINK` indicator in the main window displays the actual state of the ON4KST connection. Green means fully authenticated and synchronised, yellow indicates connection setup or synchronisation, and red indicates a lost connection, an error or the delay before the next connection attempt.
|
||||
|
||||
- **Shared band-opportunity calculation:** A central `BandOpportunityResolver` evaluates recent QRGs, band designators in station names, active callsign variants, Worked information and NOT-QRV marks. The user list, **New bands**, band-upgrade hint, Priority Score, station map and automatic band selection now use the same basis.
|
||||
|
||||
- **Extended band status display:** The band columns now distinguish:
|
||||
- `X` for worked on this band,
|
||||
- `a` for an offered and unworked band of a completely new callsign,
|
||||
- `B+` for an offered and unworked band of a callsign already worked elsewhere, and
|
||||
- `o` for a locator square already worked on this band.
|
||||
|
||||
The codes can be combined, for example as `ao` or `B+o`. The additional `a` and `o` indicators can be hidden separately in the GUI settings.
|
||||
|
||||
- **50 and 70 MHz support:** Both bands are available in station settings, Worked and NOT-QRV handling, the user list, filters, the internal database, UCXLog processing and the Win-Test listener. Existing databases are extended with the required columns.
|
||||
|
||||
- **Global message tabs:** Public messages, ON4KST DX cluster messages and directed messages between other stations can be displayed directly in the main window. The existing separate monitor window remains available and uses the same underlying message stores.
|
||||
|
||||
- **Manual QTF input:** The current antenna direction can be changed directly in KST4Contest when PSTRotator is not being used.
|
||||
|
||||
- **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.
|
||||
|
||||
- **Hideable path analysis:** The terrain profile and analysis section of the station map can be hidden completely. The selected state is stored and restored at the next application start.
|
||||
|
||||
### Changed
|
||||
|
||||
- **Session-based ON4KST connection lifecycle:** Each socket, reader, writer, message bus and queue now belongs to an explicitly identified connection session. Delayed threads from an obsolete connection can therefore no longer process data or close its replacement. `ONLINE` is reported only after the login has been accepted and all requested user lists have been received. Connection setup, login and synchronisation use bounded timeouts, while heartbeats, missing inbound traffic, EOF and read or write failures trigger controlled reconnect attempts with backoff where appropriate.
|
||||
|
||||
- **Validated ON4KST protocol commands:** Outgoing frames are built centrally and checked for valid categories, locators and prohibited frame delimiters. Because ON4KST maintains one locator per TCP session, the main locator is used for both chat categories and a conflicting secondary configuration is logged instead of sending contradictory commands to the server.
|
||||
|
||||
- **More precise QRG recognition:** Complete and relative frequency references continue to be recognised. Bare three-digit numbers are treated as QRGs only when a frequency context is available. Signal reports, band designators and unrelated numbers therefore produce fewer false frequencies.
|
||||
|
||||
- **Station-specific frequency context:** For relative QRGs, KST4Contest first uses a band context for the same station which is no more than 30 minutes old. The globally configured fallback band is used only when this context is unavailable.
|
||||
|
||||
- **Fallback band dropdown:** The global fallback can only be selected from supported band values. It applies to the complete QRG parser, not merely to DX cluster spots.
|
||||
|
||||
- **Consistent QRG formatting:** Frequencies are displayed with at least three decimal places in the user list and message tables.
|
||||
|
||||
- **Band-aware AirScout and path calculations:** KST4Contest derives a realistic frequency for each station from its current QRG and known band information. AirScout receives canonical band values. The temporary 430 MHz fallback has been replaced with 432 MHz.
|
||||
|
||||
- **Shared propagation-frequency selection:** AirScout, **Calc selected** and the station-map path analysis use the same `PropagationFrequencyResolver`. A band selected explicitly in the Reachability dropdown is respected for manual calculations.
|
||||
|
||||
- **Separate callsign variants:** Active chat members are distinguished by their complete callsign, including suffix, and by chat category. `DN9APW`, `DN9APW-2` and similar logins therefore remain separate message targets.
|
||||
|
||||
- **Shared base-callsign information:** Worked flags, NOT-QRV information and Priority Scores continue to be evaluated across variants of the same base callsign. Separate message targets no longer result in contradictory Worked information.
|
||||
|
||||
- **Corrected Priority Score eligibility:** Stations without a common available band, or with an overriding NOT-QRV mark, are no longer offered as priority candidates. An open band at a station already worked elsewhere can receive a separate Priority Boost.
|
||||
|
||||
- **Extended sked creation:** The band is selected from those enabled locally. `SSB` or `CW` is selected explicitly for the Win-Test handover instead of attempting to infer the mode unreliably from the band.
|
||||
|
||||
- **More precise Win-Test sked handover:** The QRG must belong to the selected band. Visible KST suffixes are removed for the logging target while portable callsign components are preserved. `ADDSKED` timestamps are generated correctly. A failed handover does not remove the internal KST4Contest sked.
|
||||
|
||||
- **Exact sked targets:** The timeline and automatic reminders use the complete visible KST callsign. A sked for `DN9APW-2` is not accidentally sent to another variant of the same base callsign.
|
||||
|
||||
- **Reworked beacon and automatic replies:** Both chat categories use one shared timer while retaining separate enable switches and message texts. The minimum permitted interval is two minutes and message texts are limited to 120 characters. The stored beacon state is restored from the configuration at startup.
|
||||
|
||||
- **Central variable resolution:** Message variables used by beacons, shortcuts, snippets and other generated text are processed by one shared resolver.
|
||||
|
||||
- **Improved message tables:** Truncated messages show their complete text in a tooltip. Recognised web addresses can be opened in the system browser.
|
||||
|
||||
- **More compact filter bar:** Filters retain their compact arrangement at normal widths and wrap only when the available space is genuinely insufficient. This allows the centre divider to be moved further to the right.
|
||||
|
||||
- **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.
|
||||
|
||||
- **Improved version comparison:** Versions are compared semantically so that patch releases and Nightly versions are not misclassified by conversion to a floating-point number.
|
||||
|
||||
### Fixed
|
||||
|
||||
- **Reliable initial user list:** Invalid or incomplete `UA0` member records are rejected and logged individually without preventing alphabetically following members from being processed. Valid entries are staged per category and published as one complete snapshot when the first corresponding `UE` end marker is received.
|
||||
|
||||
- **User list disappearing after login:** ON4KST may send additional `UE` frames for the same category after name, state or other live updates. Repeated end markers are now detected and ignored so that an already populated user list cannot be replaced by an empty snapshot.
|
||||
|
||||
- **Failed initial connection and lost sockets:** An unavailable server during startup no longer sends KST4Contest into an endless or busy-wait loop. The user interface remains responsive and further attempts use bounded reconnect backoff. Sockets closed by the server, or connections without inbound traffic for an excessive period, are also detected reliably.
|
||||
|
||||
- **Message-bus diagnostics:** Correctly processed ON4KST frames are no longer reported additionally as `Critical, detected unhandled Chatmessage`. Only genuinely unknown frames reach the fallback diagnostic branch.
|
||||
|
||||
- **Long-running station-selection failure:** Chat members managed by the message thread have been decoupled from the JavaFX view. Simultaneous data and table updates therefore no longer cause broken selection models or concurrent-modification problems after longer runtimes.
|
||||
|
||||
- **No phantom chat members from UM3:** Historical or additional server messages no longer create user-list entries for stations which are not actually logged into the chat.
|
||||
|
||||
- **Messages to callsigns with suffixes:** Several active variants of the same base callsign no longer overwrite each other. This resolves [Issue #73](https://github.com/praktimarc/kst4contest/issues/73).
|
||||
|
||||
- **DX cluster locators:** The reporting and reported station no longer receive the same locator accidentally. This resolves [Issue #48](https://github.com/praktimarc/kst4contest/issues/48).
|
||||
|
||||
- **Worked state in “QSO of the other”:** The Worked columns again use the correct transmitting and receiving station.
|
||||
|
||||
- **Missing SECONDAP data:** A missing second aircraft-scatter opportunity no longer produces an invalid text selection and JavaFX exception when the field is edited.
|
||||
|
||||
- **Historical callsigns:** Highlighting or selecting a callsign which is no longer present in the active user list no longer causes an exception.
|
||||
|
||||
- **Win-Test sked time and callsign handling:** Timestamps, band-to-QRG assignment, KST suffixes and portable callsigns are handled correctly.
|
||||
|
||||
- **Filter reset:** All filter predicates are actually removed, and the visible button state again matches the effective filter state.
|
||||
|
||||
### Documentation and packaging
|
||||
|
||||
- The German and English manuals have been systematically checked against the source code, extended and supplied with current screenshots. The documentation now describes not only the controls, but also how information is derived and where the limits of a result lie.
|
||||
|
||||
- The AUR provides `kst4contest-bin`, `kst4contest` and `kst4contest-git` for Arch Linux.
|
||||
|
||||
- The download page distinguishes between Stable, Beta and Nightly and offers only packages which actually belong to the corresponding channel.
|
||||
|
||||
- Nightly packages are built automatically from the current `main` branch. Stable and Beta releases use predictable asset names for the supported platforms.
|
||||
|
||||
- **Signed and notarized macOS packages:** The DMG files for Apple Silicon and Intel are signed with an Apple Developer ID and notarized by Apple, with the notarization ticket stapled into the DMG. The first launch now works by double-clicking, without the previous detour through **Open** in the context menu, and the check also succeeds without an internet connection. This applies to Nightly, Beta and Stable packages alike. The Windows packages remain unsigned.
|
||||
|
||||
- **Correct bundle identifier and version on macOS:** The application now identifies itself as `de.x08.KST4Contest` rather than `kst4contest.view`, and carries its actual version number in the bundle. Previously every release reported version `1.0` in Finder's **Get Info** panel. Existing settings are unaffected, because KST4Contest stores its data in `~/.praktiKST/` rather than keying it to the bundle identifier.
|
||||
|
||||
### Known limitations
|
||||
|
||||
- The active terrain provider uses Open-Meteo with Copernicus GLO-90 data and no more than 100 elevation samples per path.
|
||||
|
||||
- The atmospheric K factor is currently fixed at `4/3`.
|
||||
|
||||
- An antenna height of 10 metres above ground is assumed for the remote station.
|
||||
|
||||
- Aircraft-scatter information from AirScout and the terrain analysis in the station map remain separate assessments.
|
||||
|
||||
- More detailed configuration of station height, frequency and K factor is being tracked in [Issue #74](https://github.com/praktimarc/kst4contest/issues/74).
|
||||
|
||||
---
|
||||
|
||||
## v1.41.1 (2026-07-08)
|
||||
|
||||
**Hotfix for text input and focus handling**
|
||||
|
||||
### Fixed
|
||||
|
||||
- The message input field was unexpectedly cleared after some time or during particular UI updates.
|
||||
- Filtering or selecting a station could move the input focus back to the send field unintentionally.
|
||||
|
||||
The corrected version is available as [Release v1.41.1](https://github.com/praktimarc/kst4contest/releases/tag/v1.41.1).
|
||||
|
||||
---
|
||||
## v1.41.0 (2026-07-01)
|
||||
|
||||
**Station map, bounded message stores and screen-aware main window**
|
||||
|
||||
### Added
|
||||
|
||||
- **Station map:** An interactive OpenStreetMap-based map displays active chat members for which a usable locator is available.
|
||||
|
||||
- **Antenna sector and connection line:** The map shows the current local QTF, configured antenna beamwidth, maximum QRB and the path to the selected station.
|
||||
|
||||
- **Maidenhead grid:** A locator grid adapted to the current zoom level provides geographical orientation.
|
||||
|
||||
- **Terrain profile:** An elevation profile for a selected station can be requested from the Open-Meteo Elevation API. The active source uses Copernicus GLO-90 data and no more than 100 evenly distributed samples.
|
||||
|
||||
- **Geometrical path analysis:** The calculation includes line of sight, Earth curvature using `k = 4/3`, radio and terrain horizons, the first Fresnel zone and a rough obstruction estimate.
|
||||
|
||||
- **Local map proxy:** Leaflet is bundled with the application. Map tiles are loaded through a local proxy so that no external JavaScript library is required at runtime. An Internet connection is still required for OpenStreetMap tiles and online elevation data.
|
||||
|
||||
### Changed
|
||||
|
||||
- **Bounded message stores:** The global chat-message list is reduced from more than 30,000 entries to 25,000. The separate DX cluster store is reduced from more than 10,000 entries to 8,000.
|
||||
|
||||
- **Screen-aware startup size:** The main window is checked against the visible area of the primary screen at startup and reduced or repositioned when necessary.
|
||||
|
||||
- **More compact user interface:** Several UI sections were adapted for smaller displays and movable dividers.
|
||||
|
||||
### Scope of the map function
|
||||
|
||||
The station map and AirScout may refer to the same remote station, but their calculations remain separate. Aircraft used by AirScout are not included in the terrain profile.
|
||||
|
||||
Classes for Copernicus GLO-30, offline DEM imports and additional terrain providers existed in the source tree but were not part of the active calculation chain in v1.41. The elevation source actually used was Open-Meteo based on Copernicus GLO-90.
|
||||
|
||||
---
|
||||
|
||||
For the latest changelog, please refer to GitHub. The previous changelog is below.
|
||||
|
||||
## v1.40 (2026-02-16)
|
||||
**Major Feature Release: Score System, AP Timeline, Win-Test, PSTRotator**
|
||||
|
||||
+56
-785
@@ -25,22 +25,11 @@ Enter your own callsign and Maidenhead locator (6 characters, e.g., `JN49IJ`). T
|
||||
|
||||
### Active Bands
|
||||
|
||||
The **My station uses …** checkboxes define the bands available in the current local station setup. Supported choices are 50 MHz, 70 MHz, 144 MHz, 432 MHz, 1296 MHz, 2320 MHz, 3400 MHz, 5760 MHz and 10 GHz.
|
||||
|
||||
This selection controls more than the visible band columns. It is also used for:
|
||||
|
||||
- the per-band Worked and NOT-QRV filters,
|
||||
- the NOT-QRV controls visible in the **Further Info** panel,
|
||||
- the `a` and `B+` band-opportunity calculation,
|
||||
- the **New bands** filter,
|
||||
- the band-upgrade hint after a log entry, and
|
||||
- band-specific priority and Reachability functions.
|
||||
|
||||
After a change, click **Save Settings** and restart KST4Contest. Band columns and several related controls are created while the user interface is being built and are therefore not added or removed completely during the current session.
|
||||
Use the **"my station uses band"** checkboxes to select the active bands. Buttons and table rows will only appear in the user interface for selected bands. The software must be restarted after making changes.
|
||||
|
||||
### Antenna Beamwidth
|
||||
|
||||
Enter a realistic value for your antenna's beamwidth (in degrees). This value is used for the [Sked Direction Highlighting](en-Features#sked-direction-highlighting). A test value of 50° has proven effective; DM5M uses quads with 69°.
|
||||
Enter a realistic value for your antenna's beamwidth (in degrees). This value is used for the [Sked Direction Highlighting](Features#sked-direction-highlighting). A test value of 50° has proven effective; DM5M uses quads with 69°.
|
||||
|
||||
> **Do not** enter fantasy values – the direction calculations will become useless.
|
||||
|
||||
@@ -48,869 +37,151 @@ Enter a realistic value for your antenna's beamwidth (in degrees). This value is
|
||||
|
||||
Maximum distance (in km) for which direction warnings should be triggered. A realistic value for DM5M is 900 km. Stations farther away are ignored for highlighting purposes.
|
||||
|
||||
### Path Analysis and Link Budget
|
||||
|
||||
The station map uses several values from the **Station** tab to calculate the terrain profile and link budget for the selected remote station. Enter the local station data as realistically as possible. The remote-station values remain global assumptions unless more accurate information is available.
|
||||
|
||||
| Setting | Use |
|
||||
|---|---|
|
||||
| **Own antenna height AGL** | Height of the local antenna above the surrounding terrain in metres |
|
||||
| **Own TX power W** | Local transmit power in watts |
|
||||
| **Own ant. gain dBi** | Gain of the local antenna in dBi |
|
||||
| **DX OM TX power W** | Assumed transmit power of the remote station in watts |
|
||||
| **DX OM ant. gain dBi** | Assumed antenna gain of the remote station in dBi |
|
||||
|
||||
**AGL** means *Above Ground Level*. Do not enter the height above sea level. The terrain elevation at the local station already comes from the elevation profile; KST4Contest adds the configured antenna height to this value.
|
||||
|
||||
For the remote station, KST4Contest currently uses a fixed antenna height of 10 metres above the local terrain. Its transmit power and antenna gain come from the two **DX OM** fields. These values are deliberately assumptions: ON4KST provides neither the actual antenna height nor the complete station data of the remote operator.
|
||||
|
||||
Antenna gains must be entered in `dBi`. Add `2.15 dB` before entering a value specified in `dBd`:
|
||||
|
||||
```text
|
||||
dBi = dBd + 2.15 dB
|
||||
```
|
||||
|
||||
The current QTF, configured antenna beamwidth and default maximum QRB affect the map display. The bands enabled for the local station and the frequency derived for the remote station also affect the selection of the analysis frequency.
|
||||
|
||||
For the terrain profile, KST4Contest uses the antenna heights, elevation model and Earth curvature with a fixed effective Earth-radius factor of `k = 4/3`. The link budget additionally includes:
|
||||
|
||||
- distance and the current analysis frequency,
|
||||
- transmit powers and antenna gains in both directions,
|
||||
- frequency-dependent estimated feeder losses,
|
||||
- free-space path loss, and
|
||||
- a rough additional loss caused by the relevant obstruction in the terrain profile.
|
||||
|
||||
The calculation is performed in both directions. The weaker direction determines the common SSB or CW margin. Optimistic power or antenna values therefore improve the displayed result, but they do not improve the real radio path.
|
||||
|
||||
The results remain engineering estimates. Current propagation conditions, local obstructions, vegetation, buildings, interference and unknown station parameters can change the actual result considerably. Operation, frequency selection and the limits of the calculation are described under [Station Map and Path Analysis](en-Features#station-map-and-path-analysis-from-v141).
|
||||
|
||||
---
|
||||
|
||||
## Server Settings (from v1.31)
|
||||
|
||||
The connection details for the ON4KST chat server are shown at the top of the **Station** tab. They normally do not need to be changed.
|
||||
The chat server DNS and port are configurable in the Preferences:
|
||||
|
||||
| Setting | Meaning |
|
||||
|---|---|
|
||||
| **ON4KST server** | DNS name or IP address of the chat server; the software default is `www.on4kst.org` |
|
||||
| **Port** | TCP port of the chat server; the default is `23001` |
|
||||
- **Server DNS**: Default `www.on4kst.org` (changed from `www.on4kst.info` in v1.31 hotfix).
|
||||
- **Port**: Default port of the ON4KST server.
|
||||
|
||||
`www.on4kst.info` may also remain in an existing, working configuration. There is no reason to change it merely because the displayed name differs from the software default, provided that the chat connection remains reliable.
|
||||
|
||||
These values apply only to the outgoing ON4KST chat connection. They do not change the local DX cluster server or any connection to AirScout, PSTRotator or logging software.
|
||||
|
||||
The port must be between `1` and `65535`. An invalid entry is rejected and replaced with the last valid value. An incorrect server name or port, on the other hand, prevents KST4Contest from connecting to the chat.
|
||||
|
||||
Changing either value does not alter an existing TCP connection. Disconnect and reconnect the chat, or restart KST4Contest. Then use **Save Settings** so that the values are retained for the next program start.
|
||||
A change is only needed if the server moves or an alternative endpoint is used.
|
||||
|
||||
---
|
||||
|
||||
## Log Sync Settings
|
||||
|
||||
The **Log sync** tab selects the sources from which KST4Contest imports worked stations. The three input paths provide different levels of detail:
|
||||
Three methods are available for automatically marking worked stations. Details: [Log Synchronisation](en-Log-Sync).
|
||||
|
||||
|
||||
### Universal File Based Callsign Interpreter (Simplelogfile)
|
||||
|
||||
| Input path | Data used | Result in KST4Contest |
|
||||
|---|---|---|
|
||||
| **Simplelogfile** | Callsigns read from a selected file | global Worked status, but no band or locator information |
|
||||
| **General QSO UDP listener** | QSO packets from UCXLog, QARTest, N1MM+ and DXLog.net | global and per-band Worked status plus worked grid square where both band and locator are transmitted |
|
||||
| **Win-Test network listener** | native Win-Test network packets | global and per-band Worked status, locator information and, depending on the settings, QRG synchronisation and sked handover |
|
||||
Interprets any log file using regex for callsign patterns. No band information is available. Suitable as a fallback or for log programs that are not directly supported.
|
||||
|
||||
The file-based interpreter is mainly useful when the logging application provides no supported network interface. A callsign match alone, however, contains neither a reliable band nor a locator. Use one of the network listeners wherever possible if per-band information is required.
|
||||
### Network Listener for Logger's QSO UDP Broadcast
|
||||
|
||||
The general QSO UDP listener is the recommended interface for UCXLog, QARTest, N1MM+ and DXLog.net. QSO and `RadioInfo` packets use the same configurable UDP port; the default is `12060`. Separate options in **Log sync** and **TRX sync** determine whether the received QSO and frequency information is processed.
|
||||
**Recommended method.** KST4Contest listens for UDP packets sent by the logging software to the broadcast address when a QSO is saved. Stations are marked with band information. UDP port: default **12060**. (Used by UCXLog, N1MM+, QARTest, DXLog.net, etc.).
|
||||
|
||||
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.
|
||||
### Win-Test Network Listener (Additional UDP Listener)
|
||||
|
||||
All enabled input paths may be used in parallel. Their Worked information is merged into the same internal database; identical reports do not create separate Worked states. KST4Contest must be running when a QSO is saved 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).
|
||||
A dedicated network listener for Win-Test. KST4Contest receives and processes Win-Test-specific UDP packets (including sked handovers) on the configured port.
|
||||
|
||||
---
|
||||
|
||||
## TRX Sync Settings
|
||||
|
||||
TRX synchronisation imports the current frequency from the logging application and makes it available in KST4Contest as the local QRG of the first chat category. QSO and frequency synchronisation may use the same UDP receiver, but they remain separate functions: receiving a `RadioInfo` packet does not mark a station as worked, and receiving a QSO packet does not automatically change the local QRG.
|
||||
Receives the current transceiver frequency from the logging software via UDP. This enables the automatic population of the `MYQRG` variable. Useful for:
|
||||
|
||||
|
||||
- Quickly inserting your own QRG into chat messages.
|
||||
- Automatic CQ beacon with current frequency.
|
||||
|
||||
### Available QRG Sources
|
||||
|
||||
| Source | Setting | Behaviour |
|
||||
|---|---|---|
|
||||
| **General RadioInfo listener** | `Update MYQRG from RadioInfo messages received on the shared log-sync port` | Processes compatible `RadioInfo` packets on the UDP port shared with QSO synchronisation. The default port is `12060`. |
|
||||
| **Win-Test STATUS** | `Win-Test STATUS QRG Sync` | Processes the main or pass frequency from native Win-Test `STATUS` packets. The Win-Test listener uses its separately configured port, which defaults to `9871`. |
|
||||
| **Manual entry** | Disable both automatic QRG sources | The local QRG can be entered manually in the main window. |
|
||||
|
||||
The general listener is intended for logging applications which transmit compatible `RadioInfo` packets. Depending on their individual configuration, this includes UCXLog, N1MM+, QARTest and DXLog.net. QSO and `RadioInfo` packets use the same port configured under **Log sync**, but separate options determine whether KST4Contest processes QSO information, TRX information or both packet types.
|
||||
|
||||
Restart KST4Contest after changing the shared UDP port. Changes to the two QRG-sync checkboxes take effect immediately.
|
||||
|
||||
### Which QRG Is Updated?
|
||||
|
||||
Both automatic sources update `MYQRG` only. This is the local QRG of the first or primary chat category.
|
||||
|
||||
If a second chat is enabled, its QRG remains independent. It is not derived from incoming TRX packets and is available through `SECONDQRG`. The first category can therefore follow the logging application's frequency automatically while a separate QRG is entered manually for the second category.
|
||||
|
||||
As soon as at least one automatic QRG source is enabled, the first category's QRG field in the main window is bound to the received value. Manual entry becomes available again when both the general RadioInfo listener and Win-Test STATUS synchronisation are disabled.
|
||||
|
||||
### Main or Pass Frequency from Win-Test
|
||||
|
||||
By default, KST4Contest uses the main frequency contained in the Win-Test `STATUS` packet.
|
||||
|
||||
Enable `Use pass frequency from Win-Test STATUS` to use the packet's pass frequency instead. This is useful, for example, when Win-Test maintains a different frequency during split operation and that is the frequency which should be announced in the chat.
|
||||
|
||||
If the packet does not contain a valid pass frequency, KST4Contest automatically falls back to the main frequency. A missing pass frequency therefore neither clears `MYQRG` nor replaces it with an obviously incorrect number.
|
||||
|
||||
Frequencies use a consistent KST4Contest display format, for example:
|
||||
|
||||
```text
|
||||
50.300.00
|
||||
144.300.00
|
||||
1296.100.00
|
||||
10368.100.00
|
||||
```
|
||||
|
||||
The number of digits before the first dot is derived from the frequency. Microwave frequencies with four or five MHz digits are therefore formatted correctly as well.
|
||||
|
||||
### Selecting the Win-Test Station
|
||||
|
||||
Several stations in a Win-Test network may transmit `STATUS` packets at the same time. `Win-Test station name filter` selects the station which is allowed to update the local QRG in KST4Contest.
|
||||
|
||||
Example:
|
||||
|
||||
```text
|
||||
STN1
|
||||
```
|
||||
|
||||
The comparison is case-insensitive. If the field is empty, `STATUS` packets from every Win-Test station are accepted.
|
||||
|
||||
In a multi-operator setup, set the filter to the station name of the operating position which actually belongs to this KST4Contest instance. Otherwise, a packet from another position may replace the QRG currently being displayed.
|
||||
|
||||
### Using MYQRG and SECONDQRG
|
||||
|
||||
The synchronised QRG can be used in every text processed by the common KST4Contest variable resolver. This includes:
|
||||
|
||||
- the send field,
|
||||
- shortcuts,
|
||||
- snippets, and
|
||||
- automatic beacons.
|
||||
|
||||
`MYQRG` contains the complete QRG of the first chat category. `MYQRGSHORT` uses only its first seven characters. `SECONDQRG` contains the separately entered QRG of the second chat category.
|
||||
|
||||
Examples:
|
||||
|
||||
```text
|
||||
I am calling cq at MYQRG
|
||||
cq on MYQRGSHORT
|
||||
second chat qrg SECONDQRG
|
||||
```
|
||||
|
||||
The values are inserted when the message text is resolved. If the logging application changes frequency between two beacon runs, the next message already uses the updated value.
|
||||
|
||||
The local QRG may also be used as a fallback when handing a sked over to Win-Test. This only happens if the QRG can be parsed and belongs to the band explicitly selected for the sked. See [Log Synchronisation](en-Log-Sync#handing-skeds-over-to-win-test) for details.
|
||||
|
||||
Further information about text variables: [Macros and Variables](en-Macros-and-Variables#variables).
|
||||
|
||||
### Multiple Loggers or Radios
|
||||
|
||||
Every enabled QRG source writes to the same `MYQRG` value. KST4Contest does not currently assign incoming `RadioInfo` or `STATUS` packets to a particular radio or chat category.
|
||||
|
||||
If the general RadioInfo listener and Win-Test synchronisation are enabled at the same time, the most recently processed packet therefore determines the displayed QRG. The same applies when several logging applications send frequency packets to one KST4Contest instance.
|
||||
|
||||
For a setup containing several radios:
|
||||
|
||||
- QSO packets may be received from several logging applications.
|
||||
- Frequency packets should only be transmitted by the source which is intended to control `MYQRG`.
|
||||
- A Win-Test network should additionally use the station-name filter.
|
||||
- If two completely independent QRG synchronisations are required, two separate KST4Contest instances provide the clearer arrangement.
|
||||
|
||||
In other words, combining several Worked sources is useful. Combining several simultaneously transmitting frequency sources merely creates a contest over which packet arrived last.
|
||||
|
||||
Click **Save Settings** after completing the configuration.
|
||||
> **Note for multi-setup**: When running two logging programs on two computers but only one KST4Contest instance, only one logging program should send frequency packets. KST4Contest cannot distinguish between sources.
|
||||
|
||||
---
|
||||
|
||||
## AirScout Settings
|
||||
|
||||
The **AirScout** tab configures the UDP connection between KST4Contest and AirScout. KST4Contest does not request a general aircraft feed. It submits the station paths which are currently relevant, while AirScout calculates the matching aircraft and returns the result to the requesting KST4Contest instance.
|
||||
|
||||
AirScout `0.9.9.5` or newer is required.
|
||||
|
||||
{ width=85% }
|
||||
|
||||
### UDP Connection Settings
|
||||
|
||||
| Setting | Default | Use |
|
||||
|---|---:|---|
|
||||
| **Enable AirScout UDP integration** | disabled | Enables AirScout requests and the processing of returned information |
|
||||
| **AirScout server identifier** | `AS` | Logical name of the AirScout instance being addressed |
|
||||
| **KST4Contest client identifier** | `KST` | Logical name of this KST4Contest instance |
|
||||
| **AirScout UDP port** | `9872` | Shared UDP port for requests and responses |
|
||||
| **Select AirScout frequency automatically per station** | enabled | Derives a suitable band and frequency from the current context of each remote station |
|
||||
| **Forced AirScout band value** | `1440000` | Uses one fixed AirScout band value for every station when automatic selection is disabled |
|
||||
|
||||
When **Enable AirScout UDP integration** is disabled, KST4Contest neither sends AirScout requests nor processes incoming AirScout responses. The UDP receiver may remain bound so that the integration can be enabled again during the current connection.
|
||||
|
||||
KST4Contest sends AirScout packets to the broadcast address `255.255.255.255`. No separate destination IP address is therefore configured. AirScout and KST4Contest must be able to receive the same UDP broadcast; routers do not normally forward this type of broadcast into another network. If communication fails, check the UDP port, local firewall and network assignment first.
|
||||
|
||||
### Automatic Band Selection per Station
|
||||
|
||||
**Auto per station** is the recommended setting. Instead of using one fixed band value for every remote station, KST4Contest derives a suitable frequency from the available operating context.
|
||||
|
||||
The sources are evaluated in this order:
|
||||
|
||||
1. the most recently detected QRG of the remote station, provided that it is no more than 30 minutes old,
|
||||
2. one unambiguous complete QRG in the name field of an active chat entry,
|
||||
3. unambiguous band designators in the name field,
|
||||
4. 432 MHz if the same station is active in both the VHF/UHF and Microwave categories and 432 MHz is enabled for the local station,
|
||||
5. the lowest locally enabled band belonging to the supported chat category.
|
||||
|
||||
Active chat variants of the same base callsign are evaluated together. Entries such as `CALLSIGN`, `CALLSIGN-2` and `CALLSIGN-432` can therefore contribute to the same band decision while remaining separate chat members for message processing.
|
||||
|
||||
Only bands enabled under **My station uses …** are eligible for automatic selection. A manually assigned NOT-QRV mark excludes the corresponding band and takes precedence over automatically detected QRG or name information.
|
||||
|
||||
The 50/70 MHz, VHF/UHF, Microwave and EME/JT65 chat categories are supported. Other ON4KST categories do not participate in AirScout band resolution. If no sufficiently reliable frequency can be determined, KST4Contest omits the request for that station. An arbitrary fallback to 144 MHz would produce a syntactically complete packet, but not necessarily a useful calculation.
|
||||
|
||||
Automatic AirScout selection uses the same propagation-frequency resolver as the internal path analysis. Both functions therefore evaluate the station path from the same technical basis.
|
||||
|
||||
### Fixed AirScout Band
|
||||
|
||||
When **Auto per station** is disabled, KST4Contest uses the value entered under **Forced AirScout band value** for every station.
|
||||
|
||||
Enter the value in the unit used by the AirScout UDP interface:
|
||||
|
||||
| Band | AirScout value |
|
||||
|---|---:|
|
||||
| 50 MHz | `500000` |
|
||||
| 70 MHz | `700000` |
|
||||
| 144 MHz | `1440000` |
|
||||
| 432 MHz | `4320000` |
|
||||
| 1296 MHz | `12960000` |
|
||||
| 2320 MHz | `23200000` |
|
||||
| 3400 MHz | `34000000` |
|
||||
| 5760 MHz | `57600000` |
|
||||
| 10368 MHz | `103680000` |
|
||||
| 24048 MHz | `240480000` |
|
||||
|
||||
In fixed mode, neither the remote station's recently detected QRG nor a band stated in its name is considered. This option is therefore mainly useful for a station setup which is clearly limited to one band, or for troubleshooting.
|
||||
|
||||
### Server and Client Identifiers
|
||||
|
||||
The identifiers belong to the AirScout protocol. They are not DNS names or IP addresses.
|
||||
|
||||
Outgoing requests contain the client identifier followed by the server identifier:
|
||||
|
||||
```text
|
||||
"KST" "AS"
|
||||
```
|
||||
|
||||
AirScout returns them in the opposite order:
|
||||
|
||||
```text
|
||||
"AS" "KST"
|
||||
```
|
||||
|
||||
KST4Contest processes a response only if both identifiers exactly match the current configuration. The comparison is case-sensitive.
|
||||
|
||||
Identifiers must not be empty and must not contain quotation marks or line breaks.
|
||||
|
||||
If several KST4Contest instances operate in the same network, assign a distinct client identifier to each one, for example:
|
||||
|
||||
```text
|
||||
KST-144
|
||||
KST-432
|
||||
```
|
||||
|
||||
If several AirScout instances are present, use distinct server identifiers as well. This prevents a response intended for one operating position from being processed by another KST4Contest instance.
|
||||
|
||||
### Which Stations Are Requested?
|
||||
|
||||
KST4Contest starts the first periodical AirScout request approximately ten seconds after the chat connection has been established. Further requests follow every 60 seconds.
|
||||
|
||||
An active station is included only if:
|
||||
|
||||
- a usable callsign is available,
|
||||
- a locator is available,
|
||||
- its distance has been calculated,
|
||||
- its distance is below the configured **Maximum QRB**, and
|
||||
- a usable band can be determined.
|
||||
|
||||
Several active chat entries of the same base callsign do not create a separate identical path calculation for every suffix. The returned AirScout information is subsequently assigned to the corresponding active chat variants.
|
||||
|
||||
This selection does more than reduce network traffic. It also prevents AirScout from continuously calculating paths outside the intended working range of the local station.
|
||||
|
||||
### Applying Changed Settings
|
||||
|
||||
The following changes are used for new packets immediately after leaving the input field or changing the checkbox:
|
||||
|
||||
- enabling or disabling the AirScout integration,
|
||||
- server identifier,
|
||||
- client identifier,
|
||||
- automatic or fixed band selection, and
|
||||
- the forced band value.
|
||||
|
||||
After changing the UDP port, disconnect and reconnect the chat or restart KST4Contest. The existing UDP receiver otherwise remains bound to the previous port.
|
||||
|
||||
Click **Save Settings** afterwards to retain the configuration.
|
||||
|
||||
AirScout setup, aircraft display and the meaning of the returned AP information are described under [AirScout Integration](en-AirScout-Integration).
|
||||
Configuration of the interface to AirScout for aircraft scatter detection. Details: [AirScout Integration](en-AirScout-Integration).
|
||||
|
||||
---
|
||||
|
||||
## Notification Settings
|
||||
|
||||
|
||||
|
||||
Three notification types are available:
|
||||
|
||||
1. **Simple sounds**: TADA sound for incoming messages, tick for sked direction detection, etc.
|
||||
2. **CW announcement**: The callsign of a station sending a private message is output as a CW signal.
|
||||
3. **Phonetic announcement**: The callsign is pronounced phonetically.
|
||||
|
||||
### Fallback Band for Relative QRG Detection
|
||||
|
||||
The **Fallback band for relative QRG detection** dropdown selects the band used when a relative QRG cannot be assigned to a recent station-specific band context.
|
||||
|
||||
Only band prefixes supported by the frequency parser are available:
|
||||
|
||||
```text
|
||||
50 MHz
|
||||
70 MHz
|
||||
144 MHz
|
||||
432 MHz
|
||||
1296 MHz
|
||||
2320 MHz
|
||||
3400 MHz
|
||||
5760 MHz
|
||||
10368 MHz (10G)
|
||||
24048 MHz (24G)
|
||||
```
|
||||
|
||||
The dropdown is neither a filter nor an override for complete frequencies. `432.088` is recognised as a frequency in the 432 MHz band regardless of the selection. The fallback is needed for relative values such as `.205`, `,205` or `qrg 205`.
|
||||
|
||||
Before using the fallback, KST4Contest checks the sender's recent band context. If a complete frequency has been detected for the same station during the previous 30 minutes, that band takes precedence. A fallback setting of `144 MHz` therefore still turns `.100` into `432.100 MHz` if the station mentioned `432.088` shortly before.
|
||||
|
||||
Although this setting is located in the Notification tab, it affects the general QRG parser. It therefore influences the QRG column, detected active bands, priority calculations, band-upgrade hints and other functions which use a known station frequency – not only DX cluster spots.
|
||||
|
||||
Further details, including numbers which are deliberately ignored, are described under [QRG Detection](en-Features#qrg-detection).
|
||||
|
||||
### Local DX Cluster Output
|
||||
|
||||
KST4Contest can forward detected directional opportunities to logging software as DX cluster spots. A frequency recognised in the chat can therefore appear directly in the logger's band map without being entered manually.
|
||||
|
||||
The **Enable the local DX Cluster server …** checkbox starts or stops the local TCP server. When KST4Contest is connected to the chat, the change takes effect immediately.
|
||||
|
||||
The following settings and controls belong to the local DX cluster output:
|
||||
|
||||
- **TCP port**: Port on which KST4Contest accepts connections from DX cluster clients. The default is `8000`. Changing the port while the server is running restarts it on the new port. The logger must then reconnect to that port.
|
||||
- **Fallback band for relative QRG detection**: The global fallback band described above. The test spot uses `.300` on this band. Actual spots use the QRG detected for the respective sender.
|
||||
- **Spotter callsign**: Callsign shown as the spotter in generated DX cluster entries. A callsign different from the contest callsign should be used. Some logging programs filter spots apparently sent by the local station or treat them differently from external spots.
|
||||
- **Send test spot**: Sends the following entry to every currently connected DX cluster client:
|
||||
|
||||
```text
|
||||
Spotted callsign: DO5AMF
|
||||
Comment: Testing DXC-Spot: Congrats, you donated $100!
|
||||
Frequency: .300 on the selected fallback band
|
||||
```
|
||||
|
||||
With `144 MHz` selected as the fallback band, the resulting frequency is approximately `144.300 MHz`.
|
||||
|
||||
The comment is a deliberately retained Easter egg. It has no technical meaning and, despite being remarkably specific, does not initiate a payment. Its practical purpose is to make the test spot easy to identify in the logging software.
|
||||
|
||||
The test works only if
|
||||
|
||||
1. KST4Contest is connected to the ON4KST chat,
|
||||
2. the local DX cluster server is enabled, and
|
||||
3. at least one DX cluster client is connected to KST4Contest.
|
||||
|
||||
KST4Contest does not generate a spot for every frequency found in the chat. An actual spot is created only when a directed message between two stations indicates a relevant antenna direction for the local station and a usable frequency is known for the sender.
|
||||
|
||||
The complete derivation and logger setup are described under [Built-in DX Cluster Server](en-DX-Cluster-Server).
|
||||
|
||||
---
|
||||
|
||||
### Band Upgrade Hint after a Log Entry
|
||||
|
||||
After receiving a log entry from UCXLog or Win-Test, KST4Contest can check whether the station which has just been worked still offers another common and unworked band.
|
||||
|
||||
The check uses the same derivation as the `a` and `B+` display:
|
||||
|
||||
1. the bands enabled in the local station settings,
|
||||
2. QRGs detected for the remote station during the previous 30 minutes,
|
||||
3. explicit band designators in the name fields of its active chat entries,
|
||||
4. stored per-band Worked marks, and
|
||||
5. manually assigned NOT-QRV marks.
|
||||
|
||||
Active chat variants of the same normalised callsign are evaluated together. NOT-QRV takes precedence over an automatically detected QRG or band designator.
|
||||
|
||||
If at least one common and unworked band remains, the main window displays a blinking **BAND+** hint for approximately twelve seconds. The callsign and remaining bands are included in the button text; the tooltip contains the complete derivation. If general notification sounds are enabled, KST4Contest also plays a short sound.
|
||||
|
||||
The two options serve different purposes:
|
||||
|
||||
- **Blink + sound …** enables the hint after a matching log entry.
|
||||
- **Priority boost …** additionally raises the score of stations which have already been worked on at least one band but still offer another common and unworked band.
|
||||
|
||||
The Priority Boost is only one factor in the complete calculation. Distance, antenna direction, recent activity, AirScout data, skeds and negative hints may still change the final order. Enabling the option therefore guarantees neither a particular score nor a particular position in the priority list.
|
||||
|
||||
The other score weights currently have no separate user-interface controls. Several existing settings nevertheless provide input data for the calculation, particularly the [active bands](#active-bands), [antenna beamwidth](#antenna-beamwidth), [default maximum QRB](#default-maximum-qrb) and [AirScout settings](#airscout-settings).
|
||||
|
||||
The complete calculation is described under [Priority Score and Priority List](en-Features#priority-score-and-priority-list-from-v140).
|
||||
|
||||
|
||||
The hint requires a log-synchronisation source which provides band information. The file-based callsign interpreter sees callsigns only and cannot reliably identify the band of the QSO which has just been logged.
|
||||
|
||||
Further explanation: [Band Upgrade Hint after a Log Entry](en-Features#band-upgrade-hint-after-a-log-entry).
|
||||
|
||||
---
|
||||
|
||||
## Shortcut Settings
|
||||
|
||||
|
||||
|
||||
Each entry in the upper part of the **Shortcuts** tab creates one button above the message field in the main window. Pressing the button appends its configured text to the current contents of the send field.
|
||||
|
||||
If the shortcut contains a [variable](en-Macros-and-Variables#variables), it is replaced with its current value when the text is inserted. A shortcut such as
|
||||
|
||||
```text
|
||||
pse call me at MYQRGSHORT
|
||||
```
|
||||
|
||||
may therefore insert:
|
||||
|
||||
```text
|
||||
pse call me at 144.388
|
||||
```
|
||||
|
||||
The exact entries `MYQRG` and `SECONDQRG` are additionally highlighted as QRG buttons. They insert the current frequency of the primary or secondary chat category respectively.
|
||||
|
||||
The shortcut `/SETNAME MYQRG` is highlighted as well. When it is pressed, KST4Contest resolves `MYQRG` and inserts the complete server command into the send field. The command is not transmitted automatically and can still be checked before it is sent with `Enter` or **TX**.
|
||||
|
||||
|
||||
The order of the table determines the order of the buttons in the main window. Manage the entries as follows:
|
||||
|
||||
1. **Add shortcut** creates a new entry at the beginning of the list and immediately opens it for editing.
|
||||
2. Double-click an existing entry to edit it. Press `Enter` to accept the change.
|
||||
3. To remove an entry, delete its complete contents and confirm with `Enter`.
|
||||
4. Use **Move selected up** and **Move selected down** to change the position of the selected entry.
|
||||
|
||||
Changes appear in the main window immediately. Use **Save Settings** afterwards if they should remain available after the next program start.
|
||||
Configuration of quick-access buttons that appear directly in the main window. Clicking a button inserts the configured text into the send field. All [variables](Macros-and-Variables#variables) can be used.
|
||||
|
||||
---
|
||||
|
||||
## Snippet Settings
|
||||
|
||||
Snippets are longer text blocks intended primarily for messages to a selected station. They can be opened through:
|
||||
Text snippets are accessible via:
|
||||
|
||||
- a right-click on a station in the user list;
|
||||
- a right-click on a message in the public chat table;
|
||||
- a right-click on a message in the PM table; or
|
||||
- `Ctrl+1` through `Ctrl+0` for the first ten entries in the snippet list.
|
||||
- **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
|
||||
|
||||
The keyboard mapping follows the order of the table:
|
||||
|
||||
| Key combination | Snippet |
|
||||
|---|---:|
|
||||
| `Ctrl+1` | first entry |
|
||||
| `Ctrl+2` | second entry |
|
||||
| … | … |
|
||||
| `Ctrl+9` | ninth entry |
|
||||
| `Ctrl+0` | tenth entry |
|
||||
|
||||
A snippet selected from a context menu is appended to the message already prepared in the send field. Selecting a station or message will normally have inserted the appropriate `/cq` destination first.
|
||||
|
||||
A keyboard shortcut behaves differently: it replaces the current contents of the send field with a complete directed message:
|
||||
|
||||
```text
|
||||
/cq CALLSIGN snippet text
|
||||
```
|
||||
|
||||
The complete visible callsign, including any suffix, is retained. Selecting `9A0BB-70` may therefore produce:
|
||||
|
||||
```text
|
||||
/cq 9A0BB-70 pse ur qrg?
|
||||
```
|
||||
|
||||
The selected station's chat category is retained for transmission. If no station is selected, or no snippet is assigned to the chosen key combination, nothing is inserted.
|
||||
|
||||
Variables are resolved when the snippet is inserted. Station-specific variables such as `QRZNAME`, `FIRSTAP` and `SECONDAP` refer to the currently selected station. The prepared message is not sent automatically and can still be checked or edited. Press `Enter` or **TX** to send it; `Esc` clears the send field.
|
||||
|
||||
The snippet list is edited in the same way as the shortcut list:
|
||||
|
||||
1. **Add new snippet** creates a new entry at the beginning of the list.
|
||||
2. Double-click an existing entry to edit it.
|
||||
3. Press `Enter` to accept the change.
|
||||
4. Confirming an empty entry removes it.
|
||||
5. **Move selected up** and **Move selected down** change both the displayed order and the assignment to `Ctrl+1` through `Ctrl+0`.
|
||||
|
||||
The context menus and keyboard mappings are updated immediately. Use **Save Settings** afterwards to store the modified list permanently.
|
||||
|
||||
The complete list of available placeholders and their limitations is described under [Macros and Variables](en-Macros-and-Variables).
|
||||
If a callsign is selected in the user list, the snippet is addressed as a direct message:
|
||||
`/CQ CALLSIGN <snippet text>`
|
||||
|
||||
---
|
||||
|
||||
## Beacon Settings
|
||||
|
||||
|
||||
Configuration of an automatic interval beacon in the public chat channel. Recommended: use the `MYQRG` variable in the text so the current frequency is always up to date. Interval and text are freely configurable.
|
||||
|
||||
A beacon sends a public CQ message at regular intervals. It is intended for operating situations in which the local station calls CQ on a fixed frequency for an extended period. Other stations receive current QRG information without requiring the operator to enter the same message repeatedly.
|
||||
|
||||
KST4Contest uses one shared timer for both chat categories. Each category nevertheless has its own enable setting and message template:
|
||||
|
||||
- **Enable CQ beacon** enables the beacon for the respective category.
|
||||
- **Beacon message** contains the public message for that category.
|
||||
- **Shared beacon interval** sets the common interval used by both categories.
|
||||
|
||||
When both beacons are enabled, they are sent one after the other in their respective categories during the same timer run. The second beacon is only considered while the second chat is enabled and connected.
|
||||
|
||||
### Interval and timer behaviour
|
||||
|
||||
The interval is entered in whole minutes. The minimum permitted value is one minute.
|
||||
|
||||
After the chat connection has been established, KST4Contest performs the first beacon check after approximately ten seconds. The configured interval applies after that initial check.
|
||||
|
||||
Changing the interval while connected restarts the countdown with the new value. The change itself does not cause an immediate beacon message.
|
||||
|
||||
Both categories use the same timer. Separate intervals for the primary and secondary chat cannot be configured.
|
||||
|
||||
### Message text and variables
|
||||
|
||||
A beacon may use the [global variables](en-Macros-and-Variables#variables-in-the-beacon) which depend only on the local station:
|
||||
|
||||
- `MYQRG`
|
||||
- `MYQRGSHORT`
|
||||
- `SECONDQRG`
|
||||
- `MYLOCATOR`
|
||||
- `MYLOCATORSHORT`
|
||||
- `MYCALL`
|
||||
- `MYQTF`
|
||||
|
||||
A suitable message for the primary chat category is:
|
||||
|
||||
```text
|
||||
calling cq at MYQRGSHORT, ant MYQTF deg, loc MYLOCATOR
|
||||
```
|
||||
|
||||
Use `SECONDQRG` for the second chat if it operates on a different frequency:
|
||||
|
||||
```text
|
||||
calling cq at SECONDQRG, ant MYQTF deg, loc MYLOCATOR
|
||||
```
|
||||
|
||||
Variables are resolved again on every timer run. If the logging software changes the QRG stored in `MYQRG`, the next beacon can already contain the updated value. The message template does not have to be edited.
|
||||
|
||||
`MYQRG` and `MYQRGSHORT` always refer to the primary chat category. Enabling or selecting the second chat does not change this assignment.
|
||||
|
||||
Station-specific variables such as `QRZNAME`, `FIRSTAP` and `SECONDAP` require a selected remote station. A public beacon has no such destination, so these variables are not resolved in beacon messages.
|
||||
|
||||
### Message validation
|
||||
|
||||
KST4Contest validates both the configured template and the message which remains after all variables have been resolved.
|
||||
|
||||
The following restrictions apply:
|
||||
|
||||
- The final message must not be empty.
|
||||
- It must not exceed 120 characters.
|
||||
- The protocol separator `|` is not permitted.
|
||||
- Line breaks are not permitted.
|
||||
|
||||
An invalid entry is not accepted as the new beacon configuration. If a template becomes invalid only after resolving its variables, for example because the resulting text exceeds 120 characters, that beacon run is skipped.
|
||||
|
||||
A template which consists only of a temporarily empty global variable may still be stored. This can happen during startup before the first QRG has been received from the logger. KST4Contest does not send an empty message while the variable has no usable value.
|
||||
|
||||
### When should the beacon be disabled?
|
||||
|
||||
The beacon is useful only while its QRG matches the actual operation. Leaving it enabled while searching the band or changing frequencies frequently may cause other stations to look for the local station on an obsolete frequency.
|
||||
|
||||
In plain terms: the beacon saves work while calling CQ on a fixed QRG. It should be disabled while moving around the band.
|
||||
|
||||
Changes take effect during the current connection. Use **Save Settings** afterwards to retain the enable settings, message templates and interval for the next program start.
|
||||
> **Tip**: Enable the beacon when calling CQ and quickly disable it in the settings window when not calling.
|
||||
|
||||
---
|
||||
|
||||
## Messagehandling Settings (from v1.25)
|
||||
|
||||
|
||||
New settings section with the following options:
|
||||
|
||||
The most important use of the general automatic reply concerns stations which are logged into the ON4KST chat but are not taking part in the current contest. During larger contests, sked requests are sometimes sent to many logged-in stations without first checking whether they are participating. Without an automatic reply, the recipients would have to enter the same refusal repeatedly.
|
||||
|
||||
KST4Contest can answer these requests with a predefined message. A separate function provides the local QRG when a private message contains a recognised frequency request. Both functions can be enabled independently.
|
||||
|
||||
### General automatic reply
|
||||
|
||||
**Enable automatic reply to all private messages** answers incoming private messages with the text entered in the adjacent field. One common text is used for both chat categories. The configured capitalisation is preserved.
|
||||
|
||||
A suitable message is:
|
||||
|
||||
```text
|
||||
Sri, I am not taking part in this contest. No skeds.
|
||||
```
|
||||
|
||||
Do not add the `[KST4C Automsg]` prefix to the configured text. KST4Contest inserts it automatically.
|
||||
|
||||
The message received by the remote station may therefore be:
|
||||
|
||||
```text
|
||||
[KST4C Automsg] Sri, I am not taking part in this contest. No skeds.
|
||||
```
|
||||
|
||||
The incoming private message remains visible. The function neither blocks nor discards the request; it merely avoids entering the same answer repeatedly.
|
||||
|
||||
The reply is addressed to the sender's complete callsign, including any visible suffix, and sent through the chat category in which the private message was received. This distinction matters when two categories are connected at the same time: a request received through the microwave chat must not be answered accidentally through the VHF/UHF chat.
|
||||
|
||||
An empty or whitespace-only answer does not produce an automatic message. A configured text containing the protocol separator `|` or a line break is rejected as well.
|
||||
|
||||
### Automatic QRG reply
|
||||
|
||||
**Enable automatic QRG replies** reacts to common QRG requests. Matching is case-insensitive and looks for the following text fragments:
|
||||
|
||||
```text
|
||||
ur qrg?
|
||||
your qrg?
|
||||
qrg?
|
||||
freq?
|
||||
pse qrg
|
||||
```
|
||||
|
||||
The answer contains only the QRG belonging to the category in which the request was received:
|
||||
|
||||
| Incoming private message | QRG used for the reply |
|
||||
|---|---|
|
||||
| Primary category | current QRG of the primary category |
|
||||
| Second chat category | current QRG of the second category |
|
||||
|
||||
A possible reply is:
|
||||
|
||||
```text
|
||||
[KST4C Automsg] QRG is: 144.300.00
|
||||
```
|
||||
|
||||
The values come from the same QRG fields used by `MYQRG` and `SECONDQRG`. The primary QRG may be entered manually or updated through [TRX synchronisation](#trx-sync-settings). The second category uses the value configured or entered for that category.
|
||||
|
||||
If no QRG is available for the incoming category, KST4Contest does not send an incomplete reply. A message containing `QRG is:` without a frequency would technically answer the request while providing no useful information. It is therefore rejected before reaching the transmit queue.
|
||||
|
||||
When both automatic-reply functions are enabled, the QRG reply takes precedence. A recognised QRG request does not additionally produce the general reply. If the required QRG is missing, KST4Contest does not fall back to the general answer.
|
||||
|
||||
### Protection against repeated replies
|
||||
|
||||
Every automatically generated reply contains the fixed prefix:
|
||||
|
||||
```text
|
||||
[KST4C Automsg]
|
||||
```
|
||||
|
||||
The general and QRG-specific functions ignore messages which already contain this prefix. This prevents two clients with automatic replies enabled from answering each other indefinitely.
|
||||
|
||||
A common two-minute cooldown additionally applies to both reply types. The cooldown is tracked separately for each complete callsign and chat category.
|
||||
|
||||
This means:
|
||||
|
||||
- `CALLSIGN-2` and `CALLSIGN-70` have separate cooldowns.
|
||||
- The same complete callsign can still receive an independent reply in another chat category.
|
||||
- A general reply also suppresses a QRG reply to the same callsign in the same category for two minutes.
|
||||
- A QRG reply likewise suppresses the general reply.
|
||||
|
||||
The cooldown starts only after KST4Contest has produced a complete, locally valid message and placed it in the transmit queue. A missing QRG, an empty general reply or a message rejected because of invalid characters does not start the cooldown. Once the missing information has been corrected, a valid reply can therefore be generated immediately.
|
||||
|
||||
> **Note**: The configured text should describe the actual operating status clearly. If the station is only observing the contest and does not accept skeds, say exactly that. A vague automatic message is likely to produce another question – which is precisely the work this function is intended to avoid.
|
||||
|
||||
Changes take effect during the current connection. Use **Save Settings** afterwards to retain the enable settings and general reply text for the next program start.
|
||||
|
||||
Further background: [Automatic Replies to Private Messages](en-Features#automatic-replies-to-private-messages-from-v125).
|
||||
- **Auto-reply to all incoming messages**: Configurable automatic reply to private messages.
|
||||
- **Auto-reply with own CQ QRG**: When someone asks for your QRG, KST4Contest automatically replies with the content of the `MYQRG` variable.
|
||||
- **Default filter for the userinfo window**: Pre-configured message filter for the station info window *(for Gianluca :-) )*.
|
||||
|
||||
---
|
||||
|
||||
|
||||
## Win-Test Network Listener (from v1.31)
|
||||
|
||||
The Win-Test network listener processes the native Win-Test UDP protocol. It is independent of the general QSO UDP listener on port `12060` and has three separate tasks:
|
||||
A dedicated listener for Win-Test-specific UDP packets. Enables:
|
||||
|
||||
- processing QSOs including band and locator information,
|
||||
- processing STATUS packets for the local QRG, and
|
||||
- handing skeds over to the Win-Test network.
|
||||
- **Log synchronisation**: Worked stations are retrieved from Win-Test and marked in the user list.
|
||||
- **Frequency parsing**: The current TRX frequency from Win-Test populates the `MYQRG` variable.
|
||||
- **Sked handover (SKED push)**: Skeds from KST4Contest are passed directly to Win-Test via UDP. Win-Test's default UDP broadcast port (9871) is used.
|
||||
|
||||
### Log sync settings
|
||||
Settings:
|
||||
- **Enable/Disable**: Checkbox in Preferences (from v1.40).
|
||||
- **Port**: Configurable UDP port for the Win-Test listener.
|
||||
- **Sked UDP address and port**: Target address and port for SKED handover to Win-Test.
|
||||
|
||||
| Setting | Function |
|
||||
|---|---|
|
||||
| **Receive Win-Test network based UDP log messages** | Enables the Win-Test network listener. When the listener is enabled, pressing **Create sked** also attempts the Win-Test handover. |
|
||||
| **UDP-Port for Win-Test listener** | Port used by the Win-Test network. The default is `9871`. The same port is used for the sked handover. |
|
||||
| **KST station name in Win-Test network (src of SKED packets)** | Station name used by KST4Contest when sending sked packets. A unique name should be used in a network containing several clients. |
|
||||
| **Win-Test network broadcast address** | Destination address for outgoing Win-Test network packets. In a local network, the address must be reachable by the Win-Test computer. |
|
||||
|
||||
The broadcast address is configurable because `255.255.255.255` is not forwarded reliably through every station network or network interface. In a multi-computer setup, the directed broadcast address belonging to the station network may be required instead.
|
||||
|
||||
### TRX sync settings
|
||||
|
||||
| Setting | Function |
|
||||
|---|---|
|
||||
| **Win-Test STATUS QRG Sync** | Takes the current frequency from Win-Test STATUS packets and uses it as the local QRG. |
|
||||
| **Use pass frequency from Win-Test STATUS** | Uses the transmitted pass frequency instead of the normal TRX QRG. |
|
||||
| **Win-Test station name filter** | Only processes STATUS packets from the specified Win-Test station. An empty field accepts every station name. |
|
||||
|
||||
The station filter is particularly useful when several Win-Test clients are active. Without a filter, the most recently received STATUS packet from another operating position can overwrite the local QRG in KST4Contest.
|
||||
|
||||
### Sked handover
|
||||
|
||||
There is no separate internal sked mode for the Win-Test handover. When the listener is enabled, **Create sked** attempts the Win-Test transfer in addition to creating the internal sked.
|
||||
|
||||
KST4Contest only sends an `ADDSKED` packet when it can determine a QRG which belongs to the explicitly selected band. If no matching QRG is available, the internal sked remains intact and the Win-Test handover is omitted.
|
||||
|
||||
`SSB` or `CW` is selected directly in the Further Info section when the sked is created. No automatic mode inference is used.
|
||||
|
||||
Click **Save Settings** after making changes so that the port, station name, broadcast address and TRX options are restored at the next start.
|
||||
|
||||
Data handling and QRG selection: [Log Synchronisation – Win-Test](en-Log-Sync#win-test)
|
||||
> **Note**: The Win-Test listener is an **additional** listener – the standard QSO UDP broadcast listener on port 12060 remains independent.
|
||||
|
||||
---
|
||||
|
||||
## PSTRotator Settings (from v1.31)## PSTRotator Settings (from v1.31, fully configurable from v1.40)
|
||||
## PSTRotator Settings (from v1.31)
|
||||
|
||||
KST4Contest can set an antenna direction through the PSTRotator UDP interface and use the current position reported by PSTRotator as the local QTF.
|
||||
KST4Contest can control antenna direction via PSTRotator.
|
||||
|
||||
The settings are located in the **Station** tab:
|
||||
Settings:
|
||||
- **Enable/Disable**: Checkbox in Preferences (from v1.40).
|
||||
- **IP address**: IP address of the PSTRotator computer (default: `127.0.0.1` when running on the same PC).
|
||||
- **Port**: Communication port of PSTRotator.
|
||||
|
||||
| Setting | Default | Purpose |
|
||||
|---|---:|---|
|
||||
| **Enable PSTRotator** | disabled | Starts UDP communication with PSTRotator |
|
||||
| **PSTRotator host** | `127.0.0.1` | Hostname or IP address of the computer running PSTRotator |
|
||||
| **PSTRotator UDP port** | `12000` | UDP port on which PSTRotator receives control commands |
|
||||
|
||||
When both applications run on the same computer, `127.0.0.1` is normally the clearest setting. If PSTRotator runs on another computer in the station network, enter its reachable IP address or DNS name.
|
||||
|
||||
The port must be between `1` and `65534`. Port `65535` cannot be used because PSTRotator reports its position on the following port.
|
||||
|
||||
### Preparing PSTRotator
|
||||
|
||||
Configure the same UDP port under **Communication → UDP Control Port** in PSTRotator and enable **UDP Control**.
|
||||
|
||||
The default configuration uses the following pair:
|
||||
|
||||
| Direction | UDP port |
|
||||
|---|---:|
|
||||
| KST4Contest → PSTRotator | `12000` |
|
||||
| PSTRotator → KST4Contest | `12001` |
|
||||
|
||||
KST4Contest binds the return port automatically. It is not configured separately.
|
||||
|
||||
When the programs run on different computers, the local firewalls and station network must permit UDP traffic in both directions. KST4Contest cannot receive position reports if another program already occupies the return port.
|
||||
|
||||
The complete UDP protocol is documented in the [PSTRotatorAz User Manual](https://www.qsl.net/yo3dmu/ANT/PstRotatorAz%20User%20Manual.pdf).
|
||||
|
||||
### Updating the local QTF
|
||||
|
||||
KST4Contest asks PSTRotator for the current azimuth and operating mode every two seconds. The reported azimuth becomes `actualQTF`.
|
||||
|
||||
While PSTRotator integration is enabled, the QTF field in the main window is therefore read-only. It displays the most recent position reported by PSTRotator.
|
||||
|
||||
This QTF is used by:
|
||||
|
||||
- the direction filter;
|
||||
- the derivation of direction opportunities;
|
||||
- the Priority Score;
|
||||
- the antenna sector on the station map;
|
||||
- the AP and sked timeline; and
|
||||
- the `MYQTF` variable.
|
||||
|
||||
A received rotator position is therefore more than a displayed value. It changes several functions which depend on the current antenna direction.
|
||||
|
||||
The current integration uses azimuth only. Elevation control and complete azimuth/elevation tracking are outside its present scope.
|
||||
|
||||
### Applying changed settings
|
||||
|
||||
The enable setting, host and port are evaluated when the rotator connection is started. After changing them, disconnect and reconnect the ON4KST session or restart KST4Contest.
|
||||
|
||||
Use **Save Settings** afterwards so that the values are restored at the next program start.
|
||||
> **Note**: After clicking a direction button, KST4Contest waits briefly for the rotator response. With slow rotors (e.g. SPID) there may be a small delay.
|
||||
|
||||
---
|
||||
|
||||
## Sniffer Settings (from v1.31)
|
||||
|
||||
QSO monitoring is intended for stations whose communication should remain visible during busy chat activity. This may be a rare station, a DXpedition or another station in the same contest team whose sked arrangements should not disappear in the general message traffic.
|
||||
The QSO sniffer filters chat messages from configurable callsigns and forwards them to the PM window.
|
||||
|
||||
The callsign list is maintained under **QSO monitoring** in the **Notification** tab.
|
||||
Settings:
|
||||
- **Callsign list**: Comma-separated list of callsigns whose messages are always forwarded to the PM window.
|
||||
|
||||
For every monitored base callsign, KST4Contest additionally shows messages in the PM table when a variant of that callsign is either the sender or the receiver. Both connected chat categories are included.
|
||||
|
||||
The list intentionally uses the normalised base callsign. The following entries therefore produce the same monitoring entry:
|
||||
|
||||
```text
|
||||
DN9APW
|
||||
DN9APW-2
|
||||
DN9APW-70
|
||||
DN9APW-144
|
||||
```
|
||||
|
||||
In every case, KST4Contest stores and displays:
|
||||
|
||||
```text
|
||||
DN9APW
|
||||
```
|
||||
|
||||
The different KST suffixes of one station do not have to be entered separately. A later message sent by `DN9APW-2` or addressed to `DN9APW-70` is covered by the same entry.
|
||||
|
||||
This aggregation applies to QSO monitoring only. Active ChatMember objects, complete message destinations and chat categories remain separate. A message addressed to `DN9APW-70` is therefore not redirected to `DN9APW-2`.
|
||||
|
||||
A monitored message is marked in the PM table using the complete visible callsigns of its sender and receiver:
|
||||
|
||||
```text
|
||||
Sniffed: (DN9APW-2 > DL0ABC-70) Message text
|
||||
```
|
||||
|
||||
The original message remains in its normal table. Monitoring changes neither its contents nor its routing.
|
||||
|
||||
A message is included only when the monitored station is actually its sender or receiver. Merely mentioning the callsign in the message text is not sufficient. Public messages sent by a monitored station are included as well; their receiver is displayed as `ALL`.
|
||||
|
||||
A message which is already addressed directly to the local callsign remains a normal private message and does not receive an additional `Sniffed:` marker.
|
||||
|
||||
Manage the list as follows:
|
||||
|
||||
1. Press **Add monitored callsign** to add an entry.
|
||||
2. Double-click an existing entry to edit it and press `Enter` to apply the change.
|
||||
3. To remove an entry, delete the complete cell contents and press `Enter`.
|
||||
|
||||
The entered value may contain a visible KST suffix or portable components. KST4Contest normalises it to the base callsign before storing it. Different variants of the same base callsign are therefore treated as duplicates.
|
||||
|
||||
Changes to the list take effect immediately. Press **Save Settings** afterwards to retain them. The base callsigns are stored in `preferences.xml` and restored at the next program start.
|
||||
|
||||
> Base-callsign monitoring across KST suffixes is included in Nightly / v1.42.
|
||||
|
||||
Further background and the distinction from message routing: [QSO Sniffer](en-Features#qso-sniffer-from-v131).
|
||||
|
||||
---
|
||||
|
||||
## GUI Settings: Band-Column Hints
|
||||
|
||||
Two optional additions to the band columns can be enabled or disabled in the **GUI** tab:
|
||||
|
||||
- **Show "o" in band columns …** displays an `o` if the four-character grid square has already been worked on the relevant band. Disabling the option does not delete any database records; it only hides the additional indicator in the band columns. `wkdany` is unaffected.
|
||||
- **Show "a" in band columns …** distinguishes a completely new callsign from a band opportunity involving a callsign already worked elsewhere. When disabled, both cases are displayed as `B+`. The band-opportunity calculation itself remains unchanged.
|
||||
|
||||
Changes are reflected in the current user interface immediately. Click **Save Settings** afterwards if they should persist after the next start.
|
||||
|
||||
|
||||
Use case: Keep track of important stations (e.g. DX expeditions or trusted contest allies) without constantly monitoring the main chat.
|
||||
|
||||
---
|
||||
|
||||
## Worked Station Database Settings
|
||||
|
||||
The internal SQLite database stores contest-related state independently of the logging application's database:
|
||||
The internal worked database contains:
|
||||
|
||||
- the global Worked status of a callsign,
|
||||
- Worked status per band,
|
||||
- manually assigned NOT-QRV marks per band, and
|
||||
- worked four-character grid squares per band.
|
||||
- Worked status of all stations (per band)
|
||||
- NOT-QRV tags (since v1.2)
|
||||
|
||||
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.
|
||||
|
||||
Worked and NOT-QRV information expires automatically three days after its most recent change. Stored grid squares expire three days after the corresponding log entry. A manual reset before every contest is therefore normally unnecessary.
|
||||
|
||||
The **Reset worked, NOT-QRV and grid data...** button removes every Worked mark, NOT-QRV mark and stored worked grid square. A confirmation dialog is displayed first. Known callsign rows remain in the database; only the contest-related state is reset.
|
||||
|
||||
A reset is useful when you deliberately want to start with an empty contest state or have imported test data. It is not intended as a daily maintenance step.
|
||||
|
||||
Display and derivation: [Worked Callsigns, New Bands and New Grid Squares](en-Features#worked-callsigns-new-bands-and-new-grid-squares).
|
||||
**From v1.40**: Entries have an automatic lifetime of **3 days** – manually resetting before each contest is no longer strictly necessary. For a full reset, the **"Reinitialize"** button is still available.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -43,30 +43,6 @@ Similar settings:
|
||||
|
||||
---
|
||||
|
||||
## Testing the Connection
|
||||
|
||||
After the logger's DX cluster client has connected, use **Send test spot** to generate the following entry:
|
||||
|
||||
```text
|
||||
Spotted callsign: DO5AMF
|
||||
Comment: Testing DXC-Spot: Congrats, you donated $100!
|
||||
Frequency: .300 on the configured fallback band
|
||||
```
|
||||
|
||||
With `144 MHz` selected as the fallback band, the spot appears at approximately `144.300 MHz`.
|
||||
|
||||
The comment is a deliberately retained Easter egg. It makes the test entry easy to identify but has no other function. In particular, no donation or other external action is triggered.
|
||||
|
||||
Three conditions must be met before running the test:
|
||||
|
||||
1. KST4Contest is connected to the ON4KST chat.
|
||||
2. The local DX cluster server is enabled.
|
||||
3. The logging software's DX cluster client is connected to KST4Contest.
|
||||
|
||||
If no client is connected, KST4Contest displays a corresponding message. A successful test therefore confirms that at least one connected client received the generated spot.
|
||||
|
||||
---
|
||||
|
||||
## How It Works
|
||||
|
||||
A spot is generated when **both** conditions are met:
|
||||
|
||||
+57
-715
@@ -28,7 +28,7 @@ The calculation is based on the following logic:
|
||||
|
||||
The calculation does not include topographic path calculations – this is a deliberate simplification. It may be added in a future version.
|
||||
|
||||
> Configuration: [Configuration – Antenna Beamwidth](en-Configuration#antenna-beamwidth)
|
||||
> Configuration: [Configuration – Antenna Beamwidth](Configuration#antenna-beamwidth)
|
||||
|
||||
---
|
||||
|
||||
@@ -48,92 +48,26 @@ Recognised formats: `144.205`, `432.088`, `.205` (with configured band assumptio
|
||||
|
||||
---
|
||||
|
||||
## Worked Callsigns, New Bands and New Grid Squares
|
||||
## Worked Marking
|
||||
|
||||
KST4Contest distinguishes between three pieces of information which may look similar during a contest but answer different questions:
|
||||
Worked stations are visually marked in the user list – per band. Based on [Log Synchronisation](en-Log-Sync) via UDP or Simplelogfile.
|
||||
|
||||
1. Has this callsign been worked before?
|
||||
2. Has this callsign been worked on a particular band?
|
||||
3. Has the four-character Maidenhead grid square already been worked, possibly with a different station?
|
||||
Reset the database before each contest: [Configuration – Worked Station Database Settings](Configuration#worked-station-database-settings).
|
||||
|
||||
This distinction matters. A callsign already worked on one band may still be useful on another. Conversely, a new callsign may be located in a grid square which is already in the log.
|
||||
---
|
||||
|
||||
### Worked information from the log
|
||||
## NOT-QRV Tags (from v1.2)
|
||||
|
||||
[Log Synchronisation](en-Log-Sync) imports new QSOs from the logging application. The amount of information available depends on the interface being used:
|
||||
|
||||
- The file-based Simplelogfile interpreter detects callsigns only. It can therefore set only the global Worked status.
|
||||
- The QSO UDP interfaces and the Win-Test network listener can also provide the band.
|
||||
- If the log packet contains a valid locator, KST4Contest additionally stores the worked four-character grid square for that band.
|
||||
|
||||
Missing information is not guessed. A QSO without a locator does not create a worked-grid record, and a Simplelogfile match does not create a band-specific Worked mark.
|
||||
|
||||
### Meaning of the band columns
|
||||
|
||||
The shared **worked** column contains only the bands enabled under **Station → My station uses …**. Its cells deliberately use short status codes because a full description would leave very little room for the actual user list.
|
||||
|
||||
| Display | Meaning |
|
||||
|---|---|
|
||||
| `X` | The callsign has been worked on this band. |
|
||||
| `a` | The station offers this band, the band has not been worked yet, and the callsign has not been worked on any band. |
|
||||
| `B+` | The station offers this band and it has not been worked yet. The callsign has already been worked on another band. If the separate `a` display is disabled, a completely new callsign is also shown as `B+`. |
|
||||
| `o` | The station's four-character grid square has already been worked on this band, regardless of callsign. |
|
||||
| empty | No matching information is available for this band. This does not mean that the station is not QRV. |
|
||||
|
||||
The `o` is an independent overlay and can therefore be combined with the other codes. Examples include `Xo`, `ao` and `B+o`. A single `o` means that the grid square has been worked on this band, while the displayed callsign has neither a Worked mark nor a current band opportunity.
|
||||
|
||||
|
||||
|
||||
### How is a band opportunity derived?
|
||||
|
||||
KST4Contest displays `a` or `B+` only if it can derive an open band opportunity. The calculation combines:
|
||||
|
||||
1. the bands enabled for the local station,
|
||||
2. QRGs detected for the remote station during the previous 30 minutes,
|
||||
3. explicit band designators in the remote station's name field,
|
||||
4. stored per-band Worked marks, and
|
||||
5. manually assigned NOT-QRV marks.
|
||||
|
||||
Active chat entries with the same normalised callsign are evaluated together. This is particularly relevant when the station appears in several chat categories or with different visible callsign variants. An explicit band designator in the name field remains useful while the corresponding chat entry is active. A band derived from a detected QRG expires after 30 minutes.
|
||||
|
||||
The remaining set contains only bands which are enabled locally, known for the remote station and not yet worked. A manual NOT-QRV mark overrides automatically detected evidence. The chat category alone is not sufficient evidence that an individual station is QRV on a particular band.
|
||||
|
||||
The global Worked mark does not decide whether a band opportunity exists. It merely selects `a` or `B+` for the display. The actual opportunity calculation uses per-band Worked information.
|
||||
|
||||
### Meaning of `wkdany`
|
||||
|
||||
The **wkdany** subcolumn combines the global callsign and grid-square status:
|
||||
|
||||
| Display | Meaning |
|
||||
|---|---|
|
||||
| empty | Neither the callsign nor the four-character grid square has been worked. |
|
||||
| `x` | The callsign has been worked on at least one band. |
|
||||
| `o` | The four-character grid square has been worked on at least one band. |
|
||||
| `xo` | Both the callsign and the grid square have been worked. |
|
||||
|
||||
`wkdany` is deliberately band-independent. The lower-case `x` must therefore not be confused with the upper-case `X` in a band column. The global status is used for the overview and the global **wkd** filter; it is not a substitute for per-band Worked information.
|
||||
|
||||
### NOT-QRV marks
|
||||
|
||||
If a station reports that it is not QRV on a particular band, mark this in the selected station's **Further Info** panel:
|
||||
When a station indicates it is not QRV on a specific band, this can be manually marked:
|
||||
|
||||
1. Select the station in the user list.
|
||||
2. Enable the relevant band under **Not QRV**.
|
||||
3. Use **tag not qrv all** only if the station should not be requested on any supported band.
|
||||
2. Right-click → Set NOT-QRV for the appropriate band.
|
||||
|
||||
The individual NOT-QRV controls are shown for the bands enabled at the local station. **tag not qrv all**, however, marks every supported band, including bands which are not currently visible in the user interface. The state is stored per band under the normalised callsign and propagated to its active chat variants.
|
||||
These tags are stored in the internal database and persist after a KST4Contest restart. Can be reset via the settings.
|
||||
|
||||
|
||||
**Benefit**: Prevents repeated sked requests on bands where the station is not active – saves time for both sides.
|
||||
|
||||
NOT-QRV is a manual correction and therefore takes precedence over detected QRGs and band designators in the name field. The affected band is no longer offered as `a` or `B+`, is not counted as an opportunity by the **New bands** filter and is excluded by the corresponding band filter.
|
||||
|
||||
In plain terms: an automatically detected hint means "probably active on this band". A manual NOT-QRV mark means "do not request this station on this band". The next detected number must not silently reverse that decision.
|
||||
|
||||
### Storage and lifetime
|
||||
|
||||
Worked, NOT-QRV and worked-grid information 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.
|
||||
|
||||
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.
|
||||
---
|
||||
|
||||
## Direction Filter
|
||||
|
||||
@@ -149,19 +83,9 @@ Hide stations beyond a maximum distance. The **"Show only QRB [km] <="** button
|
||||
|
||||
---
|
||||
|
||||
## Filters for Worked Status, New Bands and New Grid Squares
|
||||
## Worked and NOT-QRV Filter
|
||||
|
||||
The filters above the user list use the same information as the Worked columns:
|
||||
|
||||
- **wkd** hides callsigns which have been worked on at least one band.
|
||||
- The individual band buttons hide a station if the callsign has already been worked on that band or has manually been marked NOT QRV there.
|
||||
- **New bands** shows only stations for which at least one locally enabled and unworked band is known. It evaluates recent QRG detections and band designators in the name field; NOT-QRV takes precedence.
|
||||
- **Only new grids** shows only stations whose four-character grid square has not been worked on any band. Stations without a valid locator do not pass this filter.
|
||||
- **Grid color** does not filter the list. When enabled, it gives the QRA cell of an already worked grid square a slightly darker background. New grid squares retain the normal table colour.
|
||||
|
||||
Several active filters are applied together. A station remains visible only if it satisfies every selected condition. The filters react immediately to new log entries and changed NOT-QRV marks.
|
||||
|
||||
Operation and layout of the filter bar: [User Interface – Filters](en-User-Interface#filters).
|
||||
Toggle buttons (one per band) to hide already-worked stations and/or NOT-QRV-tagged stations. The filter takes effect **immediately** without manually reactivating (live since v1.22).
|
||||
|
||||
---
|
||||
|
||||
@@ -185,27 +109,6 @@ KST4Contest detects such messages that contain your own callsign and automatical
|
||||
|
||||
---
|
||||
|
||||
## Automatic Replies to Private Messages (from v1.25)
|
||||
|
||||
Not every station logged into the ON4KST chat is taking part in the current contest. Sked requests may nevertheless be sent to many visible callsigns without first checking whether they are participating. Without an automatic reply, those stations would have to enter the same refusal repeatedly.
|
||||
|
||||
KST4Contest can answer such private messages with a predefined text. The incoming message remains visible; it is neither blocked nor discarded. A separate QRG reply recognises common requests such as `qrg?`, `freq?` and `pse qrg`.
|
||||
|
||||
When two chat categories are connected, the original context is retained. The reply is addressed to the complete sender callsign and sent through the category in which the request arrived. A QRG request receives only the QRG belonging to that category.
|
||||
|
||||
If the required QRG is missing, KST4Contest sends no incomplete answer. Empty or locally invalid general reply texts are rejected as well.
|
||||
|
||||
Automatic replies need limits. KST4Contest adds the fixed prefix `[KST4C Automsg]`, ignores incoming messages which already contain that prefix and permits only one automatic reply to the same complete callsign in the same category within two minutes. The cooldown is shared by the general and QRG-specific reply functions.
|
||||
|
||||
A rejected reply does not start the cooldown. After entering the missing QRG or correcting the configured text, KST4Contest can therefore answer the next request immediately.
|
||||
|
||||
In plain terms: the function cannot prevent indiscriminate sked requests. It prevents the recipient from having to answer every one of them with the same refusal. It is not intended to simulate a conversation, let alone start an endless discussion with another automatic client.
|
||||
|
||||
Configuration, recognised QRG requests and category handling: [Configuration – Messagehandling Settings](en-Configuration#messagehandling-settings-from-v125).
|
||||
|
||||
---
|
||||
|
||||
|
||||
## Multi-Channel Login (from v1.26)
|
||||
|
||||
Simultaneous login to **two chat categories** (e.g. 144 MHz and 432 MHz). Both chats are monitored in parallel.
|
||||
@@ -232,662 +135,101 @@ For selected stations in the user list, there are direct buttons to open the **Q
|
||||
|
||||
---
|
||||
|
||||
## Skeds and Sked Reminders
|
||||
## Sked Reminders with ALERT (from v1.40)
|
||||
|
||||
> Available from v1.40; band, callsign and Win-Test handling extended in Nightly / v1.42.
|
||||
A sked reminder service with automatic messages can be activated for each chat member. Configurable interval patterns:
|
||||
|
||||
A sked is more than a reminder tied to a particular time. During a contest, it must become visible early enough, move the agreed station up the priority list and – if required – remind the remote station as well.
|
||||
- **2+1 minutes**: Messages at 2 min and 1 min before the sked.
|
||||
- **5+2+1 minutes**: Messages at 5, 2 and 1 min before the sked.
|
||||
- **10+5+2+1 minutes**: Messages at 10, 5, 2 and 1 min before the sked.
|
||||
|
||||
KST4Contest therefore treats three tasks separately:
|
||||
In addition to the automated messages to the remote station, there is an **acoustic and visual notification** for your own operator so no sked is ever missed.
|
||||
|
||||
1. The sked is stored internally and included in the priority calculation.
|
||||
2. The scheduled contact appears in the AP and sked timeline.
|
||||
3. Automatic private reminder messages can optionally be sent before the agreed time.
|
||||
|
||||
When the Win-Test network listener is enabled, KST4Contest also attempts to hand the sked over to Win-Test. A failed handover neither removes nor prevents the internal sked.
|
||||
|
||||
### Creating a sked
|
||||
|
||||
First select the required station in the user list. The sked controls then appear at the bottom of the **Further Info** section.
|
||||
|
||||
| Control | Function |
|
||||
|---|---|
|
||||
| **Sked in** | Sets the number of minutes until the sked. Available values are 2 through 15 and 20 minutes. |
|
||||
| **Band** | Selects the sked band. The dropdown contains the local bands enabled under **Station → my station uses …**. |
|
||||
| **Mode** | Sets the mode passed to Win-Test. Available values are `SSB` and `CW`. This selection does not affect the internal sked or reminder PMs. |
|
||||
| **Create sked** | Creates the internal sked and, if the Win-Test network listener is enabled, also attempts the Win-Test handover. |
|
||||
| **Remind-PM in** | Enables automatic private reminder messages before the sked. |
|
||||
| **2+1**, **5+2+1**, **10+5+2+1** | Selects how many minutes before the sked the reminder PMs are sent. |
|
||||
|
||||
|
||||
|
||||
KST4Contest attempts to preselect a useful band. It checks the following information in this order:
|
||||
|
||||
1. a QRG of the selected station which is no more than 30 minutes old and belongs to a locally enabled band,
|
||||
2. an unambiguous band designator in the station's name field, and
|
||||
3. the first locally enabled band.
|
||||
|
||||
Active callsign variants belonging to the same base callsign are evaluated together when looking for recent band information. A manual NOT-QRV mark is taken into account by the automatic selection. The operator can still select another band explicitly when a different arrangement has been made.
|
||||
|
||||
### Effect on the Priority Score
|
||||
|
||||
A stored sked raises the score of the normalised base callsign:
|
||||
|
||||
| Time relative to the sked | Contribution to the score |
|
||||
|---|---:|
|
||||
| more than 15 minutes before the sked | `+40` |
|
||||
| 15 to 3 minutes before the sked | continuous increase from `+300` towards `+1200` |
|
||||
| less than 3 minutes before until 1 minute after the sked | `+5000` |
|
||||
| more than 1 minute after the sked | no remaining sked boost |
|
||||
|
||||
The strong weighting immediately around the scheduled time is intentional. An agreed sked should not disappear from the priority list merely because another station is currently very active but has no fixed appointment.
|
||||
|
||||
The score is calculated for the base callsign. A sked created for `DN9APW-2` therefore also affects the shared score of other active `DN9APW` variants. The actual message target nevertheless remains `DN9APW-2` in the chat category selected when the sked was created.
|
||||
|
||||
The sked is removed from the internal list five minutes after its scheduled time.
|
||||
|
||||
### Reminder PMs
|
||||
|
||||
Reminder PMs are only scheduled when **Remind-PM in** is enabled. Depending on the selected pattern, KST4Contest sends a private message such as the following two and one minute before the sked:
|
||||
|
||||
```text
|
||||
[KST4C Autoreminder] sked in 2 min
|
||||
```
|
||||
|
||||
The message is sent to the complete visible KST callsign in the chat category in which the sked was created. A sked for `DN9APW-2` is therefore not accidentally sent to `DN9APW`, `DN9APW-70` or a similarly named station in another category.
|
||||
|
||||
When a reminder is actually triggered, KST4Contest also displays the visual **SKED** indication. If simple notification sounds are enabled, a short sound is played as well. Merely arming a reminder does not start the blinking indication.
|
||||
|
||||
Creating a new set of reminders for the same complete callsign replaces the previously scheduled reminders for that callsign.
|
||||
|
||||
### Storage and limitations
|
||||
|
||||
Skeds and reminder schedules are kept in memory only. Any skeds which are still required must be recreated after restarting KST4Contest.
|
||||
|
||||
The automatic band selection is derived from available chat information. It cannot prove that the station is still operating on the most recently mentioned QRG. Check the band, time and mode before pressing **Create sked**.
|
||||
|
||||
Operation: [Station Info Panel](en-User-Interface#station-info-panel-further-info)
|
||||
|
||||
Display: [AP and Sked Timeline](#ap-and-sked-timeline)
|
||||
|
||||
Win-Test handover: [Log Synchronisation – Win-Test](en-Log-Sync#win-test)
|
||||
Activate from the FurtherInfo panel of the corresponding station.
|
||||
|
||||
---
|
||||
|
||||
## QSO Sniffer (from v1.31)
|
||||
|
||||
During a contest, it may be useful to follow the communication of one particular station. This is not limited to rare stations or DXpeditions. Sked arrangements made by another station in the same team can disappear just as easily in a busy public chat.
|
||||
|
||||
KST4Contest can therefore show every message sent or received by a monitored station additionally in the PM table. The message remains in its original table at the same time.
|
||||
|
||||
Monitoring uses the normalised base callsign. An entry for `DN9APW` consequently covers messages sent by or addressed to:
|
||||
|
||||
```text
|
||||
DN9APW-2
|
||||
DN9APW-70
|
||||
DN9APW-144
|
||||
DN9APW-432
|
||||
```
|
||||
|
||||
Entering `DN9APW-70` in the monitoring list still stores `DN9APW`. A station using several band- or operating-position-specific KST suffixes therefore needs only one entry.
|
||||
|
||||
The actual message retains the complete callsigns:
|
||||
|
||||
```text
|
||||
Sniffed: (DN9APW-70 > 9A0BB-23) pse sked 19:30
|
||||
```
|
||||
|
||||
This distinction is intentional. Monitoring aggregates the variants so that their communication remains visible. Message routing does not aggregate them because the intended login would otherwise become ambiguous.
|
||||
|
||||
The base callsign is evaluated across both connected chat categories. The category of each individual message remains unchanged.
|
||||
|
||||
The monitoring view includes:
|
||||
|
||||
- directed messages sent by a monitored station;
|
||||
- directed messages addressed to a monitored station; and
|
||||
- public messages sent by a monitored station to `ALL`.
|
||||
|
||||
A callsign which merely occurs in the message text does not trigger monitoring.
|
||||
|
||||
Messages already addressed directly to the local callsign remain normal private messages and are not additionally marked as `Sniffed:`. QSO monitoring also does not generate a separate notification sound. Sound notifications for private messages actually addressed to the local station remain independent.
|
||||
|
||||
The function does not request additional messages from the ON4KST server. It only provides another view of chat traffic which KST4Contest has already received.
|
||||
|
||||
In plain terms: QSO monitoring does not decide whether a message really contains a sked or matters to the local contest operation. It makes the communication of the selected station easier to find. The operator still decides what to do with it.
|
||||
The QSO sniffer monitors the chat for messages from a configurable callsign list and automatically forwards them to the **PM window**. This prevents relevant messages from being lost in the general chat traffic.
|
||||
|
||||
Configuration: [Configuration – Sniffer Settings](en-Configuration#sniffer-settings-from-v131)
|
||||
|
||||
Complete callsigns and chat-category separation: [Multi-Channel Login](#multi-channel-login-from-v126)
|
||||
|
||||
---
|
||||
|
||||
## Win-Test Integration
|
||||
## Win-Test Integration (from v1.31, fully configurable from v1.40)
|
||||
|
||||
KST4Contest uses a dedicated listener for the native Win-Test network protocol. It provides three separate functions:
|
||||
KST4Contest fully supports [Win-Test](https://www.win-test.com/) as a logging programme:
|
||||
|
||||
- importing new QSOs including band and, where available, locator information,
|
||||
- reading the current QRG from Win-Test STATUS packets, and
|
||||
- handing internally created skeds over to the Win-Test network as `ADDSKED` packets.
|
||||
- **Log synchronisation**: Worked stations are automatically retrieved from Win-Test and marked in the user list.
|
||||
- **Frequency parsing**: The current TRX frequency is read from Win-Test UDP packets and populates the `MYQRG` variable.
|
||||
- **Sked handover (SKED push via UDP)**: Agreed skeds from KST4Contest can be pushed directly to Win-Test, so the remote callsign appears in Win-Test's sked window.
|
||||
|
||||
The sked handover does not replace a missing QRG with a fixed default frequency. KST4Contest only sends a Win-Test sked when it can determine a QRG which belongs to the selected band. The internal sked, timeline and reminder PMs continue to work independently.
|
||||
|
||||
A visible KST suffix such as `-2`, `-70` or `-144` is retained inside KST4Contest but removed from the callsign passed to the Win-Test log. Portable components such as `/P`, `/M` and country prefixes are preserved.
|
||||
|
||||
Setup and data handling: [Log Synchronisation – Win-Test](en-Log-Sync#win-test)
|
||||
|
||||
Settings: [Win-Test Network Listener](en-Configuration#win-test-network-listener-from-v131)
|
||||
Details: [Configuration – Win-Test Network Listener](en-Configuration#win-test-network-listener)
|
||||
|
||||
---
|
||||
|
||||
## PSTRotator Interface (from v1.31, fully configurable from v1.40)
|
||||
|
||||
KST4Contest can point the antenna at the selected remote station through the PSTRotator UDP interface. The required azimuth is calculated from the local and remote locators.
|
||||
KST4Contest can control antenna direction directly via **PSTRotator**. When a station is selected in the user list, the rotator can automatically be turned to the QTF of the selected station.
|
||||
|
||||
After selecting a station, the **Further Info** section provides the **Turn ant1 to …** button:
|
||||
|
||||
|
||||
|
||||
Pressing the button performs the following steps:
|
||||
|
||||
1. KST4Contest disables PSTRotator tracking mode.
|
||||
2. The QTF of the selected station is transmitted as an integer azimuth.
|
||||
3. PSTRotator controls the configured rotor.
|
||||
4. The reported position becomes the current QTF in KST4Contest.
|
||||
|
||||
The button remains visible while PSTRotator integration is disabled. In that case, no rotator command is sent.
|
||||
|
||||
### Position feedback and SPID compatibility
|
||||
|
||||
KST4Contest requests the current azimuth every two seconds. Position reports update the local QTF field and every function which depends on the antenna direction.
|
||||
|
||||
Some SPID configurations occasionally ignore the first direction command. KST4Contest therefore checks two seconds later whether PSTRotator reported movement or reached the requested target.
|
||||
|
||||
If the position remained unchanged and the target was not reached, KST4Contest sends one compatibility sequence through `0°` followed by the actual target value.
|
||||
|
||||
This check runs in the background. The user interface remains responsive during the two-second interval. A new direction command replaces the pending check belonging to the previous command.
|
||||
|
||||
### What does the reported position confirm?
|
||||
|
||||
The displayed QTF is the azimuth reported by PSTRotator. It confirms that KST4Contest received a usable UDP position message.
|
||||
|
||||
Depending on the station setup, it does not necessarily prove that the antenna is mechanically aligned to exactly that value. This still depends on the controller, calibration, configured offsets and the feedback available to PSTRotator.
|
||||
|
||||
UDP itself provides no delivery acknowledgement. If the displayed QTF does not change, check:
|
||||
|
||||
- that **UDP Control** is enabled in PSTRotator;
|
||||
- that the host and control port match;
|
||||
- that `control port + 1` is available for the position report;
|
||||
- that the firewall permits both UDP directions; and
|
||||
- that PSTRotator itself displays a plausible rotor position.
|
||||
|
||||
In plain terms: KST4Contest provides the target and processes the reported position. The mechanical reality remains the responsibility of the rotor – and occasionally a glance outside.
|
||||
|
||||
Configuration and port assignment: [Configuration – PSTRotator Settings](en-Configuration#pstrotator-settings-from-v131-fully-configurable-from-v140).
|
||||
Configuration: [Configuration – PSTRotator Settings](en-Configuration#pstrotator-settings-from-v131)
|
||||
|
||||
---
|
||||
|
||||
## Band Upgrade Hint after a Log Entry
|
||||
## Band Alert for New QSOs (from v1.40)
|
||||
|
||||
When UCXLog or Win-Test reports a new log entry with band information, KST4Contest checks whether the worked station still offers another common band.
|
||||
|
||||
The calculation follows the same rules as `a`, `B+` and the **New bands** filter: locally enabled bands, recent QRG detections, band designators in the name field, per-band Worked marks and NOT-QRV marks. Active chat variants of the same normalised callsign are evaluated together.
|
||||
|
||||
If at least one common and unworked band remains, a blinking hint appears for approximately twelve seconds. It includes the callsign and the remaining bands, for example `BAND+ DL0ABC 432, 1296`. Its tooltip also lists the enabled, worked and NOT-QRV bands used for the decision. If general notification sounds are enabled, KST4Contest also plays a short sound.
|
||||
|
||||
The Simplelogfile interpreter cannot trigger this hint reliably because it provides no band information for the QSO which has just been logged.
|
||||
|
||||
Configuration: [Band Upgrade Hint after a Log Entry](en-Configuration#band-upgrade-hint-after-a-log-entry).
|
||||
|
||||
Worked, NOT-QRV and worked-grid data expire automatically after three days. See [Worked Station Database Settings](en-Configuration#worked-station-database-settings) for the lifetime and manual reset behaviour.
|
||||
When a station is logged, KST4Contest automatically checks whether that station has shown any other active bands in the chat that you are also QRV on. If so, a **hint alert** appears so no multi-band opportunity is missed.
|
||||
|
||||
---
|
||||
|
||||
## Priority Score and Priority List (from v1.40)
|
||||
## Worked Tag Lifetime (from v1.40)
|
||||
|
||||
### Why is a score needed at all?
|
||||
|
||||
A conventional chat user list initially tells the operator only which stations are logged in. That is not enough during a contest. The operator must also consider which stations have not yet been worked, which bands may still be available, where the antenna is pointing, whether a suitable aircraft is approaching and whether an agreed sked is about to begin.
|
||||
|
||||
With a short list, much of this can still be handled mentally. As the contest continues, several bands are used and two chat categories are monitored at the same time, the same decision has to be reconstructed over and over again.
|
||||
|
||||
KST4Contest therefore combines the available information into a priority score. The score does not answer whether a QSO will definitely be possible. It supports the more practical question:
|
||||
|
||||
> Which of the currently visible stations should I examine next?
|
||||
|
||||
### When is a station excluded?
|
||||
|
||||
Before applying the weighted factors, KST4Contest checks whether a known band opportunity exists. All active chat entries belonging to the same normalised base callsign are evaluated together.
|
||||
|
||||
The calculation uses:
|
||||
|
||||
1. the bands enabled in the local station settings,
|
||||
2. QRGs detected for the remote station during the previous 30 minutes,
|
||||
3. explicit band designators in the name fields of its active chat entries,
|
||||
4. stored per-band Worked marks, and
|
||||
5. manually assigned NOT-QRV marks.
|
||||
|
||||
NOT QRV takes precedence over automatically detected frequencies and band designators.
|
||||
|
||||
If the remote station’s bands are known but none of them is both enabled locally and still available, the station receives a score of `0`. The same applies when every common band opportunity has already been worked.
|
||||
|
||||
A station is not excluded merely because all band information is missing. An unknown band opportunity is not the same as a known incompatibility. In this case, the station is removed from consideration only if all locally enabled bands have been manually marked NOT QRV for that station.
|
||||
|
||||
Stations with a score of `0` remain visible in the user list but are not included in the priority list.
|
||||
|
||||
### Which information raises or lowers the score?
|
||||
|
||||
The score combines several independent hints. One factor will therefore not normally determine the final position on its own.
|
||||
|
||||
| Factor | Effect on priority |
|
||||
|---|---|
|
||||
| Worked status | A callsign which has not been worked on any supported band receives a higher initial priority. A station which has already been worked is ranked lower but remains a candidate when another band opportunity is available. |
|
||||
| Available bands | Several common and unworked bands raise the priority. An additional boost for band-upgrade cases can be enabled separately. |
|
||||
| Distance | Distances below 200 km are weighted lower. The range between 200 km and the configured maximum QRB is preferred. Stations beyond the maximum QRB are reduced substantially. If the QRB is unavailable, this factor is omitted. |
|
||||
| Antenna direction | The score rises when the QTF to the station lies within half of the configured antenna beamwidth around the current local QTF. The closer both directions are, the stronger the effect. |
|
||||
| AirScout | At least one currently reachable aircraft raises the score. An expected AP opportunity in zero, one or two minutes receives an additional time-dependent weighting. |
|
||||
| Recent chat activity | A message received during the previous minute has a stronger effect than one received during the previous three minutes. Several incoming lines within the activity window raise the score further. |
|
||||
| Positive signals | Detected terms such as `QRV`, `READY`, `RGR`, `OK`, `TNX` or comparable configured text patterns are treated as a positive hint for several minutes. |
|
||||
| Reply behaviour | If another visible chat line from the station follows an outgoing `/cq` message quickly, the averaged reaction time raises the score. If no such line arrives before the configured timeout, a negative mark is added. |
|
||||
| Skeds | A scheduled contact initially adds a small amount of priority. During the final 15 minutes, its influence increases continuously. From three minutes before until one minute after the scheduled time, the sked receives very high priority. |
|
||||
| Failed attempt | **Sked fail** strongly reduces the station’s score until the mark is removed with **Reset fail** or KST4Contest is restarted. |
|
||||
|
||||
The default activity window for counting incoming messages is 180 seconds. A message received during the previous 60 seconds is evaluated separately as current activity. The default no-reply timeout is 13 minutes.
|
||||
|
||||
For reply behaviour, KST4Contest cannot prove that a later public or private line is actually a reply to the operator’s request. Any subsequent line received from the same station therefore ends the pending response-time measurement. This is a practical approximation, not a statistically reliable response rate.
|
||||
|
||||
### What does a scheduled contact mean for the score?
|
||||
|
||||
A sked is a time-dependent operating commitment. An imminent sked must therefore take precedence over most normal activity and distance hints. Without this weighting, a station which happens to be very active in the chat could displace an agreed contact from the priority list.
|
||||
|
||||
The strongest sked boost is deliberately limited to the period from three minutes before until one minute after the scheduled time. A sked further in the future remains relevant but should not yet dominate current operation.
|
||||
|
||||
The score is calculated for the normalised base callsign. A sked entered for an active variant such as `9A0BB-23` therefore affects the common score of the chat entries belonging to `9A0BB`.
|
||||
|
||||
### How are multiple suffixes and chat categories handled?
|
||||
|
||||
Active callsigns such as `9A0BB-2`, `9A0BB-70`, `9A0BB-23` and `9A0BB-13` remain separate chat members. Messages can therefore still be addressed to the complete callsign in the correct chat category.
|
||||
|
||||
Worked, band, NOT-QRV and score information belongs to the common base callsign `9A0BB`. The score is calculated once and projected to all active variants. The user list may consequently contain several separate rows with the same score, while the priority list contains only one entry for the base station.
|
||||
|
||||
KST4Contest uses the most recently suitable active login in the last relevant chat category as the concrete message target. Selecting a priority candidate then resolves the complete callsign, including its suffix and chat category.
|
||||
|
||||
### Updating and displaying the score
|
||||
|
||||
New messages, AirScout data, skeds, Worked information and manual NOT-QRV or Sked-fail changes request a new calculation immediately. The score is also refreshed periodically because activity, AP and sked information changes with time even when no new event is received.
|
||||
|
||||
A delay of a few seconds between an event and the visible new order is therefore normal.
|
||||
|
||||
The user interface displays the score in three places:
|
||||
|
||||
- the numerically sortable **Score** column in the user list,
|
||||
- the **Further Info** section for the selected station, and
|
||||
- the compact list of the two highest-ranked candidates, with a separate window containing up to 15 candidates.
|
||||
|
||||
Operation: [Priority List in the User Interface](en-User-Interface#priority-list).
|
||||
|
||||
### What does the score not tell you?
|
||||
|
||||
The numerical value is neither a success probability nor a signal prediction. A score which is twice as high does not mean that the QSO is twice as likely.
|
||||
|
||||
Among other things, the calculation does not know:
|
||||
|
||||
- the actual antenna direction of the remote station,
|
||||
- its current operating situation,
|
||||
- local interference,
|
||||
- short-term propagation changes,
|
||||
- terrain obstruction outside the connected assessment functions, or
|
||||
- whether a station which is active in the chat is currently sitting at the radio.
|
||||
|
||||
Known input data may also be outdated or ambiguous. A detected frequency, for example, proves only that the QRG recently appeared in connection with that station.
|
||||
|
||||
In practical terms, the score does not replace the operator’s decision. It prevents the information already available to KST4Contest from having to be reconstructed mentally for every candidate.
|
||||
|
||||
Related settings:
|
||||
|
||||
- [Active Bands](en-Configuration#active-bands)
|
||||
- [Antenna Beamwidth](en-Configuration#antenna-beamwidth)
|
||||
- [Default Maximum QRB](en-Configuration#default-maximum-qrb)
|
||||
- [AirScout Settings](en-Configuration#airscout-settings)
|
||||
- [Band Upgrade Hint and Priority Boost](en-Configuration#band-upgrade-hint-after-a-log-entry)
|
||||
Worked stations are automatically removed from the database after **3 days**. Manually resetting the worked database before each contest is therefore no longer strictly necessary – the database keeps itself up to date.
|
||||
|
||||
---
|
||||
|
||||
## AP and Sked Timeline
|
||||
## Chatmember Score System / Priority List (from v1.40)
|
||||
|
||||
The timeline combines upcoming aircraft-scatter opportunities and stored skeds for the next 30 minutes. It therefore answers two different questions in the same place:
|
||||
KST4Contest automatically calculates a **priority score** for each active chat member. The score is derived from:
|
||||
|
||||
- When is an interesting AP opportunity expected?
|
||||
- Which previously agreed sked is approaching independently of that opportunity?
|
||||
- Antenna direction of the remote station (is it pointing towards me?)
|
||||
- QRB (distance)
|
||||
- Activity time and message count
|
||||
- Active bands and frequencies
|
||||
- AP availability (AirScout)
|
||||
- Sked direction (degrees)
|
||||
- Sked success rate and skedfail markings
|
||||
|
||||
Events further in the future appear on the right. As time passes, they move left towards the current time.
|
||||
The top candidates are highlighted in a dedicated priority list, helping you not to miss the most important contacts during contest stress.
|
||||
|
||||
|
||||
Stations with a failed sked can be marked using the **Skedfail button** in the FurtherInfo panel – this temporarily lowers their score.
|
||||
|
||||
### AP candidates
|
||||
---
|
||||
|
||||
AP candidates appear in the upper lanes. Up to four selected candidates can be displayed for each aircraft arrival minute. The selection takes the Priority Score and the reflection potential reported by AirScout into account.
|
||||
## AP Timeline (from v1.40)
|
||||
|
||||
The colour of an AP marker represents the reflection potential:
|
||||
A visual timeline shows up to 4 highly-scored stations per minute slot that should be workable via aircraft scatter. Prioritisation criteria:
|
||||
|
||||
| Colour | Reflection potential |
|
||||
|---|---:|
|
||||
| Magenta | at least 95% |
|
||||
| Red | at least 75% |
|
||||
| Yellow | at least 50% |
|
||||
| Blue | below 50% |
|
||||
|
||||
The colour is not a QSO probability. It represents the AirScout value for the calculated reflection geometry.
|
||||
|
||||
Clicking an AP candidate selects the corresponding active chat member, including its callsign suffix and chat category. A suitable message can then be prepared immediately.
|
||||
|
||||
### Skeds
|
||||
|
||||
Skeds appear as diamonds in the lower lane. Their labels use the complete KST callsign, for example `SKED: DN9APW-2`. This makes it clear which particular login was selected for the scheduled contact.
|
||||
|
||||
A sked tooltip shows at least:
|
||||
|
||||
- the complete KST callsign,
|
||||
- the agreed band, and
|
||||
- the QTF towards the remote station.
|
||||
|
||||
Where suitable AirScout data is available, the tooltip also includes current AP reachability and the next calculated AP opportunity.
|
||||
|
||||
### Antenna direction
|
||||
|
||||
When the QTF of an event is clearly outside the current antenna direction, its marker becomes more transparent. The label remains readable. A target close to the centre of the configured antenna beam is highlighted.
|
||||
|
||||
This visual effect changes neither the sked nor the Priority Score. It is simply a quick way of identifying candidates which fit the current antenna direction.
|
||||
|
||||
The timeline is a preview. AirScout data can change, and a stored sked guarantees neither a clear frequency nor an actual propagation path.
|
||||
- **Highest reflection potential** is preferred (not necessarily the fastest arrival).
|
||||
- Stations towards which your antenna is not pointing are shown **transparently**.
|
||||
|
||||
This gives the contest operator a quick overview of which stations will be reachable via which aircraft and at what time.
|
||||
|
||||
---
|
||||
|
||||
## Interval Beacon
|
||||
|
||||
KST4Contest can send recurring CQ messages to the public chat. The beacon is intended for longer periods of calling CQ on a fixed frequency: it publishes the local QRG regularly without requiring the operator to enter the same text again.
|
||||
|
||||
Both chat categories use one shared interval, but each category has its own enable setting and message template. The second beacon is only sent while the second chat is enabled and connected.
|
||||
|
||||
Global variables such as `MYQRG`, `SECONDQRG`, `MYLOCATOR` and `MYQTF` are resolved immediately before every transmission. A QRG updated by the logging software can therefore appear in the next beacon.
|
||||
|
||||
Before transmission, KST4Contest validates the completely resolved message. Empty messages, line breaks, the protocol separator `|` and messages exceeding 120 characters are not sent.
|
||||
|
||||
Disable the beacon while searching the band or changing QRG frequently. An automatically published frequency is useful only while somebody is actually listening and calling there.
|
||||
|
||||
Configuration, timer behaviour and available variables: [Configuration – Beacon Settings](en-Configuration#beacon-settings).
|
||||
Automatic CQ messages in the public channel at a configurable interval. Recommended: use the `MYQRG` variable so the current frequency is always accurate. Details: [Configuration – Beacon Settings](Configuration#beacon-settings).
|
||||
|
||||
---
|
||||
|
||||
|
||||
## Simplelogfile
|
||||
|
||||
File-based log evaluation using regex. Details: [Log Synchronisation](en-Log-Sync#method-1-universal-file-based-callsign-interpreter-simplelogfile).
|
||||
---
|
||||
|
||||
## Global Message Views
|
||||
|
||||
Most message tables in KST4Contest are deliberately tied either to the local station or to the station currently selected in the user list. Some message streams must, however, remain visible independently of that selection.
|
||||
|
||||
KST4Contest therefore provides three global message tabs below the main user list:
|
||||
|
||||
| Tab | Content |
|
||||
|---|---|
|
||||
| **Public messages** | Public chat messages, including CQ calls and beacon messages |
|
||||
| **DXCluster messages** | DX cluster messages delivered by the ON4KST server |
|
||||
| **QSO of the other** | Directed chat messages between chat logins other than the local station |
|
||||
|
||||
**Public messages** is selected by default. Changing the selected station does not affect any of these three views.
|
||||
|
||||
|
||||
|
||||
### DXCluster messages
|
||||
|
||||
The DX cluster table shows cluster messages received through the ON4KST connection. Depending on the information contained in the source message, the table displays:
|
||||
|
||||
- the time,
|
||||
- the reporting station and its locator,
|
||||
- the reported station and its locator,
|
||||
- the QRG,
|
||||
- the message text, and
|
||||
- the global Worked state of the reported station.
|
||||
|
||||
An empty locator or another empty field does not necessarily indicate a processing error. The corresponding information may simply be absent from the source message.
|
||||
|
||||
This view must not be confused with the [built-in DX Cluster server](en-DX-Cluster-Server). The built-in server sends derived direction spots to connected logging software. The **DXCluster messages** tab displays cluster traffic received from ON4KST.
|
||||
|
||||
### QSO of the other
|
||||
|
||||
The **QSO of the other** table displays directed chat messages for which neither the sender nor the receiver is the local station. Messages addressed to `ALL` are not included.
|
||||
|
||||
The table contains the following columns:
|
||||
|
||||
| Column | Meaning |
|
||||
|---|---|
|
||||
| **Time** | Time of the chat message |
|
||||
| **Call TX** | Complete callsign of the sender |
|
||||
| **Last QRG TX** | Most recently detected QRG assigned to the sender |
|
||||
| **wkd TX?** | Global Worked state of the sender |
|
||||
| **Call RX** | Complete callsign of the receiver |
|
||||
| **Last QRG RX** | Most recently detected QRG assigned to the receiver |
|
||||
| **wkd RX?** | Global Worked state of the receiver |
|
||||
| **Message** | Message text |
|
||||
| **Category** | Chat category in which the message was received |
|
||||
|
||||
The QRG columns are not a historical record of the frequency used for the displayed message. They show the latest QRG currently known for the respective chat member. The value may originate from another message and may change when a newer QRG is detected.
|
||||
|
||||
The two Worked columns show the global callsign state. They do not indicate whether the station has already been worked on the QRG or band shown next to it.
|
||||
|
||||
The expression “QSO of the other” is used as a compact user-interface label. A directed chat message does not prove that an actual radio QSO has taken place. It may equally be a sked request, a frequency exchange or another private message between two chat logins.
|
||||
|
||||
### Separate monitor window
|
||||
|
||||
The DX cluster and QSO-of-the-other tables are additionally available in a separate monitor window. It places the DX cluster table above the directed messages between other stations.
|
||||
|
||||
|
||||
|
||||
The tabs and the monitor window use the same underlying message stores. Opening the separate window does not create another connection, receive the messages a second time or maintain an independent history.
|
||||
|
||||
The window can be hidden or restored through:
|
||||
|
||||
**Windows → Hide cluster / stranger QSOs**
|
||||
|
||||
or:
|
||||
|
||||
**Windows → Show cluster / stranger QSOs**
|
||||
|
||||
The additional window is useful when these message streams should remain visible on a second monitor or while another part of the main window is being used. During periods with heavy chat traffic, the global tabs are usually more compact.
|
||||
|
||||
When a table cell cannot display its complete message, moving the mouse over the cell shows the full text in a tooltip. Web links beginning with `http://`, `https://` or `www.` can be opened in the system browser.
|
||||
File-based log evaluation using regex. Details: [Log Synchronisation](Log-Sync#method-1-universal-file-based-callsign-interpreter-simplelogfile).
|
||||
|
||||
---
|
||||
|
||||
## Station Map and Path Analysis (from v1.41)
|
||||
## Cluster & QSO of Others
|
||||
|
||||
The station map shows the geographical relationship between the local station and the chat members which are currently relevant in the main window. It is not a second, independent user list: filters applied to the chat-member table also determine which stations are passed to the map.
|
||||
|
||||
|
||||
|
||||
### Stations and markers
|
||||
|
||||
A station can be displayed only if a usable six-character Maidenhead locator is available. Chat entries without a sufficiently precise locator remain in the user list but cannot be positioned reliably on the map.
|
||||
|
||||
Active chat variants belonging to the same normalised base callsign are combined into one map marker. This avoids several markers being placed at exactly the same position when, for example, a station is logged in with separate suffixes for different bands. The marker information includes the currently derived bands and, where applicable, open `B+` opportunities.
|
||||
|
||||
Marker colours provide a compact status indication:
|
||||
|
||||
| Colour | Meaning |
|
||||
|---|---|
|
||||
| Blue | Normal station marker |
|
||||
| Yellow | The callsign has already been worked on at least one band |
|
||||
| Green | The station is inside the current antenna sector and is relevant as a directional candidate |
|
||||
| Orange | Currently selected station |
|
||||
|
||||
The selected state has the highest display priority, followed by the directional warning and Worked state. A selected station therefore remains orange even if it also meets one of the other conditions.
|
||||
|
||||
At lower zoom levels, nearby markers are combined into screen-based clusters. This is a display function and does not merge the underlying chat members. Selected stations and important directional candidates remain individually visible where possible.
|
||||
|
||||
Clicking a station marker selects the corresponding active chat member in the main window. KST4Contest scrolls to the entry in the user list, updates the **Further Info** panel and prepares the complete visible callsign as the message target. The chat suffix and category therefore remain relevant even though several variants may share one map marker.
|
||||
|
||||
### Antenna sector, connection line and locator grid
|
||||
|
||||
The map displays the local station together with the currently configured antenna direction, beamwidth and maximum QRB. These values form the visible antenna sector.
|
||||
|
||||
Selecting a remote station adds a connection line between both locations. The Maidenhead overlay provides a geographical reference without requiring the operator to translate every locator mentally.
|
||||
|
||||
The map does not know the actual radiation pattern, side lobes or elevation angle of the antenna. The displayed sector is therefore a geometrical representation of the configured horizontal beamwidth, not a complete antenna model.
|
||||
|
||||
### Terrain profile
|
||||
|
||||
For the selected path, KST4Contest requests terrain elevations from the Open-Meteo elevation service. The active provider uses Copernicus GLO-90 data and requests no more than 100 evenly distributed elevation coordinates for one path.
|
||||
|
||||
The terrain resolution and the sampling distance are not the same thing. On a long path, the distance between two requested points can be considerably larger than the nominal resolution of the elevation model. Small terrain features may therefore remain undetected.
|
||||
|
||||
The profile combines:
|
||||
|
||||
- terrain elevation,
|
||||
- the geometrical line between both antennas,
|
||||
- Earth-curvature correction using an effective Earth-radius factor of `k = 4/3`,
|
||||
- the radio and terrain horizons,
|
||||
- the first Fresnel zone,
|
||||
- minimum Fresnel clearance,
|
||||
- detected Fresnel-zone intrusion, and
|
||||
- a rough knife-edge diffraction estimate for relevant obstructions.
|
||||
|
||||
The configured **Own antenna height AGL** is added to the terrain elevation at the local station. For the remote station, KST4Contest currently assumes an antenna height of 10 metres above the local terrain.
|
||||
|
||||
Moving the mouse over the path profile marks the corresponding position on the map. This makes it easier to identify which hill or terrain section causes a reported obstruction.
|
||||
|
||||
### Frequency selection
|
||||
|
||||
Fresnel clearance and link-budget results depend on frequency. KST4Contest therefore attempts to derive a usable analysis frequency from recent QRG or band information associated with the selected station.
|
||||
|
||||
The value displayed as **Frequency** in the analysis panel is the frequency actually used for the calculation. Check it before interpreting the result. A frequency which merely belongs to a possible band is still only an approximation if the station is expected to operate elsewhere.
|
||||
|
||||
This matters particularly on the microwave bands. The Fresnel zone becomes smaller as frequency increases, while free-space path loss and feeder loss increase. A calculation performed for the wrong band may therefore look plausible while describing a different radio path.
|
||||
|
||||
### Link budget and propagation assessment
|
||||
|
||||
The link-budget estimate uses:
|
||||
|
||||
- the configured local and remote transmit powers,
|
||||
- the configured antenna gains,
|
||||
- estimated feeder losses,
|
||||
- free-space path loss, and
|
||||
- a rough additional loss derived from the terrain obstruction.
|
||||
|
||||
Antenna gains must be entered in dBi. Values specified in dBd must first be converted.
|
||||
|
||||
The calculation produces an estimated received power and a bidirectional SSB margin. The result is also made available to the Reachability calculation used by the **Tropo** column and the corresponding filter in the main window.
|
||||
|
||||
The map and the table use the same `ReachabilityService` and calculation cache. A result calculated for the map can therefore also become available to the user list without repeating the complete request.
|
||||
|
||||
KST4Contest deliberately does not request an online terrain profile for every visible chat member whenever the list changes. That would create unnecessary API traffic and make normal chat processing dependent on a large number of external requests. Select the required station on the map or use **Calc selected** when a current calculation is needed.
|
||||
|
||||
### Compact view
|
||||
|
||||
The lower analysis panel can be hidden with **Hide path analysis** and restored with **Show path analysis**. Its visibility is stored in the preferences and restored at the next start.
|
||||
|
||||
The divider between the map and the analysis panel can be moved to allocate more space to either section. Hiding the analysis panel does not discard the selected station or close the map.
|
||||
|
||||
Operation of the map window is described under [Station Map](en-User-Interface#station-map).
|
||||
|
||||
Configuration of antenna height, power and gain is described under [Path Analysis and Link Budget](en-Configuration#path-analysis-and-link-budget).
|
||||
|
||||
### Limits of the result
|
||||
|
||||
The path analysis is an engineering estimate. Among other things, it does not know:
|
||||
|
||||
- the actual antenna height and station setup of the remote operator,
|
||||
- vegetation, buildings and other clutter which is not represented in the elevation data,
|
||||
- the current refractivity profile of the atmosphere,
|
||||
- ducting, scattering or reflection conditions,
|
||||
- local interference or receiver performance, or
|
||||
- whether a detected QRG is still in use.
|
||||
|
||||
The **Mechanisms** indication lists propagation mechanisms which may be consistent with the calculated geometry. It does not prove that one of them is currently available.
|
||||
|
||||
Aircraft Scatter information is not currently coupled to the terrain-profile calculation. AirScout data and the path analysis may both describe the same remote station, but they remain separate assessments.
|
||||
|
||||
OpenStreetMap tiles and the active elevation provider require an Internet connection. Leaflet and the map application itself are bundled locally, and tile requests pass through a local proxy, but this proxy is not a permanent offline map store.
|
||||
|
||||
In plain terms: the analysis helps to identify plausible paths, obvious obstructions and incorrect assumptions. It does not replace propagation experience or a real signal.
|
||||
|
||||
---
|
||||
|
||||
## Bounded Message Stores (from v1.41)
|
||||
|
||||
During a long contest, KST4Contest may receive tens of thousands of chat and DX cluster messages. If these lists were allowed to grow without limit for the complete runtime, memory consumption would not be the only problem. Filtering, sorting and updating the tables built on top of them would also become increasingly expensive.
|
||||
|
||||
KST4Contest therefore uses two separate bounded message stores:
|
||||
|
||||
| Message store | Clean-up starts above | Size after clean-up |
|
||||
|---|---:|---:|
|
||||
| Chat messages | 30,000 entries | 25,000 entries |
|
||||
| DX cluster messages | 10,000 entries | 8,000 entries |
|
||||
|
||||
New messages are inserted at the beginning of the respective list. When the upper limit is exceeded, KST4Contest removes the oldest entries from the end until the specified target size is reached.
|
||||
|
||||
### Why are there two thresholds?
|
||||
|
||||
The store is not reduced to its maximum size again after every single incoming message. After a clean-up, the chat-message store has room for another 5,000 entries and the DX cluster store for another 2,000.
|
||||
|
||||
KST4Contest therefore removes old entries in batches instead of modifying the end of the list again for every subsequent message. The clean-up runs much less frequently as a result.
|
||||
|
||||
### Which tables share a store?
|
||||
|
||||
The following views are filtered representations of the same global chat-message list:
|
||||
|
||||
- **Public messages**,
|
||||
- the private-message table,
|
||||
- the messages in the **Further Info** panel, and
|
||||
- **QSO of the other**.
|
||||
|
||||
These tables do not each retain another 30,000 messages. When an old chat message is removed from the shared store, it disappears from all views based on that store at the same time.
|
||||
|
||||
The **DXCluster messages** tab and the DX cluster table in the separate monitor window likewise use the same cluster-message store. Opening the additional window neither creates a second message connection nor duplicates the received messages.
|
||||
|
||||
The chat and DX cluster stores are independent of each other. Heavy public-chat traffic therefore does not reduce the capacity available for DX cluster messages, and vice versa.
|
||||
|
||||
### No permanent history
|
||||
|
||||
Both message stores exist in memory only. They are written neither to the internal Worked database nor to another local message file.
|
||||
|
||||
After restarting KST4Contest, the tables begin with empty lists and are rebuilt exclusively from newly received messages. These views are working tools for the current session, not a permanent chat archive.
|
||||
|
||||
---
|
||||
|
||||
## Screen-Aware Main Window Sizing (from v1.41)
|
||||
|
||||
KST4Contest stores the most recently used size of the main window. This is useful as long as the application is started on a comparable display the next time. If it was previously used on a larger monitor, however, the stored size may extend beyond the visible area of a smaller screen.
|
||||
|
||||
KST4Contest therefore checks the stored size against the usable area of the primary screen during startup.
|
||||
|
||||
### How is the startup size determined?
|
||||
|
||||
If the stored values are valid, KST4Contest initially uses the last saved height and width. If no usable values are available, the following default size is used:
|
||||
|
||||
- 1,234 pixels wide and
|
||||
- 768 pixels high.
|
||||
|
||||
KST4Contest does not use the complete screen resolution as the available area. It uses the visual bounds reported by JavaFX for the primary screen. Taskbars, docks and similar operating-system areas are already excluded from these bounds.
|
||||
|
||||
An additional safety margin of 40 pixels is subtracted. If the stored width or height exceeds the remaining space, only the affected value is reduced.
|
||||
|
||||
After the user interface has been built with this content size, KST4Contest checks the complete native operating-system window, including its title bar and borders. The window is reduced or moved into the visible area again if necessary.
|
||||
|
||||
This catches two different cases:
|
||||
|
||||
1. The stored content area is larger than the current screen.
|
||||
2. The content area fits, but the complete native window still extends beyond the visible area because of its borders or position.
|
||||
|
||||
### What happens to the layout?
|
||||
|
||||
The complete interface is not scaled proportionally. Instead, the main window receives less space and the UI areas designed for this situation react to the available width.
|
||||
|
||||
The filter bar remains compact at normal window sizes. Its controls wrap into additional rows only when their actual required width no longer fits. The dividers can still be used to distribute the available space between the message and station areas.
|
||||
|
||||
### Limits of the automatic correction
|
||||
|
||||
The check always uses the **primary screen**. It does not restore the previous position on a particular secondary monitor.
|
||||
|
||||
The automatic size restriction currently applies to the main window only. The settings window, the separate cluster and QSO monitor window and other auxiliary windows continue to use their stored sizes without the same additional check against the primary screen.
|
||||
|
||||
In plain terms: the protection mainly prevents the central main window from becoming unusable after moving to a smaller display. It is not a complete window-position manager for a changing multi-monitor setup.
|
||||
A separate window showing the QSO flow between other stations. Particularly interesting during quieter night-time hours of a contest. This window can be minimised when not needed. Future plan: filtering to stations in your selected QTF.
|
||||
|
||||
+29
-107
@@ -1,129 +1,51 @@
|
||||
# KST4Contest – User Manual
|
||||
# KST4Contest – Wiki
|
||||
|
||||
> You are reading the English version | [Deutsche Version](de-Home)
|
||||
> 🇬🇧 You are reading the English version | 🇩🇪 [Deutsche Version](de-Home)
|
||||
|
||||
KST4Contest is a desktop client for the [ON4KST Chat](https://www.on4kst.org/chat/login.php), developed for VHF, UHF and SHF contest operation. It brings chat, candidate selection, sked planning, aircraft scatter data and external station software together in a single operating interface.
|
||||
**KST4Contest** (also known as *PraktiKST*) is a Java-based chat client for the [ON4KST Chat](http://www.on4kst.info/chat/), specifically designed for contest operation on the VHF/UHF/SHF bands (144 MHz and above).
|
||||
|
||||
KST4Contest is developed by **DO5AMF (Marc Fröhlich)**, operator at DM5M and (since May 2025) **DN9APW (Philipp Wagner)**. The source code is publicly available on [GitHub](https://github.com/praktimarc/kst4contest).
|
||||
Developed by **DO5AMF (Marc Fröhlich)**, operator at DM5M.
|
||||
|
||||
---
|
||||
|
||||
## Why use a dedicated ON4KST client?
|
||||
|
||||
During a contest, the ON4KST Chat provides a considerable amount of information: active stations, locators, frequencies, sked requests and indications of current activity. The actual problem is not seeing this data. It is turning it into the next useful contact in time.
|
||||
|
||||
KST4Contest evaluates the available information, puts it into context and presents it as part of a contest-oriented workflow. This includes antenna direction, distance, known bands and frequencies, worked status, chat activity and aircraft scatter timing.
|
||||
|
||||
The program does not decide which QSO is actually possible. Priority scores, the AP timeline and visual highlights are decision aids. The final judgement remains with the operator – not least because even a very convincing computer screen cannot complete a radio contact.
|
||||
|
||||
---
|
||||
|
||||
## How KST4Contest supports contest operation
|
||||
|
||||
- **Observe and organise chat activity:** KST4Contest can display two ON4KST chat categories at the same time. Messages, frequency information and known band activity are assigned to the corresponding stations.
|
||||
|
||||
- **Reduce the station list:** Direction, distance, worked and NOT-QRV filters help limit the user list to stations that are relevant to the current operating situation.
|
||||
|
||||
- **Prioritise candidates:** The score system evaluates active chat members using several known criteria. The currently most relevant candidates are also shown in a separate priority list.
|
||||
|
||||
- **Prepare skeds and keep them visible:** Sked reminders, automatic advance messages and the AP timeline help prevent scheduled contacts from disappearing somewhere between chat, logging and ongoing CQ operation.
|
||||
|
||||
- **Include aircraft scatter information:** The AirScout interface brings suitable aircraft and expected reflection times into candidate evaluation and sked planning.
|
||||
|
||||
- **Connect the logger and station equipment:** KST4Contest synchronises worked stations and frequency information with supported logging software. It also provides interfaces for Win-Test, PSTRotator and a built-in DX Cluster server.
|
||||
|
||||
- **Display stations and radio paths:** The station map shows active chat members, locator squares, antenna directions and the path to the selected station. A terrain profile can also be calculated for selected paths.
|
||||
|
||||
These functions share information. A detected frequency can indicate an active band, worked status comes from the logger, aircraft scatter data adds timing information and the resulting score affects the priority list. Missing or outdated input data can therefore affect the result as well.
|
||||
|
||||
---
|
||||
|
||||
## Requirements
|
||||
|
||||
A registered ON4KST account is required. Registration and login are available from the [official ON4KST login page](https://www.on4kst.org/chat/login.php).
|
||||
|
||||
English is the official language of the ON4KST Chat. This also applies when communicating with stations from your own country. Common amateur radio abbreviations such as `pse`, `agn`, `qrg`, `dir`, `rrr`, `tnx` and `73` are normal and usually considerably faster than carefully written prose.
|
||||
|
||||
Downloads, supported operating systems and installation methods are described in [Installation](en-Installation).
|
||||
|
||||
---
|
||||
|
||||
## Manual version
|
||||
|
||||
This manual describes the current stable release of KST4Contest.
|
||||
|
||||
Functions that are only available in a Beta or Nightly build are marked accordingly. If no such note is present, the description applies to the stable release.
|
||||
|
||||
- [Download Stable, Beta and Nightly builds](https://kst4contest.hamradioonline.de/download/)
|
||||
- [GitHub releases](https://github.com/praktimarc/kst4contest/releases)
|
||||
- [Version history](en-Changelog)
|
||||
|
||||
The stable release is normally the appropriate choice for contest operation. Beta and Nightly builds contain newer fixes and functions, but may still change between builds. They are intended for testing specific changes. Ten minutes before a contest is usually not the ideal time for a first test.
|
||||
|
||||
---
|
||||
|
||||
## Quick navigation
|
||||
## Quick Navigation
|
||||
|
||||
| Page | Contents |
|
||||
|---|---|
|
||||
| [Installation](en-Installation) | ON4KST account, downloads, installation and updates |
|
||||
| [Configuration](en-Configuration) | Login, station, bands, user interface and external connections |
|
||||
| [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 |
|
||||
| [Features](en-Features) | Operation, reasoning and limitations of individual functions |
|
||||
| [Macros and Variables](en-Macros-and-Variables) | Reusable messages, shortcuts and automatically substituted values |
|
||||
| [User Interface](en-User-Interface) | Interface layout and operation during a contest |
|
||||
| [Changelog](en-Changelog) | Releases, Nightly changes and resolved issues |
|
||||
| [Installation](en-Installation) | Download, Java requirements, update |
|
||||
| [Configuration](en-Configuration) | All settings in detail |
|
||||
| [Log Synchronisation](en-Log-Sync) | UCXLog, N1MM+, QARTest, DXLog.net, WinTest |
|
||||
| [AirScout Integration](en-AirScout-Integration) | Aircraft scatter detection |
|
||||
| [DX Cluster Server](en-DX-Cluster-Server) | Built-in DX cluster for your logging software |
|
||||
| [Features](en-Features) | All features at a glance |
|
||||
| [Macros and Variables](en-Macros-and-Variables) | Text snippets, shortcuts, variables |
|
||||
| [User Interface](en-User-Interface) | UI explanation and operation |
|
||||
| [Changelog](en-Changelog) | Version history |
|
||||
|
||||
---
|
||||
|
||||
## Contact and support
|
||||
## What is KST4Contest?
|
||||
|
||||
- **Download:** [Stable, Beta and Nightly builds](https://kst4contest.hamradioonline.de/download/)
|
||||
- **Source code:** [praktimarc/kst4contest](https://github.com/praktimarc/kst4contest)
|
||||
- **Bug reports and feature requests:** [GitHub Issues](https://github.com/praktimarc/kst4contest/issues)
|
||||
- **Email:** praktimarc+kst4contest@gmail.com
|
||||
Please use this address only for KST4Contest-related topics.
|
||||
The ON4KST Chat is the de-facto standard for skeds on the 144 MHz and higher bands. KST4Contest enhances the chat experience with contest-specific features:
|
||||
|
||||
### Reporting a bug
|
||||
- **Worked marking**: Stations already worked are highlighted visually, synchronised directly from your logging software via UDP.
|
||||
- **Sked direction detection**: When a station calls another one from your direction, it is highlighted green and bold.
|
||||
- **QRG detection**: KST4Contest automatically reads frequencies from the chat traffic and shows them in the user list.
|
||||
- **AirScout interface**: Reflectable aircraft are shown directly in the user list.
|
||||
- **Built-in DX cluster server**: Spots are sent directly to your logging software.
|
||||
- **Dark mode** (from v1.26): Easy on the eyes during night-time operation.
|
||||
- **Multi-channel login** (from v1.26): Simultaneously logged into two chat categories.
|
||||
|
||||
A problem is considerably easier to reproduce when the report contains at least:
|
||||
---
|
||||
|
||||
1. the KST4Contest version,
|
||||
2. the operating system and installation method,
|
||||
3. the exact steps leading to the problem,
|
||||
4. the expected and observed behaviour,
|
||||
5. a screenshot where appropriate,
|
||||
6. the error log file.
|
||||
## Contact & Support
|
||||
|
||||
The error log is stored at:
|
||||
|
||||
| Operating system | Path |
|
||||
|---|---|
|
||||
| Linux / macOS | `~/.praktiKST/kst4contest-errors.log` |
|
||||
| Windows | `C:\Users\<YourName>\.praktiKST\kst4contest-errors.log` |
|
||||
|
||||
Please inspect the file briefly before uploading it. An error log mainly contains technical information, but depending on the problem it may also include local file paths or other contextual data.
|
||||
|
||||
Some file and directory names still use the technical name `praktiKST`. They refer to the same program.
|
||||
- **Email**: praktimarc+kst4contest@gmail.com *(for kst4contest topics only)*
|
||||
- **GitHub**: https://github.com/praktimarc/kst4contest
|
||||
- **Download**: https://github.com/praktimarc/kst4contest/releases/latest
|
||||
|
||||
---
|
||||
|
||||
## Acknowledgements
|
||||
|
||||
Many functions and corrections in KST4Contest originate from observations made during actual contest operation. Reports that describe not only what happened, but also under which conditions it happened, are particularly useful.
|
||||
|
||||
Special thanks go to:
|
||||
|
||||
- Gianluca Costantino (IU3OAR)
|
||||
- Alessandro Murador (IZ3VTH)
|
||||
- Reczetár István (HA1FV)
|
||||
- Viliam Petrik (OM0AAO) for the DX Cluster idea
|
||||
- Konrad Neitzel (DC9DJ) for his work on the project structure
|
||||
- Andreas (DO5ALF), webmaster of funkerportal.de
|
||||
- Franz van Velzen (PE0WGA) for testing
|
||||
- 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.
|
||||
Special thanks to: Gianluca Costantino (IU3OAR), Alessandro Murador (IZ3VTH), Reczetár István (HA1FV), OM0AAO (Viliam Petrik, DX cluster idea), DC9DJ (Konrad Neitzel, project structure), DO5ALF (Andreas, webmaster funkerportal.de), PE0WGA (Franz van Velzen, tester) and all other testers and contributors.
|
||||
|
||||
+91
-387
@@ -2,436 +2,140 @@
|
||||
|
||||
> 🇬🇧 You are reading the English version | 🇩🇪 [Deutsche Version](de-Installation)
|
||||
|
||||
KST4Contest is distributed as a ready-to-run application package for Windows, Linux and macOS. The official release packages do not require a separate Java installation: the required Java runtime is already included.
|
||||
## Prerequisites
|
||||
|
||||
In practical terms, you need a supported operating system, an internet connection and an ON4KST account. That sounds manageable—and usually it is.
|
||||
An resolution of 1200px by 720px is recommended
|
||||
|
||||
## Requirements
|
||||
### ON4KST Account
|
||||
|
||||
### ON4KST account
|
||||
To use the chat, a registered account with the ON4KST chat service is required:
|
||||
|
||||
KST4Contest is an independent client for the ON4KST chat, but it does not replace the corresponding user account.
|
||||
- Register at: http://www.on4kst.info/chat/register.php
|
||||
|
||||
If you do not have an account yet, you can create one on the official ON4KST website:
|
||||
### Chat Etiquette
|
||||
|
||||
- [ON4KST login and registration](https://www.on4kst.org/chat/login.php)
|
||||
The official language in the ON4KST Chat is **English**. Please use English even when communicating with stations from your own country. Common HAM abbreviations (agn, dir, pse, rrr, tnx, 73 …) are widely used and understood.
|
||||
|
||||
ON4KST specifies English as the common language for the chat. This also applies when both stations happen to share another language. During contests, the usual amateur radio abbreviations such as `pse`, `agn`, `qrg`, `dir`, `rrr`, `tnx` and `73` are widely used.
|
||||
### Personal Messages
|
||||
|
||||
Using the chat and sending personal messages are covered in the user interface chapter. For the installation, the only thing that matters at this point is that the account works.
|
||||
To send a private message to another station, always use the following format:
|
||||
|
||||
### Screen size
|
||||
```
|
||||
/CQ CALLSIGN message text
|
||||
```
|
||||
|
||||
A usable screen area of approximately **1200 × 720 pixels** or more is recommended.
|
||||
Example: `/CQ DL5ASG pse sked 144.205?`
|
||||
|
||||
KST4Contest automatically adapts the main window to the available area of the primary screen. The application can therefore also be started on smaller displays. Less space is still less space, however: not all tables, filters and additional information can then be displayed at a useful size at the same time.
|
||||
|
||||
### Java
|
||||
|
||||
The ready-made packages from the [GitHub Releases](https://github.com/praktimarc/kst4contest/releases/latest) do not require a separate Java installation. The required runtime is distributed with KST4Contest.
|
||||
|
||||
A Java development environment is only required if you want to build KST4Contest from source. For the AUR packages `kst4contest` and `kst4contest-git`, Java 21 and Maven are handled as build dependencies by the package manager.
|
||||
|
||||
---
|
||||
|
||||
## Stable, Beta or Nightly?
|
||||
|
||||
KST4Contest is distributed through three development channels:
|
||||
|
||||
| Channel | Intended use | Classification |
|
||||
|---|---|---|
|
||||
| **Stable** | Normal contest operation | Published version intended for regular use |
|
||||
| **Beta** | Focused testing before a Stable release | Pre-release version with a largely defined feature set |
|
||||
| **Nightly** | Early testing of new features | Current development state from the `main` branch |
|
||||
|
||||
The **Stable version** is recommended for normal operation.
|
||||
|
||||
Beta and Nightly builds may contain features that are not yet available in the Stable release. They may also contain unfinished workflows, changed settings or new defects. That is not an unusual failure of the release process; it is the purpose of a development channel.
|
||||
|
||||
If a function in this manual is explicitly marked as **Nightly**, it is not necessarily part of the current Stable release yet.
|
||||
During heavy chat traffic (5–6 messages per second in a contest), public messages directed at a specific callsign are easily missed. However, KST4Contest also catches such messages if they are accidentally posted publicly (see [Features – PM Catching](Features#catching-personal-messages)).
|
||||
|
||||
---
|
||||
|
||||
## Download
|
||||
|
||||
The current Stable version is available here:
|
||||
### Windows
|
||||
|
||||
- [Latest KST4Contest release](https://github.com/praktimarc/kst4contest/releases/latest)
|
||||
- [All published releases](https://github.com/praktimarc/kst4contest/releases)
|
||||
The latest version can be downloaded as a ZIP file:
|
||||
|
||||
The release page contains the application packages as well as the English and German PDF manuals.
|
||||
**https://github.com/praktimarc/kst4contest/releases/latest**
|
||||
|
||||
### Which package do I need?
|
||||
The filename has the format `praktiKST-v<version_number>-windows-x64.zip`.
|
||||
|
||||
| Operating system | Package | Typical filename |
|
||||
|---|---|---|
|
||||
| Windows x64 | ZIP package | `praktiKST-v<version>-windows-x64.zip` |
|
||||
| Linux x86_64 | AppImage | `KST4Contest-v<version>-linux-x86_64.AppImage` |
|
||||
| Debian/Ubuntu amd64 | DEB package | `KST4Contest-v<version>-debian-amd64.deb` |
|
||||
| Fedora/RPM x86_64 | RPM package | `KST4Contest-v<version>-fedora-x86_64.rpm` |
|
||||
| Arch Linux x86_64 | Arch package | `KST4Contest-v<version>-archlinux-x86_64.pkg.tar.zst` |
|
||||
| Linux with Flatpak | Flatpak reference | `de.x08.KST4Contest.flatpakref` |
|
||||
| macOS Apple Silicon | DMG for ARM64 | `KST4Contest-v<version>-macos-arm64.dmg` |
|
||||
| macOS Intel | DMG for x86_64 | `KST4Contest-v<version>-macos-x86_64.dmg` |
|
||||
### Linux
|
||||
|
||||
The latest version can be downloaded as an AppImage:
|
||||
|
||||
**https://github.com/praktimarc/kst4contest/releases/latest**
|
||||
|
||||
The filename has the format `KST4Contest-v<version_number>-linux-x86_64.AppImage`.
|
||||
|
||||
### macOS
|
||||
|
||||
> ⚠️ **Best-Effort Support:** macOS builds are provided as a convenience but are **not fully tested**. We build and release macOS binaries with every release, but we cannot test every scenario on macOS. If you encounter issues, please report them – we will do our best to address them, but cannot guarantee the same level of support as for Windows and Linux.
|
||||
|
||||
The latest version can be downloaded as a DMG disk image (available for both Apple Silicon and Intel Macs):
|
||||
|
||||
**https://github.com/praktimarc/kst4contest/releases/latest**
|
||||
|
||||
The filename has the format `KST4Contest-v<version_number>-macos-<arch>.dmg`, where `<arch>` is `arm64` (Apple Silicon) or `x86_64` (Intel).
|
||||
|
||||
Only download application packages from the official GitHub Releases, the KST4Contest Flatpak repository or the linked AUR packages. Files from other sources may have been built differently, may be outdated or may have been modified.
|
||||
|
||||
---
|
||||
|
||||
## Installing on Windows
|
||||
## Installation
|
||||
|
||||
KST4Contest is distributed as a ZIP package for Windows. A conventional installer is not required.
|
||||
### Windows
|
||||
|
||||
1. Download `praktiKST-v<version>-windows-x64.zip` from the latest release.
|
||||
2. Extract the ZIP file completely into a dedicated folder.
|
||||
3. Open the extracted folder.
|
||||
4. Start `praktiKST.exe`.
|
||||
1. Download the ZIP file.
|
||||
2. Unzip the ZIP file into a folder of your choice.
|
||||
3. Run `praktiKST.exe`.
|
||||
|
||||
Do not start the application directly from the compressed ZIP file. KST4Contest consists of several files and a bundled runtime. Windows can only use this structure reliably after the archive has been extracted completely.
|
||||
Settings are stored at `%USERPROFILE%\.praktikst\preferences.xml`.
|
||||
|
||||
The application settings are not stored in the extracted program directory. They are stored in your user profile:
|
||||
### Linux
|
||||
1. Download the AppImage.
|
||||
2. Unzip the AppImage into a folder of your choice.
|
||||
3. Make the AppImage executable (in the terminal with `chmod +x KST4Contest-v<version_number>-linux-x86_64.AppImage`)
|
||||
4. Run the AppImage.
|
||||
|
||||
```text
|
||||
%USERPROFILE%\.praktiKST\preferences.xml
|
||||
```
|
||||
Settings are stored at `~/.praktikst/preferences.xml`.
|
||||
|
||||
This allows a new application version to be extracted into a different directory without losing the existing settings.
|
||||
|
||||
---
|
||||
|
||||
## Installing on Linux
|
||||
|
||||
Several Linux package formats are available. The appropriate choice depends less on KST4Contest itself than on your distribution and the way you prefer to manage updates.
|
||||
|
||||
| Installation method | Useful when … |
|
||||
|---|---|
|
||||
| **Flatpak** | updates should be managed centrally and Flatpak is already in use |
|
||||
| **AppImage** | KST4Contest should run as a portable file without package installation |
|
||||
| **DEB/RPM** | the distribution’s native package manager should be used |
|
||||
| **Arch package/AUR** | Arch Linux, Manjaro or EndeavourOS is being used |
|
||||
|
||||
### Flatpak
|
||||
|
||||
For most Linux users, Flatpak is the simplest way to keep KST4Contest installed and manageable through the system’s update tools. The KST4Contest repository is GPG-signed and contains the Stable, Beta and Nightly channels.
|
||||
|
||||
#### Installing Stable from the release file
|
||||
|
||||
Download `de.x08.KST4Contest.flatpakref` from the latest release and open it with the software manager provided by your desktop environment.
|
||||
|
||||
Alternatively, install it from a terminal:
|
||||
|
||||
```bash
|
||||
flatpak install ./de.x08.KST4Contest.flatpakref
|
||||
```
|
||||
|
||||
#### Adding the KST4Contest repository
|
||||
|
||||
The repository only needs to be added once:
|
||||
|
||||
```bash
|
||||
flatpak remote-add --if-not-exists kst4contest \
|
||||
https://praktimarc.github.io/kst4contest/kst4contest.flatpakrepo
|
||||
```
|
||||
|
||||
You can then install the Stable version:
|
||||
|
||||
```bash
|
||||
flatpak install kst4contest de.x08.KST4Contest//stable
|
||||
```
|
||||
|
||||
#### Installing Beta
|
||||
|
||||
```bash
|
||||
flatpak install kst4contest de.x08.KST4Contest//beta
|
||||
```
|
||||
|
||||
#### Installing Nightly
|
||||
|
||||
```bash
|
||||
flatpak install kst4contest de.x08.KST4Contest//nightly
|
||||
```
|
||||
|
||||
All three KST4Contest channels use the same application ID. Installing multiple KST4Contest channels in parallel is therefore not supported.
|
||||
|
||||
For example, to switch from Stable to Nightly:
|
||||
|
||||
```bash
|
||||
flatpak uninstall de.x08.KST4Contest//stable
|
||||
flatpak install kst4contest de.x08.KST4Contest//nightly
|
||||
```
|
||||
|
||||
This does not automatically remove the personal settings stored in `~/.praktiKST`.
|
||||
|
||||
Installed Flatpak applications can be updated with:
|
||||
|
||||
```bash
|
||||
flatpak update de.x08.KST4Contest
|
||||
```
|
||||
|
||||
Depending on the desktop environment, the graphical software manager may also display or automatically install available Flatpak updates. The `flatpak update` command itself performs an update; it does not promise to turn up and run by itself one day.
|
||||
|
||||
### AppImage
|
||||
|
||||
The AppImage does not require a conventional installation.
|
||||
|
||||
1. Download `KST4Contest-v<version>-linux-x86_64.AppImage`.
|
||||
2. Open a terminal in the download directory.
|
||||
3. Make the file executable:
|
||||
|
||||
```bash
|
||||
chmod +x KST4Contest-v<version>-linux-x86_64.AppImage
|
||||
```
|
||||
|
||||
4. Start KST4Contest:
|
||||
|
||||
```bash
|
||||
./KST4Contest-v<version>-linux-x86_64.AppImage
|
||||
```
|
||||
|
||||
The AppImage can then be moved to another location, such as `~/Applications`.
|
||||
|
||||
### Debian and Ubuntu
|
||||
|
||||
Install the DEB package with:
|
||||
|
||||
```bash
|
||||
sudo apt install ./KST4Contest-v<version>-debian-amd64.deb
|
||||
```
|
||||
|
||||
Alternatively, open the file with a graphical package manager.
|
||||
|
||||
### Fedora and compatible RPM systems
|
||||
|
||||
Install the RPM package with:
|
||||
|
||||
```bash
|
||||
sudo dnf install ./KST4Contest-v<version>-fedora-x86_64.rpm
|
||||
```
|
||||
|
||||
### Arch Linux: installing the release package
|
||||
|
||||
The Arch package downloaded from the GitHub Release can be installed directly:
|
||||
|
||||
```bash
|
||||
sudo pacman -U KST4Contest-v<version>-archlinux-x86_64.pkg.tar.zst
|
||||
```
|
||||
|
||||
### Arch Linux: installing from the AUR
|
||||
|
||||
Three variants are available in the AUR:
|
||||
|
||||
| Package | Content |
|
||||
|---|---|
|
||||
| [`kst4contest-bin`](https://aur.archlinux.org/packages/kst4contest-bin) | Pre-built package from the current Stable release |
|
||||
| [`kst4contest`](https://aur.archlinux.org/packages/kst4contest) | Stable release built locally from source |
|
||||
| [`kst4contest-git`](https://aur.archlinux.org/packages/kst4contest-git) | Current development state from the `main` branch |
|
||||
|
||||
For most users, `kst4contest-bin` is the straightforward option:
|
||||
|
||||
```bash
|
||||
yay -S kst4contest-bin
|
||||
```
|
||||
|
||||
To build the Stable release from source:
|
||||
|
||||
```bash
|
||||
yay -S kst4contest
|
||||
```
|
||||
|
||||
To build the current development state:
|
||||
|
||||
```bash
|
||||
yay -S kst4contest-git
|
||||
```
|
||||
|
||||
All three packages provide the same application and are therefore defined as conflicting with one another. Install only one variant at a time.
|
||||
|
||||
AUR updates are included when the selected AUR helper checks for package updates, for example:
|
||||
|
||||
```bash
|
||||
yay -Syu
|
||||
```
|
||||
|
||||
They do not happen automatically merely because the package came from the AUR.
|
||||
|
||||
---
|
||||
|
||||
## Installing on macOS
|
||||
|
||||
> **Best-effort support:** The macOS packages are built together with the other releases, but they are not tested to the same extent as the Windows and Linux versions. Feedback is welcome; fully tested support for every macOS version and hardware variant cannot currently be guaranteed.
|
||||
|
||||
Apple Silicon Macs require the package marked `arm64`. Intel Macs require the package marked `x86_64`.
|
||||
|
||||
1. Download the appropriate DMG file.
|
||||
### macOS
|
||||
1. Download the DMG file for your architecture (Apple Silicon or Intel).
|
||||
2. Open the DMG file.
|
||||
3. Drag `KST4Contest.app` into the **Applications** folder.
|
||||
4. Start KST4Contest from the Applications folder or Launchpad.
|
||||
3. Drag `KST4Contest.app` into your **Applications** folder.
|
||||
4. On first launch, macOS may show a warning because the app is not notarised. To open it:
|
||||
- Right-click (or Control-click) on `KST4Contest.app` in Finder and choose **Open**.
|
||||
- Alternatively, go to **System Settings → Privacy & Security** and click **Open Anyway**.
|
||||
5. Run KST4Contest from your Applications folder or Launchpad.
|
||||
|
||||
From version 1.42 onwards the macOS packages are signed with an Apple Developer ID and notarized by Apple. The first launch therefore works by double-clicking, without going through the context menu and without a security prompt. The notarization ticket is stapled into the DMG file itself, so the check also succeeds without an internet connection.
|
||||
|
||||
To confirm that a downloaded package really is signed, check it in a terminal:
|
||||
|
||||
```bash
|
||||
spctl --assess --type open --context context:primary-signature -v KST4Contest-v<version>-macos-arm64.dmg
|
||||
```
|
||||
|
||||
The expected result is `accepted` together with `source=Notarized Developer ID`.
|
||||
|
||||
### Versions up to and including 1.41.1
|
||||
|
||||
Older packages are not notarized, so macOS blocks the first launch.
|
||||
|
||||
If the application came from the official GitHub Release:
|
||||
|
||||
1. Open the Applications folder in Finder.
|
||||
2. Right-click or Control-click `KST4Contest.app`.
|
||||
3. Select **Open**.
|
||||
4. Confirm the launch in the dialog that appears.
|
||||
|
||||
Alternatively, macOS may provide an **Open Anyway** button under **System Settings → Privacy & Security**.
|
||||
Settings are stored at `~/.praktikst/preferences.xml`.
|
||||
|
||||
---
|
||||
|
||||
## Where are the settings stored?
|
||||
## Updating
|
||||
|
||||
KST4Contest stores its settings and other local working files in the user’s home directory. The application directory and the data directory are separate.
|
||||
KST4Contest includes an **automatic update notification service**: as soon as a new version is available, a window will appear at startup with:
|
||||
- information that a new version is available,
|
||||
- a changelog,
|
||||
- the download link for the new version.
|
||||
|
||||
| Operating system | Data directory | Settings file |
|
||||
|---|---|---|
|
||||
| Windows | `%USERPROFILE%\.praktiKST\` | `%USERPROFILE%\.praktiKST\preferences.xml` |
|
||||
| Linux | `~/.praktiKST/` | `~/.praktiKST/preferences.xml` |
|
||||
| macOS | `~/.praktiKST/` | `~/.praktiKST/preferences.xml` |
|
||||
|
||||
|
||||
Note the spelling `.praktiKST` with an uppercase `KST`. Linux and macOS distinguish between uppercase and lowercase letters. `.praktikst` would simply be a different directory.
|
||||
### Update Process
|
||||
|
||||
#### Windows
|
||||
|
||||
Currently, there is only one way to update:
|
||||
|
||||
1. Delete the old folder.
|
||||
2. Unzip the new ZIP file.
|
||||
|
||||
The settings file (`preferences.xml`) is preserved because it is stored in the user folder, not the program folder.
|
||||
|
||||
#### Linux
|
||||
|
||||
Currently as follows:
|
||||
1. Download the new AppImage
|
||||
2. Mark the new AppImage as executable
|
||||
3. (optional) Delete the old AppImage.
|
||||
|
||||
#### macOS
|
||||
|
||||
1. Download the new DMG file.
|
||||
2. Open the DMG.
|
||||
3. Drag the new `KST4Contest.app` into your **Applications** folder, replacing the old version.
|
||||
|
||||
An application update does not remove this directory. Even so, creating a backup before a major version change or extensive configuration work is sensible.
|
||||
|
||||
---
|
||||
|
||||
## Updates
|
||||
## Known Issues at Startup
|
||||
|
||||
When KST4Contest starts, it checks whether a newer Stable release is available. If it finds one, it displays an information window containing:
|
||||
### Norton 360
|
||||
|
||||
- the installed version,
|
||||
- the latest Stable version,
|
||||
- a short overview of the main changes,
|
||||
- the changelog,
|
||||
- known issues,
|
||||
- a link to the corresponding GitHub Release page.
|
||||
Norton 360 classifies `praktiKST.exe` as dangerous (false positive). An exception must be created for the file:
|
||||
|
||||
|
||||
1. Open Norton 360.
|
||||
2. Security → History → Find the corresponding event.
|
||||
3. Select "Restore & Add Exception".
|
||||
|
||||
The update checker does not install anything. It reports the new version and opens the platform-neutral release page. From there, you must select the appropriate package for Windows, Linux or macOS.
|
||||
|
||||
### Updating Windows
|
||||
|
||||
1. Close KST4Contest.
|
||||
2. Download the new Windows ZIP package.
|
||||
3. Extract it into a new or empty directory.
|
||||
4. Start the new version.
|
||||
5. Check that the existing settings have been loaded.
|
||||
6. Remove the old application directory only after that.
|
||||
|
||||
The settings are preserved because they are stored under `%USERPROFILE%\.praktiKST`, not in the application directory.
|
||||
|
||||
### Updating an AppImage
|
||||
|
||||
1. Download the new AppImage.
|
||||
2. Make it executable.
|
||||
3. Start the new file.
|
||||
4. Remove the previous AppImage only after the new version works.
|
||||
|
||||
### Updating Debian and Ubuntu
|
||||
|
||||
```bash
|
||||
sudo apt install ./KST4Contest-v<version>-debian-amd64.deb
|
||||
```
|
||||
|
||||
### Updating Fedora
|
||||
|
||||
```bash
|
||||
sudo dnf upgrade ./KST4Contest-v<version>-fedora-x86_64.rpm
|
||||
```
|
||||
|
||||
### Updating the Arch package
|
||||
|
||||
```bash
|
||||
sudo pacman -U KST4Contest-v<version>-archlinux-x86_64.pkg.tar.zst
|
||||
```
|
||||
|
||||
### Updating an AUR package
|
||||
|
||||
Update the installed package through the selected AUR helper, for example:
|
||||
|
||||
```bash
|
||||
yay -Syu
|
||||
```
|
||||
|
||||
### Updating Flatpak
|
||||
|
||||
```bash
|
||||
flatpak update de.x08.KST4Contest
|
||||
```
|
||||
|
||||
### Updating macOS
|
||||
|
||||
1. Download the new DMG file for the appropriate architecture.
|
||||
2. Close KST4Contest.
|
||||
3. Open the DMG file.
|
||||
4. Replace `KST4Contest.app` in the Applications folder.
|
||||
5. Start the new version and check the existing settings.
|
||||
|
||||
The configuration under `~/.praktiKST` is not affected.
|
||||
|
||||
---
|
||||
|
||||
## Problems during the first launch
|
||||
|
||||
### Windows reports an unknown application
|
||||
|
||||
KST4Contest is not currently signed with a commercial Windows code-signing certificate. Windows or an additional security product may therefore warn about an unknown or rarely downloaded application.
|
||||
|
||||
Check the following first:
|
||||
|
||||
- Did the file come from the [official KST4Contest release](https://github.com/praktimarc/kst4contest/releases/latest)?
|
||||
- Does the filename match the published release?
|
||||
- Was the file downloaded completely?
|
||||
- Does the security product report a specific detection name or only a general reputation warning?
|
||||
|
||||
A warning alone is neither reliable proof of malware nor automatically a false positive. If the origin of the file is unclear, do not run it or restore it from quarantine.
|
||||
|
||||
Some users have reported quarantine messages from Norton 360 in particular. If the warning can be reproduced, please create a [GitHub issue](https://github.com/praktimarc/kst4contest/issues) and include:
|
||||
|
||||
- the KST4Contest version,
|
||||
- the complete filename,
|
||||
- the security product and its version,
|
||||
- the reported detection name,
|
||||
- a screenshot of the warning, if possible.
|
||||
|
||||
### The AppImage does not start
|
||||
|
||||
Check the executable permission first:
|
||||
|
||||
```bash
|
||||
chmod +x KST4Contest-v<version>-linux-x86_64.AppImage
|
||||
```
|
||||
|
||||
Then start the file from a terminal. Error messages shown there are usually more useful than a double-click that simply produces no visible result.
|
||||
|
||||
### macOS blocks the application
|
||||
|
||||
From version 1.42 onwards this should no longer happen, because the packages are signed and notarized. If it does occur, the DMG file was most likely downloaded incompletely or modified afterwards; download it again from the official GitHub Release.
|
||||
|
||||
On older versions the block is expected. Use the **Open** function described under [Installing on macOS](#installing-on-macos).
|
||||
|
||||
### The problem remains
|
||||
|
||||
First check whether the problem has already been reported under [GitHub Issues](https://github.com/praktimarc/kst4contest/issues). If it has not, create a new issue containing:
|
||||
|
||||
- the operating system and version,
|
||||
- the KST4Contest version,
|
||||
- the installation method,
|
||||
- the exact error message,
|
||||
- the steps required to reproduce the problem.
|
||||
|
||||
“It does not work” usually describes the situation accurately, but it is of limited value during diagnosis.
|
||||
*(Reported by PE0WGA, Franz van Velzen – thank you!)*
|
||||
|
||||
+33
-91
@@ -2,7 +2,7 @@
|
||||
|
||||
> 🇬🇧 You are reading the English version | 🇩🇪 [Deutsche Version](de-Log-Synchronisation)
|
||||
|
||||
KST4Contest imports worked stations from the logging application and derives the global Worked status, per-band Worked marks and – where a locator is available – worked grid squares. Three input paths are available: the file-based Simplelogfile interpreter, the general QSO UDP listener and the dedicated Win-Test network listener.
|
||||
KST4Contest automatically marks worked stations in the chat user list. Two basic methods are available:
|
||||
|
||||
---
|
||||
|
||||
@@ -10,25 +10,24 @@ KST4Contest imports worked stations from the logging application and derives the
|
||||
|
||||
## Method 1: Universal File Based Callsign Interpreter (Simplelogfile)
|
||||
|
||||
KST4Contest reads a log file and searches it for callsigns using a configurable regular expression. The file is read only and is never modified. Binary log files can also be used; content which cannot be interpreted as text is skipped.
|
||||
KST4Contest reads a log file and searches for callsign patterns using a regular expression. Binary log files are also supported – unreadable binary content is simply ignored.
|
||||
|
||||
The advantage is broad compatibility: no dedicated network interface is required from the logging application.
|
||||
**Advantage**: Works with almost any logging program that writes a file.
|
||||
**Disadvantage**: No band information available – stations are only marked as "worked", not on which band.
|
||||
|
||||
The limitation is equally clear. A callsign match alone provides neither a reliable band nor a locator. The Simplelogfile interpreter can therefore set only the global Worked status. It does not create a per-band `X`, a worked-grid record or a reliable basis for the band-upgrade hint after a log entry.
|
||||
Enter the path to the log file in the Preferences. The file is only read, never modified (read-only).
|
||||
|
||||
Configure the log-file path and regular expression in the **Log sync** tab. Use one of the network interfaces where possible if band-specific information is required.
|
||||
> **Tip**: The Simplelogfile function can also be used to mark stations that are definitely unreachable (e.g. personal notes). This will be replaced in a later version by a better tagging system.
|
||||
|
||||
---
|
||||
|
||||
# Method 2: Network Listener for QSO UDP Packets – Recommended
|
||||
## Method 2: Network Listener (UDP Broadcast) – Recommended
|
||||
|
||||
UCXLog, QARTest, N1MM+ and DXLog.net can transmit a UDP packet when a QSO is saved. KST4Contest receives these packets on port `12060` by default and imports the callsign together with any band and locator information they contain.
|
||||
When saving a QSO, the logging software sends a UDP packet to the broadcast address of the home network. KST4Contest receives this packet and marks the station including **band information** in its internal SQLite database.
|
||||
|
||||
If a band is available, the callsign is marked as worked on that band. If the packet also contains a valid locator, KST4Contest stores its four-character grid square for that band. Missing information is not inferred from unrelated fields.
|
||||
> **Important**: KST4Contest must be **running in parallel with the logging software**. QSOs logged while KST4Contest is not running will not be captured – except with QARTest (which can send the complete log).
|
||||
|
||||
KST4Contest must be running when the packet is transmitted. Some logging applications can, however, resend an existing log: QARTest provides **Invia log completo**, while DXLog.net sends `contactreplace` packets when broadcasting the complete log. KST4Contest processes both mechanisms.
|
||||
|
||||
**Default port:** `12060`
|
||||
**Default UDP port**: 12060 (matches the default of most logging programs)
|
||||
|
||||
---
|
||||
|
||||
@@ -82,81 +81,34 @@ For the built-in DX cluster server: configure N1MM+ as a DX cluster client (serv
|
||||
- Enter the IP of the KST4Contest computer (green-highlighted fields)
|
||||
- Port: 12060
|
||||
|
||||
When broadcasting the complete logbook, DXLog.net uses `contactreplace` instead of `contactinfo`. KST4Contest processes both packet types. Older QSOs can therefore be imported by starting a complete-log broadcast while KST4Contest is running.
|
||||
|
||||
### Win-Test
|
||||
|
||||
Win-Test is connected through a dedicated UDP listener for the native Win-Test network protocol. This listener is independent of the general QSO UDP listener on port `12060`.
|
||||
Win-Test is supported with a dedicated UDP network listener that understands the native Win-Test network protocol.
|
||||
|
||||
#### QSO and Worked synchronisation
|
||||
**Advantages of Win-Test Integration:**
|
||||
- Automatic QSO synchronization to mark worked stations.
|
||||
- **Sked Handover (ADDSKED):** Using the "Create sked" button in the station info panel not only creates a sked in KST4Contest but also *sends it directly via UDP to the Win-Test network as an ADDSKED packet* – automatically, as soon as the listener is active. No separate toggle is needed.
|
||||
- You can choose between "AUTO", "SSB", or "CW" sked modes.
|
||||
- **Automatic QRG resolution for SKEDs:** KST4Contest selects the sked frequency intelligently:
|
||||
1. If the other station mentioned their QRG in a recent chat message, that frequency is used.
|
||||
2. Otherwise, your own current QRG is used (from Win-Test STATUS or manual entry).
|
||||
|
||||
For a new QSO, KST4Contest imports:
|
||||
**Settings in the "Log Synchronisation" tab:**
|
||||
- Enable `Receive Win-Test network based UDP log messages`.
|
||||
- `UDP-Port for Win-Test listener` (default: 9871).
|
||||
- `KST station name in Win-Test network (src of SKED packets)`: Defines the station name KST4Contest uses in the WT network (e.g. "KST").
|
||||
- `Win-Test network broadcast address`: Usually detected automatically; required to send sked packets to the network.
|
||||
|
||||
- the logged callsign,
|
||||
- the native Win-Test band ID, and
|
||||
- a valid locator where one is included in the packet.
|
||||
|
||||
Band IDs for 50 and 70 MHz are processed in the same way as the VHF, UHF and SHF bands. The callsign is marked as worked globally and on the detected band. If a locator is also available, its four-character grid square is stored for that band.
|
||||
|
||||
The information is written to the same internal database as Worked data received through the other QSO UDP interfaces and is restored after a restart.
|
||||
|
||||
#### Handing skeds over to Win-Test
|
||||
|
||||
Pressing **Create sked** first creates an internal KST4Contest sked. If the Win-Test network listener is enabled, KST4Contest then automatically attempts to send the sked to the Win-Test network as an `ADDSKED` packet.
|
||||
|
||||
The QRG is selected in the following order:
|
||||
|
||||
1. KST4Contest looks for the most recent QRG of the remote station on the explicitly selected band. The QRG must be no more than 30 minutes old. Active variants of the same base callsign are evaluated together.
|
||||
2. If no such QRG is available, KST4Contest checks the local QRG of the chat category in which the sked was created. It is only used if it can be parsed and actually belongs to the selected band.
|
||||
3. If neither source provides a matching QRG, no `ADDSKED` packet is sent.
|
||||
|
||||
A fixed replacement frequency such as `144.300` is deliberately not used. During a contest, a technically successful handover containing the wrong band or QRG is worse than a visibly omitted handover.
|
||||
|
||||
The internal sked remains intact in every case. This also applies when the broadcast address is invalid, the network fails or no Win-Test client can be reached.
|
||||
|
||||
#### Handling KST callsign suffixes
|
||||
|
||||
KST suffixes often identify a particular chat login or band. They are not necessarily part of the log callsign. KST4Contest therefore removes a suffix separated by `-` before handing the callsign over to Win-Test, while preserving portable and international callsign components:
|
||||
|
||||
| Callsign in the KST chat | Callsign passed to Win-Test |
|
||||
|---|---|
|
||||
| `DN9APW-2` | `DN9APW` |
|
||||
| `9A0BB-70` | `9A0BB` |
|
||||
| `EA5/G8MBI/P-70` | `EA5/G8MBI/P` |
|
||||
| `DN9APW-2/P` | `DN9APW/P` |
|
||||
|
||||
The complete callsign remains available inside KST4Contest. The timeline, reminder PMs and chat category continue to refer to the login which was actually selected.
|
||||
|
||||
#### Mode, time and notes
|
||||
|
||||
The mode is selected explicitly as `SSB` or `CW` when the sked is created. It is not inferred automatically from the QRG because a limited list of assumed band segments cannot represent every supported VHF, UHF and SHF band reliably.
|
||||
|
||||
KST4Contest sends the actual scheduled time without adding an extra minute. Where available, the notes include the locator and QTF together with an indication that the sked was created through KST4Contest.
|
||||
|
||||
The handover consists of the Win-Test packets `LOCKSKED`, `ADDSKED` and `UNLOCKSKED`.
|
||||
|
||||
|
||||
|
||||
#### Settings
|
||||
|
||||
In the **Log sync** tab:
|
||||
|
||||
- `Receive Win-Test network based UDP log messages`
|
||||
- `UDP-Port for Win-Test listener`, default `9871`
|
||||
- `KST station name in Win-Test network (src of SKED packets)`
|
||||
- `Win-Test network broadcast address`
|
||||
|
||||
In the **TRX sync** tab:
|
||||
|
||||
- `Win-Test STATUS QRG Sync`
|
||||
- `Use pass frequency from Win-Test STATUS`
|
||||
- `Win-Test station name filter`
|
||||
|
||||
The Win-Test network must be enabled in Win-Test. When several computers are used, the broadcast address must reach the relevant local network. The station name should identify the sending KST4Contest instance unambiguously within the Win-Test network.
|
||||
|
||||
Detailed settings: [Win-Test Network Listener](en-Configuration#win-test-network-listener-from-v131)
|
||||
**Settings in the "TRX Synchronisation" tab:**
|
||||
- `Win-Test STATUS QRG Sync`: When enabled, KST4Contest takes the current transceiver frequency from the Win-Test STATUS packet and uses it as your own QRG (MYQRG).
|
||||
- `Use pass frequency from Win-Test STATUS`: Instead of the main TRX frequency, the pass frequency contained in the STATUS packet is used as MYQRG (useful for multi-op setups that operate with a dedicated pass QRG).
|
||||
- `Win-Test station name filter`: If a name is entered here (e.g. "STN1"), KST4Contest only processes packets from that specific Win-Test instance. Leave empty to accept all.
|
||||
|
||||
**Settings in Win-Test:**
|
||||
- The network in Win-Test must be active.
|
||||
- Win-Test must be configured to send/receive its broadcasts on the corresponding port (default 9871).
|
||||
|
||||
---
|
||||
|
||||
## TRX Frequency Synchronisation
|
||||
|
||||
@@ -192,16 +144,6 @@ For DM5M-style setups (2 radios, 2 computers, one KST4Contest instance or two se
|
||||
|
||||
## Internal Database
|
||||
|
||||
KST4Contest stores Worked, NOT-QRV and worked-grid information in its own SQLite database. This database is independent of the logging application's database.
|
||||
KST4Contest stores worked information in an internal **SQLite database**. This is independent of the logging program's database and is only populated via the UDP broadcast.
|
||||
|
||||
The input sources provide different levels of detail:
|
||||
|
||||
| Source | Global callsign status | Per-band status | Grid square |
|
||||
|---|---:|---:|---:|
|
||||
| Simplelogfile | yes | no | no |
|
||||
| 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 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.
|
||||
|
||||
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.
|
||||
Before each new contest: reset the database! → [Configuration – Worked Station Database Settings](Configuration#worked-station-database-settings)
|
||||
|
||||
@@ -140,41 +140,16 @@ Replaced by the current antenna direction in words (e.g. `north`, `north east`,
|
||||
|
||||
## 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:
|
||||
All variables can also be used in the **automatic beacon** (interval messages). Recommended beacon configuration:
|
||||
|
||||
| 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 |
|
||||
|
||||
`QRZNAME`, `FIRSTAP` and `SECONDAP` require a selected remote station. They are therefore not resolved in a public beacon.
|
||||
|
||||
A suitable configuration for the primary category is:
|
||||
|
||||
```text
|
||||
calling cq at MYQRGSHORT, ant MYQTF deg, loc MYLOCATOR
|
||||
```
|
||||
calling cq at MYQRG, loc MYLOCATOR, GL all!
|
||||
```
|
||||
|
||||
For the second category, use `SECONDQRG` if that category should publish a different frequency:
|
||||
|
||||
```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.
|
||||
|
||||
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 common interval and the behaviour of both chat categories are described under [Configuration – Beacon Settings](en-Configuration#beacon-settings).
|
||||
Since KST4Contest automatically reads QRG data from chat messages: if other stations also use KST4Contest, they will immediately see your QRG in the QRG column of their user list.
|
||||
|
||||
---
|
||||
|
||||
|
||||
## Example Contest Workflow with Macros
|
||||
|
||||
1. Select a station in the user list → callsign is now pre-selected.
|
||||
|
||||
@@ -26,29 +26,14 @@ The central table of all currently active chat users. Columns (depending on conf
|
||||
|
||||
| Column | Content |
|
||||
|---|---|
|
||||
| Callsign | Station callsign |
|
||||
| Name | Name and additional information from the chat name field |
|
||||
| QRA | Maidenhead locator |
|
||||
| Call | Station's callsign |
|
||||
| Name | Name from the chat name field |
|
||||
| Loc | Maidenhead locator |
|
||||
| QRB | Distance in km |
|
||||
| QTF | Direction in degrees |
|
||||
| QRG | Most recent frequency detected in a chat message |
|
||||
| Tropo | Result of the band-specific tropo or path assessment |
|
||||
| Score | Current, numerically sortable priority score of the normalised base callsign |
|
||||
| Act | Minutes since the most recent activity |
|
||||
| AP | AirScout aircraft data, when enabled |
|
||||
| worked | Per-band Worked, band-opportunity and grid-square status, plus `wkdany` |
|
||||
| NOT QRV @ | Bands on which the station has manually been marked not QRV |
|
||||
| Category | Chat category of this entry |
|
||||
|
||||
### Worked, band and grid-square status
|
||||
|
||||
The subcolumns under **worked** use compact codes because several enabled bands leave little room for full descriptions. `X` marks a callsign worked on that band. `a` and `B+` identify an offered band which has not yet been worked. An appended `o` means that the four-character grid square has already been worked on this band.
|
||||
|
||||
The **wkdany** subcolumn is band-independent: `x` means that the callsign has been worked, `o` means that the grid square has been worked on any band, and `xo` means both.
|
||||
|
||||
Each status cell has a tooltip containing the legend and the state derived for that station. For the complete calculation, including NOT-QRV precedence, see [Worked Callsigns, New Bands and New Grid Squares](en-Features#worked-callsigns-new-bands-and-new-grid-squares).
|
||||
|
||||
|
||||
| QRG | Automatically detected frequency |
|
||||
| AP | AirScout aircraft data (when active) |
|
||||
| Band colours | Worked / NOT-QRV status per band |
|
||||
|
||||
**Sorting**: Click column headers. QRB sorting is numerical (corrected in v1.22).
|
||||
|
||||
@@ -68,210 +53,53 @@ Input field for the current antenna direction. Used for the planned `MYQTF` vari
|
||||
|
||||
## Filters
|
||||
|
||||
The filter bar is located above the chat-member table and groups related controls:
|
||||
The filter bar (from v1.21 as a flowpane for small screens):
|
||||
|
||||
- **Show only QTF** limits the list to a selected antenna direction.
|
||||
- **Show only QRB [km] <=** sets a maximum distance.
|
||||
- **Find** searches for a callsign.
|
||||
- **wkd** hides callsigns which have already been worked on at least one band.
|
||||
- The individual band buttons hide a station if it has already been worked on that band or has been marked NOT QRV there. Only bands enabled for the local station are shown.
|
||||
- **Only new grids** shows only stations in four-character grid squares which have not been worked on any band.
|
||||
- **Grid color** is not a filter. It marks the QRA cell of an already worked grid square without hiding stations.
|
||||
- **New bands** shows stations with at least one detected, locally enabled and unworked band opportunity. NOT-QRV marks take precedence.
|
||||
- **Reachability**, **Tropo >=0dB** and **AS next 5m** limit the list according to the selected path or AirScout criteria.
|
||||
|
||||
The filter bar has no fixed width. QTF, Worked and Reachability controls initially use the available space in their respective rows. When the horizontal divider is moved to the right and the chat-member area becomes narrower, controls wrap only when their actual required width no longer fits.
|
||||
|
||||
|
||||
|
||||
In plain terms: the filters determine the table contents, but no longer enforce the minimum width of the entire right-hand side. The bar remains compact in the normal layout and uses additional height only when the view becomes genuinely narrow. Moving the divider back to the left immediately returns the controls to the available rows.
|
||||
- **Show only QTF**: Activate direction filter (N/NE/E/… buttons or degree input)
|
||||
- **Show only QRB [km] <=**: Activate distance filter (toggle button)
|
||||
- **Hide Worked [Band]**: Hide worked stations per band (one toggle per band)
|
||||
- **Hide NOT-QRV [Band]**: Hide NOT-QRV-tagged stations per band
|
||||
|
||||
---
|
||||
|
||||
## Station Info Panel (Further Info)
|
||||
|
||||
The lower-right panel combines the messages associated with the selected station. This includes public messages, private messages to the local station and, where visible in the chat, private messages addressed to other stations.
|
||||
Bottom right: Shows all messages of a selected station (CQ messages and PMs in one panel). A message filter can be pre-configured via the default filter in the Preferences.
|
||||
|
||||
The selected filter controls which of these messages are displayed. Under **Settings → GUI**, the default filter can be set to:
|
||||
|
||||
- all messages,
|
||||
- private messages to the local station,
|
||||
- private messages to other stations, or
|
||||
- public messages.
|
||||
|
||||
This setting changes the Further Info display only. Messages are neither discarded nor removed from the other message tables, and the filter can be changed at any time for the currently selected station.
|
||||
|
||||
The lower part of the panel contains per-band **Not QRV** marks for the selected station. Individual controls are shown for the bands enabled in the local station settings. **tag not qrv all** sets or removes the mark for every supported band, including bands which are not currently visible.
|
||||
|
||||
The change immediately affects the **NOT QRV @** column, band opportunities and the corresponding filters. It is stored in the internal database and restored after a restart.
|
||||
|
||||
|
||||
|
||||
The current **Priority score** of the selected station is displayed in the same section.
|
||||
|
||||
**Sked fail** marks an unsuccessful attempt and strongly reduces the score of the normalised base callsign. **Reset fail** removes the mark. It applies to all active suffix and category variants of the station and remains active for the current program session.
|
||||
|
||||
The controls underneath are used to create a sked:
|
||||
|
||||
| Control | Meaning |
|
||||
|---|---|
|
||||
| **Sked in** | Time remaining until the sked |
|
||||
| **Band** | Agreed band selected from the locally enabled bands |
|
||||
| **Mode** | `SSB` or `CW` for a possible Win-Test handover |
|
||||
| **Create sked** | Create the internal sked |
|
||||
| **Remind-PM in** | Enable automatic reminder PMs |
|
||||
| **2+1**, **5+2+1**, **10+5+2+1** | Times at which reminder PMs are sent before the sked |
|
||||
|
||||
|
||||
|
||||
The proposed band is derived from recent QRG and name information for the station. It can be changed explicitly before creating the sked. The mode selection only affects the Win-Test handover; the internal sked and reminder PMs work independently.
|
||||
|
||||
**Create sked** always creates the appointment inside KST4Contest first. If the Win-Test network listener is active, KST4Contest then attempts an additional handover to Win-Test. If no QRG matching the selected band can be found or Win-Test cannot be reached, the internal sked, its priority contribution and any scheduled reminders remain intact.
|
||||
|
||||
The complete derivation and limitations are described under [Skeds and Sked Reminders](en-Features#skeds-and-sked-reminders).
|
||||
**Sked reminders** can also be activated here.
|
||||
|
||||
---
|
||||
|
||||
## Priority List
|
||||
|
||||
The compact priority bar is located on the right-hand side between the user list and the Further Info section. It displays the two currently highest-ranked candidates directly in the main window:
|
||||
|
||||
```text
|
||||
Priority: 1 CALLSIGN SCORE 2 CALLSIGN SCORE more
|
||||
```
|
||||
|
||||
Clicking either candidate selects the corresponding active chat member. The complete callsign, including its suffix and chat category, is used.
|
||||
|
||||
The **more** button opens a separate window containing up to 15 candidates. The list is sorted by descending score. Double-clicking an entry selects the candidate and closes the window.
|
||||
|
||||
|
||||
|
||||
Stations with a score of `0` are not included in the priority list. They remain visible in the user list so that the reason for their exclusion can be examined and, for example, an incorrect NOT-QRV mark can be changed.
|
||||
|
||||
The score is calculated for the normalised base callsign. Several active variants such as `9A0BB-2` and `9A0BB-70` may therefore display the same value in the user list. They nevertheless remain separate message targets.
|
||||
|
||||
New messages, AirScout data, skeds and status changes request a new calculation. A periodic refresh also runs in the background. A briefly outdated order is therefore not an error.
|
||||
|
||||
Calculation and limitations: [Priority Score and Priority List](en-Features#priority-score-and-priority-list-from-v140).
|
||||
Shows the top candidates calculated by the Score Service. Updates automatically in the background based on direction, distance and AP availability.
|
||||
|
||||
---
|
||||
|
||||
## Station Map
|
||||
## Cluster & QSO of Others
|
||||
|
||||
The station map is opened or closed through:
|
||||
|
||||
**Windows → Show / hide station map**
|
||||
|
||||
The window uses the chat members currently visible in the filtered user list. Changing the QRB, QTF, Worked, band or Reachability filters can therefore also change the stations shown on the map.
|
||||
|
||||
A station can additionally be opened directly from the **Further Info** panel using **Show on map**. This selects the station on the map and requests the associated path analysis.
|
||||
|
||||
Stations with the same normalised base callsign and position are combined into one marker. At lower zoom levels, nearby markers may additionally be displayed as clusters. These are display groups only; the individual chat logins remain separate message targets inside KST4Contest.
|
||||
|
||||
Clicking a station marker:
|
||||
|
||||
1. selects the corresponding chat member,
|
||||
2. scrolls the main user list to that entry,
|
||||
3. updates the **Further Info** panel, and
|
||||
4. prepares the complete visible callsign as the message target.
|
||||
|
||||
The map details for the selected station include its locator, QRB, QTF, detected bands and available band opportunities. **Trigger cluster spot** sends a spot through the built-in local DX Cluster server so that connected logging software can receive the selected station and QRG.
|
||||
|
||||
The path-analysis section shows the terrain profile and the calculated route between both stations. Depending on the available data, it includes:
|
||||
|
||||
- the analysis frequency,
|
||||
- line-of-sight and horizon information,
|
||||
- Fresnel-zone clearance,
|
||||
- detected obstructions,
|
||||
- an estimated link budget,
|
||||
- received power and SSB margin, and
|
||||
- a short assessment of the path.
|
||||
|
||||
Moving the mouse over the terrain profile highlights the corresponding geographical position on the map.
|
||||
|
||||
The analysis can be hidden using **Hide path analysis** when more space is required for the map. The compact state displays **Path analysis is hidden.** together with the **Show path analysis** button.
|
||||
|
||||
|
||||
|
||||
The selected station and map contents remain available while the analysis panel is hidden. The setting is stored and restored at the next start.
|
||||
|
||||
Calculation method and limitations: [Station Map and Path Analysis](en-Features#station-map-and-path-analysis-from-v141).
|
||||
|
||||
---
|
||||
|
||||
## Global Message Tabs and Monitor Window
|
||||
|
||||
Three global message tabs are located below the main user list. Unlike the **Further Info** panel, their contents do not depend on the station currently selected.
|
||||
|
||||
| Tab | Displayed messages |
|
||||
|---|---|
|
||||
| **Public messages** | All public chat messages, including CQ calls and beacons |
|
||||
| **DXCluster messages** | DX cluster messages received from the ON4KST server |
|
||||
| **QSO of the other** | Directed messages between chat logins other than the local station |
|
||||
|
||||
The **Public messages** tab is selected by default.
|
||||
|
||||
|
||||
|
||||
The **DXCluster messages** table contains the time, reporting and reported stations, locators, QRG, message text and global Worked state where these values are available in the received message.
|
||||
|
||||
The **QSO of the other** table contains:
|
||||
|
||||
- the complete sender and receiver callsigns,
|
||||
- the latest QRG currently known for each station,
|
||||
- the global Worked state of each station,
|
||||
- the message text, and
|
||||
- the chat category.
|
||||
|
||||
The displayed QRG is not necessarily the frequency on which the stations intend to make a contact. It is the latest QRG currently associated with the respective chat member. The Worked state is global and not specific to the displayed QRG or band.
|
||||
|
||||
A directed chat message in this table does not prove that a radio QSO has taken place. The table also contains sked requests, frequency exchanges and other directed messages between third-party chat logins.
|
||||
|
||||
### 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.
|
||||
Separate window (can be minimised). Shows the communication flow between other stations – interesting during quieter contest periods.
|
||||
|
||||
---
|
||||
|
||||
## Menu
|
||||
|
||||
### Windows
|
||||
|
||||
- **Hide cluster / stranger QSOs** hides the separate monitor window for DX cluster messages and directed messages between other stations.
|
||||
- **Show cluster / stranger QSOs** restores the monitor window.
|
||||
- **hide options** hides the settings window.
|
||||
- **show options** restores the settings window.
|
||||
- **Use dark mode design** activates the dark colour scheme.
|
||||
- **Use default mode design** restores the default colour scheme.
|
||||
- **Show / hide station map** opens or closes the separate station-map and path-analysis window.
|
||||
### Window
|
||||
- **Use Dark Mode** (from v1.26): Toggle dark colour scheme on/off.
|
||||
|
||||
---
|
||||
|
||||
## Window Sizes and Dividers
|
||||
|
||||
When **Save Settings** is clicked, KST4Contest stores the programme-window sizes and the positions of the relevant dividers in the configuration file. These values are reused at the next start.
|
||||
|
||||
The main window is additionally checked against the visible area of the primary screen during startup. If the stored size is too large, KST4Contest reduces and moves the window so that it remains accessible. The complete process is described under [Screen-Aware Main Window Sizing](en-Features#screen-aware-main-window-sizing-from-v141).
|
||||
|
||||
The other programme windows do not currently use this additional size restriction. If, for example, the separate monitor window appears too large after moving to a smaller screen, its size must be corrected manually and stored again using **Save Settings**.
|
||||
|
||||
If the layout has become inconvenient, first move the dividers back to usable positions and save the settings again. Deleting the configuration file also resets the UI values, but it removes the other stored programme settings as well. It should therefore be used only when the interface cannot be restored in another way.
|
||||
From **v1.21**, clicking **"Save Settings"** also saves window sizes and divider positions of all panels in the configuration file, which are restored on the next start.
|
||||
|
||||
If you encounter display problems: delete the configuration file → KST4Contest creates new default values.
|
||||
|
||||
---
|
||||
|
||||
## Operating Tips
|
||||
|
||||
- **Keep the settings window open**: Quick access to enable/disable the beacon.
|
||||
- **Right-click in the user list**: Opens the snippet menu and other context actions.
|
||||
- **Mark a station NOT QRV**: Select the station and use the per-band controls in the **Further Info** panel.
|
||||
- **Right-click in the user list**: Opens the snippet menu and further actions (QRZ.com profile, set NOT-QRV tags).
|
||||
- **Enter from anywhere**: When text is in the send field, Enter sends directly – even if the focus is elsewhere.
|
||||
- **Stop the beacon**: Switch off the beacon while scanning frequencies to avoid flooding the chat with messages.
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 87 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 78 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 389 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 119 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 233 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 30 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 23 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 36 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 4.1 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 2.3 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 30 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 48 KiB After Width: | Height: | Size: 63 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 36 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 100 KiB |
-1013
File diff suppressed because it is too large
Load Diff
@@ -1,128 +0,0 @@
|
||||
/*
|
||||
* Derives the jpackage --add-modules list from module-info.java so that the
|
||||
* packaging scripts never drift from the module descriptor again.
|
||||
*
|
||||
* Run as a single file source program, which behaves identically on the Linux,
|
||||
* macOS and Windows runners:
|
||||
*
|
||||
* java packaging/AddModules.java print the module list
|
||||
* java packaging/AddModules.java --verify-pom fail if pom.xml drifted
|
||||
*
|
||||
* Only platform modules are emitted. Third party requires such as jlayer are
|
||||
* skipped because they are supplied as ordinary jars on the class path, and
|
||||
* automatic modules cannot be linked into a runtime image at all. Test only
|
||||
* requires such as org.junit.jupiter.api are skipped for the same reason.
|
||||
*/
|
||||
|
||||
import java.io.IOException;
|
||||
import java.nio.file.Files;
|
||||
import java.nio.file.Path;
|
||||
import java.util.Set;
|
||||
import java.util.TreeSet;
|
||||
import java.util.regex.Matcher;
|
||||
import java.util.regex.Pattern;
|
||||
|
||||
public final class AddModules {
|
||||
|
||||
private static final Path DESCRIPTOR =
|
||||
Path.of("src", "main", "java", "module-info.java");
|
||||
|
||||
private static final Path POM = Path.of("pom.xml");
|
||||
|
||||
/** Matches "requires [transitive] [static] some.module;" in any order. */
|
||||
private static final Pattern REQUIRES = Pattern.compile(
|
||||
"requires\\s+((?:transitive\\s+|static\\s+)*)([A-Za-z0-9_.]+)\\s*;");
|
||||
|
||||
private static final Pattern ADD_MODULE =
|
||||
Pattern.compile("<addmodule>\\s*([A-Za-z0-9_.]+)\\s*</addmodule>");
|
||||
|
||||
private static final Pattern BLOCK_COMMENT =
|
||||
Pattern.compile("/\\*.*?\\*/", Pattern.DOTALL);
|
||||
|
||||
private static final Pattern LINE_COMMENT = Pattern.compile("//[^\\n]*");
|
||||
|
||||
private AddModules() {
|
||||
}
|
||||
|
||||
public static void main(String[] args) throws IOException {
|
||||
boolean verifyPom = args.length > 0 && "--verify-pom".equals(args[0]);
|
||||
|
||||
Set<String> required = platformModules(read(DESCRIPTOR));
|
||||
if (required.isEmpty()) {
|
||||
fail("No platform modules found in " + DESCRIPTOR);
|
||||
}
|
||||
|
||||
if (!verifyPom) {
|
||||
System.out.println(String.join(",", required));
|
||||
return;
|
||||
}
|
||||
|
||||
Set<String> declared = new TreeSet<>();
|
||||
Matcher matcher = ADD_MODULE.matcher(read(POM));
|
||||
while (matcher.find()) {
|
||||
declared.add(matcher.group(1));
|
||||
}
|
||||
|
||||
if (declared.equals(required)) {
|
||||
System.out.println("pom.xml <addmodules> matches module-info.java ("
|
||||
+ required.size() + " modules)");
|
||||
return;
|
||||
}
|
||||
|
||||
Set<String> missing = new TreeSet<>(required);
|
||||
missing.removeAll(declared);
|
||||
Set<String> extra = new TreeSet<>(declared);
|
||||
extra.removeAll(required);
|
||||
|
||||
System.err.println("pom.xml <addmodules> drifted from module-info.java.");
|
||||
if (!missing.isEmpty()) {
|
||||
System.err.println(" missing in pom.xml: " + String.join(", ", missing));
|
||||
}
|
||||
if (!extra.isEmpty()) {
|
||||
System.err.println(" not required by module-info.java: "
|
||||
+ String.join(", ", extra));
|
||||
}
|
||||
System.err.println(" expected: " + String.join(",", required));
|
||||
System.exit(1);
|
||||
}
|
||||
|
||||
/** Returns the platform modules required by the given descriptor, sorted. */
|
||||
static Set<String> platformModules(String source) {
|
||||
String stripped = LINE_COMMENT.matcher(
|
||||
BLOCK_COMMENT.matcher(source).replaceAll(" ")).replaceAll(" ");
|
||||
|
||||
Set<String> modules = new TreeSet<>();
|
||||
Matcher matcher = REQUIRES.matcher(stripped);
|
||||
while (matcher.find()) {
|
||||
// "requires static" is a compile time only dependency and must not
|
||||
// be linked into the shipped runtime image.
|
||||
if (matcher.group(1).contains("static")) {
|
||||
continue;
|
||||
}
|
||||
String module = matcher.group(2);
|
||||
if (isPlatformModule(module)) {
|
||||
modules.add(module);
|
||||
}
|
||||
}
|
||||
return modules;
|
||||
}
|
||||
|
||||
private static boolean isPlatformModule(String module) {
|
||||
return module.startsWith("java.")
|
||||
|| module.startsWith("jdk.")
|
||||
|| module.startsWith("javafx.");
|
||||
}
|
||||
|
||||
private static String read(Path path) throws IOException {
|
||||
if (!Files.isRegularFile(path)) {
|
||||
fail("Not found: " + path.toAbsolutePath()
|
||||
+ " (run this from the repository root)");
|
||||
}
|
||||
return Files.readString(path);
|
||||
}
|
||||
|
||||
private static void fail(String message) {
|
||||
System.err.println(message);
|
||||
System.exit(2);
|
||||
}
|
||||
}
|
||||
@@ -1,16 +0,0 @@
|
||||
pkgbase = kst4contest-bin
|
||||
pkgdesc = ON4KST Chat Client for VHF/UHF contest operation (pre-built)
|
||||
pkgver = 1.41.1
|
||||
pkgrel = 1
|
||||
url = https://github.com/praktimarc/kst4contest
|
||||
arch = x86_64
|
||||
license = GPL-3.0-only
|
||||
depends = gst-plugins-base
|
||||
depends = gst-plugins-good
|
||||
provides = kst4contest
|
||||
conflicts = kst4contest
|
||||
conflicts = kst4contest-git
|
||||
source = KST4Contest-v1.41.1-archlinux-x86_64.pkg.tar.zst::https://github.com/praktimarc/kst4contest/releases/download/v1.41.1/KST4Contest-v1.41.1-archlinux-x86_64.pkg.tar.zst
|
||||
sha256sums = 8e9a53ff832920c9ef2733635b90c5a4ffcd57a2958aaa251e92bd031142c614
|
||||
|
||||
pkgname = kst4contest-bin
|
||||
@@ -1,17 +0,0 @@
|
||||
# Maintainer: Philipp Wagner <philipp@wagnersnetz.de>
|
||||
pkgname=kst4contest-bin
|
||||
pkgver=1.41.1
|
||||
pkgrel=1
|
||||
pkgdesc="ON4KST Chat Client for VHF/UHF contest operation (pre-built)"
|
||||
arch=('x86_64')
|
||||
url="https://github.com/praktimarc/kst4contest"
|
||||
license=('GPL-3.0-only')
|
||||
depends=('gst-plugins-base' 'gst-plugins-good')
|
||||
provides=('kst4contest')
|
||||
conflicts=('kst4contest' 'kst4contest-git')
|
||||
source=("KST4Contest-v${pkgver}-archlinux-${CARCH}.pkg.tar.zst::https://github.com/praktimarc/kst4contest/releases/download/v${pkgver}/KST4Contest-v${pkgver}-archlinux-${CARCH}.pkg.tar.zst")
|
||||
sha256sums=('8e9a53ff832920c9ef2733635b90c5a4ffcd57a2958aaa251e92bd031142c614')
|
||||
|
||||
package() {
|
||||
cp -a "${srcdir}/usr" "${pkgdir}/"
|
||||
}
|
||||
@@ -1,19 +0,0 @@
|
||||
pkgbase = kst4contest-git
|
||||
pkgdesc = ON4KST Chat Client for VHF/UHF contest operation (git)
|
||||
pkgver = 1.42.0.r145.gd885924
|
||||
pkgrel = 1
|
||||
url = https://github.com/praktimarc/kst4contest
|
||||
arch = x86_64
|
||||
license = GPL-3.0-only
|
||||
makedepends = java-environment=21
|
||||
makedepends = maven
|
||||
makedepends = git
|
||||
depends = gst-plugins-base
|
||||
depends = gst-plugins-good
|
||||
provides = kst4contest
|
||||
conflicts = kst4contest
|
||||
conflicts = kst4contest-bin
|
||||
source = kst4contest::git+https://github.com/praktimarc/kst4contest.git
|
||||
sha256sums = SKIP
|
||||
|
||||
pkgname = kst4contest-git
|
||||
@@ -1,78 +0,0 @@
|
||||
# Maintainer: Philipp Wagner <philipp@wagnersnetz.de>
|
||||
pkgname=kst4contest-git
|
||||
pkgver=1.42.0.r145.gd885924
|
||||
pkgrel=1
|
||||
pkgdesc="ON4KST Chat Client for VHF/UHF contest operation (git)"
|
||||
arch=('x86_64')
|
||||
url="https://github.com/praktimarc/kst4contest"
|
||||
license=('GPL-3.0-only')
|
||||
depends=('gst-plugins-base' 'gst-plugins-good')
|
||||
makedepends=('java-environment=21' 'maven' 'git')
|
||||
provides=('kst4contest')
|
||||
conflicts=('kst4contest' 'kst4contest-bin')
|
||||
source=("kst4contest::git+https://github.com/praktimarc/kst4contest.git")
|
||||
sha256sums=('SKIP')
|
||||
|
||||
pkgver() {
|
||||
cd "${srcdir}/kst4contest"
|
||||
BASE=$(grep -m1 '<version>' pom.xml \
|
||||
| sed 's/.*<version>\(.*\)<\/version>.*/\1/' | sed 's/[-.]nightly//')
|
||||
printf '%s.r%s.g%s' "${BASE}" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
|
||||
}
|
||||
|
||||
build() {
|
||||
cd "${srcdir}/kst4contest"
|
||||
|
||||
export JAVA_HOME=$(find /usr/lib/jvm -maxdepth 1 -name 'java-21-*' -type d | head -n 1)
|
||||
export PATH="${JAVA_HOME}/bin:${PATH}"
|
||||
|
||||
mvn -B -DskipTests package dependency:copy-dependencies \
|
||||
-DincludeScope=runtime \
|
||||
-DoutputDirectory=target/dist-libs
|
||||
|
||||
cp "$(ls -t target/praktiKST-*.jar | head -n 1)" target/dist-libs/app.jar
|
||||
|
||||
mkdir -p dist
|
||||
ADD_MODULES="$(java packaging/AddModules.java)"
|
||||
jpackage \
|
||||
--type app-image \
|
||||
--name KST4Contest \
|
||||
--icon packaging/icons/kst4contest.png \
|
||||
--input target/dist-libs \
|
||||
--main-jar app.jar \
|
||||
--main-class kst4contest.view.Kst4ContestApplication \
|
||||
--module-path target/dist-libs \
|
||||
--add-modules "$ADD_MODULES" \
|
||||
--dest dist
|
||||
}
|
||||
|
||||
package() {
|
||||
cd "${srcdir}/kst4contest"
|
||||
|
||||
install -dm755 "${pkgdir}/usr/lib/KST4Contest"
|
||||
cp -a dist/KST4Contest/. "${pkgdir}/usr/lib/KST4Contest/"
|
||||
|
||||
install -dm755 "${pkgdir}/usr/bin"
|
||||
printf '#!/bin/sh\nexec /usr/lib/KST4Contest/bin/KST4Contest "$@"\n' \
|
||||
> "${pkgdir}/usr/bin/KST4Contest"
|
||||
chmod 755 "${pkgdir}/usr/bin/KST4Contest"
|
||||
|
||||
install -dm755 "${pkgdir}/usr/share/applications"
|
||||
cat > "${pkgdir}/usr/share/applications/KST4Contest.desktop" << 'EOF'
|
||||
[Desktop Entry]
|
||||
Type=Application
|
||||
Name=KST4Contest
|
||||
Comment=ON4KST Chat Client for VHF/UHF contest operation
|
||||
Exec=KST4Contest
|
||||
Icon=KST4Contest
|
||||
Categories=Network;HamRadio;
|
||||
Terminal=false
|
||||
EOF
|
||||
|
||||
if [[ -f "${pkgdir}/usr/lib/KST4Contest/lib/KST4Contest.png" ]]; then
|
||||
install -Dm644 "${pkgdir}/usr/lib/KST4Contest/lib/KST4Contest.png" \
|
||||
"${pkgdir}/usr/share/icons/hicolor/256x256/apps/KST4Contest.png"
|
||||
fi
|
||||
|
||||
install -Dm644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
|
||||
}
|
||||
@@ -1,18 +0,0 @@
|
||||
pkgbase = kst4contest
|
||||
pkgdesc = ON4KST Chat Client for VHF/UHF contest operation
|
||||
pkgver = 1.41.1
|
||||
pkgrel = 2
|
||||
url = https://github.com/praktimarc/kst4contest
|
||||
arch = x86_64
|
||||
license = GPL-3.0-only
|
||||
makedepends = java-environment=21
|
||||
makedepends = maven
|
||||
depends = gst-plugins-base
|
||||
depends = gst-plugins-good
|
||||
provides = kst4contest
|
||||
conflicts = kst4contest-bin
|
||||
conflicts = kst4contest-git
|
||||
source = kst4contest-1.41.1.tar.gz::https://github.com/praktimarc/kst4contest/archive/refs/tags/v1.41.1.tar.gz
|
||||
sha256sums = e96207a2d3fee19d35e34717f5312beb28bb087c040164e352337e749ce53b8d
|
||||
|
||||
pkgname = kst4contest
|
||||
@@ -1,85 +0,0 @@
|
||||
# Maintainer: Philipp Wagner <philipp@wagnersnetz.de>
|
||||
pkgname=kst4contest
|
||||
pkgver=1.41.1
|
||||
pkgrel=2
|
||||
pkgdesc="ON4KST Chat Client for VHF/UHF contest operation"
|
||||
arch=('x86_64')
|
||||
url="https://github.com/praktimarc/kst4contest"
|
||||
license=('GPL-3.0-only')
|
||||
depends=('gst-plugins-base' 'gst-plugins-good')
|
||||
makedepends=('java-environment=21' 'maven')
|
||||
provides=('kst4contest')
|
||||
conflicts=('kst4contest-bin' 'kst4contest-git')
|
||||
source=("${pkgname}-${pkgver}.tar.gz::https://github.com/praktimarc/kst4contest/archive/refs/tags/v${pkgver}.tar.gz")
|
||||
sha256sums=('e96207a2d3fee19d35e34717f5312beb28bb087c040164e352337e749ce53b8d')
|
||||
|
||||
build() {
|
||||
cd "${srcdir}/kst4contest-${pkgver}"
|
||||
|
||||
export JAVA_HOME=$(find /usr/lib/jvm -maxdepth 1 -name 'java-21-*' -type d | head -n 1)
|
||||
export PATH="${JAVA_HOME}/bin:${PATH}"
|
||||
|
||||
mvn -B -DskipTests package dependency:copy-dependencies \
|
||||
-DincludeScope=runtime \
|
||||
-DoutputDirectory=target/dist-libs
|
||||
|
||||
cp "$(ls -t target/praktiKST-*.jar | head -n 1)" target/dist-libs/app.jar
|
||||
|
||||
mkdir -p dist
|
||||
# This PKGBUILD builds from a released source tarball, which may predate
|
||||
# packaging/AddModules.java. Older tarballs carry the same list in pom.xml,
|
||||
# which the build keeps in sync with module-info.java from v1.42.0 onwards.
|
||||
if [ -f packaging/AddModules.java ]; then
|
||||
ADD_MODULES="$(java packaging/AddModules.java)"
|
||||
else
|
||||
ADD_MODULES="$(sed -n 's:.*<addmodule>\(.*\)</addmodule>.*:\1:p' pom.xml | paste -sd,)"
|
||||
fi
|
||||
# Same story for the packaging icon: without --icon jpackage silently ships
|
||||
# its own Duke placeholder, but tarballs older than v1.42.0 have no icon to
|
||||
# point at, so only pass the flag when the file is actually there.
|
||||
ICON_ARGS=()
|
||||
if [ -f packaging/icons/kst4contest.png ]; then
|
||||
ICON_ARGS=(--icon packaging/icons/kst4contest.png)
|
||||
fi
|
||||
jpackage \
|
||||
--type app-image \
|
||||
--name KST4Contest \
|
||||
"${ICON_ARGS[@]}" \
|
||||
--input target/dist-libs \
|
||||
--main-jar app.jar \
|
||||
--main-class kst4contest.view.Kst4ContestApplication \
|
||||
--module-path target/dist-libs \
|
||||
--add-modules "$ADD_MODULES" \
|
||||
--dest dist
|
||||
}
|
||||
|
||||
package() {
|
||||
cd "${srcdir}/kst4contest-${pkgver}"
|
||||
|
||||
install -dm755 "${pkgdir}/usr/lib/KST4Contest"
|
||||
cp -a dist/KST4Contest/. "${pkgdir}/usr/lib/KST4Contest/"
|
||||
|
||||
install -dm755 "${pkgdir}/usr/bin"
|
||||
printf '#!/bin/sh\nexec /usr/lib/KST4Contest/bin/KST4Contest "$@"\n' \
|
||||
> "${pkgdir}/usr/bin/KST4Contest"
|
||||
chmod 755 "${pkgdir}/usr/bin/KST4Contest"
|
||||
|
||||
install -dm755 "${pkgdir}/usr/share/applications"
|
||||
cat > "${pkgdir}/usr/share/applications/KST4Contest.desktop" << 'EOF'
|
||||
[Desktop Entry]
|
||||
Type=Application
|
||||
Name=KST4Contest
|
||||
Comment=ON4KST Chat Client for VHF/UHF contest operation
|
||||
Exec=KST4Contest
|
||||
Icon=KST4Contest
|
||||
Categories=Network;HamRadio;
|
||||
Terminal=false
|
||||
EOF
|
||||
|
||||
if [[ -f "${pkgdir}/usr/lib/KST4Contest/lib/KST4Contest.png" ]]; then
|
||||
install -Dm644 "${pkgdir}/usr/lib/KST4Contest/lib/KST4Contest.png" \
|
||||
"${pkgdir}/usr/share/icons/hicolor/256x256/apps/KST4Contest.png"
|
||||
fi
|
||||
|
||||
install -Dm644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
|
||||
}
|
||||
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 45 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 7.6 KiB |
@@ -1,9 +0,0 @@
|
||||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 180 180" width="180" height="180"><rect x="0" y="0" width="180" height="180" rx="40" fill="#5fd63a"></rect><g transform="translate(40,40) scale(1)">
|
||||
<path d="M20 34 h60 a12 12 0 0 1 12 12 v20 a12 12 0 0 1 -12 12 h-30 l-16 12 v-12 h-14 a12 12 0 0 1 -12 -12 v-20 a12 12 0 0 1 12 -12 z" fill="#0a110a"></path>
|
||||
<text x="50" y="65" text-anchor="middle" font-family="'Space Grotesk','Helvetica Neue',Arial,sans-serif" font-weight="700" font-size="24" letter-spacing="0.5" fill="#5fd63a">KST</text>
|
||||
<line x1="50" y1="34" x2="50" y2="17" stroke="#0a110a" stroke-width="6" stroke-linecap="round"></line>
|
||||
<circle cx="50" cy="13" r="4.5" fill="#0a110a"></circle>
|
||||
<path d="M58 6 a9 9 0 0 1 0 14" fill="none" stroke="#0a110a" stroke-width="4" stroke-linecap="round"></path>
|
||||
<path d="M64 1 a15 15 0 0 1 0 24" fill="none" stroke="#0a110a" stroke-width="4" stroke-linecap="round"></path>
|
||||
<path d="M42 6 a9 9 0 0 0 0 14" fill="none" stroke="#0a110a" stroke-width="4" stroke-linecap="round"></path>
|
||||
<path d="M36 1 a15 15 0 0 0 0 24" fill="none" stroke="#0a110a" stroke-width="4" stroke-linecap="round"></path></g></svg>
|
||||
|
Before Width: | Height: | Size: 1.2 KiB |
@@ -1,268 +0,0 @@
|
||||
#!/usr/bin/env bash
|
||||
#
|
||||
# Local signed (and optionally notarized) macOS build.
|
||||
#
|
||||
# jpackage cannot sign the app itself: it ad-hoc signs the embedded runtime and
|
||||
# then re-runs codesign on the same files without --force, which codesign
|
||||
# rejects with "is already signed". So this builds an unsigned app-image, signs
|
||||
# it from the inside out ourselves, and only then wraps it into a DMG.
|
||||
#
|
||||
# Required:
|
||||
# SIGNING_IDENTITY The name part of the Developer ID Application certificate,
|
||||
# without the "Developer ID Application: " prefix. Example:
|
||||
# SIGNING_IDENTITY="Philipp Wagner (ABCDE12345)"
|
||||
# List available ones with:
|
||||
# security find-identity -v -p codesigning
|
||||
#
|
||||
# Optional:
|
||||
# Notarization, either as three separate values (what CI uses)...
|
||||
# NOTARY_KEY Path to the App Store Connect .p8 private key
|
||||
# NOTARY_KEY_ID The key's ID, also part of the .p8 filename
|
||||
# NOTARY_ISSUER The issuer UUID, shown above the key list in the portal
|
||||
# ...or as a keychain profile previously created with
|
||||
# NOTARY_PROFILE xcrun notarytool store-credentials <name>
|
||||
#
|
||||
# With neither, the build is signed but not notarized -- enough to test
|
||||
# locally, not enough to distribute.
|
||||
#
|
||||
set -euo pipefail
|
||||
|
||||
cd "$(dirname "$0")/../.."
|
||||
REPO_ROOT="$PWD"
|
||||
|
||||
BUNDLE_ID="de.x08.KST4Contest"
|
||||
ENTITLEMENTS="packaging/macos/kst4contest.entitlements"
|
||||
|
||||
if [ -z "${SIGNING_IDENTITY:-}" ]; then
|
||||
echo "SIGNING_IDENTITY is not set. Available signing identities:" >&2
|
||||
security find-identity -v -p codesigning >&2 || true
|
||||
exit 1
|
||||
fi
|
||||
FULL_IDENTITY="Developer ID Application: $SIGNING_IDENTITY"
|
||||
|
||||
# notarytool takes either an API key triple or a stored keychain profile. The
|
||||
# triple needs no keychain at all, which is why CI uses it.
|
||||
NOTARY_ARGS=()
|
||||
if [ -n "${NOTARY_KEY:-}" ] && [ -n "${NOTARY_KEY_ID:-}" ] && [ -n "${NOTARY_ISSUER:-}" ]; then
|
||||
NOTARY_ARGS=(--key "$NOTARY_KEY" --key-id "$NOTARY_KEY_ID" --issuer "$NOTARY_ISSUER")
|
||||
elif [ -n "${NOTARY_PROFILE:-}" ]; then
|
||||
NOTARY_ARGS=(--keychain-profile "$NOTARY_PROFILE")
|
||||
fi
|
||||
|
||||
echo "==> Building JAR and collecting runtime dependencies"
|
||||
chmod +x mvnw
|
||||
./mvnw -B -DskipTests package \
|
||||
dependency:copy-dependencies -DincludeScope=runtime -DoutputDirectory=target/dist-libs
|
||||
JAR="$(ls -t target/praktiKST-*.jar | head -n 1)"
|
||||
cp "$JAR" target/dist-libs/app.jar
|
||||
|
||||
# jpackage only accepts a numeric major[.minor[.patch]] as the macOS bundle
|
||||
# version, so a Maven qualifier like "-nightly" has to be trimmed off.
|
||||
POM_VERSION="${JAR##*/praktiKST-}"
|
||||
POM_VERSION="${POM_VERSION%.jar}"
|
||||
APP_VERSION="$(printf '%s' "$POM_VERSION" | sed -e 's/[^0-9.].*$//' -e 's/\.*$//')"
|
||||
[ -n "$APP_VERSION" ] || { echo "Could not derive app version from $JAR" >&2; exit 1; }
|
||||
echo "==> Version: $POM_VERSION -> bundle version $APP_VERSION"
|
||||
|
||||
echo "==> Step 1/4: jpackage app-image (unsigned)"
|
||||
rm -rf dist
|
||||
mkdir -p dist
|
||||
ADD_MODULES="$(java packaging/AddModules.java)"
|
||||
|
||||
MACOSX_DEPLOYMENT_TARGET="13.0" jpackage \
|
||||
--type app-image \
|
||||
--name KST4Contest \
|
||||
--app-version "$APP_VERSION" \
|
||||
--icon packaging/icons/kst4contest.icns \
|
||||
--input target/dist-libs \
|
||||
--main-jar app.jar \
|
||||
--main-class kst4contest.view.Kst4ContestApplication \
|
||||
--module-path target/dist-libs \
|
||||
--add-modules "$ADD_MODULES" \
|
||||
--mac-package-identifier "$BUNDLE_ID" \
|
||||
--mac-package-name KST4Contest \
|
||||
--dest dist/appimage
|
||||
|
||||
APP="dist/appimage/KST4Contest.app"
|
||||
[ -d "$APP" ] || { echo "jpackage produced no app image" >&2; exit 1; }
|
||||
|
||||
echo "==> Step 2/4: signing bundle contents (this takes a few minutes)"
|
||||
|
||||
# Apple's notary service unpacks JARs and checks the native libraries inside
|
||||
# them. sqlite-jdbc ships libsqlitejdbc.dylib for both architectures that way,
|
||||
# and an unsigned binary in there fails the whole submission. So sign those
|
||||
# first: the app bundle's seal covers Contents/app, and rewriting a JAR
|
||||
# afterwards would invalidate it.
|
||||
echo " scanning jars for native libraries"
|
||||
find "$APP/Contents/app" -name '*.jar' -type f | while read -r JARPATH; do
|
||||
# Only unpack jars that can plausibly hold a native library. Note the
|
||||
# plain grep: "grep -q" exits at the first match, which hands unzip a
|
||||
# SIGPIPE, and under "set -o pipefail" that failure becomes the pipeline's
|
||||
# status -- inverting this very test.
|
||||
if ! unzip -l "$JARPATH" | grep -E '\.(dylib|jnilib|so)$' >/dev/null; then
|
||||
continue
|
||||
fi
|
||||
|
||||
JARABS="$(cd "$(dirname "$JARPATH")" && pwd)/$(basename "$JARPATH")"
|
||||
JARTMP="$(mktemp -d)"
|
||||
unzip -q "$JARABS" -d "$JARTMP"
|
||||
|
||||
NATIVES="$(mktemp)"
|
||||
( cd "$JARTMP" && find . -type f \( -name '*.dylib' -o -name '*.jnilib' -o -name '*.so' \) \
|
||||
| while read -r n; do
|
||||
if [ "$(file --mime-type -b "$n")" = "application/x-mach-binary" ]; then
|
||||
printf '%s\n' "${n#./}"
|
||||
fi
|
||||
done ) > "$NATIVES"
|
||||
|
||||
if [ -s "$NATIVES" ]; then
|
||||
echo " $(basename "$JARPATH"): $(wc -l < "$NATIVES" | tr -d ' ') native lib(s)"
|
||||
( cd "$JARTMP" && xargs -I {} codesign --force --timestamp --options runtime \
|
||||
--sign "$FULL_IDENTITY" {} < "$NATIVES" )
|
||||
# Update in place rather than repacking, so the rest of the jar --
|
||||
# manifest, module descriptor, entry order -- stays byte for byte.
|
||||
( cd "$JARTMP" && xargs jar --update --file "$JARABS" < "$NATIVES" )
|
||||
fi
|
||||
|
||||
rm -rf "$JARTMP" "$NATIVES"
|
||||
done
|
||||
|
||||
# Every Mach-O file has to carry its own signature before the enclosing bundle
|
||||
# can be sealed, so collect them first. jpackage leaves them ad-hoc signed,
|
||||
# hence --force on every call.
|
||||
# file(1) pads its output into columns when given several arguments at once,
|
||||
# so ask it one file at a time with -b and get an unambiguous answer.
|
||||
MACHO_LIST="$(mktemp)"
|
||||
find "$APP" -type f -print0 | while IFS= read -r -d '' f; do
|
||||
case "$(file --mime-type -b "$f")" in
|
||||
application/x-mach-binary) printf '%s\n' "$f" ;;
|
||||
esac
|
||||
done > "$MACHO_LIST"
|
||||
|
||||
COUNT="$(wc -l < "$MACHO_LIST" | tr -d ' ')"
|
||||
echo " $COUNT Mach-O files to sign"
|
||||
|
||||
# Serially, deliberately. Running codesign concurrently over several files of
|
||||
# the same bundle fails intermittently -- a CI run died with "replacing existing
|
||||
# signature" immediately followed by "No such file or directory" for that same
|
||||
# path, while the identical script passed locally. Each call contacts Apple's
|
||||
# timestamp server, so this costs about a minute for a runtime this size.
|
||||
xargs -I {} codesign --force --timestamp --options runtime \
|
||||
--sign "$FULL_IDENTITY" {} < "$MACHO_LIST"
|
||||
rm -f "$MACHO_LIST"
|
||||
|
||||
# The embedded JDK is a bundle in its own right and must be sealed before the
|
||||
# app that contains it.
|
||||
echo " sealing embedded runtime"
|
||||
codesign --force --timestamp --options runtime \
|
||||
--sign "$FULL_IDENTITY" "$APP/Contents/runtime"
|
||||
|
||||
# Entitlements go on the outermost bundle: the hardened runtime derives the
|
||||
# process's entitlements from the main executable's signature.
|
||||
echo " sealing app bundle"
|
||||
codesign --force --timestamp --options runtime \
|
||||
--entitlements "$ENTITLEMENTS" \
|
||||
--sign "$FULL_IDENTITY" "$APP"
|
||||
|
||||
# Apple rejects the whole submission over a single unsigned native library, and
|
||||
# a round trip to the notary service costs minutes. Check its two criteria --
|
||||
# a Developer ID authority and a secure timestamp -- locally first.
|
||||
echo " preflight: verifying native libraries inside jars"
|
||||
PREFLIGHT_ERRORS="$(mktemp)"
|
||||
find "$APP/Contents/app" -name '*.jar' -type f | while read -r JARPATH; do
|
||||
if ! unzip -l "$JARPATH" | grep -E '\.(dylib|jnilib|so)$' >/dev/null; then
|
||||
continue
|
||||
fi
|
||||
CHECKTMP="$(mktemp -d)"
|
||||
unzip -q "$JARPATH" -d "$CHECKTMP"
|
||||
find "$CHECKTMP" -type f \( -name '*.dylib' -o -name '*.jnilib' -o -name '*.so' \) \
|
||||
| while read -r NATIVE; do
|
||||
[ "$(file --mime-type -b "$NATIVE")" = "application/x-mach-binary" ] || continue
|
||||
INFO="$(codesign -dv --verbose=2 "$NATIVE" 2>&1 || true)"
|
||||
LABEL="$(basename "$JARPATH")/${NATIVE#"$CHECKTMP"/}"
|
||||
printf '%s' "$INFO" | grep -q "Authority=Developer ID Application" \
|
||||
|| echo "$LABEL: not signed with a Developer ID certificate" >> "$PREFLIGHT_ERRORS"
|
||||
printf '%s' "$INFO" | grep -q "Timestamp=" \
|
||||
|| echo "$LABEL: signature has no secure timestamp" >> "$PREFLIGHT_ERRORS"
|
||||
done
|
||||
rm -rf "$CHECKTMP"
|
||||
done
|
||||
if [ -s "$PREFLIGHT_ERRORS" ]; then
|
||||
echo "ERROR: these would fail notarization:" >&2
|
||||
sed 's/^/ /' "$PREFLIGHT_ERRORS" >&2
|
||||
rm -f "$PREFLIGHT_ERRORS"
|
||||
exit 1
|
||||
fi
|
||||
rm -f "$PREFLIGHT_ERRORS"
|
||||
echo " preflight ok"
|
||||
|
||||
echo "==> Step 3/4: building the dmg"
|
||||
|
||||
# Not with jpackage: "jpackage --type dmg --app-image" re-signs the app it is
|
||||
# handed, replacing our Developer ID signature with an ad-hoc one and dropping
|
||||
# the hardened runtime flag. hdiutil copies the bundle verbatim instead.
|
||||
DMG="dist/KST4Contest-${APP_VERSION}.dmg"
|
||||
STAGE="$(mktemp -d)"
|
||||
# ditto rather than cp -R: it preserves the extended attributes the code
|
||||
# signature depends on.
|
||||
ditto "$APP" "$STAGE/KST4Contest.app"
|
||||
ln -s /Applications "$STAGE/Applications"
|
||||
|
||||
hdiutil create -volname "KST4Contest" -srcfolder "$STAGE" \
|
||||
-ov -format UDZO -quiet "$DMG"
|
||||
rm -rf "$STAGE"
|
||||
[ -f "$DMG" ] || { echo "hdiutil produced no DMG" >&2; exit 1; }
|
||||
|
||||
# Signing the DMG itself is not what Gatekeeper judges -- that is the .app
|
||||
# inside -- but Apple expects the container to be signed too.
|
||||
codesign --force --timestamp --sign "$FULL_IDENTITY" "$DMG"
|
||||
echo "==> Built $DMG"
|
||||
|
||||
echo "==> Step 4/4: verification"
|
||||
|
||||
if [ ${#NOTARY_ARGS[@]} -gt 0 ]; then
|
||||
echo " submitting for notarization (waits for Apple's verdict)"
|
||||
# Without a timeout a stalled submission would hang a CI job forever.
|
||||
xcrun notarytool submit "$DMG" "${NOTARY_ARGS[@]}" --wait --timeout 30m
|
||||
echo " stapling ticket"
|
||||
xcrun stapler staple "$DMG"
|
||||
else
|
||||
echo " no notarization credentials set, skipping notarization"
|
||||
fi
|
||||
|
||||
# Everything below inspects the app as it actually ships, mounted from the DMG,
|
||||
# rather than the staging copy on disk.
|
||||
MOUNT_POINT="$(mktemp -d)"
|
||||
hdiutil attach "$DMG" -nobrowse -quiet -mountpoint "$MOUNT_POINT"
|
||||
trap 'hdiutil detach "$MOUNT_POINT" -quiet 2>/dev/null || hdiutil detach "$MOUNT_POINT" -force -quiet 2>/dev/null || true' EXIT
|
||||
SHIPPED_APP="$MOUNT_POINT/KST4Contest.app"
|
||||
|
||||
echo "--- codesign --verify on the app inside the DMG ---"
|
||||
codesign --verify --deep --strict --verbose=2 "$SHIPPED_APP"
|
||||
|
||||
echo "--- app identity ---"
|
||||
codesign -dv --verbose=2 "$SHIPPED_APP" 2>&1 | grep -iE "identifier|authority|teamidentifier|flags"
|
||||
|
||||
# An ad-hoc signature here means something along the way re-signed the bundle.
|
||||
if codesign -dv "$SHIPPED_APP" 2>&1 | grep -q "adhoc"; then
|
||||
echo "ERROR: the app inside the DMG is ad-hoc signed, not Developer ID signed" >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
echo "--- entitlements as signed ---"
|
||||
codesign -d --entitlements - --xml "$SHIPPED_APP" 2>/dev/null | plutil -convert xml1 -o - - | grep -E "key|true|false"
|
||||
|
||||
echo "--- dmg identity ---"
|
||||
codesign -dv --verbose=2 "$DMG" 2>&1 | grep -iE "authority|teamidentifier" | head -2
|
||||
|
||||
echo "--- spctl assessment ---"
|
||||
# Without notarization this reports "rejected"; that is expected.
|
||||
spctl --assess --type execute --verbose=4 "$SHIPPED_APP" || true
|
||||
|
||||
if [ ${#NOTARY_ARGS[@]} -gt 0 ]; then
|
||||
echo "--- stapler validate ---"
|
||||
xcrun stapler validate "$DMG"
|
||||
fi
|
||||
|
||||
echo
|
||||
echo "Done: $REPO_ROOT/$DMG"
|
||||
@@ -1,64 +0,0 @@
|
||||
#!/usr/bin/env bash
|
||||
#
|
||||
# Import the Developer ID certificate into a throwaway keychain on a CI runner.
|
||||
#
|
||||
# A runner cannot answer the keychain's authorization dialog, so the login
|
||||
# keychain is unusable there. This creates a dedicated keychain instead, whose
|
||||
# password is generated here and needed nowhere else -- it is discarded with the
|
||||
# keychain at the end of the job.
|
||||
#
|
||||
# Reads from the environment:
|
||||
# MACOS_CERT_P12 base64 of the exported .p12
|
||||
# MACOS_CERT_PASSWORD the password that .p12 was exported with
|
||||
#
|
||||
# Exports to $GITHUB_ENV:
|
||||
# SIGNING_IDENTITY for packaging/macos/build-signed-dmg.sh
|
||||
# SIGNING_KEYCHAIN so the cleanup step knows what to delete
|
||||
#
|
||||
set -euo pipefail
|
||||
|
||||
: "${MACOS_CERT_P12:?MACOS_CERT_P12 is not set}"
|
||||
: "${MACOS_CERT_PASSWORD:?MACOS_CERT_PASSWORD is not set}"
|
||||
: "${RUNNER_TEMP:?RUNNER_TEMP is not set}"
|
||||
: "${GITHUB_ENV:?GITHUB_ENV is not set}"
|
||||
|
||||
KEYCHAIN="$RUNNER_TEMP/kst4contest-signing.keychain-db"
|
||||
KEYCHAIN_PASSWORD="$(uuidgen)"
|
||||
CERT="$RUNNER_TEMP/cert.p12"
|
||||
|
||||
printf '%s' "$MACOS_CERT_P12" | base64 --decode > "$CERT"
|
||||
|
||||
security create-keychain -p "$KEYCHAIN_PASSWORD" "$KEYCHAIN"
|
||||
# Keychains re-lock after five minutes by default, which would strand a build
|
||||
# halfway through signing.
|
||||
security set-keychain-settings -lut 21600 "$KEYCHAIN"
|
||||
security unlock-keychain -p "$KEYCHAIN_PASSWORD" "$KEYCHAIN"
|
||||
|
||||
security import "$CERT" -k "$KEYCHAIN" -P "$MACOS_CERT_PASSWORD" \
|
||||
-T /usr/bin/codesign -T /usr/bin/security
|
||||
rm -f "$CERT"
|
||||
|
||||
# Lets codesign reach the private key without the UI prompt a runner has no way
|
||||
# of answering.
|
||||
security set-key-partition-list -S apple-tool:,apple:,codesign: \
|
||||
-s -k "$KEYCHAIN_PASSWORD" "$KEYCHAIN" >/dev/null
|
||||
|
||||
# codesign searches the keychain list, so the new keychain has to be on it --
|
||||
# added to whatever the runner already had, not in place of it.
|
||||
EXISTING_KEYCHAINS="$(security list-keychains -d user | sed -e 's/^[[:space:]]*"//' -e 's/"$//')"
|
||||
# shellcheck disable=SC2086
|
||||
security list-keychains -d user -s "$KEYCHAIN" $EXISTING_KEYCHAINS
|
||||
|
||||
IDENTITY="$(security find-identity -v -p codesigning "$KEYCHAIN" \
|
||||
| sed -n 's/.*"Developer ID Application: \(.*\)".*/\1/p' | head -n 1)"
|
||||
|
||||
if [ -z "$IDENTITY" ]; then
|
||||
echo "No 'Developer ID Application' identity found in the imported certificate." >&2
|
||||
echo "What the keychain does contain:" >&2
|
||||
security find-identity -v -p codesigning "$KEYCHAIN" >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
echo "Imported identity: Developer ID Application: $IDENTITY"
|
||||
echo "SIGNING_IDENTITY=$IDENTITY" >> "$GITHUB_ENV"
|
||||
echo "SIGNING_KEYCHAIN=$KEYCHAIN" >> "$GITHUB_ENV"
|
||||
@@ -1,21 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
|
||||
<plist version="1.0">
|
||||
<dict>
|
||||
<!-- The JVM compiles bytecode to machine code at runtime and executes it
|
||||
from memory it allocated itself. Under the hardened runtime all three
|
||||
of these are required or the app is killed on launch. -->
|
||||
<key>com.apple.security.cs.allow-jit</key>
|
||||
<true/>
|
||||
<key>com.apple.security.cs.allow-unsigned-executable-memory</key>
|
||||
<true/>
|
||||
<!-- jpackage bundles JavaFX native libraries that are signed with our own
|
||||
identity rather than Apple's, and the JVM dlopen()s them at runtime. -->
|
||||
<key>com.apple.security.cs.disable-library-validation</key>
|
||||
<true/>
|
||||
|
||||
<!-- KST4Contest talks to the ON4KST chat servers. -->
|
||||
<key>com.apple.security.network.client</key>
|
||||
<true/>
|
||||
</dict>
|
||||
</plist>
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
<groupId>de.x08</groupId>
|
||||
<artifactId>praktiKST</artifactId>
|
||||
<version>1.42.0-nightly</version>
|
||||
<version>1.41.0-nightly</version>
|
||||
|
||||
<name>praktiKST</name>
|
||||
|
||||
@@ -24,12 +24,12 @@
|
||||
<launcher>${project.artifactId}</launcher>
|
||||
<appName>${project.artifactId}</appName>
|
||||
<main.class>kst4contest.view.Kst4ContestApplication</main.class>
|
||||
<java.version>21</java.version>
|
||||
<java.version>17</java.version>
|
||||
<required.maven.version>3.6.3</required.maven.version>
|
||||
<jar.filename>${project.artifactId}-${project.version}</jar.filename>
|
||||
|
||||
<!-- Dependency versions -->
|
||||
<javafx.version>21.0.5</javafx.version>
|
||||
<javafx.version>19.0.2.1</javafx.version>
|
||||
<jetbrains.annotations.version>24.0.1</jetbrains.annotations.version>
|
||||
<junit.version>5.10.1</junit.version>
|
||||
<lombok.version>1.18.44</lombok.version>
|
||||
@@ -50,13 +50,12 @@
|
||||
<maven.wrapper.plugin>3.2.0</maven.wrapper.plugin>
|
||||
<moditect.maven.plugin>1.0.0.RC2</moditect.maven.plugin>
|
||||
<jpackage.maven.plugin>0.1.3</jpackage.maven.plugin>
|
||||
<maven.pmd.version>3.28.0</maven.pmd.version>
|
||||
<pmd.version>7.17.0</pmd.version>
|
||||
<maven.pmd.version>3.21.2</maven.pmd.version>
|
||||
<pmd.version>6.55.0</pmd.version>
|
||||
<codehaus.version.plugin>2.16.1</codehaus.version.plugin>
|
||||
<javafx.maven.plugin>0.0.8</javafx.maven.plugin>
|
||||
<spotbugs.maven.plugin>4.9.8.2</spotbugs.maven.plugin>
|
||||
<spotbugs.version>4.9.8</spotbugs.version>
|
||||
<exec.maven.plugin>3.1.0</exec.maven.plugin>
|
||||
|
||||
<!-- other properties -->
|
||||
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
|
||||
@@ -94,13 +93,6 @@
|
||||
<version>${javafx.version}</version>
|
||||
</dependency>
|
||||
|
||||
<!-- JLayer: pure-Java MP3 decoder, used instead of JavaFX Media for Flatpak audio compatibility -->
|
||||
<dependency>
|
||||
<groupId>javazoom</groupId>
|
||||
<artifactId>jlayer</artifactId>
|
||||
<version>1.0.1</version>
|
||||
</dependency>
|
||||
|
||||
<!-- SQLite -->
|
||||
<dependency>
|
||||
<groupId>org.xerial</groupId>
|
||||
@@ -151,32 +143,20 @@
|
||||
<version>${jetbrains.annotations.version}</version>
|
||||
<scope>compile</scope>
|
||||
</dependency>
|
||||
|
||||
<!--
|
||||
<dependency>
|
||||
<groupId>org.junit.jupiter</groupId>
|
||||
<artifactId>junit-jupiter-api</artifactId>
|
||||
<version>${junit.version}</version>
|
||||
<scope>compile</scope>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.mockito</groupId>
|
||||
<artifactId>mockito-core</artifactId>
|
||||
<version>5.17.0</version>
|
||||
<scope>compile</scope>
|
||||
<groupId>xml-apis</groupId>
|
||||
<artifactId>xml-apis</artifactId>
|
||||
<version>2.0.2</version>
|
||||
</dependency>
|
||||
|
||||
<!--
|
||||
<dependency>
|
||||
<groupId>xml-apis</groupId>
|
||||
<artifactId>xml-apis</artifactId>
|
||||
<version>2.0.2</version>
|
||||
</dependency>
|
||||
|
||||
<dependency>
|
||||
<groupId>javax.xml.parsers</groupId>
|
||||
<artifactId>jaxp-api</artifactId>
|
||||
<version>1.4.5</version>
|
||||
</dependency>
|
||||
-->
|
||||
<dependency>
|
||||
<groupId>javax.xml.parsers</groupId>
|
||||
<artifactId>jaxp-api</artifactId>
|
||||
<version>1.4.5</version>
|
||||
</dependency>
|
||||
-->
|
||||
|
||||
</dependencies>
|
||||
|
||||
@@ -209,36 +189,6 @@
|
||||
</executions>
|
||||
</plugin>
|
||||
|
||||
<!--
|
||||
Fails the build whenever the jpackage module list below drifts
|
||||
from the requires clauses in src/main/java/module-info.java.
|
||||
This is bound to validate rather than to a workflow trigger so
|
||||
it also fires on direct pushes to main, on local builds and in
|
||||
the AUR PKGBUILDs, which never run the pull request check.
|
||||
-->
|
||||
<plugin>
|
||||
<groupId>org.codehaus.mojo</groupId>
|
||||
<artifactId>exec-maven-plugin</artifactId>
|
||||
<version>${exec.maven.plugin}</version>
|
||||
<executions>
|
||||
<execution>
|
||||
<id>verify-packaging-module-list</id>
|
||||
<phase>validate</phase>
|
||||
<goals>
|
||||
<goal>exec</goal>
|
||||
</goals>
|
||||
<configuration>
|
||||
<executable>${java.home}/bin/java</executable>
|
||||
<workingDirectory>${project.basedir}</workingDirectory>
|
||||
<arguments>
|
||||
<argument>packaging/AddModules.java</argument>
|
||||
<argument>--verify-pom</argument>
|
||||
</arguments>
|
||||
</configuration>
|
||||
</execution>
|
||||
</executions>
|
||||
</plugin>
|
||||
|
||||
<plugin>
|
||||
<groupId>org.apache.maven.plugins</groupId>
|
||||
<artifactId>maven-compiler-plugin</artifactId>
|
||||
@@ -297,15 +247,6 @@
|
||||
<version>${maven.surfire.plugin}</version>
|
||||
<configuration>
|
||||
<testFailureIgnore>true</testFailureIgnore>
|
||||
<!--
|
||||
Without this, Surefire's automatic module-path detection splits the
|
||||
JUnit Platform jars across classpath and module-path inconsistently
|
||||
(module org.junit.platform.commons ends up loaded while a class from
|
||||
junit-platform-engine stays in the unnamed module), which fails with
|
||||
an IllegalAccessError before any test can run. The project itself has
|
||||
no module-info.java, so plain classpath execution is correct here.
|
||||
-->
|
||||
<useModulePath>false</useModulePath>
|
||||
</configuration>
|
||||
</plugin>
|
||||
|
||||
@@ -339,7 +280,30 @@
|
||||
<groupId>org.apache.maven.plugins</groupId>
|
||||
<artifactId>maven-pmd-plugin</artifactId>
|
||||
<version>${maven.pmd.version}</version>
|
||||
<dependencies>
|
||||
<dependency>
|
||||
<groupId>net.sourceforge.pmd</groupId>
|
||||
<artifactId>pmd-core</artifactId>
|
||||
<version>${pmd.version}</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>net.sourceforge.pmd</groupId>
|
||||
<artifactId>pmd-java</artifactId>
|
||||
<version>${pmd.version}</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>net.sourceforge.pmd</groupId>
|
||||
<artifactId>pmd-javascript</artifactId>
|
||||
<version>${pmd.version}</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>net.sourceforge.pmd</groupId>
|
||||
<artifactId>pmd-jsp</artifactId>
|
||||
<version>${pmd.version}</version>
|
||||
</dependency>
|
||||
</dependencies>
|
||||
<configuration>
|
||||
<sourceEncoding>${project.build.sourceEncoding}</sourceEncoding>
|
||||
<minimumTokens>100</minimumTokens>
|
||||
<targetJdk>${java.version}</targetJdk>
|
||||
<linkXRef>false</linkXRef>
|
||||
@@ -467,26 +431,12 @@
|
||||
</dependencyset>
|
||||
</dependencysets>
|
||||
</modulepath>
|
||||
<!--
|
||||
Keep in sync with the requires clauses in
|
||||
src/main/java/module-info.java. The packaging
|
||||
scripts derive this list automatically via
|
||||
packaging/AddModules.java, and the PR check
|
||||
runs that helper in its pom verification mode
|
||||
so this block cannot drift unnoticed.
|
||||
-->
|
||||
<addmodules>
|
||||
<addmodule>java.desktop</addmodule>
|
||||
<addmodule>java.net.http</addmodule>
|
||||
<addmodule>java.sql</addmodule>
|
||||
<addmodule>javafx.controls</addmodule>
|
||||
<addmodule>javafx.graphics</addmodule>
|
||||
<addmodule>javafx.fxml</addmodule>
|
||||
<addmodule>javafx.media</addmodule>
|
||||
<addmodule>javafx.web</addmodule>
|
||||
<addmodule>jdk.crypto.ec</addmodule>
|
||||
<addmodule>jdk.jsobject</addmodule>
|
||||
<addmodule>jdk.net</addmodule>
|
||||
<addmodule>jdk.xml.dom</addmodule>
|
||||
<addmodule>java.sql</addmodule>
|
||||
</addmodules>
|
||||
<mainclass>${main.class}</mainclass>
|
||||
<input>${project.build.directory}/modules</input>
|
||||
|
||||
@@ -18,18 +18,11 @@ public class ApplicationConstants {
|
||||
public static final String APPLICATION_NAME = "praktiKST";
|
||||
|
||||
/**
|
||||
* Version shown to the user and used for semantic version comparison.
|
||||
* Name of file to store preferences in.
|
||||
*/
|
||||
public static final String APPLICATION_CURRENT_VERSION = "1.42";
|
||||
public static final double APPLICATION_CURRENTVERSIONNUMBER = 1.41;
|
||||
|
||||
/**
|
||||
* Legacy numeric representation used only while older update feeds and
|
||||
* application versions still exist.
|
||||
*/
|
||||
@Deprecated
|
||||
public static final double APPLICATION_CURRENTVERSIONNUMBER = 1.42;
|
||||
|
||||
public static final String VERSIONINFOURLFORUPDATES_KST4CONTEST = "https://kst4contest.hamradioonline.de/kst4ContestVersionInfo.xml";
|
||||
public static final String VERSIONINFOURLFORUPDATES_KST4CONTEST = "https://do5amf.funkerportal.de/kst4ContestVersionInfo.xml";
|
||||
public static final String VERSIONINFDOWNLOADEDLOCALFILE = "kst4ContestVersionInfo.xml";
|
||||
|
||||
public static final String STYLECSSFILE_DEFAULT_DAYLIGHT = "KST4ContestDefaultDay.css";
|
||||
@@ -43,26 +36,9 @@ public class ApplicationConstants {
|
||||
|
||||
public static final String DISCONNECT_RDR_POISONPILL = "UNKNOWN: KST4C KILL POISONPILL_KILLTHREAD=: " + sessionRuntimeUniqueId; //whereever a (blocking) udp or tcp reader in an infinite loop gets this message, it will break this loop
|
||||
|
||||
public static final String AUTOANSWER_PREFIX = "[KST4C Automsg]"; // hard-coded marker (user cannot remove it)
|
||||
public static final String AUTOANSWER_PREFIX = "[KST4C Automsg] "; // hard-coded marker (user can't remove it)
|
||||
|
||||
/**
|
||||
* UI message retention limits.
|
||||
*
|
||||
* The global chat message list is the backing list for several FilteredLists
|
||||
* and TableViews. It must not grow without limit during long contest runs.
|
||||
*
|
||||
* The list is kept in newest-first order:
|
||||
* index 0 = newest message
|
||||
* last index = oldest message
|
||||
*/
|
||||
public static final int CHAT_MESSAGE_STORE_MAX_SIZE = 30000;
|
||||
public static final int CHAT_MESSAGE_STORE_TRIM_TO_SIZE = 25000;
|
||||
|
||||
/**
|
||||
* DXCluster table retention limits.
|
||||
*/
|
||||
public static final int CLUSTER_MESSAGE_STORE_MAX_SIZE = 10000;
|
||||
public static final int CLUSTER_MESSAGE_STORE_TRIM_TO_SIZE = 8000;
|
||||
|
||||
/**
|
||||
* generates a unique runtime id per session. Its used to feed the poison pill in order to kill only this one and
|
||||
|
||||
+103
-271
@@ -1,315 +1,147 @@
|
||||
package kst4contest.controller;
|
||||
|
||||
|
||||
import java.io.IOException;
|
||||
import java.net.DatagramPacket;
|
||||
import java.net.DatagramSocket;
|
||||
import java.net.InetAddress;
|
||||
import java.nio.charset.StandardCharsets;
|
||||
import java.util.ArrayList;
|
||||
import java.util.LinkedHashSet;
|
||||
import java.util.List;
|
||||
import java.util.Locale;
|
||||
import java.util.Set;
|
||||
import java.net.NoRouteToHostException;
|
||||
import java.net.SocketException;
|
||||
import java.net.UnknownHostException;
|
||||
import java.util.TimerTask;
|
||||
import java.util.logging.Level;
|
||||
import java.util.logging.Logger;
|
||||
|
||||
import kst4contest.model.Band;
|
||||
import javafx.collections.ObservableList;
|
||||
import kst4contest.locatorUtils.Location;
|
||||
import kst4contest.model.ChatMember;
|
||||
|
||||
|
||||
/**
|
||||
* Sends periodical path requests and an AirScout watchlist for the currently
|
||||
* active ON4KST stations.
|
||||
*/
|
||||
public class AirScoutPeriodicalAPReflectionInquirerTask extends TimerTask {
|
||||
|
||||
private static final Logger LOGGER = Logger.getLogger(
|
||||
AirScoutPeriodicalAPReflectionInquirerTask.class.getName()
|
||||
);
|
||||
private ChatController client;
|
||||
|
||||
private static final String BROADCAST_ADDRESS = "255.255.255.255";
|
||||
public AirScoutPeriodicalAPReflectionInquirerTask(ChatController client) {
|
||||
|
||||
|
||||
|
||||
private final ChatController client;
|
||||
|
||||
/*
|
||||
* ASWATCHLIST is sent as one common list. Remember one syntactically valid
|
||||
* AirScout band value so an empty list can still be sent on a later cycle
|
||||
* to remove stations which are no longer active.
|
||||
*/
|
||||
private String lastWatchListBandValue;
|
||||
|
||||
public AirScoutPeriodicalAPReflectionInquirerTask(
|
||||
ChatController client
|
||||
) {
|
||||
this.client = client;
|
||||
|
||||
}
|
||||
|
||||
@Override
|
||||
public void run() {
|
||||
Thread.currentThread().setName(
|
||||
"AirscoutPeriodicalReflectionInquirerTask"
|
||||
);
|
||||
|
||||
/*
|
||||
* Keep the scheduled task installed so that AirScout can be enabled at
|
||||
* runtime, but do not send anything while the integration is disabled.
|
||||
Thread.currentThread().setName("AirscoutPeriodicalReflectionInquirierTask");
|
||||
|
||||
String KSTClientsNameForQuery = this.client.getChatPreferences().getAirScout_asClientNameString();
|
||||
String ASServerNameStringForAnswer = this.client.getChatPreferences().getAirScout_asServerNameString();
|
||||
|
||||
//TODO: Manage prefixes kst and as via preferences file and instance
|
||||
//TODO: Check if locator is changeable via the preferences object, need to be correct if it changes
|
||||
DatagramSocket dsocket;
|
||||
|
||||
// String prefix_asSetpath ="ASSETPATH: \"KST\" \"AS\" "; //working original
|
||||
// String prefix_asWatchList = "ASWATCHLIST: \"KST\" \"AS\" "; //working original
|
||||
|
||||
String prefix_asSetpath ="ASSETPATH: \"" + this.client.getChatPreferences().getAirScout_asClientNameString() + "\" \"" + this.client.getChatPreferences().getAirScout_asServerNameString() + "\" ";
|
||||
String prefix_asWatchList = "ASWATCHLIST: \""+ this.client.getChatPreferences().getAirScout_asClientNameString()+ "\" \"" + this.client.getChatPreferences().getAirScout_asServerNameString() + "\" ";
|
||||
|
||||
String bandString = "1440000"; //TODO: this must variable in case of higher bands! ... default: 1440000
|
||||
// String myCallAndMyLocString = this.client.getChatPreferences().getStn_loginCallSign() + "," + this.client.getChatPreferences().getStn_loginLocatorMainCat(); //before fix 1.266
|
||||
|
||||
|
||||
String ownCallSign = this.client.getChatPreferences().getStn_loginCallSign();
|
||||
try {
|
||||
if (this.client.getChatPreferences().getStn_loginCallSign().contains("-")) {
|
||||
ownCallSign = this.client.getChatPreferences().getStn_loginCallSign().split("-")[0];
|
||||
} else {
|
||||
ownCallSign = this.client.getChatPreferences().getStn_loginCallSign();
|
||||
}
|
||||
} catch (Exception e) {
|
||||
System.out.println("[ASPERIODICAL, Error]: " + e.getMessage());
|
||||
}
|
||||
String myCallAndMyLocString = ownCallSign + "," + this.client.getChatPreferences().getStn_loginLocatorMainCat(); //bugfix, Airscout do not process 9A1W-2 but 9A1W like formatted calls
|
||||
|
||||
|
||||
String suffix = ""; //"FOREIGNCALL,FOREIGNLOC " -- dont forget the space at the end!!!
|
||||
String asWatchListString = prefix_asWatchList + bandString + "," + myCallAndMyLocString;
|
||||
String asWatchListStringSuffix = asWatchListString;
|
||||
|
||||
String host = "255.255.255.255";
|
||||
// int port = 9872;
|
||||
|
||||
int port = client.getChatPreferences().getAirScout_asCommunicationPort();
|
||||
// byte[] message = "ASSETPATH: \"KST\" \"AS\" 1440000,DO5AMF,JN49GL,OK1MZM,JN89IW ".getBytes(); Original, ging
|
||||
InetAddress address;
|
||||
|
||||
|
||||
/**
|
||||
* Iterate over chatmemberlist and asking airscout for plane reflection information
|
||||
* To avoid a concurrentmodifyexception, we have to convert the original list to an array at first
|
||||
* since the iterator brakes if the list changing during the iteration time
|
||||
*/
|
||||
if (!client.getChatPreferences().isAirScout_asUDPListenerEnabled()) {
|
||||
return;
|
||||
}
|
||||
ObservableList<ChatMember> praktiKSTActiveUserList = this.client.getLst_chatMemberList();
|
||||
|
||||
String clientIdentifier =
|
||||
client.getChatPreferences().getAirScout_asClientNameString();
|
||||
String serverIdentifier =
|
||||
client.getChatPreferences().getAirScout_asServerNameString();
|
||||
String ownCallSign = normalizeOwnCallSign(
|
||||
client.getChatPreferences().getStn_loginCallSign()
|
||||
);
|
||||
String ownLocator =
|
||||
client.getChatPreferences().getStn_loginLocatorMainCat();
|
||||
|
||||
if (ownCallSign == null
|
||||
|| ownCallSign.isBlank()
|
||||
|| ownLocator == null
|
||||
|| ownLocator.isBlank()) {
|
||||
LOGGER.warning(
|
||||
"AirScout queries were skipped because the own callsign "
|
||||
+ "or locator is missing."
|
||||
);
|
||||
return;
|
||||
}
|
||||
ChatMember[] ary_threadSafeChatMemberArray = new ChatMember[praktiKSTActiveUserList.size()];
|
||||
praktiKSTActiveUserList.toArray(ary_threadSafeChatMemberArray);
|
||||
|
||||
String setPathPrefix =
|
||||
"ASSETPATH: \"" + clientIdentifier
|
||||
+ "\" \"" + serverIdentifier + "\" ";
|
||||
for (ChatMember i : ary_threadSafeChatMemberArray) {
|
||||
|
||||
String watchListPrefix =
|
||||
"ASWATCHLIST: \"" + clientIdentifier
|
||||
+ "\" \"" + serverIdentifier + "\" ";
|
||||
if (i.getQrb() < this.client.getChatPreferences().getStn_maxQRBDefault())
|
||||
//Here: check if maximum distance to the chatmember is reached, only ask AS if distance is lower!
|
||||
//this counts for AS request and Aswatchlist
|
||||
{
|
||||
suffix = i.getCallSign() + "," + i.getQra() + " ";
|
||||
|
||||
String ownStation = ownCallSign + "," + ownLocator;
|
||||
List<ChatMember> activeMembers = client.snapshotChatMembers();
|
||||
List<String> watchListTargets = new ArrayList<>();
|
||||
Set<String> processedCallsigns = new LinkedHashSet<>();
|
||||
String watchListBandValue = null;
|
||||
int port = client.getChatPreferences()
|
||||
.getAirScout_asCommunicationPort();
|
||||
String queryStringToAirScout = "";
|
||||
|
||||
try (
|
||||
DatagramSocket socket = new DatagramSocket()
|
||||
) {
|
||||
socket.setBroadcast(true);
|
||||
InetAddress broadcastAddress =
|
||||
InetAddress.getByName(BROADCAST_ADDRESS);
|
||||
queryStringToAirScout += prefix_asSetpath + bandString + "," + myCallAndMyLocString + "," + suffix;
|
||||
|
||||
for (ChatMember member : activeMembers) {
|
||||
if (!isUsableAirScoutTarget(member)) {
|
||||
continue;
|
||||
byte[] queryStringToAirScoutMSG = queryStringToAirScout.getBytes();
|
||||
|
||||
try {
|
||||
address = InetAddress.getByName("255.255.255.255");
|
||||
DatagramPacket packet = new DatagramPacket(queryStringToAirScoutMSG, queryStringToAirScoutMSG.length, address, port);
|
||||
dsocket = new DatagramSocket();
|
||||
dsocket.setBroadcast(true);
|
||||
dsocket.send(packet);
|
||||
dsocket.close();
|
||||
} catch (UnknownHostException e1) {
|
||||
e1.printStackTrace();
|
||||
} catch (NoRouteToHostException e) {
|
||||
e.printStackTrace();
|
||||
} catch (SocketException e) {
|
||||
e.printStackTrace();
|
||||
} catch (IOException e) {
|
||||
e.printStackTrace();
|
||||
}
|
||||
// System.out.println("[ASUDPTask, info:] sent query " + queryStringToAirScout);
|
||||
|
||||
if (member.getQrb() == null
|
||||
|| member.getQrb()
|
||||
>= client.getChatPreferences().getStn_maxQRBDefault()) {
|
||||
continue;
|
||||
}
|
||||
|
||||
String callsignKey = member.getCallSignRaw();
|
||||
if (callsignKey == null || callsignKey.isBlank()) {
|
||||
callsignKey = member.getCallSign();
|
||||
}
|
||||
if (callsignKey == null
|
||||
|| !processedCallsigns.add(
|
||||
callsignKey.trim().toUpperCase(Locale.ROOT)
|
||||
)) {
|
||||
continue;
|
||||
}
|
||||
|
||||
/*
|
||||
* The resolver may deliberately return an exact QRG. AirScout must
|
||||
* only see a canonical protocol band value such as 4320000.
|
||||
*/
|
||||
String bandValue = canonicalizeAirScoutBandValue(
|
||||
client.resolveAirScoutBandValue(member)
|
||||
);
|
||||
if (bandValue == null) {
|
||||
continue;
|
||||
}
|
||||
|
||||
if (watchListBandValue == null) {
|
||||
watchListBandValue = bandValue;
|
||||
}
|
||||
|
||||
String targetStation =
|
||||
member.getCallSign() + "," + member.getQra();
|
||||
|
||||
String pathQuery =
|
||||
setPathPrefix
|
||||
+ bandValue
|
||||
+ ","
|
||||
+ ownStation
|
||||
+ ","
|
||||
+ targetStation
|
||||
+ " ";
|
||||
|
||||
sendPacket(
|
||||
socket,
|
||||
broadcastAddress,
|
||||
port,
|
||||
pathQuery
|
||||
);
|
||||
|
||||
watchListTargets.add(targetStation);
|
||||
asWatchListStringSuffix += "," + i.getCallSign() + "," + i.getQra();
|
||||
}
|
||||
|
||||
/*
|
||||
* AirScout keeps one watchlist per client/server pair. Do not send
|
||||
* separate lists for the individual station bands because a later
|
||||
* list would replace stations from an earlier one.
|
||||
*
|
||||
* If there are no targets in this cycle, reuse the last valid band
|
||||
* token and send an empty list so AirScout can clear stale entries.
|
||||
*/
|
||||
if (watchListBandValue == null) {
|
||||
watchListBandValue = lastWatchListBandValue;
|
||||
}
|
||||
|
||||
if (watchListBandValue != null) {
|
||||
StringBuilder watchListMessage = new StringBuilder(
|
||||
watchListPrefix
|
||||
+ watchListBandValue
|
||||
+ ","
|
||||
+ ownStation
|
||||
);
|
||||
|
||||
for (String targetStation : watchListTargets) {
|
||||
watchListMessage
|
||||
.append(",")
|
||||
.append(targetStation);
|
||||
}
|
||||
|
||||
watchListMessage.append(" ");
|
||||
|
||||
sendPacket(
|
||||
socket,
|
||||
broadcastAddress,
|
||||
port,
|
||||
watchListMessage.toString()
|
||||
);
|
||||
|
||||
lastWatchListBandValue = watchListBandValue;
|
||||
}
|
||||
|
||||
} catch (IOException exception) {
|
||||
LOGGER.log(
|
||||
Level.WARNING,
|
||||
"Could not send the periodical AirScout queries.",
|
||||
exception
|
||||
);
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
|
||||
/**
|
||||
* Converts a frequency-like value returned by the station resolver into the
|
||||
* canonical band token expected by the AirScout UDP protocol.
|
||||
*
|
||||
* <p>The internal resolver may keep an exact working frequency for path
|
||||
* analysis. This method removes that precision only at the AirScout protocol
|
||||
* boundary. For example, {@code 4321740} is sent to AirScout as
|
||||
* {@code 4320000}.</p>
|
||||
*
|
||||
* @param resolvedValue frequency-like AirScout value produced by the resolver
|
||||
* @return canonical AirScout band value, or {@code null} if unsupported
|
||||
*/
|
||||
private String canonicalizeAirScoutBandValue(String resolvedValue) {
|
||||
if (resolvedValue == null || resolvedValue.isBlank()) {
|
||||
return null;
|
||||
}
|
||||
|
||||
String normalizedValue = resolvedValue.trim();
|
||||
/**
|
||||
* As next we will set the ASWatchlist. All stations in chat will be watched by airscout causing following code.\n\n
|
||||
* ASWATCHLIST: "KST" "AS" 4320000,DO5AMF,JN49GL,DF9QX,JO42HD,DG2KBC,JN58MI,DJ0PY,JO32MF,DL1YDI,JO42FA,DL6BF,JO32QI,F1NZC,JN15MR,F4TXU,JN23CX,F5GHP,IN96LE,F6HTJ,JN12KQ,G0GGG,IO81VE,G0JCC,IO82MA,G0JDL,JO02SI,G0MBL,JO01QH,G4AEP,IO91MB,G4CLA,IO92JL,G4DCV,IO91OF,G4LOH,IO70JC,G4MKF,IO91HJ,G4TRA,IO81WN,G8GXP,IO93FQ,G8VHI,IO92FM,GW0RHC,IO71UN,HA4ND,JN97MJ,I5/HB9SJV/P,JN52JS,IW2DAL,JN45NN,OK1FPR,JO80CE,OK6M,JN99CR,OV3T,JO46CM,OZ2M,JO65FR,PA0V,JO33II,PA2RU,JO32LT,PA3DOL,JO22MT,PA9R,JO22JK,PE1EVX,JO22MP,S51AT,JN75GW,SM7KOJ,JO66ND,SP9TTG,JO90KW�
|
||||
* The watchlist-String is bult by the for loop which builds the AP queries
|
||||
*/
|
||||
asWatchListStringSuffix += " ";
|
||||
|
||||
if ("off".equalsIgnoreCase(normalizedValue)
|
||||
|| "auto".equalsIgnoreCase(normalizedValue)) {
|
||||
return null;
|
||||
}
|
||||
byte[] queryStringToAirScoutMSG = asWatchListStringSuffix.getBytes();
|
||||
|
||||
final long numericValue;
|
||||
try {
|
||||
numericValue = Long.parseLong(normalizedValue);
|
||||
} catch (NumberFormatException exception) {
|
||||
LOGGER.log(
|
||||
Level.WARNING,
|
||||
"Unsupported AirScout band value: " + resolvedValue,
|
||||
exception
|
||||
);
|
||||
return null;
|
||||
address = InetAddress.getByName("255.255.255.255");
|
||||
DatagramPacket packet = new DatagramPacket(queryStringToAirScoutMSG, queryStringToAirScoutMSG.length, address, port);
|
||||
dsocket = new DatagramSocket();
|
||||
dsocket.setBroadcast(true);
|
||||
dsocket.send(packet);
|
||||
dsocket.close();
|
||||
} catch (IOException e) {
|
||||
e.printStackTrace();
|
||||
}
|
||||
|
||||
double frequencyMHz = numericValue / 10_000.0;
|
||||
Band band = Band.fromFrequency(frequencyMHz);
|
||||
// System.out.println("[ASUDPTask, info:] set watchlist: " + asWatchListStringSuffix);
|
||||
|
||||
if (band == null) {
|
||||
LOGGER.warning(
|
||||
"AirScout query skipped because frequency "
|
||||
+ frequencyMHz
|
||||
+ " MHz does not belong to a supported band."
|
||||
);
|
||||
return null;
|
||||
}
|
||||
|
||||
return band.getPrefix() + "0000";
|
||||
}
|
||||
|
||||
|
||||
/**
|
||||
* Removes the ON4KST login suffix because AirScout expects the actual
|
||||
* station callsign, for example 9A1W instead of 9A1W-2.
|
||||
*
|
||||
* @param callSign configured ON4KST login callsign
|
||||
* @return callsign without an ON4KST login suffix
|
||||
*/
|
||||
private String normalizeOwnCallSign(String callSign) {
|
||||
if (callSign == null) {
|
||||
return null;
|
||||
}
|
||||
|
||||
String normalizedCallSign = callSign.trim();
|
||||
int suffixSeparator = normalizedCallSign.indexOf("-");
|
||||
|
||||
if (suffixSeparator > 0) {
|
||||
return normalizedCallSign.substring(0, suffixSeparator);
|
||||
}
|
||||
|
||||
return normalizedCallSign;
|
||||
}
|
||||
|
||||
private boolean isUsableAirScoutTarget(ChatMember member) {
|
||||
return member != null
|
||||
&& member.getCallSign() != null
|
||||
&& !member.getCallSign().isBlank()
|
||||
&& member.getQra() != null
|
||||
&& !member.getQra().isBlank();
|
||||
}
|
||||
|
||||
private void sendPacket(
|
||||
DatagramSocket socket,
|
||||
InetAddress address,
|
||||
int port,
|
||||
String message
|
||||
) throws IOException {
|
||||
byte[] payload = message.getBytes(StandardCharsets.UTF_8);
|
||||
|
||||
DatagramPacket packet = new DatagramPacket(
|
||||
payload,
|
||||
payload.length,
|
||||
address,
|
||||
port
|
||||
);
|
||||
|
||||
socket.send(packet);
|
||||
}
|
||||
}
|
||||
@@ -1,222 +1,121 @@
|
||||
package kst4contest.controller;
|
||||
|
||||
import java.util.Arrays;
|
||||
import java.util.TimerTask;
|
||||
|
||||
import kst4contest.model.ChatCategory;
|
||||
import kst4contest.model.ChatMessage;
|
||||
import kst4contest.model.ThreadStateMessage;
|
||||
|
||||
/**
|
||||
* Sends the configured public-chat beacons for both active chat categories.
|
||||
* This class is for sending beacons intervalled to the public chat. Gets all
|
||||
* preferences and instances via the Chatpreferences-object of the
|
||||
* Chatcontroller.
|
||||
* <br/><br/>
|
||||
* The task will be runned out of the singleton ChatController instance in an
|
||||
* intervall as specified by the Chatpreferences-instance (typically as
|
||||
* configured in the xml file.
|
||||
*
|
||||
* <p>Both categories deliberately share one timer and therefore the same
|
||||
* interval. Their enable flags and message templates remain independent. Every
|
||||
* run reads the current preferences, resolves global message variables and
|
||||
* sends only the categories which are currently enabled.</p>
|
||||
*
|
||||
* <p>Beacon messages use the regular outbound chat-message pipeline. They are
|
||||
* not assembled as raw ON4KST frames, because that would bypass the common
|
||||
* category, delimiter and message-text validation.</p>
|
||||
* @author prakt
|
||||
*
|
||||
*/
|
||||
public class BeaconTask extends TimerTask {
|
||||
|
||||
private static final String THREAD_NICKNAME = "MyBeacon";
|
||||
private ChatController chatController;
|
||||
private ThreadStatusCallback callBackToController;
|
||||
private String ThreadNickName = "MyBeacon";
|
||||
|
||||
private final ChatController chatController;
|
||||
private final ThreadStatusCallback callbackToController;
|
||||
public BeaconTask(ChatController client, ThreadStatusCallback callback) {
|
||||
this.callBackToController = callback;
|
||||
this.chatController = client;
|
||||
|
||||
/**
|
||||
* Creates one execution of the shared beacon timer.
|
||||
*
|
||||
* @param chatController controller providing preferences and the TX queue
|
||||
* @param callbackToController callback used by the thread-status display
|
||||
*/
|
||||
public BeaconTask(
|
||||
ChatController chatController,
|
||||
ThreadStatusCallback callbackToController
|
||||
) {
|
||||
this.chatController = chatController;
|
||||
this.callbackToController = callbackToController;
|
||||
}
|
||||
|
||||
@Override
|
||||
public void run() {
|
||||
Thread.currentThread().setName("BeaconTask");
|
||||
reportStatus(THREAD_NICKNAME, true, "initialized", false);
|
||||
|
||||
sendMainCategoryBeacon();
|
||||
sendSecondCategoryBeacon();
|
||||
}
|
||||
ThreadStateMessage threadStateMessage = new ThreadStateMessage(this.ThreadNickName, true, "initialized", false);
|
||||
callBackToController.onThreadStatus(ThreadNickName,threadStateMessage);
|
||||
|
||||
/**
|
||||
* Sends the main-category beacon if it is currently enabled.
|
||||
*/
|
||||
private void sendMainCategoryBeacon() {
|
||||
if (!chatController.getChatPreferences()
|
||||
.isBcn_beaconsEnabledMainCat()) {
|
||||
reportStatus(
|
||||
THREAD_NICKNAME + " 1",
|
||||
false,
|
||||
"off",
|
||||
false
|
||||
);
|
||||
return;
|
||||
Thread.currentThread().setName("BeaconTask");
|
||||
|
||||
|
||||
ChatMessage beaconMSG = new ChatMessage();
|
||||
|
||||
String replaceVariables = this.chatController.getChatPreferences().getBcn_beaconTextMainCat();
|
||||
|
||||
replaceVariables = replaceVariables.replaceAll("MYQRG", this.chatController.getChatPreferences().getMYQRGFirstCat().getValue());
|
||||
replaceVariables = replaceVariables.replaceAll("MYCALL", this.chatController.getChatPreferences().getStn_loginCallSign());
|
||||
replaceVariables = replaceVariables.replaceAll("MYLOCATOR", this.chatController.getChatPreferences().getStn_loginLocatorMainCat());
|
||||
replaceVariables = replaceVariables.replaceAll("MYQTF", this.chatController.getChatPreferences().getActualQTF().getValue() + "");
|
||||
replaceVariables = replaceVariables.replaceAll("SECONDQRG", this.chatController.getChatPreferences().getActualQTF().getValue() + "");
|
||||
|
||||
|
||||
beaconMSG.setMessageText(
|
||||
"MSG|" + this.chatController.getChatPreferences().getLoginChatCategoryMain().getCategoryNumber() + "|0|" + replaceVariables + "|0|");
|
||||
beaconMSG.setMessageDirectedToServer(true);
|
||||
|
||||
|
||||
|
||||
|
||||
ChatMessage beaconMSG2 = new ChatMessage();
|
||||
|
||||
String replaceVariables2 = this.chatController.getChatPreferences().getBcn_beaconTextSecondCat();
|
||||
|
||||
replaceVariables2 = replaceVariables2.replaceAll("MYQRG", this.chatController.getChatPreferences().getMYQRGFirstCat().getValue());
|
||||
replaceVariables2 = replaceVariables2.replaceAll("MYCALL", this.chatController.getChatPreferences().getStn_loginCallSign());
|
||||
replaceVariables2 = replaceVariables2.replaceAll("MYLOCATOR", this.chatController.getChatPreferences().getStn_loginLocatorMainCat());
|
||||
replaceVariables2 = replaceVariables2.replaceAll("MYQTF", this.chatController.getChatPreferences().getActualQTF().getValue() + "");
|
||||
replaceVariables2 = replaceVariables2.replaceAll("SECONDQRG", this.chatController.getChatPreferences().getMYQRGSecondCat().getValue() + "");
|
||||
|
||||
|
||||
beaconMSG2.setMessageText(
|
||||
"MSG|" + this.chatController.getChatPreferences().getLoginChatCategorySecond().getCategoryNumber() + "|0|" + replaceVariables + "|0|");
|
||||
beaconMSG2.setMessageDirectedToServer(true);
|
||||
|
||||
|
||||
|
||||
/**
|
||||
* beacon 1st Chatcategory
|
||||
*/
|
||||
if (this.chatController.getChatPreferences().isBcn_beaconsEnabledMainCat() ) {
|
||||
|
||||
System.out.println(new Utils4KST().time_generateCurrentMMDDhhmmTimeString()
|
||||
+ " [BeaconTask, Info]: Sending CQ: " + beaconMSG.getMessageText());
|
||||
this.chatController.getMessageTXBus().add(beaconMSG);
|
||||
|
||||
threadStateMessage = new ThreadStateMessage(this.ThreadNickName + " 1", true, "on", false);
|
||||
callBackToController.onThreadStatus(ThreadNickName,threadStateMessage);
|
||||
|
||||
} else {
|
||||
threadStateMessage = new ThreadStateMessage(this.ThreadNickName + " 1", false, "off", false);
|
||||
callBackToController.onThreadStatus(ThreadNickName,threadStateMessage);
|
||||
}
|
||||
|
||||
ChatMessage beaconMessage = buildBeaconMessage(
|
||||
chatController.getChatPreferences()
|
||||
.getLoginChatCategoryMain(),
|
||||
chatController.getChatPreferences()
|
||||
.getBcn_beaconTextMainCat(),
|
||||
"main category"
|
||||
);
|
||||
/**
|
||||
* beacon 2nd Chatcategory
|
||||
*/
|
||||
if (this.chatController.getChatPreferences().isLoginToSecondChatEnabled()) { //only send if 2nd cat enabled
|
||||
|
||||
if (beaconMessage == null) {
|
||||
reportStatus(
|
||||
THREAD_NICKNAME + " 1",
|
||||
false,
|
||||
"invalid text",
|
||||
true
|
||||
);
|
||||
return;
|
||||
}
|
||||
if (this.chatController.getChatPreferences().isBcn_beaconsEnabledSecondCat()) {
|
||||
|
||||
System.out.println(
|
||||
new Utils4KST().time_generateCurrentMMDDhhmmTimeString()
|
||||
+ " [BeaconTask, Info]: Sending main-category CQ: "
|
||||
+ beaconMessage.getMessageText()
|
||||
);
|
||||
beaconMSG2.setMessageText(
|
||||
"MSG|" + this.chatController.getChatPreferences().getLoginChatCategorySecond().getCategoryNumber() + "|0|" + replaceVariables2 + "|0|");
|
||||
beaconMSG2.setMessageDirectedToServer(true);
|
||||
|
||||
chatController.getMessageTXBus().add(beaconMessage);
|
||||
System.out.println(new Utils4KST().time_generateCurrentMMDDhhmmTimeString()
|
||||
+ " [BeaconTask, Info]: Sending CQ 2nd Cat: " + beaconMSG2.getMessageText());
|
||||
this.chatController.getMessageTXBus().add(beaconMSG2);
|
||||
|
||||
reportStatus(
|
||||
THREAD_NICKNAME + " 1",
|
||||
true,
|
||||
"on",
|
||||
false
|
||||
);
|
||||
}
|
||||
threadStateMessage = new ThreadStateMessage(this.ThreadNickName + " 2", true, "on", false);
|
||||
callBackToController.onThreadStatus(ThreadNickName,threadStateMessage);
|
||||
|
||||
/**
|
||||
* Sends the second-category beacon if the second login and its beacon are
|
||||
* currently enabled.
|
||||
*/
|
||||
private void sendSecondCategoryBeacon() {
|
||||
if (!chatController.getChatPreferences()
|
||||
.isLoginToSecondChatEnabled()
|
||||
|| !chatController.getChatPreferences()
|
||||
.isBcn_beaconsEnabledSecondCat()) {
|
||||
reportStatus(
|
||||
THREAD_NICKNAME + " 2",
|
||||
false,
|
||||
"off",
|
||||
false
|
||||
);
|
||||
return;
|
||||
}
|
||||
|
||||
ChatMessage beaconMessage = buildBeaconMessage(
|
||||
chatController.getChatPreferences()
|
||||
.getLoginChatCategorySecond(),
|
||||
chatController.getChatPreferences()
|
||||
.getBcn_beaconTextSecondCat(),
|
||||
"second category"
|
||||
);
|
||||
|
||||
if (beaconMessage == null) {
|
||||
reportStatus(
|
||||
THREAD_NICKNAME + " 2",
|
||||
false,
|
||||
"invalid text",
|
||||
true
|
||||
);
|
||||
return;
|
||||
}
|
||||
|
||||
System.out.println(
|
||||
new Utils4KST().time_generateCurrentMMDDhhmmTimeString()
|
||||
+ " [BeaconTask, Info]: Sending second-category CQ: "
|
||||
+ beaconMessage.getMessageText()
|
||||
);
|
||||
|
||||
chatController.getMessageTXBus().add(beaconMessage);
|
||||
|
||||
reportStatus(
|
||||
THREAD_NICKNAME + " 2",
|
||||
true,
|
||||
"on",
|
||||
false
|
||||
);
|
||||
}
|
||||
|
||||
/**
|
||||
* Resolves and validates one beacon before placing it in the regular outbound
|
||||
* message queue.
|
||||
*
|
||||
* <p>The returned message contains only the public-chat payload and its chat
|
||||
* category. {@link WriteThread} creates the final ON4KST frame through
|
||||
* {@link On4KstProtocol#chatMessage(int, String)}. This prevents a configurable
|
||||
* beacon text from bypassing the common protocol validation.</p>
|
||||
*
|
||||
* @param category target ON4KST chat category
|
||||
* @param configuredText configured beacon template
|
||||
* @param categoryDescription text used in diagnostic output
|
||||
* @return prepared message, or {@code null} if the category or text is invalid
|
||||
*/
|
||||
private ChatMessage buildBeaconMessage(
|
||||
ChatCategory category,
|
||||
String configuredText,
|
||||
String categoryDescription
|
||||
) {
|
||||
try {
|
||||
if (category == null) {
|
||||
throw new IllegalArgumentException(
|
||||
"No chat category is configured."
|
||||
);
|
||||
} else {
|
||||
threadStateMessage = new ThreadStateMessage(this.ThreadNickName + " 2", false, "off", false);
|
||||
callBackToController.onThreadStatus(ThreadNickName,threadStateMessage);
|
||||
}
|
||||
|
||||
On4KstProtocol.category(category.getCategoryNumber());
|
||||
|
||||
String resolvedText =
|
||||
chatController.resolveAndValidateBeaconText(
|
||||
configuredText
|
||||
);
|
||||
|
||||
ChatMessage beaconMessage = new ChatMessage();
|
||||
beaconMessage.setMessageText(resolvedText);
|
||||
beaconMessage.setChatCategory(category);
|
||||
beaconMessage.setMessageDirectedToServer(false);
|
||||
|
||||
return beaconMessage;
|
||||
} catch (IllegalArgumentException exception) {
|
||||
System.out.println(
|
||||
"[BeaconTask, Warning]: Beacon for "
|
||||
+ categoryDescription
|
||||
+ " was not queued: "
|
||||
+ exception.getMessage()
|
||||
);
|
||||
return null;
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
/**
|
||||
* Forwards one state update to the existing thread-status display.
|
||||
*/
|
||||
private void reportStatus(
|
||||
String threadName,
|
||||
boolean running,
|
||||
String information,
|
||||
boolean criticalState
|
||||
) {
|
||||
ThreadStateMessage stateMessage = new ThreadStateMessage(
|
||||
threadName,
|
||||
running,
|
||||
information,
|
||||
criticalState
|
||||
);
|
||||
callbackToController.onThreadStatus(
|
||||
THREAD_NICKNAME,
|
||||
stateMessage
|
||||
);
|
||||
}
|
||||
}
|
||||
File diff suppressed because it is too large
Load Diff
@@ -14,12 +14,6 @@ import kst4contest.ApplicationConstants;
|
||||
import kst4contest.model.ChatMember;
|
||||
import kst4contest.utils.ApplicationFileUtils;
|
||||
|
||||
import java.util.EnumMap;
|
||||
import java.util.HashSet;
|
||||
import java.util.Set;
|
||||
|
||||
import kst4contest.model.Band;
|
||||
|
||||
public class DBController {
|
||||
|
||||
/**
|
||||
@@ -36,14 +30,14 @@ public class DBController {
|
||||
* Number of milliseconds after which worked/not-QRV data is considered outdated
|
||||
* and therefore automatically reset.
|
||||
*/
|
||||
private static final long WORKED_DATA_EXPIRATION_IN_MILLISECONDS =
|
||||
3L * 24L * 60L * 60L * 1000L;
|
||||
private static final long WORKED_DATA_EXPIRATION_IN_MILLISECONDS = 65L * 60L * 60L * 1000L;
|
||||
|
||||
/**
|
||||
* Database schema version that includes the raw-callsign normalization migration
|
||||
* marker. The marker is stored in SQLite PRAGMA user_version so the expensive
|
||||
* normalization rebuild is executed only once per database file.
|
||||
*/
|
||||
private static final int CURRENT_DATABASE_SCHEMA_VERSION = 14;
|
||||
private static final int CURRENT_DATABASE_SCHEMA_VERSION = 13;
|
||||
|
||||
/**
|
||||
* Minimum interval between two expiration cleanup runs. This avoids repeated full
|
||||
@@ -142,10 +136,8 @@ public class DBController {
|
||||
*/
|
||||
private synchronized void ensureChatMemberTableCompatibility() {
|
||||
createChatMemberTableIfRequired();
|
||||
createWorkedGrossFieldTableIfRequired();
|
||||
versionUpdateOfDBCheckAndChangeV11ToV12();
|
||||
versionUpdateOfDBCheckAndChangeV12ToV13();
|
||||
versionUpdateOfDBCheckAndChangeV13ToV14();
|
||||
|
||||
if (helper_isDatabaseSchemaVersionOlderThanCurrent() || helper_isCallsignNormalizationMigrationRequired()) {
|
||||
normalizeStoredCallsignsToRawCallsigns();
|
||||
@@ -231,8 +223,6 @@ public class DBController {
|
||||
+ "worked3400 BOOLEAN DEFAULT 0, "
|
||||
+ "worked5600 BOOLEAN DEFAULT 0, "
|
||||
+ "worked10G BOOLEAN DEFAULT 0, "
|
||||
+ "worked50 BOOLEAN DEFAULT 0, "
|
||||
+ "worked70 BOOLEAN DEFAULT 0, "
|
||||
+ "notQRV144 BOOLEAN DEFAULT 0, "
|
||||
+ "notQRV432 BOOLEAN DEFAULT 0, "
|
||||
+ "notQRV1240 BOOLEAN DEFAULT 0, "
|
||||
@@ -240,8 +230,6 @@ public class DBController {
|
||||
+ "notQRV3400 BOOLEAN DEFAULT 0, "
|
||||
+ "notQRV5600 BOOLEAN DEFAULT 0, "
|
||||
+ "notQRV10G BOOLEAN DEFAULT 0, "
|
||||
+ "notQRV50 BOOLEAN DEFAULT 0, "
|
||||
+ "notQRV70 BOOLEAN DEFAULT 0, "
|
||||
+ "lastFlagsChangeEpochMs INTEGER DEFAULT 0"
|
||||
+ ");";
|
||||
|
||||
@@ -252,30 +240,6 @@ public class DBController {
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Creates the persistent gross-field table used by the new-locator filter.
|
||||
* The primary key is band + gross field because the filter only needs to know
|
||||
* whether a large locator square has already been worked on a band.
|
||||
*/
|
||||
private synchronized void createWorkedGrossFieldTableIfRequired() {
|
||||
|
||||
String createTableSql =
|
||||
"CREATE TABLE IF NOT EXISTS WorkedGrossField ("
|
||||
+ "band TEXT NOT NULL, "
|
||||
+ "grossField TEXT NOT NULL, "
|
||||
+ "locator TEXT, "
|
||||
+ "callsign TEXT, "
|
||||
+ "source TEXT, "
|
||||
+ "lastWorkedEpochMs INTEGER NOT NULL, "
|
||||
+ "PRIMARY KEY (band, grossField)"
|
||||
+ ");";
|
||||
|
||||
try (Statement statement = connection.createStatement()) {
|
||||
statement.executeUpdate(createTableSql);
|
||||
} catch (SQLException e) {
|
||||
throw new RuntimeException("[DBH, ERROR:] Could not create WorkedGrossField table", e);
|
||||
}
|
||||
}
|
||||
/**
|
||||
* Updates old v1.1 databases to the v1.2 schema by adding the not-QRV fields if
|
||||
* they are missing.
|
||||
@@ -308,22 +272,6 @@ public class DBController {
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Updates old v1.3 databases to the v1.4 schema by adding the worked/not-QRV
|
||||
* columns for the 50 MHz and 70 MHz bands if they are missing.
|
||||
*/
|
||||
public synchronized void versionUpdateOfDBCheckAndChangeV13ToV14() {
|
||||
|
||||
try {
|
||||
ensureColumnExists("ChatMember", "worked50", "BOOLEAN DEFAULT 0");
|
||||
ensureColumnExists("ChatMember", "worked70", "BOOLEAN DEFAULT 0");
|
||||
ensureColumnExists("ChatMember", "notQRV50", "BOOLEAN DEFAULT 0");
|
||||
ensureColumnExists("ChatMember", "notQRV70", "BOOLEAN DEFAULT 0");
|
||||
} catch (SQLException e) {
|
||||
throw new RuntimeException("[DBH, ERROR:] Could not migrate database from v1.3 to v1.4", e);
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Adds a missing column to an existing table. This method is used for safe schema
|
||||
* upgrades on customer systems which still contain older database files.
|
||||
@@ -473,11 +421,7 @@ public class DBController {
|
||||
targetChatMember.setWorked3400(targetChatMember.isWorked3400() || sourceChatMember.isWorked3400());
|
||||
targetChatMember.setWorked5600(targetChatMember.isWorked5600() || sourceChatMember.isWorked5600());
|
||||
targetChatMember.setWorked10G(targetChatMember.isWorked10G() || sourceChatMember.isWorked10G());
|
||||
targetChatMember.setWorked50(targetChatMember.isWorked50() || sourceChatMember.isWorked50());
|
||||
targetChatMember.setWorked70(targetChatMember.isWorked70() || sourceChatMember.isWorked70());
|
||||
|
||||
targetChatMember.setQrv50(targetChatMember.isQrv50() && sourceChatMember.isQrv50());
|
||||
targetChatMember.setQrv70(targetChatMember.isQrv70() && sourceChatMember.isQrv70());
|
||||
targetChatMember.setQrv144(targetChatMember.isQrv144() && sourceChatMember.isQrv144());
|
||||
targetChatMember.setQrv432(targetChatMember.isQrv432() && sourceChatMember.isQrv432());
|
||||
targetChatMember.setQrv1240(targetChatMember.isQrv1240() && sourceChatMember.isQrv1240());
|
||||
@@ -516,8 +460,6 @@ public class DBController {
|
||||
+ "worked3400 = 0, "
|
||||
+ "worked5600 = 0, "
|
||||
+ "worked10G = 0, "
|
||||
+ "worked50 = 0, "
|
||||
+ "worked70 = 0, "
|
||||
+ "notQRV144 = 0, "
|
||||
+ "notQRV432 = 0, "
|
||||
+ "notQRV1240 = 0, "
|
||||
@@ -525,8 +467,6 @@ public class DBController {
|
||||
+ "notQRV3400 = 0, "
|
||||
+ "notQRV5600 = 0, "
|
||||
+ "notQRV10G = 0, "
|
||||
+ "notQRV50 = 0, "
|
||||
+ "notQRV70 = 0, "
|
||||
+ "lastFlagsChangeEpochMs = 0 "
|
||||
+ "WHERE lastFlagsChangeEpochMs > 0 AND lastFlagsChangeEpochMs < ?;";
|
||||
|
||||
@@ -537,15 +477,7 @@ public class DBController {
|
||||
} catch (SQLException e) {
|
||||
throw new RuntimeException("[DBH, ERROR:] Could not reset expired worked data", e);
|
||||
}
|
||||
|
||||
try (PreparedStatement deleteGrossFieldsStatement = connection.prepareStatement(
|
||||
"DELETE FROM WorkedGrossField WHERE lastWorkedEpochMs > 0 AND lastWorkedEpochMs < ?;")) {
|
||||
deleteGrossFieldsStatement.setLong(1, expirationThresholdEpochMs);
|
||||
deleteGrossFieldsStatement.executeUpdate();
|
||||
} catch (SQLException e) {
|
||||
throw new RuntimeException(e);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Stores a chatmember with its metadata in the database. The unique key is always
|
||||
@@ -563,9 +495,9 @@ public class DBController {
|
||||
|
||||
String insertOrUpdateSql =
|
||||
"INSERT INTO ChatMember ("
|
||||
+ "callsign, qra, name, lastActivityDateTime, worked, worked144, worked432, worked1240, worked2300, worked3400, worked5600, worked10G, worked50, worked70, "
|
||||
+ "notQRV144, notQRV432, notQRV1240, notQRV2300, notQRV3400, notQRV5600, notQRV10G, notQRV50, notQRV70, lastFlagsChangeEpochMs"
|
||||
+ ") VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) "
|
||||
+ "callsign, qra, name, lastActivityDateTime, worked, worked144, worked432, worked1240, worked2300, worked3400, worked5600, worked10G, "
|
||||
+ "notQRV144, notQRV432, notQRV1240, notQRV2300, notQRV3400, notQRV5600, notQRV10G, lastFlagsChangeEpochMs"
|
||||
+ ") VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) "
|
||||
+ "ON CONFLICT(callsign) DO UPDATE SET "
|
||||
+ "qra = excluded.qra, "
|
||||
+ "name = excluded.name, "
|
||||
@@ -586,18 +518,14 @@ public class DBController {
|
||||
preparedStatement.setInt(10, helper_booleanIntConverter(chatMemberToStore.isWorked3400()));
|
||||
preparedStatement.setInt(11, helper_booleanIntConverter(chatMemberToStore.isWorked5600()));
|
||||
preparedStatement.setInt(12, helper_booleanIntConverter(chatMemberToStore.isWorked10G()));
|
||||
preparedStatement.setInt(13, helper_booleanIntConverter(chatMemberToStore.isWorked50()));
|
||||
preparedStatement.setInt(14, helper_booleanIntConverter(chatMemberToStore.isWorked70()));
|
||||
preparedStatement.setInt(15, helper_booleanIntConverter(!chatMemberToStore.isQrv144()));
|
||||
preparedStatement.setInt(16, helper_booleanIntConverter(!chatMemberToStore.isQrv432()));
|
||||
preparedStatement.setInt(17, helper_booleanIntConverter(!chatMemberToStore.isQrv1240()));
|
||||
preparedStatement.setInt(18, helper_booleanIntConverter(!chatMemberToStore.isQrv2300()));
|
||||
preparedStatement.setInt(19, helper_booleanIntConverter(!chatMemberToStore.isQrv3400()));
|
||||
preparedStatement.setInt(20, helper_booleanIntConverter(!chatMemberToStore.isQrv5600()));
|
||||
preparedStatement.setInt(21, helper_booleanIntConverter(!chatMemberToStore.isQrv10G()));
|
||||
preparedStatement.setInt(22, helper_booleanIntConverter(!chatMemberToStore.isQrv50()));
|
||||
preparedStatement.setInt(23, helper_booleanIntConverter(!chatMemberToStore.isQrv70()));
|
||||
preparedStatement.setLong(24, resolvedLastFlagsChangeEpochMs);
|
||||
preparedStatement.setInt(13, helper_booleanIntConverter(!chatMemberToStore.isQrv144()));
|
||||
preparedStatement.setInt(14, helper_booleanIntConverter(!chatMemberToStore.isQrv432()));
|
||||
preparedStatement.setInt(15, helper_booleanIntConverter(!chatMemberToStore.isQrv1240()));
|
||||
preparedStatement.setInt(16, helper_booleanIntConverter(!chatMemberToStore.isQrv2300()));
|
||||
preparedStatement.setInt(17, helper_booleanIntConverter(!chatMemberToStore.isQrv3400()));
|
||||
preparedStatement.setInt(18, helper_booleanIntConverter(!chatMemberToStore.isQrv5600()));
|
||||
preparedStatement.setInt(19, helper_booleanIntConverter(!chatMemberToStore.isQrv10G()));
|
||||
preparedStatement.setLong(20, resolvedLastFlagsChangeEpochMs);
|
||||
preparedStatement.executeUpdate();
|
||||
} catch (SQLException e) {
|
||||
System.err.println("[DBH, ERROR:] Chatmember could not been stored.");
|
||||
@@ -679,19 +607,13 @@ public class DBController {
|
||||
|
||||
String resetAllWorkedDataSql =
|
||||
"UPDATE ChatMember SET "
|
||||
+ "worked = 0, worked144 = 0, worked432 = 0, worked1240 = 0, worked2300 = 0, worked3400 = 0, worked5600 = 0, worked10G = 0, worked50 = 0, worked70 = 0, "
|
||||
+ "notQRV144 = 0, notQRV432 = 0, notQRV1240 = 0, notQRV2300 = 0, notQRV3400 = 0, notQRV5600 = 0, notQRV10G = 0, notQRV50 = 0, notQRV70 = 0, "
|
||||
+ "worked = 0, worked144 = 0, worked432 = 0, worked1240 = 0, worked2300 = 0, worked3400 = 0, worked5600 = 0, worked10G = 0, "
|
||||
+ "notQRV144 = 0, notQRV432 = 0, notQRV1240 = 0, notQRV2300 = 0, notQRV3400 = 0, notQRV5600 = 0, notQRV10G = 0, "
|
||||
+ "lastFlagsChangeEpochMs = 0;";
|
||||
|
||||
try (Statement statement = connection.createStatement()) {
|
||||
// return statement.executeUpdate(resetAllWorkedDataSql);
|
||||
int affectedRows = statement.executeUpdate(resetAllWorkedDataSql);
|
||||
statement.executeUpdate("DELETE FROM WorkedGrossField;");
|
||||
return affectedRows;
|
||||
|
||||
|
||||
return statement.executeUpdate(resetAllWorkedDataSql);
|
||||
} catch (SQLException e) {
|
||||
|
||||
System.err.println("[DBH, ERROR:] Couldn't reset the worked data");
|
||||
e.printStackTrace();
|
||||
return -1;
|
||||
@@ -715,30 +637,16 @@ public class DBController {
|
||||
String workedBandColumnName = helper_resolveWorkedBandColumnName(chatMemberToStore);
|
||||
|
||||
if (workedBandColumnName == null) {
|
||||
return helper_updateWorkedAnyOnChatMember(chatMemberToStore);
|
||||
System.out.println("[DBCtrl, Error]: unknown at which band the qso had been!");
|
||||
return false;
|
||||
}
|
||||
|
||||
// String updateWorkedSql =
|
||||
// "UPDATE ChatMember SET worked = 1, " + workedBandColumnName + " = 1, lastFlagsChangeEpochMs = ? WHERE callsign = ?;";
|
||||
|
||||
String updateWorkedSql =
|
||||
"UPDATE ChatMember SET worked = 1, "
|
||||
+ workedBandColumnName
|
||||
+ " = 1, "
|
||||
+ "qra = CASE WHEN ? IS NOT NULL AND TRIM(?) <> '' AND LOWER(TRIM(?)) <> 'unknown' THEN ? ELSE qra END, "
|
||||
+ "lastFlagsChangeEpochMs = ? WHERE callsign = ?;";
|
||||
"UPDATE ChatMember SET worked = 1, " + workedBandColumnName + " = 1, lastFlagsChangeEpochMs = ? WHERE callsign = ?;";
|
||||
|
||||
try (PreparedStatement preparedStatement = connection.prepareStatement(updateWorkedSql)) {
|
||||
// preparedStatement.setLong(1, System.currentTimeMillis());
|
||||
// preparedStatement.setString(2, chatMemberToStore.getCallSignRaw());
|
||||
|
||||
String qra = chatMemberToStore.getQra();
|
||||
preparedStatement.setString(1, qra);
|
||||
preparedStatement.setString(2, qra);
|
||||
preparedStatement.setString(3, qra);
|
||||
preparedStatement.setString(4, qra);
|
||||
preparedStatement.setLong(5, System.currentTimeMillis());
|
||||
preparedStatement.setString(6, chatMemberToStore.getCallSignRaw());
|
||||
preparedStatement.setLong(1, System.currentTimeMillis());
|
||||
preparedStatement.setString(2, chatMemberToStore.getCallSignRaw());
|
||||
|
||||
int affectedRows = preparedStatement.executeUpdate();
|
||||
return affectedRows > 0;
|
||||
@@ -749,47 +657,6 @@ public class DBController {
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Updates only the global worked-any flag of a stored chatmember row.
|
||||
*
|
||||
* <p>This is used when an external logger confirms that a station was worked,
|
||||
* but the software cannot reliably map the QSO to one of the persisted band
|
||||
* columns. The UI status "x" is based on this global worked flag, so this method
|
||||
* makes no-band or unsupported-band log entries persistent as worked-any.</p>
|
||||
*
|
||||
* @param chatMemberToStore chatmember that contains the worked call and optional locator
|
||||
* @return true if an existing database row was updated
|
||||
* @throws SQLException if the database write fails
|
||||
*/
|
||||
private synchronized boolean helper_updateWorkedAnyOnChatMember(ChatMember chatMemberToStore) throws SQLException {
|
||||
|
||||
if (chatMemberToStore == null
|
||||
|| chatMemberToStore.getCallSignRaw() == null
|
||||
|| chatMemberToStore.getCallSignRaw().isBlank()) {
|
||||
return false;
|
||||
}
|
||||
|
||||
String updateWorkedAnySql =
|
||||
"UPDATE ChatMember SET worked = 1, "
|
||||
+ "qra = CASE WHEN ? IS NOT NULL AND TRIM(?) <> '' AND LOWER(TRIM(?)) <> 'unknown' THEN ? ELSE qra END, "
|
||||
+ "lastFlagsChangeEpochMs = ? WHERE callsign = ?;";
|
||||
|
||||
try (PreparedStatement preparedStatement = connection.prepareStatement(updateWorkedAnySql)) {
|
||||
String qra = chatMemberToStore.getQra();
|
||||
|
||||
preparedStatement.setString(1, qra);
|
||||
preparedStatement.setString(2, qra);
|
||||
preparedStatement.setString(3, qra);
|
||||
preparedStatement.setString(4, qra);
|
||||
preparedStatement.setLong(5, System.currentTimeMillis());
|
||||
preparedStatement.setString(6, chatMemberToStore.getCallSignRaw());
|
||||
|
||||
int affectedRows = preparedStatement.executeUpdate();
|
||||
return affectedRows > 0;
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
/**
|
||||
* Updates all not-QRV flags for a chatmember row. The method uses the normalized
|
||||
* raw callsign and updates the timestamp so that automatic contest cleanup can
|
||||
@@ -814,8 +681,6 @@ public class DBController {
|
||||
+ "notQRV3400 = ?, "
|
||||
+ "notQRV5600 = ?, "
|
||||
+ "notQRV10G = ?, "
|
||||
+ "notQRV50 = ?, "
|
||||
+ "notQRV70 = ?, "
|
||||
+ "lastFlagsChangeEpochMs = ? "
|
||||
+ "WHERE callsign = ?;";
|
||||
|
||||
@@ -827,10 +692,8 @@ public class DBController {
|
||||
preparedStatement.setInt(5, helper_booleanIntConverter(!chatMemberToStore.isQrv3400()));
|
||||
preparedStatement.setInt(6, helper_booleanIntConverter(!chatMemberToStore.isQrv5600()));
|
||||
preparedStatement.setInt(7, helper_booleanIntConverter(!chatMemberToStore.isQrv10G()));
|
||||
preparedStatement.setInt(8, helper_booleanIntConverter(!chatMemberToStore.isQrv50()));
|
||||
preparedStatement.setInt(9, helper_booleanIntConverter(!chatMemberToStore.isQrv70()));
|
||||
preparedStatement.setLong(10, System.currentTimeMillis());
|
||||
preparedStatement.setString(11, chatMemberToStore.getCallSignRaw());
|
||||
preparedStatement.setLong(8, System.currentTimeMillis());
|
||||
preparedStatement.setString(9, chatMemberToStore.getCallSignRaw());
|
||||
|
||||
int affectedRows = preparedStatement.executeUpdate();
|
||||
|
||||
@@ -858,9 +721,9 @@ public class DBController {
|
||||
|
||||
String upsertCompleteRowSql =
|
||||
"INSERT INTO ChatMember ("
|
||||
+ "callsign, qra, name, lastActivityDateTime, worked, worked144, worked432, worked1240, worked2300, worked3400, worked5600, worked10G, worked50, worked70, "
|
||||
+ "notQRV144, notQRV432, notQRV1240, notQRV2300, notQRV3400, notQRV5600, notQRV10G, notQRV50, notQRV70, lastFlagsChangeEpochMs"
|
||||
+ ") VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) "
|
||||
+ "callsign, qra, name, lastActivityDateTime, worked, worked144, worked432, worked1240, worked2300, worked3400, worked5600, worked10G, "
|
||||
+ "notQRV144, notQRV432, notQRV1240, notQRV2300, notQRV3400, notQRV5600, notQRV10G, lastFlagsChangeEpochMs"
|
||||
+ ") VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) "
|
||||
+ "ON CONFLICT(callsign) DO UPDATE SET "
|
||||
+ "qra = excluded.qra, "
|
||||
+ "name = excluded.name, "
|
||||
@@ -873,8 +736,6 @@ public class DBController {
|
||||
+ "worked3400 = excluded.worked3400, "
|
||||
+ "worked5600 = excluded.worked5600, "
|
||||
+ "worked10G = excluded.worked10G, "
|
||||
+ "worked50 = excluded.worked50, "
|
||||
+ "worked70 = excluded.worked70, "
|
||||
+ "notQRV144 = excluded.notQRV144, "
|
||||
+ "notQRV432 = excluded.notQRV432, "
|
||||
+ "notQRV1240 = excluded.notQRV1240, "
|
||||
@@ -882,8 +743,6 @@ public class DBController {
|
||||
+ "notQRV3400 = excluded.notQRV3400, "
|
||||
+ "notQRV5600 = excluded.notQRV5600, "
|
||||
+ "notQRV10G = excluded.notQRV10G, "
|
||||
+ "notQRV50 = excluded.notQRV50, "
|
||||
+ "notQRV70 = excluded.notQRV70, "
|
||||
+ "lastFlagsChangeEpochMs = excluded.lastFlagsChangeEpochMs;";
|
||||
|
||||
try (PreparedStatement preparedStatement = connection.prepareStatement(upsertCompleteRowSql)) {
|
||||
@@ -899,18 +758,14 @@ public class DBController {
|
||||
preparedStatement.setInt(10, helper_booleanIntConverter(chatMemberToStore.isWorked3400()));
|
||||
preparedStatement.setInt(11, helper_booleanIntConverter(chatMemberToStore.isWorked5600()));
|
||||
preparedStatement.setInt(12, helper_booleanIntConverter(chatMemberToStore.isWorked10G()));
|
||||
preparedStatement.setInt(13, helper_booleanIntConverter(chatMemberToStore.isWorked50()));
|
||||
preparedStatement.setInt(14, helper_booleanIntConverter(chatMemberToStore.isWorked70()));
|
||||
preparedStatement.setInt(15, helper_booleanIntConverter(!chatMemberToStore.isQrv144()));
|
||||
preparedStatement.setInt(16, helper_booleanIntConverter(!chatMemberToStore.isQrv432()));
|
||||
preparedStatement.setInt(17, helper_booleanIntConverter(!chatMemberToStore.isQrv1240()));
|
||||
preparedStatement.setInt(18, helper_booleanIntConverter(!chatMemberToStore.isQrv2300()));
|
||||
preparedStatement.setInt(19, helper_booleanIntConverter(!chatMemberToStore.isQrv3400()));
|
||||
preparedStatement.setInt(20, helper_booleanIntConverter(!chatMemberToStore.isQrv5600()));
|
||||
preparedStatement.setInt(21, helper_booleanIntConverter(!chatMemberToStore.isQrv10G()));
|
||||
preparedStatement.setInt(22, helper_booleanIntConverter(!chatMemberToStore.isQrv50()));
|
||||
preparedStatement.setInt(23, helper_booleanIntConverter(!chatMemberToStore.isQrv70()));
|
||||
preparedStatement.setLong(24, chatMemberToStore.getLastFlagsChangeEpochMs());
|
||||
preparedStatement.setInt(13, helper_booleanIntConverter(!chatMemberToStore.isQrv144()));
|
||||
preparedStatement.setInt(14, helper_booleanIntConverter(!chatMemberToStore.isQrv432()));
|
||||
preparedStatement.setInt(15, helper_booleanIntConverter(!chatMemberToStore.isQrv1240()));
|
||||
preparedStatement.setInt(16, helper_booleanIntConverter(!chatMemberToStore.isQrv2300()));
|
||||
preparedStatement.setInt(17, helper_booleanIntConverter(!chatMemberToStore.isQrv3400()));
|
||||
preparedStatement.setInt(18, helper_booleanIntConverter(!chatMemberToStore.isQrv5600()));
|
||||
preparedStatement.setInt(19, helper_booleanIntConverter(!chatMemberToStore.isQrv10G()));
|
||||
preparedStatement.setLong(20, chatMemberToStore.getLastFlagsChangeEpochMs());
|
||||
preparedStatement.executeUpdate();
|
||||
} catch (SQLException e) {
|
||||
throw new RuntimeException("[DBH, ERROR:] Could not rebuild normalized ChatMember row", e);
|
||||
@@ -939,8 +794,6 @@ public class DBController {
|
||||
builtChatMember.setWorked3400(helper_IntToBooleanConverter(resultSet.getInt("worked3400")));
|
||||
builtChatMember.setWorked5600(helper_IntToBooleanConverter(resultSet.getInt("worked5600")));
|
||||
builtChatMember.setWorked10G(helper_IntToBooleanConverter(resultSet.getInt("worked10G")));
|
||||
builtChatMember.setWorked50(helper_IntToBooleanConverter(resultSet.getInt("worked50")));
|
||||
builtChatMember.setWorked70(helper_IntToBooleanConverter(resultSet.getInt("worked70")));
|
||||
builtChatMember.setQrv144(!helper_IntToBooleanConverter(resultSet.getInt("notQRV144")));
|
||||
builtChatMember.setQrv432(!helper_IntToBooleanConverter(resultSet.getInt("notQRV432")));
|
||||
builtChatMember.setQrv1240(!helper_IntToBooleanConverter(resultSet.getInt("notQRV1240")));
|
||||
@@ -948,8 +801,6 @@ public class DBController {
|
||||
builtChatMember.setQrv3400(!helper_IntToBooleanConverter(resultSet.getInt("notQRV3400")));
|
||||
builtChatMember.setQrv5600(!helper_IntToBooleanConverter(resultSet.getInt("notQRV5600")));
|
||||
builtChatMember.setQrv10G(!helper_IntToBooleanConverter(resultSet.getInt("notQRV10G")));
|
||||
builtChatMember.setQrv50(!helper_IntToBooleanConverter(resultSet.getInt("notQRV50")));
|
||||
builtChatMember.setQrv70(!helper_IntToBooleanConverter(resultSet.getInt("notQRV70")));
|
||||
builtChatMember.setLastFlagsChangeEpochMs(resultSet.getLong("lastFlagsChangeEpochMs"));
|
||||
|
||||
return builtChatMember;
|
||||
@@ -971,8 +822,6 @@ public class DBController {
|
||||
targetChatMember.setWorked3400(sourceChatMember.isWorked3400());
|
||||
targetChatMember.setWorked5600(sourceChatMember.isWorked5600());
|
||||
targetChatMember.setWorked10G(sourceChatMember.isWorked10G());
|
||||
targetChatMember.setWorked50(sourceChatMember.isWorked50());
|
||||
targetChatMember.setWorked70(sourceChatMember.isWorked70());
|
||||
targetChatMember.setQrv144(sourceChatMember.isQrv144());
|
||||
targetChatMember.setQrv432(sourceChatMember.isQrv432());
|
||||
targetChatMember.setQrv1240(sourceChatMember.isQrv1240());
|
||||
@@ -980,8 +829,6 @@ public class DBController {
|
||||
targetChatMember.setQrv3400(sourceChatMember.isQrv3400());
|
||||
targetChatMember.setQrv5600(sourceChatMember.isQrv5600());
|
||||
targetChatMember.setQrv10G(sourceChatMember.isQrv10G());
|
||||
targetChatMember.setQrv50(sourceChatMember.isQrv50());
|
||||
targetChatMember.setQrv70(sourceChatMember.isQrv70());
|
||||
targetChatMember.setLastFlagsChangeEpochMs(sourceChatMember.getLastFlagsChangeEpochMs());
|
||||
}
|
||||
|
||||
@@ -1007,10 +854,6 @@ public class DBController {
|
||||
return "worked5600";
|
||||
} else if (chatMemberToStore.isWorked10G()) {
|
||||
return "worked10G";
|
||||
} else if (chatMemberToStore.isWorked50()) {
|
||||
return "worked50";
|
||||
} else if (chatMemberToStore.isWorked70()) {
|
||||
return "worked70";
|
||||
}
|
||||
|
||||
return null;
|
||||
@@ -1053,17 +896,13 @@ public class DBController {
|
||||
|| chatMemberToStore.isWorked3400()
|
||||
|| chatMemberToStore.isWorked5600()
|
||||
|| chatMemberToStore.isWorked10G()
|
||||
|| chatMemberToStore.isWorked50()
|
||||
|| chatMemberToStore.isWorked70()
|
||||
|| !chatMemberToStore.isQrv144()
|
||||
|| !chatMemberToStore.isQrv432()
|
||||
|| !chatMemberToStore.isQrv1240()
|
||||
|| !chatMemberToStore.isQrv2300()
|
||||
|| !chatMemberToStore.isQrv3400()
|
||||
|| !chatMemberToStore.isQrv5600()
|
||||
|| !chatMemberToStore.isQrv10G()
|
||||
|| !chatMemberToStore.isQrv50()
|
||||
|| !chatMemberToStore.isQrv70();
|
||||
|| !chatMemberToStore.isQrv10G();
|
||||
}
|
||||
|
||||
/**
|
||||
@@ -1116,79 +955,4 @@ public class DBController {
|
||||
// dbc.storeChatMember(dummy);
|
||||
// dbc.updateWkdInfoOnChatMember(dummy);
|
||||
}
|
||||
|
||||
/**
|
||||
* Inserts or updates a worked gross field for the new-locator filter.
|
||||
*
|
||||
* @param band worked band
|
||||
* @param locator6 six-character Maidenhead locator
|
||||
* @param callsignRaw normalized raw callsign or null
|
||||
* @param source source identifier such as UCXLOG or WINTEST
|
||||
*/
|
||||
public synchronized void upsertWorkedGrossField(Band band, String locator6, String callsignRaw, String source) {
|
||||
|
||||
String grossField = WorkedGrossFieldCache.extractGrossField(locator6);
|
||||
String normalizedLocator6 = WorkedGrossFieldCache.extractLocator6(locator6);
|
||||
|
||||
if (band == null || grossField == null) {
|
||||
return;
|
||||
}
|
||||
|
||||
String upsertSql =
|
||||
"INSERT INTO WorkedGrossField (band, grossField, locator, callsign, source, lastWorkedEpochMs) "
|
||||
+ "VALUES (?, ?, ?, ?, ?, ?) "
|
||||
+ "ON CONFLICT(band, grossField) DO UPDATE SET "
|
||||
+ "locator = COALESCE(excluded.locator, WorkedGrossField.locator), "
|
||||
+ "callsign = COALESCE(excluded.callsign, WorkedGrossField.callsign), "
|
||||
+ "source = excluded.source, "
|
||||
+ "lastWorkedEpochMs = excluded.lastWorkedEpochMs;";
|
||||
|
||||
try (PreparedStatement preparedStatement = connection.prepareStatement(upsertSql)) {
|
||||
preparedStatement.setString(1, band.name());
|
||||
preparedStatement.setString(2, grossField);
|
||||
preparedStatement.setString(3, normalizedLocator6);
|
||||
preparedStatement.setString(4, callsignRaw);
|
||||
preparedStatement.setString(5, source == null ? "UNKNOWN" : source);
|
||||
preparedStatement.setLong(6, System.currentTimeMillis());
|
||||
preparedStatement.executeUpdate();
|
||||
} catch (SQLException e) {
|
||||
throw new RuntimeException("[DBH, ERROR:] Could not upsert worked gross field", e);
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Loads all non-expired worked gross fields from the database.
|
||||
*
|
||||
* @return map of band to worked gross fields
|
||||
*/
|
||||
public synchronized Map<Band, Set<String>> fetchWorkedGrossFieldsFromDB() {
|
||||
|
||||
resetExpiredWorkedDataIfRequired();
|
||||
|
||||
Map<Band, Set<String>> result = new EnumMap<>(Band.class);
|
||||
|
||||
try (Statement statement = connection.createStatement();
|
||||
ResultSet resultSet = statement.executeQuery("SELECT band, grossField FROM WorkedGrossField ORDER BY band, grossField;")) {
|
||||
|
||||
while (resultSet.next()) {
|
||||
Band band;
|
||||
try {
|
||||
band = Band.valueOf(resultSet.getString("band"));
|
||||
} catch (Exception ignored) {
|
||||
continue;
|
||||
}
|
||||
|
||||
String grossField = WorkedGrossFieldCache.extractGrossField(resultSet.getString("grossField"));
|
||||
if (grossField == null) {
|
||||
continue;
|
||||
}
|
||||
|
||||
result.computeIfAbsent(band, ignored -> new HashSet<>()).add(grossField);
|
||||
}
|
||||
} catch (SQLException e) {
|
||||
throw new RuntimeException("[DBH, ERROR:] Could not fetch worked gross fields", e);
|
||||
}
|
||||
|
||||
return result;
|
||||
}
|
||||
}
|
||||
|
||||
@@ -1,363 +1,237 @@
|
||||
package kst4contest.controller;
|
||||
|
||||
import kst4contest.model.ChatMember;
|
||||
import kst4contest.model.ChatPreferences;
|
||||
import kst4contest.model.ThreadStateMessage;
|
||||
|
||||
import java.io.IOException;
|
||||
import java.io.OutputStream;
|
||||
import java.io.*;
|
||||
import java.net.ServerSocket;
|
||||
import java.net.Socket;
|
||||
import java.nio.charset.StandardCharsets;
|
||||
import java.util.ArrayList;
|
||||
import java.util.Collections;
|
||||
import java.util.Iterator;
|
||||
import java.util.List;
|
||||
import java.util.*;
|
||||
import java.util.concurrent.ExecutorService;
|
||||
import java.util.concurrent.Executors;
|
||||
import java.util.concurrent.ScheduledExecutorService;
|
||||
import java.util.concurrent.TimeUnit;
|
||||
import java.util.logging.Level;
|
||||
import java.util.logging.Logger;
|
||||
|
||||
public class DXClusterThreadPooledServer implements Runnable {
|
||||
public class DXClusterThreadPooledServer implements Runnable{
|
||||
|
||||
private static final Logger LOGGER =
|
||||
Logger.getLogger(DXClusterThreadPooledServer.class.getName());
|
||||
private static final String THREAD_NICKNAME = "DXCluster-Server";
|
||||
private List<Socket> clientSockets = Collections.synchronizedList(new ArrayList<>()); //list of all connected clients
|
||||
|
||||
private final List<Socket> clientSockets =
|
||||
Collections.synchronizedList(new ArrayList<>());
|
||||
|
||||
private final ChatController chatController;
|
||||
private final ThreadStatusCallback callBackToController;
|
||||
private final int serverPort;
|
||||
|
||||
private final ExecutorService threadPool =
|
||||
private ThreadStatusCallback callBackToController;
|
||||
private String ThreadNickName = "DXCluster-Server";
|
||||
ChatController chatController = null;
|
||||
protected int serverPort = 8080;
|
||||
protected ServerSocket serverSocket = null;
|
||||
protected boolean isStopped = false;
|
||||
protected Thread runningThread= null;
|
||||
protected ExecutorService threadPool =
|
||||
Executors.newFixedThreadPool(10);
|
||||
Socket clientSocket;
|
||||
|
||||
private final ScheduledExecutorService keepAliveExecutor =
|
||||
Executors.newSingleThreadScheduledExecutor();
|
||||
|
||||
private volatile boolean stopped;
|
||||
private ServerSocket serverSocket;
|
||||
|
||||
public DXClusterThreadPooledServer(
|
||||
int port,
|
||||
ChatController chatController,
|
||||
ThreadStatusCallback callback
|
||||
) {
|
||||
public DXClusterThreadPooledServer(int port, ChatController chatController, ThreadStatusCallback callback){
|
||||
this.serverPort = port;
|
||||
this.chatController = chatController;
|
||||
this.callBackToController = callback;
|
||||
}
|
||||
|
||||
@Override
|
||||
public void run() {
|
||||
Thread.currentThread().setName("DXCluster-thread-pooled-server");
|
||||
public void run(){
|
||||
|
||||
try {
|
||||
serverSocket = new ServerSocket(serverPort);
|
||||
ThreadStateMessage threadStateMessage = new ThreadStateMessage(this.ThreadNickName, true, "initialized", false);
|
||||
callBackToController.onThreadStatus(ThreadNickName,threadStateMessage);
|
||||
|
||||
if (stopped) {
|
||||
return;
|
||||
synchronized(this){
|
||||
this.runningThread = Thread.currentThread();
|
||||
runningThread.setName("DXCluster-thread-pooled-server");
|
||||
}
|
||||
openServerSocket();
|
||||
while(! isStopped()){
|
||||
clientSocket = null;
|
||||
try {
|
||||
clientSocket = this.serverSocket.accept();
|
||||
|
||||
synchronized(clientSockets) {
|
||||
clientSockets.add(clientSocket); // add dx cluster client to the "clients list" for broadcasting
|
||||
}
|
||||
|
||||
} catch (IOException e) {
|
||||
if(isStopped()) {
|
||||
System.out.println("Server Stopped.") ;
|
||||
break;
|
||||
}
|
||||
throw new RuntimeException(
|
||||
"Error accepting client connection", e);
|
||||
}
|
||||
|
||||
callBackToController.onThreadStatus(
|
||||
THREAD_NICKNAME,
|
||||
new ThreadStateMessage(
|
||||
THREAD_NICKNAME,
|
||||
true,
|
||||
"Listening on TCP port " + serverPort,
|
||||
false
|
||||
)
|
||||
);
|
||||
DXClusterServerWorkerRunnable worker = new DXClusterServerWorkerRunnable(clientSocket, "Thread Pooled DXCluster Server ", chatController, clientSockets, chatController);
|
||||
|
||||
keepAliveExecutor.scheduleAtFixedRate(
|
||||
this::sendKeepAlive,
|
||||
30,
|
||||
30,
|
||||
TimeUnit.SECONDS
|
||||
);
|
||||
this.threadPool.execute(worker);
|
||||
|
||||
while (!stopped) {
|
||||
try {
|
||||
Socket clientSocket = serverSocket.accept();
|
||||
clientSockets.add(clientSocket);
|
||||
}
|
||||
this.threadPool.shutdown();
|
||||
System.out.println("Server Stopped.") ;
|
||||
}
|
||||
|
||||
threadPool.execute(
|
||||
new DXClusterServerWorkerRunnable(
|
||||
clientSocket,
|
||||
clientSockets
|
||||
)
|
||||
);
|
||||
} catch (IOException exception) {
|
||||
if (!stopped) {
|
||||
LOGGER.log(
|
||||
Level.SEVERE,
|
||||
"Error accepting DX Cluster client connection",
|
||||
exception
|
||||
);
|
||||
}
|
||||
private synchronized boolean isStopped() {
|
||||
return this.isStopped;
|
||||
}
|
||||
|
||||
public synchronized void stop(){
|
||||
this.isStopped = true;
|
||||
try {
|
||||
this.serverSocket.close();
|
||||
synchronized(clientSockets) {
|
||||
for (Socket socket : clientSockets) {
|
||||
socket.close(); // close all client connections
|
||||
}
|
||||
}
|
||||
} catch (IOException exception) {
|
||||
if (!stopped) {
|
||||
LOGGER.log(
|
||||
Level.SEVERE,
|
||||
"Cannot open DX Cluster TCP port " + serverPort,
|
||||
exception
|
||||
);
|
||||
|
||||
callBackToController.onThreadStatus(
|
||||
THREAD_NICKNAME,
|
||||
new ThreadStateMessage(
|
||||
THREAD_NICKNAME,
|
||||
false,
|
||||
"Cannot open TCP port "
|
||||
+ serverPort
|
||||
+ ": "
|
||||
+ exception.getMessage(),
|
||||
true
|
||||
)
|
||||
);
|
||||
}
|
||||
} finally {
|
||||
closeServerSocket();
|
||||
closeClientSockets();
|
||||
keepAliveExecutor.shutdownNow();
|
||||
threadPool.shutdownNow();
|
||||
} catch (IOException e) {
|
||||
throw new RuntimeException("DXCCSERVER Error closing server", e);
|
||||
}
|
||||
}
|
||||
|
||||
public synchronized void stop() {
|
||||
stopped = true;
|
||||
closeServerSocket();
|
||||
closeClientSockets();
|
||||
keepAliveExecutor.shutdownNow();
|
||||
threadPool.shutdownNow();
|
||||
}
|
||||
|
||||
public boolean hasConnectedClients() {
|
||||
synchronized (clientSockets) {
|
||||
removeClosedClients();
|
||||
return !clientSockets.isEmpty();
|
||||
private void openServerSocket() {
|
||||
try {
|
||||
this.serverSocket = new ServerSocket(this.serverPort);
|
||||
} catch (IOException e) {
|
||||
throw new RuntimeException("DXCCSERVER Cannot open port ", e);
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Sends one DX Cluster spot to all currently connected clients.
|
||||
* Sends a DX cluster message to ALL connected log programs via telnet, returns true if sent
|
||||
*
|
||||
* @return true if the spot was delivered to at least one client
|
||||
* @param aChatMember
|
||||
* @return boolean true if message had been sent
|
||||
*/
|
||||
public boolean broadcastSingleDXClusterEntryToLoggers(
|
||||
ChatMember chatMember
|
||||
) {
|
||||
final String clusterMessage;
|
||||
public boolean broadcastSingleDXClusterEntryToLoggers(ChatMember aChatMember) {
|
||||
synchronized(clientSockets) {
|
||||
|
||||
try {
|
||||
String frequency = Utils4KST.normalizeFrequencyString(
|
||||
chatMember.getFrequency().getValue(),
|
||||
chatController
|
||||
.getChatPreferences()
|
||||
.getNotify_optionalFrequencyPrefix()
|
||||
);
|
||||
System.out.println("DXClusterSrvr: broadcasting message to clients: " + clientSockets.size());
|
||||
|
||||
clusterMessage =
|
||||
"DX de "
|
||||
+ chatController
|
||||
.getChatPreferences()
|
||||
.getNotify_DXCSrv_SpottersCallSign()
|
||||
.getValue()
|
||||
+ ": "
|
||||
+ frequency
|
||||
+ " "
|
||||
+ chatMember.getCallSign().toUpperCase()
|
||||
+ " "
|
||||
+ chatMember.getQra().toUpperCase()
|
||||
+ " "
|
||||
+ new Utils4KST()
|
||||
.time_generateCurrenthhmmZTimeStringForClusterMessage()
|
||||
+ ((char) 7)
|
||||
+ ((char) 7)
|
||||
+ "\r\n";
|
||||
} catch (Exception exception) {
|
||||
LOGGER.log(
|
||||
Level.SEVERE,
|
||||
"Cannot build DX Cluster message",
|
||||
exception
|
||||
);
|
||||
return false;
|
||||
}
|
||||
try {
|
||||
|
||||
int deliveredClients = 0;
|
||||
|
||||
synchronized (clientSockets) {
|
||||
Iterator<Socket> iterator = clientSockets.iterator();
|
||||
|
||||
while (iterator.hasNext()) {
|
||||
Socket socket = iterator.next();
|
||||
|
||||
if (socket == null || socket.isClosed()) {
|
||||
iterator.remove();
|
||||
continue;
|
||||
}
|
||||
|
||||
try {
|
||||
OutputStream output = socket.getOutputStream();
|
||||
output.write(
|
||||
clusterMessage.getBytes(
|
||||
StandardCharsets.US_ASCII
|
||||
)
|
||||
);
|
||||
output.flush();
|
||||
deliveredClients++;
|
||||
} catch (IOException exception) {
|
||||
LOGGER.log(
|
||||
Level.WARNING,
|
||||
"DX Cluster client disconnected while sending a spot",
|
||||
exception
|
||||
);
|
||||
|
||||
closeSocket(socket);
|
||||
iterator.remove();
|
||||
}
|
||||
System.out.println("-------------> ORIGINALEE VAL: " + aChatMember.getFrequency().getValue());
|
||||
System.out.println("-------------> NORMALIZED VAL: " + Utils4KST.normalizeFrequencyString(aChatMember.getFrequency().getValue(), chatController.getChatPreferences().getNotify_optionalFrequencyPrefix()) + " ");
|
||||
} catch (Exception e) {
|
||||
System.out.println("DXCThPooledServer: Error accessing value in chatmember object: " + e.getMessage());
|
||||
// e.printStackTrace();
|
||||
}
|
||||
}
|
||||
|
||||
if (deliveredClients > 0) {
|
||||
callBackToController.onThreadStatus(
|
||||
THREAD_NICKNAME,
|
||||
new ThreadStateMessage(
|
||||
THREAD_NICKNAME,
|
||||
true,
|
||||
"Last spot sent to "
|
||||
+ deliveredClients
|
||||
+ " DX Cluster client(s):\n"
|
||||
+ clusterMessage,
|
||||
false
|
||||
)
|
||||
);
|
||||
}
|
||||
|
||||
return deliveredClients > 0;
|
||||
}
|
||||
|
||||
private void sendKeepAlive() {
|
||||
synchronized (clientSockets) {
|
||||
Iterator<Socket> iterator = clientSockets.iterator();
|
||||
|
||||
while (iterator.hasNext()) {
|
||||
Socket socket = iterator.next();
|
||||
|
||||
if (socket == null || socket.isClosed()) {
|
||||
iterator.remove();
|
||||
continue;
|
||||
}
|
||||
|
||||
try {
|
||||
OutputStream output = socket.getOutputStream();
|
||||
output.write(
|
||||
"\r\n".getBytes(StandardCharsets.US_ASCII)
|
||||
);
|
||||
output.flush();
|
||||
} catch (IOException exception) {
|
||||
closeSocket(socket);
|
||||
iterator.remove();
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
private void removeClosedClients() {
|
||||
clientSockets.removeIf(
|
||||
socket -> socket == null || socket.isClosed()
|
||||
);
|
||||
}
|
||||
|
||||
private synchronized void closeServerSocket() {
|
||||
if (serverSocket == null || serverSocket.isClosed()) {
|
||||
return;
|
||||
}
|
||||
|
||||
try {
|
||||
serverSocket.close();
|
||||
} catch (IOException exception) {
|
||||
LOGGER.log(
|
||||
Level.WARNING,
|
||||
"Error closing DX Cluster server socket",
|
||||
exception
|
||||
);
|
||||
}
|
||||
}
|
||||
|
||||
private void closeClientSockets() {
|
||||
synchronized (clientSockets) {
|
||||
for (Socket socket : clientSockets) {
|
||||
closeSocket(socket);
|
||||
|
||||
try {
|
||||
|
||||
OutputStream output = socket.getOutputStream();
|
||||
|
||||
String singleDXClusterMessage = "DX de ";
|
||||
|
||||
// singleDXClusterMessage += chatController.getChatPreferences().getLoginCallSign() + ": ";
|
||||
|
||||
|
||||
|
||||
|
||||
singleDXClusterMessage += this.chatController.getChatPreferences().getNotify_DXCSrv_SpottersCallSign().getValue() + ": ";
|
||||
singleDXClusterMessage += Utils4KST.normalizeFrequencyString(aChatMember.getFrequency().getValue(), chatController.getChatPreferences().getNotify_optionalFrequencyPrefix()) + " ";
|
||||
singleDXClusterMessage += aChatMember.getCallSign().toUpperCase() + " "; //we need such an amount of spaces for n1mm to work, otherwise bullshit happens
|
||||
singleDXClusterMessage += aChatMember.getQra().toUpperCase() + " ";
|
||||
singleDXClusterMessage += new Utils4KST().time_generateCurrenthhmmZTimeStringForClusterMessage() + ((char)7) + ((char)7) + "\r\n";
|
||||
|
||||
// singleDXClusterMessage += chatController.getChatPreferences().getLoginCallSign() + ": ";
|
||||
// singleDXClusterMessage += Utils4KST.normalizeFrequencyString(aChatMember.getFrequency().getValue(), chatController.getChatPreferences().getNotify_optionalFrequencyPrefix()) + " ";
|
||||
// singleDXClusterMessage += aChatMember.getCallSign().toUpperCase() + " ";
|
||||
// singleDXClusterMessage += aChatMember.getQra().toUpperCase() + " ";
|
||||
// singleDXClusterMessage += new Utils4KST().time_generateCurrenthhmmZTimeStringForClusterMessage() + ((char)7) + ((char)7) + "\r\n";
|
||||
|
||||
output.write((singleDXClusterMessage).getBytes());
|
||||
|
||||
ThreadStateMessage threadStateMessage = new ThreadStateMessage(this.ThreadNickName, true, "Last msg to " + clientSockets.size() + " Cluster Clients:\n" + singleDXClusterMessage, false);
|
||||
callBackToController.onThreadStatus(ThreadNickName,threadStateMessage);
|
||||
|
||||
} catch (IOException e) {
|
||||
e.printStackTrace();
|
||||
System.out.println("[DXClusterSrvr, Error:] broadcasting DXC-message to clients went wrong!");
|
||||
return false;
|
||||
}
|
||||
}
|
||||
|
||||
clientSockets.clear();
|
||||
}
|
||||
return true; //if message had been sent, return true for "ok"
|
||||
}
|
||||
|
||||
private static void closeSocket(Socket socket) {
|
||||
if (socket == null || socket.isClosed()) {
|
||||
return;
|
||||
}
|
||||
|
||||
try {
|
||||
socket.close();
|
||||
} catch (IOException ignored) {
|
||||
// The connection is already unusable.
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
class DXClusterServerWorkerRunnable implements Runnable {
|
||||
class DXClusterServerWorkerRunnable implements Runnable{
|
||||
|
||||
private static final Logger LOGGER =
|
||||
Logger.getLogger(DXClusterServerWorkerRunnable.class.getName());
|
||||
protected Socket clientSocket = null;
|
||||
protected String serverText = null;
|
||||
private ChatController client = null;
|
||||
private List<Socket> dxClusterClientSocketsConnectedList;
|
||||
private ThreadStatusCallback callBackToController;
|
||||
private String ThreadNickName = "DXCluster-Server";
|
||||
|
||||
private final Socket clientSocket;
|
||||
private final List<Socket> clientSockets;
|
||||
|
||||
DXClusterServerWorkerRunnable(
|
||||
Socket clientSocket,
|
||||
List<Socket> clientSockets
|
||||
) {
|
||||
public DXClusterServerWorkerRunnable(Socket clientSocket, String serverText, ChatController chatController, List<Socket> clientSockets, ThreadStatusCallback callback) {
|
||||
this.clientSocket = clientSocket;
|
||||
this.clientSockets = clientSockets;
|
||||
this.serverText = serverText;
|
||||
this.client = chatController;
|
||||
this.dxClusterClientSocketsConnectedList = clientSockets;
|
||||
this.callBackToController = callback;
|
||||
|
||||
}
|
||||
|
||||
@Override
|
||||
public void run() {
|
||||
try {
|
||||
OutputStream output = clientSocket.getOutputStream();
|
||||
output.write(
|
||||
"login: ".getBytes(StandardCharsets.US_ASCII)
|
||||
);
|
||||
output.flush();
|
||||
dxClusterClientSocketsConnectedList.add(clientSocket);
|
||||
|
||||
System.out.println(
|
||||
"[DXClusterServer] New client connected: "
|
||||
+ clientSocket.getInetAddress()
|
||||
);
|
||||
} catch (IOException exception) {
|
||||
LOGGER.log(
|
||||
Level.WARNING,
|
||||
"Cannot initialise DX Cluster client connection",
|
||||
exception
|
||||
);
|
||||
Timer dXCkeepAliveTimer = new Timer();
|
||||
dXCkeepAliveTimer.schedule(new TimerTask() {
|
||||
|
||||
synchronized (clientSockets) {
|
||||
clientSockets.remove(clientSocket);
|
||||
}
|
||||
@Override
|
||||
public void run() {
|
||||
|
||||
try {
|
||||
clientSocket.close();
|
||||
} catch (IOException ignored) {
|
||||
// The connection is already unusable.
|
||||
StringBuilder connectedClients = new StringBuilder(); //only for statistics
|
||||
|
||||
for (Socket socket : dxClusterClientSocketsConnectedList) {
|
||||
|
||||
connectedClients.append(socket.getInetAddress()).append("\n");
|
||||
|
||||
try {
|
||||
OutputStream output = socket.getOutputStream();
|
||||
output.write(("\r\n").getBytes());
|
||||
|
||||
} catch (IOException e) {
|
||||
e.printStackTrace();
|
||||
System.out.println("[DXClusterSrvr, Error:] broadcasting DXC-message to clients went wrong!");
|
||||
dXCkeepAliveTimer.purge();
|
||||
|
||||
try {
|
||||
socket.close();
|
||||
} catch (IOException ex) {
|
||||
ex.printStackTrace();
|
||||
}
|
||||
finally {
|
||||
this.cancel();
|
||||
}
|
||||
dxClusterClientSocketsConnectedList.remove(socket); //if socket is closed by client, remove it from the broadcast list and close it
|
||||
}
|
||||
}
|
||||
|
||||
// ThreadStateMessage threadStateMessage = new ThreadStateMessage(ThreadNickName, true, "Connected clients: " + connectedClients.toString(), false);
|
||||
// callBackToController.onThreadStatus(ThreadNickName,threadStateMessage);
|
||||
|
||||
}
|
||||
}, 30000, 30000);
|
||||
|
||||
|
||||
output.write(("login: ").getBytes()); //say hello to the client, it will answer with a callsign
|
||||
System.out.println("[DXClusterThreadPooledServer, Info:] New cluster client connected! "); //TODO: maybe integrate non blocking reader for client identification
|
||||
|
||||
} catch (IOException e) {
|
||||
e.printStackTrace();
|
||||
} finally {
|
||||
synchronized(dxClusterClientSocketsConnectedList) {
|
||||
dxClusterClientSocketsConnectedList.remove(clientSocket); // Entferne den Client nach Verarbeitung
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
|
||||
}
|
||||
@@ -2,8 +2,6 @@ package kst4contest.controller;
|
||||
|
||||
import java.io.*;
|
||||
import java.net.*;
|
||||
import java.util.logging.Level;
|
||||
import java.util.logging.Logger;
|
||||
|
||||
import kst4contest.model.ChatMessage;
|
||||
|
||||
@@ -15,7 +13,6 @@ import kst4contest.model.ChatMessage;
|
||||
* No need for it as it´s not longer a console application
|
||||
*/
|
||||
public class InputReaderThread extends Thread {
|
||||
private static final Logger LOGGER = Logger.getLogger(InputReaderThread.class.getName());
|
||||
private PrintWriter writer;
|
||||
private Socket socket;
|
||||
private ChatController client;
|
||||
@@ -42,7 +39,8 @@ public class InputReaderThread extends Thread {
|
||||
try {
|
||||
sendThisMessage23001 = reader.readLine();
|
||||
} catch (IOException e) {
|
||||
LOGGER.log(Level.SEVERE, "Error reading from stdin", e);
|
||||
// TODO Auto-generated catch block
|
||||
e.printStackTrace();
|
||||
}
|
||||
|
||||
ownMSG.setMessageText("MSG|" + this.client.getChatCategoryMain().getCategoryNumber() + "|0|" + sendThisMessage23001 + "|0|");
|
||||
@@ -55,8 +53,8 @@ public class InputReaderThread extends Thread {
|
||||
try {
|
||||
this.sleep(500);
|
||||
} catch (InterruptedException e) {
|
||||
LOGGER.log(Level.SEVERE, "InputReaderThread interrupted", e);
|
||||
Thread.currentThread().interrupt();
|
||||
// TODO Auto-generated catch block
|
||||
e.printStackTrace();
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
-81
@@ -1,81 +0,0 @@
|
||||
//package kst4contest.controller;
|
||||
//
|
||||
//import kst4contest.model.Band;
|
||||
//import org.junit.jupiter.api.Test;
|
||||
//import org.junit.jupiter.params.ParameterizedTest;
|
||||
//import org.junit.jupiter.params.provider.ValueSource;
|
||||
//
|
||||
//import java.util.regex.Matcher;
|
||||
//import java.util.regex.Pattern;
|
||||
//
|
||||
//import static org.junit.jupiter.api.Assertions.assertEquals;
|
||||
//import static org.junit.jupiter.api.Assertions.assertFalse;
|
||||
//import static org.junit.jupiter.api.Assertions.assertNotNull;
|
||||
//import static org.junit.jupiter.api.Assertions.assertNull;
|
||||
//import static org.junit.jupiter.api.Assertions.assertTrue;
|
||||
//
|
||||
//class MessageBusManagementThreadFrequencyContextTest {
|
||||
//
|
||||
// private static final Pattern THREE_DIGIT_VALUE =
|
||||
// Pattern.compile("\\b\\d{3}\\b");
|
||||
//
|
||||
// @ParameterizedTest
|
||||
// @ValueSource(strings = {
|
||||
// "qrg 210",
|
||||
// "QRG: 210",
|
||||
// "freq is 210",
|
||||
// "frequency = 210",
|
||||
// "on 210",
|
||||
// "210 MHz",
|
||||
// "210 qrg"
|
||||
// })
|
||||
// void acceptsBareThreeDigitValueWithFrequencyContext(String messageText) {
|
||||
// Matcher matcher = findThreeDigitValue(messageText);
|
||||
//
|
||||
// assertTrue(
|
||||
// MessageBusManagementThread
|
||||
// .hasExplicitBareFrequencyContext(
|
||||
// messageText,
|
||||
// matcher.start(),
|
||||
// matcher.end()
|
||||
// )
|
||||
// );
|
||||
// }
|
||||
//
|
||||
// @ParameterizedTest
|
||||
// @ValueSource(strings = {
|
||||
// "599",
|
||||
// "144",
|
||||
// "serial 210",
|
||||
// "score 210",
|
||||
// "worked 210 stations"
|
||||
// })
|
||||
// void rejectsBareThreeDigitValueWithoutFrequencyContext(String messageText) {
|
||||
// Matcher matcher = findThreeDigitValue(messageText);
|
||||
//
|
||||
// assertFalse(
|
||||
// MessageBusManagementThread
|
||||
// .hasExplicitBareFrequencyContext(
|
||||
// messageText,
|
||||
// matcher.start(),
|
||||
// matcher.end()
|
||||
// )
|
||||
// );
|
||||
// }
|
||||
//
|
||||
// @Test
|
||||
// void resolvesOnlySupportedFallbackPrefixes() {
|
||||
// assertEquals(Band.B_144, Band.fromPrefix("144"));
|
||||
// assertEquals(Band.B_432, Band.fromPrefix(" 432 "));
|
||||
// assertEquals(Band.B_10G, Band.fromPrefix("10368"));
|
||||
// assertNull(Band.fromPrefix("999"));
|
||||
// assertNull(Band.fromPrefix(null));
|
||||
// }
|
||||
//
|
||||
// private Matcher findThreeDigitValue(String messageText) {
|
||||
// Matcher matcher = THREE_DIGIT_VALUE.matcher(messageText);
|
||||
// assertTrue(matcher.find(), "Test message must contain a three-digit value");
|
||||
// assertNotNull(matcher.group());
|
||||
// return matcher;
|
||||
// }
|
||||
//}
|
||||
@@ -1,154 +0,0 @@
|
||||
package kst4contest.controller;
|
||||
|
||||
import java.math.BigDecimal;
|
||||
import java.util.List;
|
||||
import java.util.Objects;
|
||||
|
||||
import kst4contest.model.AirPlane;
|
||||
import kst4contest.model.AirPlaneReflectionInfo;
|
||||
import kst4contest.model.ChatMember;
|
||||
import kst4contest.model.ChatPreferences;
|
||||
|
||||
/**
|
||||
* Resolves variables used in operator messages, shortcuts, snippets and
|
||||
* beacons.
|
||||
*
|
||||
* <p>Global variables only depend on the local station configuration and can
|
||||
* therefore be used in every message context. Station variables additionally
|
||||
* require a selected remote station. Keeping both groups in one resolver
|
||||
* prevents the send field and the beacon tasks from implementing different
|
||||
* replacement rules.</p>
|
||||
*/
|
||||
public final class MessageVariableResolver {
|
||||
|
||||
private static final int SHORT_VALUE_LENGTH = 7;
|
||||
|
||||
private final ChatPreferences chatPreferences;
|
||||
|
||||
/**
|
||||
* Creates a resolver backed by the live application preferences.
|
||||
*
|
||||
* @param chatPreferences preferences that provide current station values
|
||||
*/
|
||||
public MessageVariableResolver(ChatPreferences chatPreferences) {
|
||||
this.chatPreferences = Objects.requireNonNull(chatPreferences, "chatPreferences");
|
||||
}
|
||||
|
||||
/**
|
||||
* Resolves variables which do not require a selected remote station.
|
||||
*
|
||||
* <p>The replacement is literal rather than regular-expression based.
|
||||
* Callsigns, locators and frequencies are data, not regular expressions.</p>
|
||||
*
|
||||
* @param template text that may contain variables
|
||||
* @return text with all available global variables resolved, or {@code null}
|
||||
* when the supplied template is {@code null}
|
||||
*/
|
||||
public String resolveGlobalVariables(String template) {
|
||||
if (template == null) {
|
||||
return null;
|
||||
}
|
||||
|
||||
String primaryFrequency = valueOrEmpty(chatPreferences.getMYQRGFirstCat().getValue());
|
||||
String secondaryFrequency = valueOrEmpty(chatPreferences.getMYQRGSecondCat().getValue());
|
||||
String ownLocator = valueOrEmpty(chatPreferences.getStn_loginLocatorMainCat());
|
||||
|
||||
String resolvedText = template;
|
||||
resolvedText = resolvedText.replace("MYQRGSHORT", abbreviate(primaryFrequency));
|
||||
resolvedText = resolvedText.replace("MYQRG", primaryFrequency);
|
||||
resolvedText = resolvedText.replace("SECONDQRG", secondaryFrequency);
|
||||
resolvedText = resolvedText.replace("MYLOCATORSHORT", abbreviateLocator(ownLocator));
|
||||
resolvedText = resolvedText.replace("MYLOCATOR", ownLocator);
|
||||
resolvedText = resolvedText.replace("MYCALL", valueOrEmpty(chatPreferences.getStn_loginCallSign()));
|
||||
resolvedText = resolvedText.replace("MYQTF", formatHeading(chatPreferences.getActualQTF().getValue().doubleValue()));
|
||||
return resolvedText;
|
||||
}
|
||||
|
||||
/**
|
||||
* Resolves global variables and variables derived from a selected station.
|
||||
*
|
||||
* <p>If no station is selected, station-specific placeholders remain visible.
|
||||
* This is intentional: silently removing {@code QRZNAME}, {@code FIRSTAP} or
|
||||
* {@code SECONDAP} could create a plausible-looking but incomplete message.</p>
|
||||
*
|
||||
* @param template text that may contain variables
|
||||
* @param selectedStation currently selected remote station, may be {@code null}
|
||||
* @return resolved message text
|
||||
*/
|
||||
public String resolveForSelectedStation(String template, ChatMember selectedStation) {
|
||||
String resolvedText = resolveGlobalVariables(template);
|
||||
|
||||
if (resolvedText == null || selectedStation == null) {
|
||||
return resolvedText;
|
||||
}
|
||||
|
||||
resolvedText = resolvedText.replace("QRZNAME", resolveStationName(selectedStation));
|
||||
resolvedText = resolvedText.replace("FIRSTAP", resolveFirstAirPlane(selectedStation));
|
||||
resolvedText = resolvedText.replace("SECONDAP", resolveSecondAirPlane(selectedStation));
|
||||
return resolvedText;
|
||||
}
|
||||
|
||||
private String resolveStationName(ChatMember selectedStation) {
|
||||
String stationName = valueOrEmpty(selectedStation.getName()).trim();
|
||||
|
||||
if (!stationName.isEmpty()) {
|
||||
return stationName;
|
||||
}
|
||||
|
||||
return valueOrEmpty(selectedStation.getCallSign());
|
||||
}
|
||||
|
||||
private String resolveFirstAirPlane(ChatMember selectedStation) {
|
||||
List<AirPlane> risingAirPlanes = getRisingAirPlanes(selectedStation);
|
||||
|
||||
if (risingAirPlanes.isEmpty()) {
|
||||
return "no ap available";
|
||||
}
|
||||
|
||||
AirPlane firstAirPlane = risingAirPlanes.get(0);
|
||||
return "a " + firstAirPlane.getPotencialDescriptionAsWord()
|
||||
+ " in " + firstAirPlane.getArrivingDurationMinutes() + " min";
|
||||
}
|
||||
|
||||
private String resolveSecondAirPlane(ChatMember selectedStation) {
|
||||
List<AirPlane> risingAirPlanes = getRisingAirPlanes(selectedStation);
|
||||
|
||||
if (risingAirPlanes.size() < 2) {
|
||||
return "";
|
||||
}
|
||||
|
||||
AirPlane secondAirPlane = risingAirPlanes.get(1);
|
||||
return "Next " + secondAirPlane.getPotencialDescriptionAsWord()
|
||||
+ " in " + secondAirPlane.getArrivingDurationMinutes() + " min";
|
||||
}
|
||||
|
||||
private List<AirPlane> getRisingAirPlanes(ChatMember selectedStation) {
|
||||
AirPlaneReflectionInfo reflectionInfo = selectedStation.getAirPlaneReflectInfo();
|
||||
|
||||
if (reflectionInfo == null || reflectionInfo.getRisingAirplanes() == null) {
|
||||
return List.of();
|
||||
}
|
||||
|
||||
return reflectionInfo.getRisingAirplanes();
|
||||
}
|
||||
|
||||
private String abbreviate(String value) {
|
||||
return value.substring(0, Math.min(value.length(), SHORT_VALUE_LENGTH));
|
||||
}
|
||||
|
||||
private String abbreviateLocator(String locator) {
|
||||
return locator.substring(0, Math.min(locator.length(), 4));
|
||||
}
|
||||
|
||||
private String formatHeading(double headingDegrees) {
|
||||
if (!Double.isFinite(headingDegrees)) {
|
||||
return "";
|
||||
}
|
||||
|
||||
return BigDecimal.valueOf(headingDegrees).stripTrailingZeros().toPlainString();
|
||||
}
|
||||
|
||||
private String valueOrEmpty(String value) {
|
||||
return value == null ? "" : value;
|
||||
}
|
||||
}
|
||||
@@ -1,842 +0,0 @@
|
||||
package kst4contest.controller;
|
||||
|
||||
import java.io.IOException;
|
||||
import java.net.InetSocketAddress;
|
||||
import java.net.Socket;
|
||||
import java.net.SocketException;
|
||||
import java.time.Duration;
|
||||
import java.time.LocalDateTime;
|
||||
import java.time.ZoneOffset;
|
||||
import java.time.format.DateTimeFormatter;
|
||||
import java.time.format.DateTimeParseException;
|
||||
import java.util.ArrayList;
|
||||
import java.util.Collection;
|
||||
import java.util.List;
|
||||
import java.util.Locale;
|
||||
import java.util.Map;
|
||||
import java.util.Set;
|
||||
import java.util.concurrent.ConcurrentHashMap;
|
||||
import java.util.concurrent.LinkedBlockingQueue;
|
||||
import java.util.concurrent.ScheduledExecutorService;
|
||||
import java.util.concurrent.Executors;
|
||||
import java.util.concurrent.TimeUnit;
|
||||
import java.util.concurrent.atomic.AtomicLong;
|
||||
import java.util.logging.Level;
|
||||
import java.util.logging.Logger;
|
||||
|
||||
import jdk.net.ExtendedSocketOptions;
|
||||
import kst4contest.ApplicationConstants;
|
||||
import kst4contest.model.ChatCategory;
|
||||
import kst4contest.model.ChatMember;
|
||||
import kst4contest.model.ChatMessage;
|
||||
import kst4contest.model.ChatPreferences;
|
||||
|
||||
/**
|
||||
* Owns the complete lifecycle of the single ON4KST TCP session.
|
||||
*
|
||||
* <p>Every reader, writer, queue and parser belongs to an immutable session id.
|
||||
* A delayed failure from an old socket can therefore never close or consume data
|
||||
* from its replacement.</p>
|
||||
*/
|
||||
final class On4KstConnectionManager {
|
||||
private static final Logger LOGGER =
|
||||
Logger.getLogger(On4KstConnectionManager.class.getName());
|
||||
private static final DateTimeFormatter LIVE_MESSAGE_TIMESTAMP =
|
||||
DateTimeFormatter.ofPattern("yyyyMMddHHmmss");
|
||||
|
||||
static final int CONNECT_TIMEOUT_MILLIS = 10_000; //TCP-Connect-Timeout
|
||||
static final long LOGIN_FALLBACK_MILLIS = 2_000L; //Login-Fallback
|
||||
static final long HANDSHAKE_TIMEOUT_MILLIS = 45_000L; //Handshake-Timeout
|
||||
static final long APPLICATION_HEARTBEAT_AFTER_MILLIS = 90_000L; //Application-Heartbeat
|
||||
static final long INBOUND_STALE_AFTER_MILLIS = 210_000L; //Stale-Timeout - time without rxed data
|
||||
static final List<Long> RECONNECT_DELAYS_MILLIS =
|
||||
List.of(2_000L, 5_000L, 10_000L, 20_000L, 30_000L); //Reconnect-Backoff if no connection possible
|
||||
|
||||
private final ChatController controller;
|
||||
private final ScheduledExecutorService scheduler;
|
||||
private final AtomicLong generation = new AtomicLong();
|
||||
private final AtomicLong lastReceivedMessageTimestamp = new AtomicLong();
|
||||
|
||||
private volatile Session activeSession;
|
||||
private volatile On4KstConnectionState state =
|
||||
On4KstConnectionState.DISCONNECTED;
|
||||
private volatile boolean stopRequested = true;
|
||||
private int reconnectAttempt;
|
||||
|
||||
On4KstConnectionManager(ChatController controller) {
|
||||
this.controller = controller;
|
||||
this.scheduler = Executors.newSingleThreadScheduledExecutor(runnable -> {
|
||||
Thread thread = new Thread(runnable, "On4KstConnectionSupervisor");
|
||||
thread.setDaemon(true);
|
||||
return thread;
|
||||
});
|
||||
this.scheduler.scheduleAtFixedRate(
|
||||
this::monitorActiveSession, 5L, 5L, TimeUnit.SECONDS);
|
||||
LOGGER.fine("ON4KST connection supervisor initialized");
|
||||
}
|
||||
|
||||
/**
|
||||
* Returns the last lifecycle state published by the connection supervisor.
|
||||
*
|
||||
* @return current immutable connection-state value
|
||||
*/
|
||||
On4KstConnectionState getState() {
|
||||
return state;
|
||||
}
|
||||
|
||||
/**
|
||||
* Verifies that a callback still belongs to the currently installed session.
|
||||
*
|
||||
* <p>Every reconnect receives a new id. Late EOF, write or parser callbacks from
|
||||
* an obsolete socket therefore become harmless instead of closing the replacement
|
||||
* connection.</p>
|
||||
*
|
||||
* @param sessionId id captured by the calling worker
|
||||
* @return {@code true} only for the current, open and non-stopped session
|
||||
*/
|
||||
boolean isActiveSession(long sessionId) {
|
||||
Session session = activeSession;
|
||||
return session != null
|
||||
&& session.id == sessionId
|
||||
&& !session.closed
|
||||
&& !stopRequested;
|
||||
}
|
||||
|
||||
/**
|
||||
* Starts a non-blocking connection attempt.
|
||||
*
|
||||
* <p>Configuration is validated before a socket is opened. A duplicate Connect
|
||||
* action is ignored while another attempt or session is active. Connection work
|
||||
* runs on the supervisor executor, so an unreachable server cannot block the
|
||||
* JavaFX application thread.</p>
|
||||
*/
|
||||
void start() {
|
||||
long token;
|
||||
synchronized (this) {
|
||||
if (!stopRequested && state.isConnectionAttemptActive()) {
|
||||
return;
|
||||
}
|
||||
|
||||
try {
|
||||
validateConfiguration();
|
||||
} catch (IllegalArgumentException invalidConfiguration) {
|
||||
stopRequested = true;
|
||||
transition(On4KstConnectionState.DISCONNECTED,
|
||||
"Invalid ON4KST configuration: "
|
||||
+ invalidConfiguration.getMessage(), true);
|
||||
return;
|
||||
}
|
||||
|
||||
stopRequested = false;
|
||||
reconnectAttempt = 0;
|
||||
token = generation.incrementAndGet();
|
||||
transition(On4KstConnectionState.CONNECTING,
|
||||
"Opening ON4KST connection", false);
|
||||
}
|
||||
|
||||
scheduler.execute(() -> openConnection(token));
|
||||
}
|
||||
|
||||
/**
|
||||
* Stops the current session and invalidates every scheduled callback or reconnect
|
||||
* belonging to it.
|
||||
*/
|
||||
void stopByUser() {
|
||||
Session oldSession;
|
||||
synchronized (this) {
|
||||
stopRequested = true;
|
||||
generation.incrementAndGet();
|
||||
transition(On4KstConnectionState.STOPPING,
|
||||
"Disconnecting from ON4KST", false);
|
||||
oldSession = activeSession;
|
||||
activeSession = null;
|
||||
}
|
||||
|
||||
closeSession(oldSession);
|
||||
controller.onOn4KstConnectionLost();
|
||||
transition(On4KstConnectionState.DISCONNECTED,
|
||||
"Disconnected by user", false);
|
||||
}
|
||||
|
||||
/**
|
||||
* Records one received protocol line as proof of application-level liveness.
|
||||
*
|
||||
* <p>TCP's {@code isConnected()} only states that a connection once succeeded.
|
||||
* It does not prove that the peer is still reachable. Updating the inbound
|
||||
* timestamp here gives the monitor a meaningful end-to-end signal.</p>
|
||||
*
|
||||
* @param sessionId immutable source-session id
|
||||
* @param line complete protocol line received from ON4KST
|
||||
*/
|
||||
void onInboundActivity(long sessionId, String line) {
|
||||
Session session = activeSession;
|
||||
if (session == null || session.id != sessionId || session.closed) {
|
||||
return;
|
||||
}
|
||||
|
||||
long now = System.currentTimeMillis();
|
||||
session.lastInboundMillis.set(now);
|
||||
session.lastProgressMillis.set(now);
|
||||
|
||||
String opcode = opcode(line);
|
||||
if ("CK".equals(opcode)) {
|
||||
sendHeartbeat(session);
|
||||
}
|
||||
|
||||
if (!session.loginSent
|
||||
&& line != null
|
||||
&& line.toLowerCase(Locale.ROOT).contains("login")) {
|
||||
scheduler.execute(() -> sendLogin(sessionId));
|
||||
}
|
||||
|
||||
if ("CH".equals(opcode) || "CR".equals(opcode)) {
|
||||
recordHistoryTimestamp(line);
|
||||
}
|
||||
}
|
||||
|
||||
void onLogstat(long sessionId, String[] fields) {
|
||||
String[] copy = fields == null ? new String[0] : fields.clone();
|
||||
scheduler.execute(() -> handleLogstat(sessionId, copy));
|
||||
}
|
||||
|
||||
void stageInitialChatMember(long sessionId, ChatMember member) {
|
||||
Session session = activeSession;
|
||||
if (session == null || session.id != sessionId || member == null
|
||||
|| member.getChatCategory() == null || member.getCallSign() == null) {
|
||||
return;
|
||||
}
|
||||
|
||||
int category = member.getChatCategory().getCategoryNumber();
|
||||
session.initialMembers
|
||||
.computeIfAbsent(category, ignored -> new ConcurrentHashMap<>())
|
||||
.put(member.getCallSign().trim().toUpperCase(Locale.ROOT), member);
|
||||
session.lastProgressMillis.set(System.currentTimeMillis());
|
||||
}
|
||||
|
||||
void onInitialUserListCompleted(long sessionId, ChatCategory category) {
|
||||
if (category == null) {
|
||||
return;
|
||||
}
|
||||
scheduler.execute(() -> completeInitialUserList(
|
||||
sessionId, category.getCategoryNumber()));
|
||||
}
|
||||
|
||||
private void openConnection(long token) {
|
||||
if (!mayOpen(token)) {
|
||||
return;
|
||||
}
|
||||
|
||||
LOGGER.log(Level.INFO,
|
||||
"Opening ON4KST TCP session {0}", token);
|
||||
Socket socket = new Socket();
|
||||
try {
|
||||
ChatPreferences preferences = controller.getChatPreferences();
|
||||
socket.connect(new InetSocketAddress(
|
||||
preferences.getStn_on4kstServersDns(),
|
||||
preferences.getStn_on4kstServersPort()),
|
||||
CONNECT_TIMEOUT_MILLIS);
|
||||
configureSocket(socket);
|
||||
LOGGER.log(Level.INFO,
|
||||
"ON4KST TCP session {0} connected to {1}",
|
||||
new Object[] {token, socket.getRemoteSocketAddress()});
|
||||
|
||||
LinkedBlockingQueue<ChatMessage> receiveQueue =
|
||||
new LinkedBlockingQueue<>();
|
||||
LinkedBlockingQueue<ChatMessage> transmitQueue =
|
||||
new LinkedBlockingQueue<>();
|
||||
Session session = new Session(token, socket, receiveQueue, transmitQueue);
|
||||
|
||||
ReadThread readThread = new ReadThread(
|
||||
token, socket, receiveQueue, this::isActiveSession,
|
||||
line -> onInboundActivity(token, line),
|
||||
failure -> onConnectionFailure(token, failure));
|
||||
WriteThread writeThread = new WriteThread(
|
||||
token, socket, transmitQueue,
|
||||
controller.getChatPreferences().getLoginChatCategoryMain()
|
||||
.getCategoryNumber(),
|
||||
this::isActiveSession,
|
||||
failure -> onConnectionFailure(token, failure),
|
||||
controller::onOn4KstOutboundFrameRejected);
|
||||
MessageBusManagementThread messageProcessor =
|
||||
new MessageBusManagementThread(
|
||||
controller, controller, token, receiveQueue,
|
||||
this::isActiveSession);
|
||||
|
||||
session.readThread = readThread;
|
||||
session.writeThread = writeThread;
|
||||
session.messageProcessor = messageProcessor;
|
||||
|
||||
synchronized (this) {
|
||||
if (!mayOpen(token)) {
|
||||
closeSession(session);
|
||||
return;
|
||||
}
|
||||
activeSession = session;
|
||||
controller.installOn4KstSession(
|
||||
token, socket, receiveQueue, transmitQueue,
|
||||
readThread, writeThread, messageProcessor);
|
||||
transition(On4KstConnectionState.WAITING_FOR_LOGIN_PROMPT,
|
||||
"TCP connected; waiting for ON4KST login prompt", false);
|
||||
}
|
||||
|
||||
messageProcessor.start();
|
||||
writeThread.start();
|
||||
readThread.start();
|
||||
scheduler.schedule(
|
||||
() -> sendLogin(token), LOGIN_FALLBACK_MILLIS,
|
||||
TimeUnit.MILLISECONDS);
|
||||
} catch (Throwable exception) {
|
||||
// Errors must be caught as well: an Error escaping here would be
|
||||
// swallowed by the scheduler and leave the state machine stuck in
|
||||
// CONNECTING without any reconnect attempt or user visible failure.
|
||||
try {
|
||||
socket.close();
|
||||
} catch (IOException ignored) {
|
||||
// The original connection exception is more useful.
|
||||
}
|
||||
scheduler.execute(() -> handleOpenFailure(token, exception));
|
||||
}
|
||||
}
|
||||
|
||||
private boolean mayOpen(long token) {
|
||||
return !stopRequested && generation.get() == token;
|
||||
}
|
||||
|
||||
private void sendLogin(long sessionId) {
|
||||
Session session = activeSession;
|
||||
if (session == null || session.id != sessionId || session.loginSent
|
||||
|| session.closed || stopRequested) {
|
||||
return;
|
||||
}
|
||||
|
||||
try {
|
||||
ChatPreferences preferences = controller.getChatPreferences();
|
||||
int mainCategory = preferences.getLoginChatCategoryMain()
|
||||
.getCategoryNumber();
|
||||
long historyFrom = Math.max(
|
||||
0L, lastReceivedMessageTimestamp.get() - 1L);
|
||||
String login = On4KstProtocol.login(
|
||||
preferences.getStn_loginCallSign(),
|
||||
preferences.getStn_loginPassword(),
|
||||
mainCategory,
|
||||
"KST4Contest v" + ApplicationConstants.APPLICATION_CURRENT_VERSION,
|
||||
historyFrom);
|
||||
|
||||
session.loginSent = true;
|
||||
session.lastProgressMillis.set(System.currentTimeMillis());
|
||||
LOGGER.log(Level.INFO,
|
||||
"Sending ON4KST login for session {0}, main category {1}",
|
||||
new Object[] {sessionId, mainCategory});
|
||||
transition(On4KstConnectionState.AUTHENTICATING,
|
||||
"ON4KST login sent", false);
|
||||
sendControl(session, login);
|
||||
} catch (IllegalArgumentException invalidConfiguration) {
|
||||
failPermanently(session,
|
||||
"Invalid ON4KST login configuration: "
|
||||
+ invalidConfiguration.getMessage());
|
||||
}
|
||||
}
|
||||
|
||||
private void handleLogstat(long sessionId, String[] fields) {
|
||||
Session session = activeSession;
|
||||
if (session == null || session.id != sessionId || session.closed) {
|
||||
return;
|
||||
}
|
||||
|
||||
String code = fields.length > 1 ? fields[1] : "";
|
||||
if (!"100".equals(code)) {
|
||||
String serverText = fields.length > 2 ? fields[2] : "Login rejected";
|
||||
failPermanently(session,
|
||||
"ON4KST login rejected (" + code + "): " + serverText);
|
||||
return;
|
||||
}
|
||||
|
||||
if (session.authenticated) {
|
||||
return;
|
||||
}
|
||||
session.authenticated = true;
|
||||
session.lastProgressMillis.set(System.currentTimeMillis());
|
||||
LOGGER.log(Level.INFO,
|
||||
"ON4KST login accepted for session {0}", sessionId);
|
||||
|
||||
int mainCategory = controller.getChatPreferences()
|
||||
.getLoginChatCategoryMain().getCategoryNumber();
|
||||
transition(On4KstConnectionState.SYNCING_MAIN_CHAT,
|
||||
"Login accepted; loading main chat", false);
|
||||
sendControl(session, On4KstProtocol.settingsDone(mainCategory));
|
||||
}
|
||||
|
||||
/**
|
||||
* Publishes the initial user snapshot for one chat category exactly once.
|
||||
*
|
||||
* <p>ON4KST can send further {@code UE} frames after live user updates or
|
||||
* after commands such as {@code SETNAME} and {@code BACK}. Those frames do
|
||||
* not announce a new, empty snapshot. Treating them as another initial-list
|
||||
* completion would remove the already published members because the staging
|
||||
* map was consumed by the first {@code UE} frame.</p>
|
||||
*
|
||||
* <p>The completed-category set is updated before the staging map is removed.
|
||||
* This makes the operation idempotent even if completion callbacks should
|
||||
* later be invoked from more than one thread. A genuinely empty initial list
|
||||
* remains valid: the first {@code UE} for a category is always processed,
|
||||
* even when no preceding valid {@code UA0} frame was staged.</p>
|
||||
*
|
||||
* @param sessionId immutable id of the socket session that received the frame
|
||||
* @param categoryNumber numeric ON4KST category terminated by {@code UE}
|
||||
*/
|
||||
private void completeInitialUserList(long sessionId, int categoryNumber) {
|
||||
Session session = activeSession;
|
||||
if (session == null || session.id != sessionId || session.closed) {
|
||||
return;
|
||||
}
|
||||
|
||||
if (!session.completedInitialUserLists.add(categoryNumber)) {
|
||||
LOGGER.log(Level.FINE,
|
||||
"ON4KST session {0}: ignoring duplicate user-list end "
|
||||
+ "marker for category {1}; the initial snapshot "
|
||||
+ "has already been published",
|
||||
new Object[] {sessionId, categoryNumber});
|
||||
return;
|
||||
}
|
||||
|
||||
Map<String, ChatMember> staged =
|
||||
session.initialMembers.remove(categoryNumber);
|
||||
Collection<ChatMember> completeMembers = staged == null
|
||||
? List.of()
|
||||
: new ArrayList<>(staged.values());
|
||||
|
||||
LOGGER.log(Level.INFO,
|
||||
"ON4KST session {0}: complete user list for category {1} "
|
||||
+ "contains {2} valid users",
|
||||
new Object[] {
|
||||
sessionId,
|
||||
categoryNumber,
|
||||
completeMembers.size()
|
||||
});
|
||||
|
||||
controller.replaceActiveChatMembersForCategory(
|
||||
sessionId,
|
||||
new ChatCategory(categoryNumber),
|
||||
completeMembers);
|
||||
|
||||
ChatPreferences preferences = controller.getChatPreferences();
|
||||
int mainCategory =
|
||||
preferences.getLoginChatCategoryMain().getCategoryNumber();
|
||||
|
||||
if (categoryNumber == mainCategory && !session.mainListComplete) {
|
||||
session.mainListComplete = true;
|
||||
configureMainChat(session);
|
||||
|
||||
if (hasDistinctSecondChat(preferences)) {
|
||||
int secondCategory =
|
||||
preferences.getLoginChatCategorySecond()
|
||||
.getCategoryNumber();
|
||||
|
||||
transition(
|
||||
On4KstConnectionState.SYNCING_SECOND_CHAT,
|
||||
"Main chat ready; loading second chat",
|
||||
false);
|
||||
|
||||
sendControl(
|
||||
session,
|
||||
On4KstProtocol.addChat(
|
||||
secondCategory,
|
||||
Math.max(
|
||||
0L,
|
||||
lastReceivedMessageTimestamp.get() - 1L)));
|
||||
} else {
|
||||
markOnline(session);
|
||||
}
|
||||
return;
|
||||
}
|
||||
|
||||
if (hasDistinctSecondChat(preferences)
|
||||
&& categoryNumber
|
||||
== preferences.getLoginChatCategorySecond()
|
||||
.getCategoryNumber()
|
||||
&& !session.secondListComplete) {
|
||||
session.secondListComplete = true;
|
||||
configureSecondChat(session);
|
||||
markOnline(session);
|
||||
}
|
||||
}
|
||||
|
||||
private void configureMainChat(Session session) {
|
||||
ChatPreferences preferences = controller.getChatPreferences();
|
||||
int category = preferences.getLoginChatCategoryMain().getCategoryNumber();
|
||||
sendControl(session, On4KstProtocol.setLocator(
|
||||
category, preferences.getStn_loginLocatorMainCat()));
|
||||
if (preferences.getStn_loginNameMainCat() != null
|
||||
&& !preferences.getStn_loginNameMainCat().isBlank()) {
|
||||
sendControl(session, On4KstProtocol.setName(
|
||||
category, preferences.getStn_loginNameMainCat()));
|
||||
}
|
||||
sendControl(session, On4KstProtocol.back(category));
|
||||
|
||||
String secondLocator = preferences.getStn_loginLocatorSecondCat();
|
||||
String mainLocator = preferences.getStn_loginLocatorMainCat();
|
||||
if (preferences.isLoginToSecondChatEnabled()
|
||||
&& secondLocator != null && !secondLocator.isBlank()
|
||||
&& !secondLocator.equalsIgnoreCase(mainLocator)) {
|
||||
controller.onOn4KstConnectionWarning(
|
||||
"ON4KST uses one locator per TCP session. The second-chat locator '"
|
||||
+ secondLocator + "' is ignored; using '" + mainLocator + "'.");
|
||||
}
|
||||
}
|
||||
|
||||
private void configureSecondChat(Session session) {
|
||||
ChatPreferences preferences = controller.getChatPreferences();
|
||||
int category = preferences.getLoginChatCategorySecond().getCategoryNumber();
|
||||
if (preferences.getStn_loginNameSecondCat() != null
|
||||
&& !preferences.getStn_loginNameSecondCat().isBlank()) {
|
||||
sendControl(session, On4KstProtocol.setName(
|
||||
category, preferences.getStn_loginNameSecondCat()));
|
||||
}
|
||||
sendControl(session, On4KstProtocol.back(category));
|
||||
}
|
||||
|
||||
private void markOnline(Session session) {
|
||||
if (!isActiveSession(session.id)) {
|
||||
return;
|
||||
}
|
||||
reconnectAttempt = 0;
|
||||
session.online = true;
|
||||
session.lastProgressMillis.set(System.currentTimeMillis());
|
||||
LOGGER.log(Level.INFO,
|
||||
"ON4KST session {0} is authenticated and synchronized",
|
||||
session.id);
|
||||
transition(On4KstConnectionState.ONLINE,
|
||||
"ON4KST session is authenticated and synchronized", false);
|
||||
controller.onOn4KstConnectionOnline();
|
||||
}
|
||||
|
||||
private void sendControl(Session session, String frame) {
|
||||
if (session == null || !isActiveSession(session.id)) {
|
||||
return;
|
||||
}
|
||||
ChatMessage message = new ChatMessage();
|
||||
message.setMessageDirectedToServer(true);
|
||||
message.setMessageText(frame);
|
||||
session.transmitQueue.offer(message);
|
||||
}
|
||||
|
||||
private void sendHeartbeat(Session session) {
|
||||
if (session == null || !isActiveSession(session.id)) {
|
||||
return;
|
||||
}
|
||||
long now = System.currentTimeMillis();
|
||||
session.lastHeartbeatMillis.set(now);
|
||||
LOGGER.log(Level.FINE,
|
||||
"Sending application heartbeat for ON4KST session {0}",
|
||||
session.id);
|
||||
ChatMessage heartbeat = new ChatMessage();
|
||||
heartbeat.setMessageDirectedToServer(true);
|
||||
heartbeat.setMessageText("");
|
||||
session.transmitQueue.offer(heartbeat);
|
||||
}
|
||||
|
||||
private void onConnectionFailure(long sessionId, Throwable failure) {
|
||||
scheduler.execute(() -> failSession(sessionId, failure));
|
||||
}
|
||||
|
||||
private void failSession(long sessionId, Throwable failure) {
|
||||
Session failedSession;
|
||||
synchronized (this) {
|
||||
failedSession = activeSession;
|
||||
if (failedSession == null || failedSession.id != sessionId
|
||||
|| failedSession.closed) {
|
||||
return;
|
||||
}
|
||||
activeSession = null;
|
||||
failedSession.closed = true;
|
||||
}
|
||||
|
||||
closeSession(failedSession);
|
||||
controller.onOn4KstConnectionLost();
|
||||
if (stopRequested) {
|
||||
transition(On4KstConnectionState.DISCONNECTED,
|
||||
"ON4KST connection stopped", false);
|
||||
return;
|
||||
}
|
||||
|
||||
scheduleReconnect(failure);
|
||||
}
|
||||
|
||||
private void handleOpenFailure(long token, Throwable failure) {
|
||||
if (!mayOpen(token)) {
|
||||
return;
|
||||
}
|
||||
controller.onOn4KstConnectionLost();
|
||||
scheduleReconnect(failure);
|
||||
}
|
||||
|
||||
private void scheduleReconnect(Throwable failure) {
|
||||
if (stopRequested) {
|
||||
transition(On4KstConnectionState.DISCONNECTED,
|
||||
"ON4KST connection stopped", false);
|
||||
return;
|
||||
}
|
||||
|
||||
String reason = describeFailure(failure);
|
||||
LOGGER.log(Level.WARNING,
|
||||
"ON4KST connection lost; automatic reconnect scheduled", failure);
|
||||
long delay = RECONNECT_DELAYS_MILLIS.get(Math.min(
|
||||
reconnectAttempt, RECONNECT_DELAYS_MILLIS.size() - 1));
|
||||
reconnectAttempt++;
|
||||
transition(On4KstConnectionState.RECONNECT_WAIT,
|
||||
"Connection lost (" + reason + "); reconnecting in "
|
||||
+ Duration.ofMillis(delay).toSeconds() + " s", true);
|
||||
|
||||
long nextToken = generation.incrementAndGet();
|
||||
scheduler.schedule(() -> {
|
||||
if (!mayOpen(nextToken)) {
|
||||
return;
|
||||
}
|
||||
transition(On4KstConnectionState.CONNECTING,
|
||||
"Reconnecting to ON4KST", false);
|
||||
openConnection(nextToken);
|
||||
}, delay, TimeUnit.MILLISECONDS);
|
||||
}
|
||||
|
||||
private void failPermanently(Session session, String reason) {
|
||||
if (session == null || !isActiveSession(session.id)) {
|
||||
return;
|
||||
}
|
||||
stopRequested = true;
|
||||
generation.incrementAndGet();
|
||||
activeSession = null;
|
||||
session.closed = true;
|
||||
closeSession(session);
|
||||
controller.onOn4KstConnectionLost();
|
||||
LOGGER.log(Level.WARNING, reason);
|
||||
transition(On4KstConnectionState.DISCONNECTED, reason, true);
|
||||
}
|
||||
|
||||
private void monitorActiveSession() {
|
||||
try {
|
||||
Session session = activeSession;
|
||||
if (session == null || session.closed || stopRequested) {
|
||||
return;
|
||||
}
|
||||
|
||||
if (session.socket.isClosed()) {
|
||||
failSession(session.id,
|
||||
new SocketException("Socket is closed"));
|
||||
return;
|
||||
}
|
||||
|
||||
long now = System.currentTimeMillis();
|
||||
if (!session.online
|
||||
&& now - session.lastProgressMillis.get()
|
||||
> HANDSHAKE_TIMEOUT_MILLIS) {
|
||||
failSession(session.id,
|
||||
new SocketException("ON4KST handshake timed out"));
|
||||
return;
|
||||
}
|
||||
|
||||
long inboundIdle = now - session.lastInboundMillis.get();
|
||||
if (inboundIdle > INBOUND_STALE_AFTER_MILLIS) {
|
||||
failSession(session.id,
|
||||
new SocketException("No ON4KST data received for "
|
||||
+ inboundIdle / 1_000L + " seconds"));
|
||||
return;
|
||||
}
|
||||
|
||||
if (inboundIdle > APPLICATION_HEARTBEAT_AFTER_MILLIS
|
||||
&& session.lastHeartbeatMillis.get()
|
||||
< session.lastInboundMillis.get()) {
|
||||
sendHeartbeat(session);
|
||||
}
|
||||
} catch (RuntimeException exception) {
|
||||
LOGGER.log(Level.WARNING,
|
||||
"ON4KST connection monitor failed", exception);
|
||||
}
|
||||
}
|
||||
|
||||
private void validateConfiguration() {
|
||||
ChatPreferences preferences = controller.getChatPreferences();
|
||||
On4KstProtocol.login(
|
||||
preferences.getStn_loginCallSign(),
|
||||
preferences.getStn_loginPassword(),
|
||||
preferences.getLoginChatCategoryMain().getCategoryNumber(),
|
||||
"KST4Contest v" + ApplicationConstants.APPLICATION_CURRENT_VERSION,
|
||||
0L);
|
||||
On4KstProtocol.locator(preferences.getStn_loginLocatorMainCat());
|
||||
if (preferences.getStn_loginNameMainCat() != null
|
||||
&& !preferences.getStn_loginNameMainCat().isBlank()) {
|
||||
On4KstProtocol.field(
|
||||
preferences.getStn_loginNameMainCat(), "main chat name");
|
||||
}
|
||||
|
||||
if (preferences.isLoginToSecondChatEnabled()) {
|
||||
if (preferences.getLoginChatCategorySecond() == null) {
|
||||
throw new IllegalArgumentException("Second chat has no category");
|
||||
}
|
||||
On4KstProtocol.category(
|
||||
preferences.getLoginChatCategorySecond().getCategoryNumber());
|
||||
if (preferences.getLoginChatCategorySecond().getCategoryNumber()
|
||||
== preferences.getLoginChatCategoryMain().getCategoryNumber()) {
|
||||
controller.onOn4KstConnectionWarning(
|
||||
"Second ON4KST chat equals the main chat and will not be added twice.");
|
||||
}
|
||||
if (preferences.getStn_loginNameSecondCat() != null
|
||||
&& !preferences.getStn_loginNameSecondCat().isBlank()) {
|
||||
On4KstProtocol.field(
|
||||
preferences.getStn_loginNameSecondCat(), "second chat name");
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
private boolean hasDistinctSecondChat(ChatPreferences preferences) {
|
||||
return preferences.isLoginToSecondChatEnabled()
|
||||
&& preferences.getLoginChatCategorySecond() != null
|
||||
&& preferences.getLoginChatCategorySecond().getCategoryNumber()
|
||||
!= preferences.getLoginChatCategoryMain().getCategoryNumber();
|
||||
}
|
||||
|
||||
private void configureSocket(Socket socket) throws IOException {
|
||||
socket.setTcpNoDelay(true);
|
||||
socket.setKeepAlive(true);
|
||||
|
||||
try {
|
||||
socket.setOption(ExtendedSocketOptions.TCP_KEEPIDLE, 45);
|
||||
socket.setOption(ExtendedSocketOptions.TCP_KEEPINTERVAL, 15);
|
||||
socket.setOption(ExtendedSocketOptions.TCP_KEEPCOUNT, 3);
|
||||
} catch (UnsupportedOperationException | IOException | LinkageError exception) {
|
||||
// LinkageError covers runtime images built without the jdk.net module;
|
||||
// the connection stays usable, only kernel side keepalive is missing.
|
||||
LOGGER.log(Level.INFO,
|
||||
"Platform does not support configurable TCP keepalive; "
|
||||
+ "application heartbeat remains active", exception);
|
||||
}
|
||||
}
|
||||
|
||||
private void closeSession(Session session) {
|
||||
if (session == null) {
|
||||
return;
|
||||
}
|
||||
LOGGER.log(Level.FINE,
|
||||
"Closing ON4KST session {0}", session.id);
|
||||
session.closed = true;
|
||||
if (session.readThread != null) {
|
||||
session.readThread.interrupt();
|
||||
}
|
||||
if (session.writeThread != null) {
|
||||
session.writeThread.interrupt();
|
||||
}
|
||||
if (session.messageProcessor != null) {
|
||||
session.messageProcessor.interrupt();
|
||||
}
|
||||
try {
|
||||
session.socket.close();
|
||||
} catch (IOException exception) {
|
||||
LOGGER.log(Level.FINE, "Error closing obsolete ON4KST socket", exception);
|
||||
}
|
||||
}
|
||||
|
||||
private void transition(
|
||||
On4KstConnectionState newState,
|
||||
String detail,
|
||||
boolean critical
|
||||
) {
|
||||
On4KstConnectionState previousState = state;
|
||||
state = newState;
|
||||
Level level = critical
|
||||
|| newState == On4KstConnectionState.DISCONNECTED
|
||||
|| newState == On4KstConnectionState.RECONNECT_WAIT
|
||||
? Level.WARNING : Level.INFO;
|
||||
LOGGER.log(level,
|
||||
"ON4KST state {0} -> {1}; detail: {2}",
|
||||
new Object[] {previousState, newState, detail});
|
||||
controller.updateOn4KstConnectionState(newState, detail, critical);
|
||||
}
|
||||
|
||||
private void recordHistoryTimestamp(String line) {
|
||||
long timestamp = parseMessageTimestamp(line);
|
||||
if (timestamp > 0L) {
|
||||
lastReceivedMessageTimestamp.accumulateAndGet(timestamp, Math::max);
|
||||
}
|
||||
}
|
||||
|
||||
static long parseMessageTimestamp(String line) {
|
||||
String[] fields = line == null ? new String[0] : line.split("\\|", -1);
|
||||
if (fields.length < 3) {
|
||||
return 0L;
|
||||
}
|
||||
|
||||
try {
|
||||
long numeric = Long.parseLong(fields[2]);
|
||||
long now = System.currentTimeMillis() / 1_000L;
|
||||
if (numeric > 0L && numeric <= now + 86_400L) {
|
||||
return numeric;
|
||||
}
|
||||
} catch (NumberFormatException ignored) {
|
||||
return 0L;
|
||||
}
|
||||
|
||||
try {
|
||||
return LocalDateTime.parse(fields[2], LIVE_MESSAGE_TIMESTAMP)
|
||||
.toEpochSecond(ZoneOffset.UTC);
|
||||
} catch (DateTimeParseException ignored) {
|
||||
return 0L;
|
||||
}
|
||||
}
|
||||
|
||||
private String opcode(String line) {
|
||||
if (line == null) {
|
||||
return "";
|
||||
}
|
||||
int separator = line.indexOf('|');
|
||||
return (separator < 0 ? line : line.substring(0, separator))
|
||||
.trim().toUpperCase(Locale.ROOT);
|
||||
}
|
||||
|
||||
private String describeFailure(Throwable failure) {
|
||||
if (failure == null) {
|
||||
return "unknown error";
|
||||
}
|
||||
String message = failure.getMessage();
|
||||
return message == null || message.isBlank()
|
||||
? failure.getClass().getSimpleName() : message;
|
||||
}
|
||||
|
||||
private static final class Session {
|
||||
private final Set<Integer> completedInitialUserLists =
|
||||
ConcurrentHashMap.newKeySet();
|
||||
|
||||
private final long id;
|
||||
private final Socket socket;
|
||||
private final LinkedBlockingQueue<ChatMessage> receiveQueue;
|
||||
private final LinkedBlockingQueue<ChatMessage> transmitQueue;
|
||||
private final long connectedMillis = System.currentTimeMillis();
|
||||
private final AtomicLong lastInboundMillis =
|
||||
new AtomicLong(connectedMillis);
|
||||
private final AtomicLong lastProgressMillis =
|
||||
new AtomicLong(connectedMillis);
|
||||
private final AtomicLong lastHeartbeatMillis = new AtomicLong();
|
||||
private final Map<Integer, Map<String, ChatMember>> initialMembers =
|
||||
new ConcurrentHashMap<>();
|
||||
|
||||
private volatile ReadThread readThread;
|
||||
private volatile WriteThread writeThread;
|
||||
private volatile MessageBusManagementThread messageProcessor;
|
||||
private volatile boolean loginSent;
|
||||
private volatile boolean authenticated;
|
||||
private volatile boolean mainListComplete;
|
||||
private volatile boolean secondListComplete;
|
||||
private volatile boolean online;
|
||||
private volatile boolean closed;
|
||||
|
||||
private Session(
|
||||
long id,
|
||||
Socket socket,
|
||||
LinkedBlockingQueue<ChatMessage> receiveQueue,
|
||||
LinkedBlockingQueue<ChatMessage> transmitQueue
|
||||
) {
|
||||
this.id = id;
|
||||
this.socket = socket;
|
||||
this.receiveQueue = receiveQueue;
|
||||
this.transmitQueue = transmitQueue;
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -1,50 +0,0 @@
|
||||
package kst4contest.controller;
|
||||
|
||||
/**
|
||||
* Observable lifecycle of the ON4KST TCP session.
|
||||
*
|
||||
* <p>A connected TCP socket is deliberately not synonymous with an authenticated
|
||||
* chat session. The intermediate states make that distinction visible to the UI
|
||||
* and prevent application messages from being sent in the wrong protocol context.</p>
|
||||
*/
|
||||
public enum On4KstConnectionState {
|
||||
DISCONNECTED,
|
||||
CONNECTING,
|
||||
WAITING_FOR_LOGIN_PROMPT,
|
||||
AUTHENTICATING,
|
||||
SYNCING_MAIN_CHAT,
|
||||
SYNCING_SECOND_CHAT,
|
||||
ONLINE,
|
||||
RECONNECT_WAIT,
|
||||
STOPPING;
|
||||
|
||||
/**
|
||||
* Returns whether the complete application-level ON4KST handshake has finished.
|
||||
*
|
||||
* @return {@code true} only after authentication and all requested user lists
|
||||
* have been synchronized
|
||||
*/
|
||||
public boolean isOnline() {
|
||||
return this == ONLINE;
|
||||
}
|
||||
|
||||
/**
|
||||
* Returns whether a connection attempt or usable session is currently owned by
|
||||
* the connection manager.
|
||||
*
|
||||
* <p>This is intentionally broader than {@link #isOnline()}. The UI uses it to
|
||||
* prevent a second Connect action while authentication, synchronization or a
|
||||
* scheduled reconnect is already in progress.</p>
|
||||
*
|
||||
* @return {@code true} while connecting, synchronizing, online or waiting for
|
||||
* an automatic reconnect
|
||||
*/
|
||||
public boolean isConnectionAttemptActive() {
|
||||
return switch (this) {
|
||||
case CONNECTING, WAITING_FOR_LOGIN_PROMPT, AUTHENTICATING,
|
||||
SYNCING_MAIN_CHAT, SYNCING_SECOND_CHAT, ONLINE,
|
||||
RECONNECT_WAIT -> true;
|
||||
default -> false;
|
||||
};
|
||||
}
|
||||
}
|
||||
@@ -1,192 +0,0 @@
|
||||
package kst4contest.controller;
|
||||
|
||||
import java.util.Locale;
|
||||
import java.util.regex.Pattern;
|
||||
|
||||
/**
|
||||
* Builds ON4KST port-23001 frames and rejects values that could break framing or
|
||||
* put the server into an invalid chat context.
|
||||
*
|
||||
* <p>All outbound protocol construction is concentrated here. User-controlled
|
||||
* values may therefore never introduce a field separator or a second line, and
|
||||
* category and locator validation happens before the frame reaches the socket.</p>
|
||||
*/
|
||||
final class On4KstProtocol {
|
||||
private static final Pattern LOCATOR_6 =
|
||||
Pattern.compile("^[A-Ra-r]{2}[0-9]{2}[A-Xa-x]{2}$");
|
||||
|
||||
private On4KstProtocol() {
|
||||
}
|
||||
|
||||
/**
|
||||
* Builds the initial authenticated login frame.
|
||||
*
|
||||
* @param callsign login callsign
|
||||
* @param password ON4KST password; never logged by this class
|
||||
* @param category primary chat category
|
||||
* @param clientName client identification sent to the server
|
||||
* @param lastMessageTimestamp earliest history timestamp to request
|
||||
* @return validated frame without CR/LF terminator
|
||||
*/
|
||||
static String login(
|
||||
String callsign,
|
||||
String password,
|
||||
int category,
|
||||
String clientName,
|
||||
long lastMessageTimestamp
|
||||
) {
|
||||
return "LOGINC|" + field(callsign, "callsign")
|
||||
+ "|" + password(password)
|
||||
+ "|" + category(category)
|
||||
+ "|" + field(clientName, "client name")
|
||||
+ "|25|0|1|" + Math.max(0L, lastMessageTimestamp) + "|0|";
|
||||
}
|
||||
|
||||
/** Builds the settings-complete frame for the supplied chat category. */
|
||||
static String settingsDone(int category) {
|
||||
return "SDONE|" + category(category) + "|";
|
||||
}
|
||||
|
||||
/** Builds the frame used to add a distinct second chat to the same session. */
|
||||
static String addChat(int category, long lastMessageTimestamp) {
|
||||
return "ACHAT|" + category(category)
|
||||
+ "|25|10|2|" + Math.max(0L, lastMessageTimestamp)
|
||||
+ "|0|";
|
||||
}
|
||||
|
||||
/** Builds a category-qualified locator command after validating Maidenhead syntax. */
|
||||
static String setLocator(int category, String locator) {
|
||||
return command(category, "/SETLOC " + locator(locator));
|
||||
}
|
||||
|
||||
/** Builds a category-qualified chat-name command. */
|
||||
static String setName(int category, String name) {
|
||||
return command(category, "/SETNAME " + field(name, "chat name"));
|
||||
}
|
||||
|
||||
/** Builds the command that changes the operator state back to available. */
|
||||
static String back(int category) {
|
||||
return command(category, "/BACK");
|
||||
}
|
||||
|
||||
/**
|
||||
* Wraps one validated slash command in an ON4KST message frame.
|
||||
*
|
||||
* @return frame without CR/LF terminator
|
||||
*/
|
||||
static String command(int category, String command) {
|
||||
return "MSG|" + category(category) + "|0|"
|
||||
+ messageText(command) + "|0|";
|
||||
}
|
||||
|
||||
/**
|
||||
* Wraps one operator chat message in a category-qualified ON4KST frame.
|
||||
*
|
||||
* @return frame without CR/LF terminator
|
||||
*/
|
||||
static String chatMessage(int category, String text) {
|
||||
return "MSG|" + category(category) + "|0|"
|
||||
+ messageText(text) + "|0|";
|
||||
}
|
||||
|
||||
/**
|
||||
* Removes trailing line terminators from a legacy raw frame while rejecting an
|
||||
* embedded line break that could inject a second server command.
|
||||
*
|
||||
* @param frame legacy raw frame, possibly with trailing CR/LF
|
||||
* @return exactly one normalized protocol line
|
||||
* @throws IllegalArgumentException if the value is {@code null} or contains an
|
||||
* embedded line break
|
||||
*/
|
||||
static String normalizeRawFrame(String frame) {
|
||||
if (frame == null) {
|
||||
throw new IllegalArgumentException("ON4KST frame must not be null");
|
||||
}
|
||||
|
||||
int end = frame.length();
|
||||
while (end > 0) {
|
||||
char last = frame.charAt(end - 1);
|
||||
if (last != '\r' && last != '\n') {
|
||||
break;
|
||||
}
|
||||
end--;
|
||||
}
|
||||
|
||||
String normalized = frame.substring(0, end);
|
||||
if (normalized.indexOf('\r') >= 0 || normalized.indexOf('\n') >= 0) {
|
||||
throw new IllegalArgumentException(
|
||||
"ON4KST frame contains an embedded line break");
|
||||
}
|
||||
return normalized;
|
||||
}
|
||||
|
||||
/**
|
||||
* Validates and normalizes a six-character Maidenhead locator.
|
||||
*
|
||||
* @return upper-case locator
|
||||
*/
|
||||
static String locator(String locator) {
|
||||
String normalized = field(locator, "locator").toUpperCase(Locale.ROOT);
|
||||
if (!LOCATOR_6.matcher(normalized).matches()) {
|
||||
throw new IllegalArgumentException(
|
||||
"Locator must be a six-character Maidenhead locator: " + normalized);
|
||||
}
|
||||
return normalized;
|
||||
}
|
||||
|
||||
/** Rejects message text containing an ON4KST field or line delimiter. */
|
||||
static String messageText(String text) {
|
||||
String value = field(text, "message text");
|
||||
if (value.indexOf('|') >= 0) {
|
||||
throw new IllegalArgumentException(
|
||||
"Message text contains the ON4KST field separator '|'");
|
||||
}
|
||||
return value;
|
||||
}
|
||||
|
||||
/**
|
||||
* Validates one required, non-password protocol field.
|
||||
*
|
||||
* @param value field value
|
||||
* @param label diagnostic label used in validation errors
|
||||
* @return trimmed value
|
||||
*/
|
||||
static String field(String value, String label) {
|
||||
if (value == null || value.isBlank()) {
|
||||
throw new IllegalArgumentException(label + " must not be empty");
|
||||
}
|
||||
if (value.indexOf('|') >= 0
|
||||
|| value.indexOf('\r') >= 0
|
||||
|| value.indexOf('\n') >= 0) {
|
||||
throw new IllegalArgumentException(
|
||||
label + " contains an ON4KST frame delimiter");
|
||||
}
|
||||
return value.trim();
|
||||
}
|
||||
|
||||
private static String password(String value) {
|
||||
if (value == null || value.isEmpty()) {
|
||||
throw new IllegalArgumentException("password must not be empty");
|
||||
}
|
||||
if (value.indexOf('|') >= 0
|
||||
|| value.indexOf('\r') >= 0
|
||||
|| value.indexOf('\n') >= 0) {
|
||||
throw new IllegalArgumentException(
|
||||
"password contains an ON4KST frame delimiter");
|
||||
}
|
||||
return value;
|
||||
}
|
||||
|
||||
/**
|
||||
* Validates the category range supported by ON4KST.
|
||||
*
|
||||
* @return the unchanged category for convenient inline use
|
||||
*/
|
||||
static int category(int category) {
|
||||
if (category < 1 || category > 12) {
|
||||
throw new IllegalArgumentException(
|
||||
"Unsupported ON4KST chat category: " + category);
|
||||
}
|
||||
return category;
|
||||
}
|
||||
}
|
||||
@@ -1,142 +0,0 @@
|
||||
package kst4contest.controller;
|
||||
|
||||
import static org.junit.jupiter.api.Assertions.assertEquals;
|
||||
import static org.junit.jupiter.api.Assertions.assertThrows;
|
||||
import static org.junit.jupiter.api.Assertions.assertDoesNotThrow;
|
||||
import static org.junit.jupiter.api.Assertions.assertEquals;
|
||||
import static org.junit.jupiter.api.Assertions.assertThrows;
|
||||
|
||||
import org.junit.jupiter.api.Test;
|
||||
|
||||
import java.time.LocalDateTime;
|
||||
import java.time.ZoneOffset;
|
||||
import kst4contest.model.ChatPreferences;
|
||||
|
||||
|
||||
class On4KstProtocolTest {
|
||||
@Test
|
||||
void buildsLoginWithReplayOverlap() {
|
||||
assertEquals(
|
||||
"LOGINC|DL1ABC|secret|2|KST4Contest v1.2.3|25|0|1|12344|0|",
|
||||
On4KstProtocol.login(
|
||||
"DL1ABC", "secret", 2,
|
||||
"KST4Contest v1.2.3", 12_344L));
|
||||
}
|
||||
|
||||
@Test
|
||||
void buildsContextSafeSecondChatFrames() {
|
||||
assertEquals("SDONE|2|", On4KstProtocol.settingsDone(2));
|
||||
assertEquals("ACHAT|3|25|10|2|100|0|",
|
||||
On4KstProtocol.addChat(3, 100L));
|
||||
assertEquals("MSG|2|0|/SETLOC JO31AA|0|",
|
||||
On4KstProtocol.setLocator(2, "jo31aa"));
|
||||
assertEquals("MSG|3|0|/SETNAME 10G 10368.200|0|",
|
||||
On4KstProtocol.setName(3, "10G 10368.200"));
|
||||
}
|
||||
|
||||
@Test
|
||||
void stripsOnlyTrailingLineEndings() {
|
||||
assertEquals("CK|", On4KstProtocol.normalizeRawFrame("CK|\r\n"));
|
||||
assertThrows(IllegalArgumentException.class,
|
||||
() -> On4KstProtocol.normalizeRawFrame("CK|\rBROKEN"));
|
||||
}
|
||||
|
||||
@Test
|
||||
void rejectsValuesThatCouldCreateASecondProtocolFrame() {
|
||||
assertThrows(IllegalArgumentException.class,
|
||||
() -> On4KstProtocol.chatMessage(2, "hello|0|"));
|
||||
assertThrows(IllegalArgumentException.class,
|
||||
() -> On4KstProtocol.chatMessage(2, "hello\r\nQUIT|"));
|
||||
assertThrows(IllegalArgumentException.class,
|
||||
() -> On4KstProtocol.login(
|
||||
"DL1ABC", "bad|password", 2, "client", 0L));
|
||||
}
|
||||
|
||||
@Test
|
||||
void rejectsInvalidLocatorAndCategoryBeforeTheyReachTheServer() {
|
||||
assertThrows(IllegalArgumentException.class,
|
||||
() -> On4KstProtocol.setLocator(2, "JO31"));
|
||||
assertThrows(IllegalArgumentException.class,
|
||||
() -> On4KstProtocol.settingsDone(99));
|
||||
}
|
||||
|
||||
@Test
|
||||
void convertsBothHistoryAndLiveMessageTimestampsForReconnect() {
|
||||
assertEquals(1_186_819_108L,
|
||||
On4KstConnectionManager.parseMessageTimestamp(
|
||||
"CR|2|1186819108|EA6VQ|Gabriel|0|msg|0|"));
|
||||
assertEquals(
|
||||
LocalDateTime.of(2026, 8, 13, 12, 34, 56)
|
||||
.toEpochSecond(ZoneOffset.UTC),
|
||||
On4KstConnectionManager.parseMessageTimestamp(
|
||||
"CH|2|20260813123456|DL1ABC|Op|0|msg|0|"));
|
||||
}
|
||||
|
||||
@Test
|
||||
void resolvesBeaconVariablesBeforeApplyingProtocolValidation() {
|
||||
ChatPreferences preferences = new ChatPreferences();
|
||||
preferences.setMYQRGFirstCat("144.300");
|
||||
|
||||
ChatController controller = new ChatController();
|
||||
controller.setChatPreferences(preferences);
|
||||
|
||||
controller.validateBeaconTemplate(
|
||||
"calling cq at MYQRG"
|
||||
);
|
||||
|
||||
assertEquals(
|
||||
"calling cq at 144.300",
|
||||
controller.resolveAndValidateBeaconText(
|
||||
"calling cq at MYQRG"
|
||||
)
|
||||
);
|
||||
}
|
||||
|
||||
@Test
|
||||
void acceptsTemporarilyUnresolvedVariableOnlyBeaconTemplate() {
|
||||
ChatPreferences preferences = new ChatPreferences();
|
||||
preferences.setMYQRGFirstCat("");
|
||||
|
||||
ChatController controller = new ChatController();
|
||||
controller.setChatPreferences(preferences);
|
||||
|
||||
assertDoesNotThrow(
|
||||
() -> controller.validateBeaconTemplate("MYQRG")
|
||||
);
|
||||
|
||||
assertThrows(
|
||||
IllegalArgumentException.class,
|
||||
() -> controller.resolveAndValidateBeaconText("MYQRG")
|
||||
);
|
||||
}
|
||||
|
||||
@Test
|
||||
void rejectsEmptyOverlongAndProtocolBreakingBeaconText() {
|
||||
ChatPreferences preferences = new ChatPreferences();
|
||||
|
||||
ChatController controller = new ChatController();
|
||||
controller.setChatPreferences(preferences);
|
||||
|
||||
assertThrows(
|
||||
IllegalArgumentException.class,
|
||||
() -> controller.validateBeaconTemplate(" ")
|
||||
);
|
||||
|
||||
assertThrows(
|
||||
IllegalArgumentException.class,
|
||||
() -> controller.validateBeaconTemplate(
|
||||
"cq at 144.300|0|QUIT"
|
||||
)
|
||||
);
|
||||
|
||||
assertThrows(
|
||||
IllegalArgumentException.class,
|
||||
() -> controller.validateBeaconTemplate(
|
||||
"x".repeat(
|
||||
ChatController.MAX_BEACON_TEXT_LENGTH
|
||||
+ 1
|
||||
)
|
||||
)
|
||||
);
|
||||
}
|
||||
}
|
||||
@@ -1,100 +0,0 @@
|
||||
package kst4contest.controller;
|
||||
|
||||
import static org.junit.jupiter.api.Assertions.assertEquals;
|
||||
|
||||
import java.io.BufferedReader;
|
||||
import java.io.OutputStreamWriter;
|
||||
import java.io.InputStreamReader;
|
||||
import java.net.ServerSocket;
|
||||
import java.net.Socket;
|
||||
import java.nio.charset.StandardCharsets;
|
||||
import java.time.Duration;
|
||||
import java.util.concurrent.CompletableFuture;
|
||||
import java.util.concurrent.LinkedBlockingQueue;
|
||||
import java.util.concurrent.TimeUnit;
|
||||
import java.util.concurrent.atomic.AtomicBoolean;
|
||||
|
||||
import org.junit.jupiter.api.Test;
|
||||
import org.junit.jupiter.api.Timeout;
|
||||
|
||||
import kst4contest.model.ChatMessage;
|
||||
|
||||
class On4KstSocketThreadTest {
|
||||
@Test
|
||||
@Timeout(5)
|
||||
void eofIsReportedImmediately() throws Exception {
|
||||
try (ServerSocket server = new ServerSocket(0)) {
|
||||
CompletableFuture<Void> serverDone = CompletableFuture.runAsync(() -> {
|
||||
try (Socket accepted = server.accept();
|
||||
OutputStreamWriter out = new OutputStreamWriter(
|
||||
accepted.getOutputStream(), StandardCharsets.UTF_8)) {
|
||||
out.write("CK|\r\n");
|
||||
out.flush();
|
||||
} catch (Exception exception) {
|
||||
throw new RuntimeException(exception);
|
||||
}
|
||||
});
|
||||
|
||||
try (Socket client = new Socket("127.0.0.1", server.getLocalPort())) {
|
||||
LinkedBlockingQueue<ChatMessage> queue = new LinkedBlockingQueue<>();
|
||||
AtomicBoolean active = new AtomicBoolean(true);
|
||||
CompletableFuture<Throwable> failure = new CompletableFuture<>();
|
||||
ReadThread reader = new ReadThread(
|
||||
7L, client, queue, ignored -> active.get(), ignored -> { },
|
||||
failure::complete);
|
||||
reader.start();
|
||||
|
||||
assertEquals("CK|", queue.poll(2, TimeUnit.SECONDS).getMessageText());
|
||||
failure.get(2, TimeUnit.SECONDS);
|
||||
active.set(false);
|
||||
reader.join(Duration.ofSeconds(2).toMillis());
|
||||
}
|
||||
serverDone.get(2, TimeUnit.SECONDS);
|
||||
}
|
||||
}
|
||||
|
||||
@Test
|
||||
@Timeout(5)
|
||||
void writerUsesOneExactCrLfPerFrameIncludingHeartbeat() throws Exception {
|
||||
try (ServerSocket server = new ServerSocket(0)) {
|
||||
CompletableFuture<String> firstLine = new CompletableFuture<>();
|
||||
CompletableFuture<String> secondLine = new CompletableFuture<>();
|
||||
CompletableFuture<Void> serverDone = CompletableFuture.runAsync(() -> {
|
||||
try (Socket accepted = server.accept();
|
||||
BufferedReader in = new BufferedReader(new InputStreamReader(
|
||||
accepted.getInputStream(), StandardCharsets.UTF_8))) {
|
||||
firstLine.complete(in.readLine());
|
||||
secondLine.complete(in.readLine());
|
||||
} catch (Exception exception) {
|
||||
throw new RuntimeException(exception);
|
||||
}
|
||||
});
|
||||
|
||||
try (Socket client = new Socket("127.0.0.1", server.getLocalPort())) {
|
||||
LinkedBlockingQueue<ChatMessage> queue = new LinkedBlockingQueue<>();
|
||||
AtomicBoolean active = new AtomicBoolean(true);
|
||||
WriteThread writer = new WriteThread(
|
||||
11L, client, queue, 2, ignored -> active.get(),
|
||||
ignored -> { }, ignored -> { });
|
||||
writer.start();
|
||||
|
||||
queue.add(serverFrame(""));
|
||||
queue.add(serverFrame("SDONE|2|\r"));
|
||||
assertEquals("", firstLine.get(2, TimeUnit.SECONDS));
|
||||
assertEquals("SDONE|2|", secondLine.get(2, TimeUnit.SECONDS));
|
||||
|
||||
active.set(false);
|
||||
writer.interrupt();
|
||||
writer.join(Duration.ofSeconds(2).toMillis());
|
||||
}
|
||||
serverDone.get(2, TimeUnit.SECONDS);
|
||||
}
|
||||
}
|
||||
|
||||
private ChatMessage serverFrame(String text) {
|
||||
ChatMessage message = new ChatMessage();
|
||||
message.setMessageDirectedToServer(true);
|
||||
message.setMessageText(text);
|
||||
return message;
|
||||
}
|
||||
}
|
||||
@@ -1,671 +0,0 @@
|
||||
package kst4contest.controller;
|
||||
import kst4contest.logic.BandOpportunityResolver;
|
||||
import kst4contest.view.map.MapCallsignRawSnapshot;
|
||||
import kst4contest.logic.PropagationFrequencyResolver;
|
||||
|
||||
import java.util.ArrayList;
|
||||
import java.util.Collections;
|
||||
import java.util.List;
|
||||
import java.util.Locale;
|
||||
import java.util.Map;
|
||||
import java.util.function.Consumer;
|
||||
|
||||
import javafx.application.Platform;
|
||||
import kst4contest.locatorUtils.Location;
|
||||
import kst4contest.model.Band;
|
||||
import kst4contest.model.ChatMember;
|
||||
import kst4contest.view.map.GeometryOnlyPathAnalysisService;
|
||||
|
||||
import kst4contest.view.map.OpenMeteoTerrainProfileProvider;
|
||||
import kst4contest.view.map.PathAnalysisRequest;
|
||||
import kst4contest.view.map.PathAnalysisResult;
|
||||
import kst4contest.view.map.PathAnalysisService;
|
||||
import kst4contest.view.map.PathGeometryUtils;
|
||||
import java.util.EnumSet;
|
||||
import java.util.Objects;
|
||||
import java.util.Set;
|
||||
import java.util.concurrent.ConcurrentHashMap;
|
||||
import java.util.concurrent.ExecutorService;
|
||||
import java.util.concurrent.Executors;
|
||||
import java.util.concurrent.ThreadFactory;
|
||||
import java.util.function.Consumer;
|
||||
|
||||
/**
|
||||
* Central service for tropo/path reachability calculations.
|
||||
*
|
||||
* <p>This service is now the single calculation path for:
|
||||
* <ul>
|
||||
* <li>the station table Tropo column</li>
|
||||
* <li>the Tropo filter/sorter</li>
|
||||
* <li>the station map path-analysis detail panel</li>
|
||||
* </ul>
|
||||
*
|
||||
* <p>The service always calculates a full {@link PathAnalysisResult}. When the
|
||||
* result contains a usable link budget, the bidirectional SSB margin is copied
|
||||
* into all matching {@link ChatMember} objects. The UI can then sort/filter by
|
||||
* a simple number while the map still receives the full path result.</p>
|
||||
*/
|
||||
public final class ReachabilityService {
|
||||
|
||||
private static final long FAILED_ANALYSIS_RETRY_DELAY_MS = 5L * 60L * 1000L;
|
||||
|
||||
private final ChatController chatController;
|
||||
private final PathAnalysisService pathAnalysisService;
|
||||
private final ExecutorService executor;
|
||||
|
||||
/**
|
||||
* Prevents duplicate jobs for the same path while a calculation is already
|
||||
* queued or running.
|
||||
*/
|
||||
private final Set<String> queuedCalculationKeys = ConcurrentHashMap.newKeySet();
|
||||
|
||||
|
||||
|
||||
/**
|
||||
* Stores completed usable path-analysis results. Failed/no-budget results are
|
||||
* not permanently cached so transient terrain/network problems can be retried.
|
||||
*/
|
||||
private final Map<String, PathAnalysisResult> pathAnalysisResultCache = new ConcurrentHashMap<>();
|
||||
|
||||
/**
|
||||
* Temporary callback list for map requests waiting for an already running
|
||||
* background calculation.
|
||||
*/
|
||||
private final Map<String, List<Consumer<PathAnalysisResult>>> pendingMapCallbacksByKey = new ConcurrentHashMap<>();
|
||||
|
||||
/**
|
||||
* Prevents immediate retry loops for failed/no-budget analyses, especially
|
||||
* when a TableView cell repeatedly asks for the same value.
|
||||
*/
|
||||
private final Map<String, Long> failedCalculationRetryAfterEpochMs = new ConcurrentHashMap<>();
|
||||
|
||||
public ReachabilityService(ChatController chatController) {
|
||||
this.chatController = Objects.requireNonNull(chatController, "chatController");
|
||||
this.pathAnalysisService = new GeometryOnlyPathAnalysisService(new OpenMeteoTerrainProfileProvider());
|
||||
this.executor = Executors.newSingleThreadExecutor(new ReachabilityThreadFactory());
|
||||
}
|
||||
|
||||
/**
|
||||
* Ensures that the automatically selected reachability band is calculated.
|
||||
*
|
||||
* @param member chatmember to evaluate
|
||||
*/
|
||||
public void ensureAutoTropoMarginCalculated(ChatMember member) {
|
||||
ensureTropoMarginCalculated(member, resolveAutoBand(member));
|
||||
}
|
||||
|
||||
/**
|
||||
* Ensures that a station/band SSB-margin value exists if it is already cached.
|
||||
*
|
||||
* <p>This method deliberately does not start online terrain analysis anymore.
|
||||
* It is safe to call from table cells and filters because it will not consume
|
||||
* API quota. Full calculations are now started only by explicit map/manual
|
||||
* requests.</p>
|
||||
*
|
||||
* @param member chatmember to evaluate
|
||||
* @param band band to evaluate
|
||||
*/
|
||||
public void ensureTropoMarginCalculated(ChatMember member, Band band) {
|
||||
if (member == null || band == null) {
|
||||
return;
|
||||
}
|
||||
|
||||
if (member.hasFiniteTropoSsbMarginDb(band)) {
|
||||
return;
|
||||
}
|
||||
|
||||
PathAnalysisRequest request = buildRequestForChatMember(member, band);
|
||||
if (request == null) {
|
||||
return;
|
||||
}
|
||||
|
||||
PathAnalysisResult cachedResult = pathAnalysisResultCache.get(buildCalculationKey(request));
|
||||
if (cachedResult != null) {
|
||||
storePathAnalysisResultInChatMembers(member, band, cachedResult);
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
|
||||
/**
|
||||
* Requests a full path analysis for the station map.
|
||||
*
|
||||
* <p>This is the only normal automatic entry point for online/full terrain
|
||||
* analysis. The map needs the full PathAnalysisResult, and the station table
|
||||
* needs the SSB margin. Both are produced here through the same calculation.</p>
|
||||
*
|
||||
* @param member best matching ChatMember, may be null when only a map snapshot exists
|
||||
* @param selectedSnapshot selected map snapshot
|
||||
* @param fxCallback callback executed on the JavaFX thread
|
||||
* @param requestedBandOverride operator-selected band, or null for automatic resolution
|
||||
*/
|
||||
public void requestPathAnalysisForMap(ChatMember member,
|
||||
MapCallsignRawSnapshot selectedSnapshot,
|
||||
Band requestedBandOverride,
|
||||
Consumer<PathAnalysisResult> fxCallback) {
|
||||
|
||||
String ownLocator6 = normalizeLocator6(chatController.getChatPreferences().getStn_loginLocatorMainCat());
|
||||
|
||||
if (selectedSnapshot == null) {
|
||||
dispatchFxCallback(fxCallback, PathAnalysisResult.waitingForSelection(ownLocator6));
|
||||
return;
|
||||
}
|
||||
|
||||
String targetLocator6 = normalizeLocator6(selectedSnapshot.locator6());
|
||||
|
||||
if (ownLocator6.length() != 6) {
|
||||
dispatchFxCallback(fxCallback,
|
||||
PathAnalysisResult.waitingForValidHomeLocator(ownLocator6, targetLocator6));
|
||||
return;
|
||||
}
|
||||
|
||||
if (!selectedSnapshot.hasUsablePosition()) {
|
||||
dispatchFxCallback(fxCallback,
|
||||
PathAnalysisResult.waitingForValidTarget(ownLocator6, targetLocator6));
|
||||
return;
|
||||
}
|
||||
|
||||
Band analysisBand;
|
||||
double analysisFrequencyMHz;
|
||||
|
||||
if (requestedBandOverride != null) {
|
||||
/*
|
||||
* An explicit operator selection has priority over automatic propagation
|
||||
* resolution. Exact recent QRG information on that band is still used
|
||||
* when available; otherwise the band's default analysis frequency is used.
|
||||
*/
|
||||
analysisBand = requestedBandOverride;
|
||||
analysisFrequencyMHz =
|
||||
resolveAnalysisFrequencyForBand(member, analysisBand);
|
||||
} else {
|
||||
PropagationFrequencyResolver.Resolution frequencyResolution =
|
||||
resolveAutomaticPropagationFrequency(member);
|
||||
|
||||
if (frequencyResolution == null) {
|
||||
dispatchFxCallback(
|
||||
fxCallback,
|
||||
PathAnalysisResult.waitingForUsableBand(
|
||||
ownLocator6,
|
||||
targetLocator6,
|
||||
selectedSnapshot.callSignRaw()
|
||||
)
|
||||
);
|
||||
return;
|
||||
}
|
||||
|
||||
analysisBand = frequencyResolution.getBand();
|
||||
analysisFrequencyMHz =
|
||||
frequencyResolution.getAnalysisFrequencyMHz();
|
||||
}
|
||||
|
||||
PathAnalysisRequest request = buildRequest(
|
||||
ownLocator6,
|
||||
selectedSnapshot.callSignRaw(),
|
||||
targetLocator6,
|
||||
selectedSnapshot.latitudeDeg(),
|
||||
selectedSnapshot.longitudeDeg(),
|
||||
analysisFrequencyMHz
|
||||
);
|
||||
|
||||
requestPathAnalysisAndStore(member, analysisBand, request, fxCallback);
|
||||
}
|
||||
|
||||
|
||||
|
||||
/**
|
||||
* Starts a full on-demand reachability calculation for one station row.
|
||||
*
|
||||
* <p>Use this for explicit operator actions only. It may call the online terrain
|
||||
* API and therefore must not be used from TableView cell factories or automatic
|
||||
* chat-join processing.</p>
|
||||
*
|
||||
* @param member station to calculate
|
||||
* @param band selected reachability band
|
||||
*/
|
||||
public void calculateSelectedStationOnDemand(ChatMember member, Band band) {
|
||||
if (member == null || band == null) {
|
||||
return;
|
||||
}
|
||||
|
||||
PathAnalysisRequest request = buildRequestForChatMember(member, band);
|
||||
if (request == null) {
|
||||
member.setTropoSsbMarginDb(band, Double.NaN);
|
||||
chatController.fireUserListUpdate("Reachability unavailable");
|
||||
return;
|
||||
}
|
||||
|
||||
requestPathAnalysisAndStore(member, band, request, null);
|
||||
}
|
||||
|
||||
/**
|
||||
* Resolves the auto reachability band through the shared propagation
|
||||
* frequency selection used by AirScout and path analysis.
|
||||
*
|
||||
* @param member member to inspect
|
||||
* @return resolved band
|
||||
*/
|
||||
public Band resolveAutoBand(ChatMember member) {
|
||||
PropagationFrequencyResolver.Resolution resolution =
|
||||
resolveAutomaticPropagationFrequency(member);
|
||||
return resolution == null ? null : resolution.getBand();
|
||||
}
|
||||
|
||||
/**
|
||||
* Resolves one automatic band and exact analysis frequency for a station.
|
||||
*
|
||||
* @param member any active category variant of the target station
|
||||
* @return shared propagation resolution, or {@code null} for unsupported data
|
||||
*/
|
||||
public PropagationFrequencyResolver.Resolution resolveAutomaticPropagationFrequency(
|
||||
ChatMember member
|
||||
) {
|
||||
return PropagationFrequencyResolver.resolve(
|
||||
resolveCallsignVariants(member),
|
||||
getEnabledStationBands(),
|
||||
System.currentTimeMillis()
|
||||
);
|
||||
}
|
||||
|
||||
/**
|
||||
* Returns the active own bands configured in the station preferences. High bands
|
||||
* above 10 GHz are intentionally ignored for the first version.
|
||||
*
|
||||
* @return set of enabled bands
|
||||
*/
|
||||
public EnumSet<Band> getEnabledStationBands() {
|
||||
return BandOpportunityResolver.getEnabledStationBands(
|
||||
chatController.getChatPreferences()
|
||||
);
|
||||
}
|
||||
|
||||
private List<ChatMember> resolveCallsignVariants(ChatMember member) {
|
||||
if (member == null) {
|
||||
return List.of();
|
||||
}
|
||||
|
||||
String rawCall = member.getCallSignRaw() != null
|
||||
? member.getCallSignRaw()
|
||||
: member.getCallSign();
|
||||
|
||||
List<ChatMember> variants = chatController.findActiveChatMembersByRawCall(rawCall);
|
||||
return variants.isEmpty() ? List.of(member) : variants;
|
||||
}
|
||||
|
||||
|
||||
|
||||
/**
|
||||
* Stops the background executor.
|
||||
*/
|
||||
public void shutdown() {
|
||||
executor.shutdownNow();
|
||||
}
|
||||
|
||||
/**
|
||||
* Starts or reuses one shared path-analysis calculation.
|
||||
*
|
||||
* @param member matching ChatMember, may be null for map-only snapshots
|
||||
* @param band band under which the value is stored in ChatMember
|
||||
* @param request full path-analysis request
|
||||
* @param fxCallback optional map callback
|
||||
*/
|
||||
private void requestPathAnalysisAndStore(ChatMember member,
|
||||
Band band,
|
||||
PathAnalysisRequest request,
|
||||
Consumer<PathAnalysisResult> fxCallback) {
|
||||
|
||||
if (request == null || band == null) {
|
||||
return;
|
||||
}
|
||||
|
||||
String calculationKey = buildCalculationKey(request);
|
||||
|
||||
PathAnalysisResult cachedResult = pathAnalysisResultCache.get(calculationKey);
|
||||
if (cachedResult != null) {
|
||||
storePathAnalysisResultInChatMembers(member, band, cachedResult);
|
||||
dispatchFxCallback(fxCallback, cachedResult);
|
||||
return;
|
||||
}
|
||||
|
||||
Long retryAfterEpochMs = failedCalculationRetryAfterEpochMs.get(calculationKey);
|
||||
if (retryAfterEpochMs != null && System.currentTimeMillis() < retryAfterEpochMs) {
|
||||
dispatchFxCallback(fxCallback, createNoProfileResult(
|
||||
request,
|
||||
"Previous path analysis failed or the terrain API limit was reached. Retry is delayed briefly."
|
||||
));
|
||||
return;
|
||||
}
|
||||
|
||||
addPendingCallback(calculationKey, fxCallback);
|
||||
|
||||
if (!queuedCalculationKeys.add(calculationKey)) {
|
||||
return;
|
||||
}
|
||||
|
||||
executor.submit(() -> {
|
||||
PathAnalysisResult result;
|
||||
|
||||
try {
|
||||
result = pathAnalysisService.analyze(request);
|
||||
if (result == null) {
|
||||
result = createNoProfileResult(request, "Path analysis returned no result.");
|
||||
}
|
||||
} catch (Exception exception) {
|
||||
result = createNoProfileResult(
|
||||
request,
|
||||
"Path analysis failed: " + exception.getMessage()
|
||||
);
|
||||
}
|
||||
|
||||
boolean usableBudget = hasUsableLinkBudget(result);
|
||||
|
||||
if (usableBudget) {
|
||||
pathAnalysisResultCache.put(calculationKey, result);
|
||||
failedCalculationRetryAfterEpochMs.remove(calculationKey);
|
||||
} else {
|
||||
failedCalculationRetryAfterEpochMs.put(
|
||||
calculationKey,
|
||||
System.currentTimeMillis() + FAILED_ANALYSIS_RETRY_DELAY_MS
|
||||
);
|
||||
}
|
||||
|
||||
queuedCalculationKeys.remove(calculationKey);
|
||||
|
||||
PathAnalysisResult finalResult = result;
|
||||
Runnable updateTask = () -> {
|
||||
storePathAnalysisResultInChatMembers(member, band, finalResult);
|
||||
dispatchAndClearPendingCallbacks(calculationKey, finalResult);
|
||||
chatController.fireUserListUpdate("Reachability calculated");
|
||||
};
|
||||
|
||||
if (Platform.isFxApplicationThread()) {
|
||||
updateTask.run();
|
||||
} else {
|
||||
Platform.runLater(updateTask);
|
||||
}
|
||||
});
|
||||
}
|
||||
|
||||
/**
|
||||
* Builds a path-analysis request from a ChatMember row.
|
||||
*
|
||||
* @param member station row
|
||||
* @param band selected reachability band
|
||||
* @return request or null if locators are not usable
|
||||
*/
|
||||
private PathAnalysisRequest buildRequestForChatMember(ChatMember member, Band band) {
|
||||
String ownLocator6 = normalizeLocator6(chatController.getChatPreferences().getStn_loginLocatorMainCat());
|
||||
String targetLocator6 = normalizeLocator6(member.getQra());
|
||||
|
||||
if (ownLocator6.length() != 6 || targetLocator6.length() != 6) {
|
||||
return null;
|
||||
}
|
||||
|
||||
Location targetLocation = new Location(targetLocator6);
|
||||
double analysisFrequencyMHz = resolveAnalysisFrequencyForBand(member, band);
|
||||
|
||||
return buildRequest(
|
||||
ownLocator6,
|
||||
member.getCallSignRaw(),
|
||||
targetLocator6,
|
||||
targetLocation.getLatitude().toDegrees(),
|
||||
targetLocation.getLongitude().toDegrees(),
|
||||
analysisFrequencyMHz
|
||||
);
|
||||
}
|
||||
|
||||
/**
|
||||
* Builds the shared PathAnalysisRequest used by map and table/manual requests.
|
||||
*/
|
||||
private PathAnalysisRequest buildRequest(String ownLocator6,
|
||||
String targetCallsignRaw,
|
||||
String targetLocator6,
|
||||
double targetLatitudeDeg,
|
||||
double targetLongitudeDeg,
|
||||
double analysisFrequencyMHz) {
|
||||
|
||||
Location homeLocation = new Location(ownLocator6);
|
||||
|
||||
return new PathAnalysisRequest(
|
||||
ownLocator6,
|
||||
homeLocation.getLatitude().toDegrees(),
|
||||
homeLocation.getLongitude().toDegrees(),
|
||||
targetCallsignRaw,
|
||||
targetLocator6,
|
||||
targetLatitudeDeg,
|
||||
targetLongitudeDeg,
|
||||
analysisFrequencyMHz,
|
||||
chatController.getChatPreferences().getStn_pathAnalysisOwnAntennaHeightMeters(),
|
||||
chatController.getChatPreferences().getStn_pathAnalysisDefaultTargetAntennaHeightMeters(),
|
||||
PathGeometryUtils.DEFAULT_EFFECTIVE_EARTH_RADIUS_FACTOR,
|
||||
chatController.getChatPreferences().buildPathLinkBudgetSettings()
|
||||
);
|
||||
}
|
||||
|
||||
/**
|
||||
* Stores the SSB margin from a completed analysis in all matching ChatMember
|
||||
* objects. Matching uses raw callsign and locator.
|
||||
*/
|
||||
private void storePathAnalysisResultInChatMembers(ChatMember primaryMember,
|
||||
Band band,
|
||||
PathAnalysisResult result) {
|
||||
|
||||
if (band == null || result == null) {
|
||||
return;
|
||||
}
|
||||
|
||||
double marginDb = hasUsableLinkBudget(result)
|
||||
? result.linkBudgetSummary().bidirectionalSsbMarginDb()
|
||||
: Double.NaN;
|
||||
|
||||
if (primaryMember != null) {
|
||||
primaryMember.setTropoSsbMarginDb(band, marginDb);
|
||||
}
|
||||
|
||||
String resultCallSignRaw = normalizeCallsignRaw(result.toCallsignRaw());
|
||||
String resultLocator6 = normalizeLocator6(result.toLocator6());
|
||||
|
||||
for (ChatMember member : chatController.snapshotChatMembers()) {
|
||||
if (member == null) {
|
||||
continue;
|
||||
}
|
||||
|
||||
String memberCallSignRaw = normalizeCallsignRaw(member.getCallSignRaw());
|
||||
if (!resultCallSignRaw.isBlank() && !resultCallSignRaw.equals(memberCallSignRaw)) {
|
||||
continue;
|
||||
}
|
||||
|
||||
String memberLocator6 = normalizeLocator6(member.getQra());
|
||||
if (!resultLocator6.isBlank() && !resultLocator6.equals(memberLocator6)) {
|
||||
continue;
|
||||
}
|
||||
|
||||
member.setTropoSsbMarginDb(band, marginDb);
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
|
||||
/**
|
||||
* Resolves the analysis frequency for one member/band pair.
|
||||
*
|
||||
* <p>Preference order:
|
||||
* <ol>
|
||||
* <li>knownActiveBands frequency for the band</li>
|
||||
* <li>current displayed QRG if it belongs to the same band</li>
|
||||
* <li>band default frequency</li>
|
||||
* </ol>
|
||||
*/
|
||||
private double resolveAnalysisFrequencyForBand(ChatMember member, Band band) {
|
||||
if (band == null) {
|
||||
return Double.NaN;
|
||||
}
|
||||
|
||||
ChatMember.ActiveFrequencyInfo latestFrequencyInfo = null;
|
||||
for (ChatMember variant : resolveCallsignVariants(member)) {
|
||||
ChatMember.ActiveFrequencyInfo activeFrequencyInfo =
|
||||
variant.getKnownActiveBands().get(band);
|
||||
|
||||
if (activeFrequencyInfo != null
|
||||
&& Double.isFinite(activeFrequencyInfo.frequency)
|
||||
&& activeFrequencyInfo.frequency > 0.0
|
||||
&& (latestFrequencyInfo == null
|
||||
|| activeFrequencyInfo.timestampEpoch > latestFrequencyInfo.timestampEpoch)) {
|
||||
latestFrequencyInfo = activeFrequencyInfo;
|
||||
}
|
||||
}
|
||||
|
||||
if (latestFrequencyInfo != null) {
|
||||
return latestFrequencyInfo.frequency;
|
||||
}
|
||||
|
||||
if (member != null && member.getFrequency() != null && member.getFrequency().getValue() != null) {
|
||||
double parsedFrequencyMHz = PathGeometryUtils.tryParseFrequencyMHz(member.getFrequency().getValue());
|
||||
if (Double.isFinite(parsedFrequencyMHz) && parsedFrequencyMHz > 0.0) {
|
||||
Band parsedBand = Band.fromFrequency(parsedFrequencyMHz);
|
||||
if (parsedBand == null || parsedBand == band) {
|
||||
return parsedFrequencyMHz;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
return band.getDefaultAnalysisFrequencyMHz();
|
||||
}
|
||||
|
||||
/**
|
||||
* Adds a map callback to the pending callback list for one calculation key.
|
||||
*
|
||||
* @param calculationKey path key
|
||||
* @param fxCallback callback to add
|
||||
*/
|
||||
private void addPendingCallback(String calculationKey, Consumer<PathAnalysisResult> fxCallback) {
|
||||
if (fxCallback == null) {
|
||||
return;
|
||||
}
|
||||
|
||||
pendingMapCallbacksByKey
|
||||
.computeIfAbsent(
|
||||
calculationKey,
|
||||
ignored -> Collections.synchronizedList(new ArrayList<>())
|
||||
)
|
||||
.add(fxCallback);
|
||||
}
|
||||
|
||||
/**
|
||||
* Dispatches and removes all callbacks waiting for one completed calculation.
|
||||
*
|
||||
* @param calculationKey path key
|
||||
* @param result completed result
|
||||
*/
|
||||
private void dispatchAndClearPendingCallbacks(String calculationKey, PathAnalysisResult result) {
|
||||
List<Consumer<PathAnalysisResult>> callbacks = pendingMapCallbacksByKey.remove(calculationKey);
|
||||
if (callbacks == null || callbacks.isEmpty()) {
|
||||
return;
|
||||
}
|
||||
|
||||
List<Consumer<PathAnalysisResult>> callbackSnapshot;
|
||||
synchronized (callbacks) {
|
||||
callbackSnapshot = new ArrayList<>(callbacks);
|
||||
}
|
||||
|
||||
for (Consumer<PathAnalysisResult> callback : callbackSnapshot) {
|
||||
dispatchFxCallback(callback, result);
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Executes a map callback on the JavaFX application thread.
|
||||
*
|
||||
* @param fxCallback callback to execute
|
||||
* @param result result to pass
|
||||
*/
|
||||
private void dispatchFxCallback(Consumer<PathAnalysisResult> fxCallback, PathAnalysisResult result) {
|
||||
if (fxCallback == null) {
|
||||
return;
|
||||
}
|
||||
|
||||
if (Platform.isFxApplicationThread()) {
|
||||
fxCallback.accept(result);
|
||||
} else {
|
||||
Platform.runLater(() -> fxCallback.accept(result));
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Checks whether the result contains a usable link-budget summary.
|
||||
*
|
||||
* @param result path-analysis result
|
||||
* @return true if SSB margin can be read
|
||||
*/
|
||||
private boolean hasUsableLinkBudget(PathAnalysisResult result) {
|
||||
return result != null
|
||||
&& result.linkBudgetSummary() != null
|
||||
&& result.linkBudgetSummary().hasUsableBudget();
|
||||
}
|
||||
|
||||
/**
|
||||
* Creates a no-profile/no-budget result for failed service calculations.
|
||||
*
|
||||
* @param request original request
|
||||
* @param statusText status shown in the map detail panel
|
||||
* @return placeholder path result
|
||||
*/
|
||||
private PathAnalysisResult createNoProfileResult(PathAnalysisRequest request, String statusText) {
|
||||
return PathAnalysisResult.noProfile(
|
||||
"Reachability",
|
||||
request.fromLocator6(),
|
||||
request.toLocator6(),
|
||||
request.toCallsignRaw(),
|
||||
Double.NaN,
|
||||
Double.NaN,
|
||||
request.homeAntennaHeightMeters(),
|
||||
request.targetAntennaHeightMeters(),
|
||||
request.frequencyMHz(),
|
||||
statusText
|
||||
);
|
||||
}
|
||||
|
||||
/**
|
||||
* Builds a stable calculation key.
|
||||
*
|
||||
* <p>The key includes station, locators, frequency, antenna heights and link
|
||||
* budget settings. If any relevant input changes, a new calculation is allowed.</p>
|
||||
*/
|
||||
private String buildCalculationKey(PathAnalysisRequest request) {
|
||||
return normalizeLocator6(request.fromLocator6())
|
||||
+ "|"
|
||||
+ normalizeCallsignRaw(request.toCallsignRaw())
|
||||
+ "|"
|
||||
+ normalizeLocator6(request.toLocator6())
|
||||
+ "|"
|
||||
+ String.format(Locale.US, "%.5f", request.toLatitudeDeg())
|
||||
+ "|"
|
||||
+ String.format(Locale.US, "%.5f", request.toLongitudeDeg())
|
||||
+ "|"
|
||||
+ String.format(Locale.US, "%.3f", request.frequencyMHz())
|
||||
+ "|"
|
||||
+ String.format(Locale.US, "%.1f", request.homeAntennaHeightMeters())
|
||||
+ "|"
|
||||
+ String.format(Locale.US, "%.1f", request.targetAntennaHeightMeters())
|
||||
+ "|"
|
||||
+ request.linkBudgetSettings();
|
||||
}
|
||||
|
||||
private String normalizeCallsignRaw(String callSignRaw) {
|
||||
return callSignRaw == null ? "" : callSignRaw.trim().toUpperCase(Locale.ROOT);
|
||||
}
|
||||
|
||||
private String normalizeLocator6(String locator) {
|
||||
return locator == null ? "" : locator.trim().toUpperCase(Locale.ROOT);
|
||||
}
|
||||
|
||||
|
||||
|
||||
private static final class ReachabilityThreadFactory implements ThreadFactory {
|
||||
@Override
|
||||
public Thread newThread(Runnable runnable) {
|
||||
Thread thread = new Thread(runnable, "reachability-service");
|
||||
thread.setDaemon(true);
|
||||
return thread;
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -1,130 +1,118 @@
|
||||
package kst4contest.controller;
|
||||
|
||||
import java.io.BufferedReader;
|
||||
import java.io.EOFException;
|
||||
import java.io.IOException;
|
||||
import java.io.InputStreamReader;
|
||||
import java.net.Socket;
|
||||
import java.io.*;
|
||||
import java.net.*;
|
||||
import java.nio.charset.StandardCharsets;
|
||||
import java.util.concurrent.LinkedBlockingQueue;
|
||||
import java.util.function.Consumer;
|
||||
import java.util.function.LongPredicate;
|
||||
import java.util.logging.Level;
|
||||
import java.util.logging.Logger;
|
||||
|
||||
import kst4contest.model.ChatMessage;
|
||||
|
||||
/**
|
||||
* Reads exactly one immutable ON4KST connection session.
|
||||
* This thread is responsible for reading telnet servers input at port 23001 and printing it
|
||||
* to the console.
|
||||
* It runs in an infinite loop until the client disconnects from the server.
|
||||
*
|
||||
* <p>EOF is a connection-loss event, not an empty chat message. Every line is
|
||||
* associated with the session id captured by this reader, so a delayed exception
|
||||
* from an obsolete socket cannot affect a newer reconnect.</p>
|
||||
* @author www.codejava.net
|
||||
*/
|
||||
public class ReadThread extends Thread {
|
||||
private static final Logger LOGGER = Logger.getLogger(ReadThread.class.getName());
|
||||
private BufferedReader reader;
|
||||
private Socket socket;
|
||||
private ChatController client;
|
||||
public boolean accidentalDisconnected;
|
||||
|
||||
private final long sessionId;
|
||||
private final Socket socket;
|
||||
private final LinkedBlockingQueue<ChatMessage> receiveQueue;
|
||||
private final LongPredicate sessionIsActive;
|
||||
private final Consumer<String> inboundActivity;
|
||||
private final Consumer<Throwable> connectionFailure;
|
||||
private final BufferedReader reader;
|
||||
|
||||
/**
|
||||
* Compatibility constructor for the pre-session controller path.
|
||||
*
|
||||
* @deprecated new connections should be created by
|
||||
* {@link On4KstConnectionManager}
|
||||
*/
|
||||
@Deprecated
|
||||
public ReadThread(Socket socket, ChatController client) throws IOException {
|
||||
this(0L, socket, client.getMessageRXBus(), ignored -> true,
|
||||
ignored -> { }, ignored -> { });
|
||||
}
|
||||
|
||||
/**
|
||||
* Creates the reader for one connection generation.
|
||||
*
|
||||
* @param sessionId immutable id of the owning socket session
|
||||
* @param socket connected ON4KST socket
|
||||
* @param receiveQueue private receive queue belonging to this session
|
||||
* @param sessionIsActive guard against callbacks from an obsolete session
|
||||
* @param inboundActivity callback used for liveness and protocol progress
|
||||
* @param connectionFailure callback for EOF, I/O and unexpected runtime errors
|
||||
* @throws IOException if the socket input stream cannot be opened
|
||||
*/
|
||||
public ReadThread(
|
||||
long sessionId,
|
||||
Socket socket,
|
||||
LinkedBlockingQueue<ChatMessage> receiveQueue,
|
||||
LongPredicate sessionIsActive,
|
||||
Consumer<String> inboundActivity,
|
||||
Consumer<Throwable> connectionFailure
|
||||
) throws IOException {
|
||||
this.sessionId = sessionId;
|
||||
public boolean isAccidentalDisconnected() {
|
||||
return accidentalDisconnected;
|
||||
}
|
||||
|
||||
public void setAccidentalDisconnected(boolean accidentalDisconnected) {
|
||||
this.accidentalDisconnected = accidentalDisconnected;
|
||||
}
|
||||
|
||||
// private boolean readingFinished = true; //kst4contest.test 4 23001
|
||||
private boolean readingFinished = true;
|
||||
|
||||
InputStream input;
|
||||
|
||||
public ReadThread(Socket socket, ChatController client) {
|
||||
this.socket = socket;
|
||||
this.receiveQueue = receiveQueue;
|
||||
this.sessionIsActive = sessionIsActive;
|
||||
this.inboundActivity = inboundActivity;
|
||||
this.connectionFailure = connectionFailure;
|
||||
this.reader = new BufferedReader(new InputStreamReader(
|
||||
socket.getInputStream(), StandardCharsets.UTF_8));
|
||||
}
|
||||
|
||||
@Override
|
||||
public void run() {
|
||||
Thread.currentThread().setName("ReadFromOn4Kst-" + sessionId);
|
||||
LOGGER.log(Level.FINE,
|
||||
"ON4KST reader started for session {0}", sessionId);
|
||||
this.client = client;
|
||||
|
||||
try {
|
||||
while (!isInterrupted() && sessionIsActive.test(sessionId)) {
|
||||
String response = reader.readLine();
|
||||
if (response == null) {
|
||||
throw new EOFException("ON4KST closed the TCP connection");
|
||||
}
|
||||
input = socket.getInputStream();
|
||||
reader = new BufferedReader(new InputStreamReader(input, StandardCharsets.UTF_8));
|
||||
|
||||
inboundActivity.accept(response);
|
||||
if (!sessionIsActive.test(sessionId)) {
|
||||
break;
|
||||
}
|
||||
|
||||
ChatMessage message = new ChatMessage();
|
||||
message.setMessageText(response);
|
||||
receiveQueue.put(message);
|
||||
}
|
||||
} catch (InterruptedException interrupted) {
|
||||
Thread.currentThread().interrupt();
|
||||
} catch (IOException exception) {
|
||||
if (sessionIsActive.test(sessionId)) {
|
||||
LOGGER.log(Level.FINE,
|
||||
"ON4KST read failed for session " + sessionId,
|
||||
exception);
|
||||
connectionFailure.accept(exception);
|
||||
}
|
||||
} catch (RuntimeException exception) {
|
||||
if (sessionIsActive.test(sessionId)) {
|
||||
LOGGER.log(Level.SEVERE, "Unexpected ON4KST reader failure", exception);
|
||||
connectionFailure.accept(exception);
|
||||
}
|
||||
} finally {
|
||||
LOGGER.log(Level.FINE,
|
||||
"ON4KST reader stopped for session {0}", sessionId);
|
||||
} catch (IOException ex) {
|
||||
System.out.println("Error getting input stream: " + ex.getMessage());
|
||||
ex.printStackTrace();
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Interrupts the read loop and closes the session socket.
|
||||
*
|
||||
* @return always {@code true} after a successful close
|
||||
* @throws IOException if closing the reader or socket fails
|
||||
*/
|
||||
public boolean terminateConnection() throws IOException {
|
||||
interrupt();
|
||||
reader.close();
|
||||
socket.close();
|
||||
return true;
|
||||
public void run() {
|
||||
Thread.currentThread().setName("ReadFromTelnetThread");
|
||||
|
||||
ChatMessage message; //bugfix leak, moved out of while
|
||||
while (true) {
|
||||
|
||||
// System.out.println("rdth");
|
||||
|
||||
try {
|
||||
|
||||
String response = reader.readLine();
|
||||
message = new ChatMessage();
|
||||
message.setMessageText(response);
|
||||
|
||||
// message.setDirectedToServer(false);
|
||||
// message.setDirectedToServer(false);
|
||||
// message.setDirectedToServer(false);
|
||||
|
||||
|
||||
if (response != null) {
|
||||
client.getMessageRXBus().put(message);
|
||||
// System.out.println("[RT]: read message and added it to msgrxqueue --- " + response + " ---");
|
||||
} else {
|
||||
System.out.println("[RT]: read message responsed a nullstring, do nothing, buffersize = " + socket.getReceiveBufferSize() + ", reader ready? "
|
||||
+ reader.ready());
|
||||
// reader = new BufferedReader(new InputStreamReader(input));
|
||||
// response = reader.readLine();
|
||||
this.client.getSocket().close();
|
||||
this.interrupt();
|
||||
|
||||
}
|
||||
|
||||
}
|
||||
catch (Exception sexc) {
|
||||
System.out.println("[ReadThread, CRITICAL: ] Socket geschlossen: " + sexc.getMessage());
|
||||
try {
|
||||
this.client.getSocket().close();
|
||||
this.interrupt();
|
||||
break;
|
||||
|
||||
} catch (IOException e) {
|
||||
// TODO Auto-generated catch block
|
||||
e.printStackTrace();
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
}
|
||||
}
|
||||
|
||||
public boolean terminateConnection() throws IOException {
|
||||
this.reader.close();
|
||||
this.input.close();
|
||||
this.socket.close();
|
||||
|
||||
return true;
|
||||
}
|
||||
|
||||
public boolean isReadingFinished() {
|
||||
return readingFinished;
|
||||
}
|
||||
|
||||
public void setReadingFinished(boolean readingReady) {
|
||||
this.readingFinished = readingReady;
|
||||
}
|
||||
|
||||
|
||||
}
|
||||
@@ -2,7 +2,6 @@ package kst4contest.controller;
|
||||
|
||||
import javafx.application.Platform;
|
||||
import kst4contest.ApplicationConstants;
|
||||
import kst4contest.model.Band;
|
||||
import kst4contest.model.ChatMember;
|
||||
import kst4contest.model.ThreadStateMessage;
|
||||
import kst4contest.view.GuiUtils;
|
||||
@@ -15,6 +14,7 @@ import java.net.*;
|
||||
import java.nio.charset.StandardCharsets;
|
||||
import java.util.ArrayList;
|
||||
import java.util.Arrays;
|
||||
import java.util.Locale;
|
||||
import java.util.Map;
|
||||
import java.util.concurrent.ConcurrentHashMap;
|
||||
import java.util.regex.Matcher;
|
||||
@@ -164,79 +164,18 @@ public class ReadUDPByWintestThread extends Thread {
|
||||
}
|
||||
|
||||
/**
|
||||
* Formats a frequency from a Win-Test STATUS packet for use as MYQRG.
|
||||
* Parse Win-Test STATUS packets and update own QRG from WT station.
|
||||
*
|
||||
* <p>Win-Test transmits the frequency in units of 0.1 kHz. KST4Contest
|
||||
* displays frequencies as {@code MHz.kHz.10Hz}, for example
|
||||
* {@code 144.300.00} or {@code 10368.100.00}. The MHz part may contain
|
||||
* between one and five digits. Deriving its length from the complete value
|
||||
* avoids separate and incomplete handling for individual bands.</p>
|
||||
*
|
||||
* @param frequencyIn100Hz frequency received from Win-Test in units of
|
||||
* 0.1 kHz, equivalent to 100 Hz
|
||||
* @return frequency formatted for MYQRG
|
||||
* @throws IllegalArgumentException if the supplied frequency is not positive
|
||||
* or too small to be formatted
|
||||
* @throws ArithmeticException if the supplied value exceeds the supported
|
||||
* numeric range
|
||||
*/
|
||||
private String helper_formatWinTestFrequency(long frequencyIn100Hz) {
|
||||
if (frequencyIn100Hz <= 0) {
|
||||
throw new IllegalArgumentException(
|
||||
"Win-Test frequency must be greater than zero"
|
||||
);
|
||||
}
|
||||
|
||||
/*
|
||||
* Multiplication by ten creates a digit sequence whose final five
|
||||
* digits represent kHz and 10-Hz groups:
|
||||
*
|
||||
* 1443210 -> 14432100 -> 144.321.00
|
||||
* 103681000 -> 1036810000 -> 10368.100.00
|
||||
*/
|
||||
long frequencyIn10Hz = Math.multiplyExact(
|
||||
frequencyIn100Hz,
|
||||
10L
|
||||
);
|
||||
|
||||
String frequencyDigits = Long.toString(frequencyIn10Hz);
|
||||
|
||||
if (frequencyDigits.length() < 6) {
|
||||
throw new IllegalArgumentException(
|
||||
"Win-Test frequency is too small: " + frequencyIn100Hz
|
||||
);
|
||||
}
|
||||
|
||||
int mhzEndIndex = frequencyDigits.length() - 5;
|
||||
int khzEndIndex = frequencyDigits.length() - 2;
|
||||
|
||||
return frequencyDigits.substring(0, mhzEndIndex)
|
||||
+ "."
|
||||
+ frequencyDigits.substring(mhzEndIndex, khzEndIndex)
|
||||
+ "."
|
||||
+ frequencyDigits.substring(khzEndIndex);
|
||||
}
|
||||
|
||||
/**
|
||||
* Parses a Win-Test STATUS packet and optionally updates MYQRG.
|
||||
*
|
||||
* <p>The packet is tokenised while preserving quoted station names.
|
||||
* The configured station-name filter is applied before any frequency is
|
||||
* processed. An empty filter accepts STATUS packets from every Win-Test
|
||||
* station.</p>
|
||||
*
|
||||
* <p>The main frequency is read from token 7. If pass-frequency use is
|
||||
* enabled and token 11 contains a valid frequency, the pass frequency is
|
||||
* used instead. A missing or invalid pass frequency deliberately falls
|
||||
* back to the main frequency.</p>
|
||||
*
|
||||
* @param msg complete Win-Test STATUS packet
|
||||
* Parsing model (tokenized with quotes preserved):
|
||||
* parts[0] = "STATUS"
|
||||
* parts[1] = station name (example: "STN1")
|
||||
* parts[5] = val2 (used to derive mode: 1 => SSB, else CW)
|
||||
* parts[7] = frequency in 0.1 kHz units (example: 1443210 => 144321.0)
|
||||
*/
|
||||
private void parseStatus(String msg) {
|
||||
try {
|
||||
ArrayList<String> parts = new ArrayList<>();
|
||||
Matcher matcher = STATUS_TOKEN_PATTERN.matcher(msg);
|
||||
|
||||
while (matcher.find()) {
|
||||
if (matcher.group(1) != null) {
|
||||
parts.add(matcher.group(1));
|
||||
@@ -246,105 +185,86 @@ public class ReadUDPByWintestThread extends Thread {
|
||||
}
|
||||
|
||||
if (parts.size() < 8) {
|
||||
System.out.println(
|
||||
"[WinTest] STATUS too short: " + msg
|
||||
);
|
||||
System.out.println("[WinTest] STATUS too short: " + msg);
|
||||
return;
|
||||
}
|
||||
|
||||
String stationName = parts.get(1);
|
||||
String stationFilter = client
|
||||
.getChatPreferences()
|
||||
.getLogsynch_wintestNetworkStationNameOfWintestClient1();
|
||||
|
||||
if (stationFilter != null
|
||||
&& !stationFilter.isBlank()
|
||||
&& !stationName.equalsIgnoreCase(stationFilter)) {
|
||||
String stn = parts.get(1);
|
||||
String stationFilter = client.getChatPreferences().getLogsynch_wintestNetworkStationNameOfWintestClient1();
|
||||
if (stationFilter != null && !stationFilter.isBlank() && !stn.equalsIgnoreCase(stationFilter)) {
|
||||
return;
|
||||
}
|
||||
|
||||
String modeValue = parts.get(5);
|
||||
long mainFrequencyRaw = Long.parseLong(parts.get(7));
|
||||
double mainFrequencyKHz = mainFrequencyRaw / 10.0;
|
||||
String val2 = parts.get(5);
|
||||
String freqRaw = parts.get(7);
|
||||
double freqFloat = Integer.parseInt(freqRaw) / 10.0;
|
||||
|
||||
String mode;
|
||||
|
||||
if ("1".equals(modeValue)) {
|
||||
mode = mainFrequencyKHz > 10000.0 ? "usb" : "lsb";
|
||||
if ("1".equals(val2)) {
|
||||
mode = freqFloat > 10000.0 ? "usb" : "lsb";
|
||||
} else {
|
||||
mode = "cw";
|
||||
}
|
||||
|
||||
String formattedMainQrg =
|
||||
helper_formatWinTestFrequency(mainFrequencyRaw);
|
||||
|
||||
/*
|
||||
* Token 11 may contain the pass frequency, depending on the
|
||||
* Win-Test STATUS packet. Small numeric flag values must not be
|
||||
* interpreted as frequencies.
|
||||
*/
|
||||
String formattedPassQrg = null;
|
||||
|
||||
// Format as MMM.KKK.HH display format (e.g. 144.300.00) consistent with UCX thread
|
||||
// freqFloat is in kHz (e.g. 144300.0), convert to Hz-string for formatting
|
||||
long freqHzTimes100 = Math.round(freqFloat * 100.0); // e.g. 14430000
|
||||
String hzStr = String.valueOf(freqHzTimes100);
|
||||
String formattedQRG;
|
||||
if (hzStr.length() == 8) {
|
||||
// 144MHz range: 14430000 -> 144.300.00
|
||||
formattedQRG = String.format("%s.%s.%s", hzStr.substring(0, 3), hzStr.substring(3, 6), hzStr.substring(6, 8));
|
||||
} else if (hzStr.length() == 9) {
|
||||
// 1296MHz range: 129600000 -> 1296.000.00
|
||||
formattedQRG = String.format("%s.%s.%s", hzStr.substring(0, 4), hzStr.substring(4, 7), hzStr.substring(7, 9));
|
||||
} else if (hzStr.length() == 7) {
|
||||
// 70MHz range: 7010000 -> 70.100.00
|
||||
formattedQRG = String.format("%s.%s.%s", hzStr.substring(0, 2), hzStr.substring(2, 5), hzStr.substring(5, 7));
|
||||
} else if (hzStr.length() == 6) {
|
||||
// 50MHz range: 5030000 but 6 digits: 503000 -> 5.030.00
|
||||
formattedQRG = String.format("%s.%s.%s", hzStr.substring(0, 1), hzStr.substring(1, 4), hzStr.substring(4, 6));
|
||||
} else {
|
||||
formattedQRG = String.format(Locale.US, "%.1f", freqFloat); // fallback
|
||||
}
|
||||
// Parse pass frequency from parts[11] if available (WT STATUS format)
|
||||
String formattedPassQRG = null;
|
||||
if (parts.size() > 11) {
|
||||
try {
|
||||
long passFrequencyRaw =
|
||||
Long.parseLong(parts.get(11));
|
||||
double passFrequencyKHz =
|
||||
passFrequencyRaw / 10.0;
|
||||
|
||||
if (passFrequencyKHz > 100.0) {
|
||||
formattedPassQrg =
|
||||
helper_formatWinTestFrequency(
|
||||
passFrequencyRaw
|
||||
);
|
||||
String passFreqRaw = parts.get(11);
|
||||
double passFreqFloat = Integer.parseInt(passFreqRaw) / 10.0;
|
||||
if (passFreqFloat > 100) { // Must be a valid radio frequency (> 100 kHz), protects against parsing boolean flag tokens
|
||||
long passFreqHzTimes100 = Math.round(passFreqFloat * 100.0);
|
||||
String passHzStr = String.valueOf(passFreqHzTimes100);
|
||||
if (passHzStr.length() == 8) {
|
||||
formattedPassQRG = String.format("%s.%s.%s", passHzStr.substring(0, 3), passHzStr.substring(3, 6), passHzStr.substring(6, 8));
|
||||
} else if (passHzStr.length() == 9) {
|
||||
formattedPassQRG = String.format("%s.%s.%s", passHzStr.substring(0, 4), passHzStr.substring(4, 7), passHzStr.substring(7, 9));
|
||||
} else if (passHzStr.length() == 7) {
|
||||
formattedPassQRG = String.format("%s.%s.%s", passHzStr.substring(0, 2), passHzStr.substring(2, 5), passHzStr.substring(5, 7));
|
||||
} else if (passHzStr.length() == 6) {
|
||||
formattedPassQRG = String.format("%s.%s.%s", passHzStr.substring(0, 1), passHzStr.substring(1, 4), passHzStr.substring(4, 6));
|
||||
} else {
|
||||
formattedPassQRG = String.format(Locale.US, "%.1f", passFreqFloat);
|
||||
}
|
||||
}
|
||||
} catch (IllegalArgumentException
|
||||
| ArithmeticException ignored) {
|
||||
/*
|
||||
* Token 11 does not contain a usable frequency.
|
||||
* The main frequency remains the safe fallback.
|
||||
*/
|
||||
} catch (Exception ignored) {
|
||||
// parts[11] not a valid frequency, leave formattedPassQRG as null
|
||||
}
|
||||
}
|
||||
|
||||
boolean usePassQrg = client
|
||||
.getChatPreferences()
|
||||
.isLogsynch_wintestUsePassQrg();
|
||||
|
||||
final String qrgToSet =
|
||||
usePassQrg && formattedPassQrg != null
|
||||
? formattedPassQrg
|
||||
: formattedMainQrg;
|
||||
|
||||
if (client
|
||||
.getChatPreferences()
|
||||
.isLogsynch_wintestQrgSyncEnabled()) {
|
||||
Platform.runLater(
|
||||
() -> client
|
||||
.getChatPreferences()
|
||||
.getMYQRGFirstCat()
|
||||
.set(qrgToSet)
|
||||
);
|
||||
if (this.client.getChatPreferences().isLogsynch_wintestQrgSyncEnabled()) {
|
||||
final String qrgToSet = (this.client.getChatPreferences().isLogsynch_wintestUsePassQrg() && formattedPassQRG != null)
|
||||
? formattedPassQRG
|
||||
: formattedQRG;
|
||||
// JavaFX StringProperty must be updated on the FX Application Thread
|
||||
Platform.runLater(() -> this.client.getChatPreferences().getMYQRGFirstCat().set(qrgToSet));
|
||||
}
|
||||
|
||||
System.out.println(
|
||||
"[WinTest STATUS] stn=" + stationName
|
||||
+ ", mode=" + mode
|
||||
+ ", qrg=" + formattedMainQrg
|
||||
+ (formattedPassQrg != null
|
||||
? ", passQrg=" + formattedPassQrg
|
||||
: "")
|
||||
+ ", selectedQrg=" + qrgToSet
|
||||
+ ", syncActive="
|
||||
+ client
|
||||
.getChatPreferences()
|
||||
.isLogsynch_wintestQrgSyncEnabled()
|
||||
);
|
||||
} catch (Exception exception) {
|
||||
System.out.println(
|
||||
"[WinTest] STATUS parsing error: "
|
||||
+ exception.getMessage()
|
||||
);
|
||||
System.out.println("[WinTest STATUS] stn=" + stn + ", mode=" + mode + ", qrg=" + formattedQRG
|
||||
+ (formattedPassQRG != null ? ", passQrg=" + formattedPassQRG : "")
|
||||
+ ", syncActive=" + this.client.getChatPreferences().isLogsynch_wintestQrgSyncEnabled());
|
||||
} catch (Exception e) {
|
||||
System.out.println("[WinTest] STATUS parsing error: " + e.getMessage());
|
||||
}
|
||||
}
|
||||
|
||||
@@ -366,74 +286,6 @@ public class ReadUDPByWintestThread extends Thread {
|
||||
// socket.send(new DatagramPacket(bytes, bytes.length, broadcast, 9871));
|
||||
// }
|
||||
|
||||
|
||||
/**
|
||||
* Resolves the project Band enum from Win-Test band IDs.
|
||||
*
|
||||
* <p>Only bands that exist in the current Band enum are returned. 50/70 MHz are
|
||||
* still represented as worked flags in ChatMember, but they are not part of the
|
||||
* current Reachability/New-Locator band enum.</p>
|
||||
*
|
||||
* @param bandId Win-Test band id from ADDQSO
|
||||
* @return matching Band or null
|
||||
*/
|
||||
private Band helper_resolveBandFromWinTestBandId(String bandId) {
|
||||
if (bandId == null) {
|
||||
return null;
|
||||
}
|
||||
|
||||
return switch (bandId.trim()) {
|
||||
case "10" -> Band.B_50;
|
||||
case "11" -> Band.B_70;
|
||||
case "12" -> Band.B_144;
|
||||
case "14" -> Band.B_432;
|
||||
case "16" -> Band.B_1296;
|
||||
case "17" -> Band.B_2320;
|
||||
case "18" -> Band.B_3400;
|
||||
case "19" -> Band.B_5760;
|
||||
case "20" -> Band.B_10G;
|
||||
case "21" -> Band.B_24G;
|
||||
default -> null;
|
||||
};
|
||||
}
|
||||
|
||||
/**
|
||||
* Extracts the locator from a Win-Test ADDQSO packet.
|
||||
*
|
||||
* <p>Current parser model based on the existing split-by-quotes code:
|
||||
* <ul>
|
||||
* <li>{@code split("\"")[7]} = callsign</li>
|
||||
* <li>{@code split("\"")[11]} = received exchange, e.g. 599001</li>
|
||||
* <li>{@code split("\"")[13]} = locator, e.g. JO51UM</li>
|
||||
* </ul>
|
||||
*
|
||||
* <p>If the dedicated locator field is empty, the exchange is used as fallback.</p>
|
||||
*
|
||||
* @param msg raw ADDQSO message
|
||||
* @return normalized six-character locator or null
|
||||
*/
|
||||
private String helper_resolveLocatorFromWinTestAddQso(String msg) {
|
||||
if (msg == null) {
|
||||
return null;
|
||||
}
|
||||
|
||||
String[] quotedParts = msg.split("\"");
|
||||
|
||||
if (quotedParts.length > 13) {
|
||||
String locator = WorkedGrossFieldCache.extractLocator6(quotedParts[13]);
|
||||
if (locator != null) {
|
||||
return locator;
|
||||
}
|
||||
}
|
||||
|
||||
if (quotedParts.length > 11) {
|
||||
return WorkedGrossFieldCache.extractLocator6(quotedParts[11]);
|
||||
}
|
||||
|
||||
return null;
|
||||
}
|
||||
|
||||
|
||||
/**
|
||||
* Catches add-qso messages of wintest if a new qso gets into the log<br/>
|
||||
*
|
||||
@@ -458,22 +310,16 @@ public class ReadUDPByWintestThread extends Thread {
|
||||
// receivedQsos.put(qsoNumber, msg);
|
||||
// lastKnownQso = Math.max(lastKnownQso, qsoNumber);
|
||||
String callSignCatched = msg.split("\"") [7];
|
||||
String locatorFromLogger = helper_resolveLocatorFromWinTestAddQso(msg);
|
||||
|
||||
ChatMember workedCall = new ChatMember();
|
||||
workedCall.setCallSign(callSignCatched);
|
||||
workedCall.setWorked(true); //its worked at this place, for sure!
|
||||
|
||||
if (locatorFromLogger != null) {
|
||||
workedCall.setQra(locatorFromLogger);
|
||||
}
|
||||
|
||||
ArrayList<Integer> markTheseChattersAsWorked = client.checkListForChatMemberIndexesByCallSign(workedCall);
|
||||
|
||||
String bandId;
|
||||
bandId = msg.split("\"")[6].split(" ")[4].trim();
|
||||
|
||||
Band workedBand = helper_resolveBandFromWinTestBandId(bandId);
|
||||
switch (bandId) {
|
||||
case "10" -> workedCall.setWorked50(true);
|
||||
case "11" -> workedCall.setWorked70(true);
|
||||
@@ -490,10 +336,6 @@ public class ReadUDPByWintestThread extends Thread {
|
||||
default -> System.out.println("[WinTestUDPRcvr: warning] Unbekannte Band-ID: " + bandId);
|
||||
}
|
||||
|
||||
if (workedBand != null && locatorFromLogger != null) {
|
||||
this.client.registerWorkedGrossField(workedBand, locatorFromLogger, workedCall, "WINTEST");
|
||||
}
|
||||
|
||||
if (!markTheseChattersAsWorked.isEmpty()) {
|
||||
//Worked call is part of the current chatmember list
|
||||
|
||||
@@ -503,13 +345,6 @@ public class ReadUDPByWintestThread extends Thread {
|
||||
|
||||
modifyThat.setWorked(true); //worked its for sure
|
||||
|
||||
if (locatorFromLogger != null
|
||||
&& (modifyThat.getQra() == null
|
||||
|| modifyThat.getQra().isBlank()
|
||||
|| "unknown".equalsIgnoreCase(modifyThat.getQra()))) {
|
||||
modifyThat.setQra(locatorFromLogger);
|
||||
}
|
||||
|
||||
if (workedCall.isWorked50()) {
|
||||
modifyThat.setWorked50(true);
|
||||
} else if (workedCall.isWorked70()) {
|
||||
@@ -563,11 +398,7 @@ public class ReadUDPByWintestThread extends Thread {
|
||||
if (!isInChat) {
|
||||
|
||||
workedCall.setName("unknown");
|
||||
|
||||
if (workedCall.getQra() == null || workedCall.getQra().isBlank()) {
|
||||
workedCall.setQra("unknown");
|
||||
}
|
||||
|
||||
workedCall.setQra("unknown");
|
||||
workedCall.setLastActivity(new Utils4KST().time_generateActualTimeInDateFormat());
|
||||
this.client.getDbHandler().storeChatMember(workedCall);
|
||||
}
|
||||
|
||||
@@ -1,13 +1,9 @@
|
||||
package kst4contest.controller;
|
||||
|
||||
import java.io.IOException;
|
||||
import java.net.DatagramPacket;
|
||||
import java.net.DatagramSocket;
|
||||
import java.net.InetSocketAddress;
|
||||
import java.net.SocketException;
|
||||
import java.net.SocketTimeoutException;
|
||||
import java.io.*;
|
||||
import java.net.*;
|
||||
import java.util.ArrayList;
|
||||
import java.util.Comparator;
|
||||
import java.util.List;
|
||||
|
||||
import javafx.collections.FXCollections;
|
||||
import javafx.collections.ObservableList;
|
||||
@@ -25,245 +21,188 @@ import kst4contest.model.ThreadStateMessage;
|
||||
* @author www.codejava.net
|
||||
*/
|
||||
public class ReadUDPbyAirScoutMessageThread extends Thread {
|
||||
private BufferedReader reader;
|
||||
private Socket socket;
|
||||
private ChatController client;
|
||||
private int localPort;
|
||||
private String ASIdentificator, ChatClientIdentificator;
|
||||
private ThreadStatusCallback callBackToController;
|
||||
private String ThreadNickName = "AirScout msg";
|
||||
// public ReadUDPbyAirScoutMessageThread(int localPort) {
|
||||
// this.localPort = localPort;
|
||||
// }
|
||||
|
||||
private final ChatController client;
|
||||
private final int localPort;
|
||||
private final ThreadStatusCallback callBackToController;
|
||||
public ReadUDPbyAirScoutMessageThread(int localPort, ChatController client, String ASIdentificator,
|
||||
String ChatClientIdentificator, ThreadStatusCallback callback) {
|
||||
|
||||
private final String threadNickName = "AirScout msg";
|
||||
|
||||
private DatagramSocket socket;
|
||||
|
||||
public ReadUDPbyAirScoutMessageThread(
|
||||
int localPort,
|
||||
ChatController client,
|
||||
ThreadStatusCallback callback
|
||||
) {
|
||||
this.callBackToController = callback;
|
||||
this.localPort = localPort;
|
||||
this.client = client;
|
||||
this.callBackToController = callback;
|
||||
this.ASIdentificator = ASIdentificator;
|
||||
this.ChatClientIdentificator = ChatClientIdentificator;
|
||||
}
|
||||
|
||||
@Override
|
||||
public void interrupt() {
|
||||
System.out.println("ReadUDP");
|
||||
super.interrupt();
|
||||
try {
|
||||
if (this.socket != null) {
|
||||
|
||||
if (socket != null && !socket.isClosed()) {
|
||||
socket.close();
|
||||
this.socket.close();
|
||||
}
|
||||
} catch (Exception e) {
|
||||
// TODO Auto-generated catch block
|
||||
e.printStackTrace();
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Checks whether an AirScout response is addressed to the currently
|
||||
* configured server and client identifiers.
|
||||
*
|
||||
* Outgoing message:
|
||||
* ASSETPATH: "client" "server" ...
|
||||
*
|
||||
* Corresponding response:
|
||||
* ASNEAREST: "server" "client" ...
|
||||
*
|
||||
* The comparison is deliberately case-sensitive. In a setup with several
|
||||
* clients, KST-A and kst-a must not silently become the same destination.
|
||||
*
|
||||
* @param message received UDP message
|
||||
* @return true if the response belongs to this KST4Contest instance
|
||||
*/
|
||||
private boolean isMessageForConfiguredClient(String message) {
|
||||
if (message == null || !message.startsWith("ASNEAREST:")) {
|
||||
return false;
|
||||
}
|
||||
private void callThreadStateToUi (ThreadStateMessage threadStateMessage) {
|
||||
if (callBackToController != null) {
|
||||
//update the visual control of running thread
|
||||
callBackToController.onThreadStatus("AirScout", threadStateMessage);
|
||||
}
|
||||
}
|
||||
|
||||
String[] quotedParts = message.split("\"");
|
||||
if (quotedParts.length < 4) {
|
||||
return false;
|
||||
}
|
||||
|
||||
String receivedServerIdentifier = quotedParts[1].trim();
|
||||
String receivedClientIdentifier = quotedParts[3].trim();
|
||||
|
||||
String configuredServerIdentifier =
|
||||
client.getChatPreferences()
|
||||
.getAirScout_asServerNameString();
|
||||
String configuredClientIdentifier =
|
||||
client.getChatPreferences()
|
||||
.getAirScout_asClientNameString();
|
||||
|
||||
if (configuredServerIdentifier == null
|
||||
|| configuredClientIdentifier == null) {
|
||||
return false;
|
||||
}
|
||||
|
||||
return configuredServerIdentifier.equals(
|
||||
receivedServerIdentifier
|
||||
) && configuredClientIdentifier.equals(
|
||||
receivedClientIdentifier
|
||||
);
|
||||
}
|
||||
|
||||
@Override
|
||||
public void run() {
|
||||
Thread.currentThread().setName(
|
||||
"ReadUDPByAirScoutThread"
|
||||
);
|
||||
Thread.currentThread().setName("ReadUDPByAirScoutThread");
|
||||
|
||||
DatagramSocket socket = null;
|
||||
boolean running;
|
||||
byte[] buf = new byte[1777];
|
||||
DatagramPacket packet;
|
||||
// DatagramPacket packet = new DatagramPacket(buf, buf.length); //changed due to save memory
|
||||
packet = new DatagramPacket(buf, buf.length);
|
||||
|
||||
try {
|
||||
|
||||
socket = new DatagramSocket(null);
|
||||
socket.setReuseAddress(true);
|
||||
socket.bind(new InetSocketAddress(localPort));
|
||||
socket.receive(packet);
|
||||
socket.setSoTimeout(3000);
|
||||
|
||||
while (!Thread.currentThread().isInterrupted()) {
|
||||
if (client.isDisconnectionPerformedByUser()) {
|
||||
break;
|
||||
} catch (SocketException e) {
|
||||
// TODO Auto-generated catch block
|
||||
e.printStackTrace();
|
||||
|
||||
} catch (IOException e) {
|
||||
// TODO Auto-generated catch block
|
||||
// e.printStackTrace();
|
||||
}
|
||||
|
||||
|
||||
while (true) {
|
||||
// packet = new DatagramPacket(buf, buf.length);
|
||||
// DatagramPacket packet = new DatagramPacket(SRPDefinitions.BYTE_BUFFER_MAX_LENGTH);
|
||||
try {
|
||||
if (this.client.isDisconnectionPerformedByUser()) {
|
||||
break;//TODO: what if it´s not the finally closage but a band channel change?
|
||||
}
|
||||
|
||||
byte[] buffer = new byte[1777];
|
||||
DatagramPacket packet = new DatagramPacket(
|
||||
buffer,
|
||||
buffer.length
|
||||
);
|
||||
socket.receive(packet);
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
} catch (SocketTimeoutException e2) {
|
||||
// this will catch the repeating Sockettimeoutexception...nothing to do
|
||||
// e2.printStackTrace();
|
||||
}
|
||||
catch (IOException e) {
|
||||
// TODO Auto-generated catch block
|
||||
e.printStackTrace();
|
||||
}
|
||||
|
||||
InetAddress address = packet.getAddress();
|
||||
int port = packet.getPort();
|
||||
// packet = new DatagramPacket(buf, buf.length, address, port);
|
||||
String received = new String(packet.getData(), packet.getOffset(), packet.getLength());
|
||||
received = received.trim();
|
||||
|
||||
if (received.contains(ApplicationConstants.DISCONNECT_RDR_POISONPILL)) {
|
||||
System.out.println("ReadUdpByASMsgTh, Info: got poison, now dieing....");
|
||||
try {
|
||||
socket.receive(packet);
|
||||
} catch (SocketTimeoutException timeoutException) {
|
||||
/*
|
||||
* AirScout may remain silent for some time. Continue with a
|
||||
* new packet instead of processing the previous packet again.
|
||||
*/
|
||||
continue;
|
||||
terminateConnection();
|
||||
} catch (Exception e) {
|
||||
System.out.println("ASUDPRDR: catched error " + e.getMessage());
|
||||
}
|
||||
|
||||
String received = new String(
|
||||
packet.getData(),
|
||||
packet.getOffset(),
|
||||
packet.getLength()
|
||||
).trim();
|
||||
|
||||
if (received.contains(
|
||||
ApplicationConstants.DISCONNECT_RDR_POISONPILL
|
||||
)) {
|
||||
System.out.println(
|
||||
"[AirScout UDP, info]: Received shutdown packet."
|
||||
);
|
||||
break;
|
||||
}
|
||||
|
||||
/*
|
||||
* The socket remains bound so that AirScout can be enabled
|
||||
* without reconnecting. Disabled means that received data is
|
||||
* discarded and no station state is changed.
|
||||
*/
|
||||
if (!client.getChatPreferences()
|
||||
.isAirScout_asUDPListenerEnabled()) {
|
||||
continue;
|
||||
}
|
||||
|
||||
if (!isMessageForConfiguredClient(received)) {
|
||||
continue;
|
||||
}
|
||||
|
||||
processAirScoutResponse(received);
|
||||
}
|
||||
} catch (SocketException exception) {
|
||||
if (!Thread.currentThread().isInterrupted()) {
|
||||
System.out.println(
|
||||
"[AirScout UDP, error]: Could not use UDP port "
|
||||
+ localPort
|
||||
+ ": "
|
||||
+ exception.getMessage()
|
||||
);
|
||||
}
|
||||
} catch (IOException exception) {
|
||||
if (!Thread.currentThread().isInterrupted()) {
|
||||
System.out.println(
|
||||
"[AirScout UDP, error]: Communication failed: "
|
||||
+ exception.getMessage()
|
||||
);
|
||||
}
|
||||
} finally {
|
||||
if (socket != null && !socket.isClosed()) {
|
||||
socket.close();
|
||||
break;
|
||||
}
|
||||
|
||||
socket = null;
|
||||
|
||||
if (received.contains("ASSETPATH") || received.contains("ASWATCHLIST")) {
|
||||
// do nothing, that is your own message
|
||||
} else if (received.contains("ASNEAREST:")) { //answer by airscout
|
||||
|
||||
// processASUDPMessage(received); //TODO: 2025-11-Zeile deaktiviert. Fand hier Doppelberechnung statt?!
|
||||
|
||||
AirPlaneReflectionInfo apReflectInfoForChatMember;
|
||||
|
||||
apReflectInfoForChatMember = processASUDPMessage(received);
|
||||
if (!this.client.getLst_chatMemberList().isEmpty()) {
|
||||
|
||||
try {
|
||||
|
||||
// this.client.getLst_chatMemberList()
|
||||
// .get(this.client.checkListForChatMemberIndexByCallSign(
|
||||
// apReflectInfoForChatMember.getReceiver()))
|
||||
// .setAirPlaneReflectInfo(apReflectInfoForChatMember); // TODO: here we set the ap info at
|
||||
// // the central instance of
|
||||
// // chatmember list .... -1 is a
|
||||
// // problem!
|
||||
|
||||
ArrayList<Integer> addApInfoToThese = this.client.checkListForChatMemberIndexesByCallSign(apReflectInfoForChatMember.getReceiver());
|
||||
addApInfoToThese.forEach((integerIndex) -> {this.client.getLst_chatMemberList().get(integerIndex).setAirPlaneReflectInfo(apReflectInfoForChatMember); });
|
||||
|
||||
// AirScout availability strongly affects priority => request recompute the score of the chatmember
|
||||
this.client.getScoreService().requestRecompute("airscout-update");
|
||||
|
||||
/**
|
||||
* CK| MSGBUS BGFX Listactualizer Exception in thread "Thread-10"
|
||||
* java.util.ConcurrentModificationException at
|
||||
* java.base/java.util.AbstractList$Itr.checkForComodification(AbstractList.java:399)
|
||||
* at java.base/java.util.AbstractList$Itr.next(AbstractList.java:368) at
|
||||
* kst4contest.controller.ChatController.checkListForChatMemberIndexByCallSign(ChatController.java:173)
|
||||
* at
|
||||
* kst4contest.controller.ReadUDPbyAirScoutMessageThread.run(ReadUDPbyAirScoutMessageThread.java:93)
|
||||
*
|
||||
*/
|
||||
// System.out.println("[ReadUdpByASth, AP-Info catched: ] " + apReflectInfoForChatMember.toString());
|
||||
// }
|
||||
} catch (Exception e) {
|
||||
|
||||
System.out.println("ReadUdpByAsMsgTh, Warning:"
|
||||
+ apReflectInfoForChatMember.getReceiver().getCallSign()
|
||||
+ " is not in the Chatmemberlist or the Chatmemberlist is modified by another Thread");
|
||||
// TODO: handle exception
|
||||
}
|
||||
|
||||
// String[] newState = new String[3];
|
||||
// newState[0] = "On";
|
||||
// newState[1] = "received line";
|
||||
// newState[2] = apReflectInfoForChatMember.toString();
|
||||
// callThreadStateToUi(newState);
|
||||
ThreadStateMessage threadStateMessage = new ThreadStateMessage(this.ThreadNickName, true, "received line\n" + apReflectInfoForChatMember.toString(), false);
|
||||
callBackToController.onThreadStatus(ThreadNickName,threadStateMessage);
|
||||
}
|
||||
|
||||
}
|
||||
// packet = null; //reset packet
|
||||
buf = new byte[1777]; // reset buffer for future smaller packets
|
||||
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
/**
|
||||
* Parses an AirScout response and applies it to every active category
|
||||
* instance of the reported station.
|
||||
*
|
||||
* @param received received ASNEAREST message
|
||||
*/
|
||||
private void processAirScoutResponse(String received) {
|
||||
try {
|
||||
AirPlaneReflectionInfo reflectionInfo =
|
||||
processASUDPMessage(received);
|
||||
|
||||
if (reflectionInfo == null
|
||||
|| reflectionInfo.getReceiver() == null) {
|
||||
return;
|
||||
}
|
||||
|
||||
String receiverCallSign =
|
||||
reflectionInfo.getReceiver().getCallSignRaw();
|
||||
|
||||
if (receiverCallSign == null
|
||||
|| receiverCallSign.isBlank()) {
|
||||
receiverCallSign =
|
||||
reflectionInfo.getReceiver().getCallSign();
|
||||
}
|
||||
|
||||
if (receiverCallSign == null
|
||||
|| receiverCallSign.isBlank()) {
|
||||
return;
|
||||
}
|
||||
|
||||
List<ChatMember> matchingMembers =
|
||||
client.findActiveChatMembersByRawCall(
|
||||
receiverCallSign
|
||||
);
|
||||
|
||||
for (ChatMember matchingMember : matchingMembers) {
|
||||
matchingMember.setAirPlaneReflectInfo(
|
||||
reflectionInfo
|
||||
);
|
||||
}
|
||||
|
||||
if (!matchingMembers.isEmpty()) {
|
||||
client.getScoreService().requestRecompute(
|
||||
"airscout-update"
|
||||
);
|
||||
}
|
||||
|
||||
if (callBackToController != null) {
|
||||
ThreadStateMessage threadStateMessage =
|
||||
new ThreadStateMessage(
|
||||
threadNickName,
|
||||
true,
|
||||
"Received AirScout response\n"
|
||||
+ reflectionInfo,
|
||||
false
|
||||
);
|
||||
|
||||
callBackToController.onThreadStatus(
|
||||
threadNickName,
|
||||
threadStateMessage
|
||||
);
|
||||
}
|
||||
} catch (RuntimeException exception) {
|
||||
System.out.println(
|
||||
"[AirScout UDP, warning]: Could not process response: "
|
||||
+ exception.getMessage()
|
||||
);
|
||||
}
|
||||
}
|
||||
public AirPlaneReflectionInfo processASUDPMessage(String udpStringToProcess) {
|
||||
|
||||
// System.out.println("RDUDPAS RECV: " + udpStringToProcess);
|
||||
|
||||
|
||||
// TODO: filter messages which are directed to another client
|
||||
|
||||
/*
|
||||
* Example mesage: ASNEAREST: "AS" "KST"
|
||||
@@ -365,8 +304,11 @@ public class ReadUDPbyAirScoutMessageThread extends Thread {
|
||||
}
|
||||
|
||||
public boolean terminateConnection() {
|
||||
if (socket != null && !socket.isClosed()) {
|
||||
socket.close();
|
||||
|
||||
try {
|
||||
this.socket.close();
|
||||
} catch (Exception e) {
|
||||
System.out.println("udpbyas: catched " + e.getMessage());
|
||||
}
|
||||
|
||||
return true;
|
||||
|
||||
@@ -22,9 +22,6 @@ import org.xml.sax.InputSource;
|
||||
import org.xml.sax.SAXException;
|
||||
|
||||
import kst4contest.model.ChatMember;
|
||||
import kst4contest.model.Band;
|
||||
|
||||
import javafx.application.Platform;
|
||||
|
||||
/**
|
||||
* This thread is responsible for reading server's input and printing it to the
|
||||
@@ -67,119 +64,6 @@ public class ReadUDPbyUCXMessageThread extends Thread {
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Strips binary logger framing bytes before the XML payload. Some UCXLog packets
|
||||
* contain transport bytes before the XML declaration.
|
||||
*
|
||||
* @param rawPacket raw UDP payload
|
||||
* @return cleaned XML string or trimmed original text
|
||||
*/
|
||||
private String helper_extractXmlPayload(String rawPacket) {
|
||||
if (rawPacket == null) {
|
||||
return "";
|
||||
}
|
||||
|
||||
int xmlStart = rawPacket.indexOf("<?xml");
|
||||
if (xmlStart < 0) {
|
||||
xmlStart = rawPacket.indexOf("<contactinfo");
|
||||
}
|
||||
if (xmlStart < 0) {
|
||||
xmlStart = rawPacket.indexOf("<contactreplace");
|
||||
}
|
||||
if (xmlStart < 0) {
|
||||
xmlStart = rawPacket.indexOf("<RadioInfo");
|
||||
}
|
||||
|
||||
return xmlStart >= 0
|
||||
? rawPacket.substring(xmlStart).trim()
|
||||
: rawPacket.trim();
|
||||
}
|
||||
|
||||
/**
|
||||
* Reads an optional XML child node.
|
||||
*
|
||||
* @param element parent element
|
||||
* @param tagName tag to read
|
||||
* @return trimmed value or empty string
|
||||
*/
|
||||
private String helper_getOptionalElementText(Element element, String tagName) {
|
||||
if (element == null || tagName == null) {
|
||||
return "";
|
||||
}
|
||||
|
||||
NodeList nodeList = element.getElementsByTagName(tagName);
|
||||
if (nodeList == null || nodeList.getLength() == 0 || nodeList.item(0) == null) {
|
||||
return "";
|
||||
}
|
||||
|
||||
String textContent = nodeList.item(0).getTextContent();
|
||||
return textContent == null ? "" : textContent.trim();
|
||||
}
|
||||
|
||||
/**
|
||||
* Resolves the QSO locator from UCXLog contactinfo. gridsquare is preferred,
|
||||
* rcvnr is used as fallback for exchanges such as 001JO41HK.
|
||||
*
|
||||
* @param element contactinfo XML element
|
||||
* @return normalized six-character locator or null
|
||||
*/
|
||||
private String helper_resolveLocatorFromContactInfo(Element element) {
|
||||
String gridSquare = WorkedGrossFieldCache.extractLocator6(helper_getOptionalElementText(element, "gridsquare"));
|
||||
if (gridSquare != null) {
|
||||
return gridSquare;
|
||||
}
|
||||
|
||||
return WorkedGrossFieldCache.extractLocator6(helper_getOptionalElementText(element, "rcvnr"));
|
||||
}
|
||||
|
||||
/**
|
||||
* Resolves the project Band enum from logger band values.
|
||||
*
|
||||
* @param band logger band text
|
||||
* @return matching Band or null
|
||||
*/
|
||||
private Band helper_resolveBandFromLoggerBand(String band) {
|
||||
if (band == null) {
|
||||
return null;
|
||||
}
|
||||
|
||||
switch (band.trim()) {
|
||||
case "50":
|
||||
case "6m":
|
||||
return Band.B_50;
|
||||
case "70":
|
||||
case "4m":
|
||||
return Band.B_70;
|
||||
case "144":
|
||||
case "2m":
|
||||
return Band.B_144;
|
||||
case "432":
|
||||
case "70cm":
|
||||
return Band.B_432;
|
||||
case "1240":
|
||||
case "1296":
|
||||
case "23cm":
|
||||
return Band.B_1296;
|
||||
case "2300":
|
||||
case "2320":
|
||||
case "13cm":
|
||||
return Band.B_2320;
|
||||
case "3400":
|
||||
case "9cm":
|
||||
return Band.B_3400;
|
||||
case "5600":
|
||||
case "5760":
|
||||
case "6cm":
|
||||
return Band.B_5760;
|
||||
case "10G":
|
||||
case "10368":
|
||||
case "3cm":
|
||||
return Band.B_10G;
|
||||
default:
|
||||
return null;
|
||||
}
|
||||
}
|
||||
|
||||
public void run() {
|
||||
|
||||
System.out.println("ReadUDPByUCXLogThread: started Thread for UCXLog getUDP");
|
||||
@@ -293,10 +177,18 @@ public class ReadUDPbyUCXMessageThread extends Thread {
|
||||
|
||||
File logUDPMessageToThisFile;
|
||||
|
||||
String udpMsg = helper_extractXmlPayload(udpPacketToProcess);
|
||||
String udpMsg = udpPacketToProcess;
|
||||
|
||||
ChatMember modifyThat = null;
|
||||
|
||||
// System.out.println("ReadUDPByUCX, message catched: " + udpMsg);
|
||||
|
||||
// String[] threadStatusMessage = new String[2];
|
||||
// threadStatusMessage = new String[3];
|
||||
// threadStatusMessage[0] = "on";
|
||||
// threadStatusMessage[1] = "received message:";
|
||||
// threadStatusMessage[2] = udpMsg;
|
||||
|
||||
ThreadStateMessage threadStateMessage = new ThreadStateMessage(this.ThreadNickName, true, "received Message\n" + udpMsg, false);
|
||||
|
||||
callBackToController.onThreadStatus(ThreadNickName,threadStateMessage);
|
||||
@@ -305,7 +197,7 @@ public class ReadUDPbyUCXMessageThread extends Thread {
|
||||
try {
|
||||
dbf.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
|
||||
} catch (ParserConfigurationException e1) {
|
||||
|
||||
// TODO Auto-generated catch block
|
||||
e1.printStackTrace();
|
||||
}
|
||||
|
||||
@@ -314,26 +206,12 @@ public class ReadUDPbyUCXMessageThread extends Thread {
|
||||
Document doc = db.parse(new InputSource(new StringReader(udpMsg)));
|
||||
|
||||
/**
|
||||
* case Log-QSO-Packet in ucxlog / DXLog and compatible
|
||||
* case Log-QSO-Packet in ucxlog
|
||||
*
|
||||
*/
|
||||
NodeList list = doc.getElementsByTagName("contactinfo");
|
||||
|
||||
if (list.getLength() == 0) {
|
||||
list = doc.getElementsByTagName("contactreplace");
|
||||
//DXlog will send contactreplace instead of contactinfo on clicking "broadcast whole logbook"
|
||||
}
|
||||
|
||||
if (list.getLength() != 0) {
|
||||
|
||||
/*
|
||||
* QSO and TRX information share the same UDP receiver. The log-sync
|
||||
* preference therefore controls processing, not ownership of the socket.
|
||||
*/
|
||||
if (!client.getChatPreferences().isLogsynch_ucxUDPWkdCallListenerEnabled()) {
|
||||
return "";
|
||||
}
|
||||
|
||||
for (int temp = 0; temp < list.getLength(); temp++) {
|
||||
|
||||
Node node = list.item(temp);
|
||||
@@ -343,9 +221,10 @@ public class ReadUDPbyUCXMessageThread extends Thread {
|
||||
Element element = (Element) node;
|
||||
|
||||
String call = element.getElementsByTagName("call").item(0).getTextContent();
|
||||
String band = helper_getOptionalElementText(element, "band");
|
||||
String gridSquare = helper_resolveLocatorFromContactInfo(element);
|
||||
String points = helper_getOptionalElementText(element, "points");
|
||||
// call = call.toLowerCase();
|
||||
String band = element.getElementsByTagName("band").item(0).getTextContent();
|
||||
|
||||
String points = element.getElementsByTagName("points").item(0).getTextContent();
|
||||
|
||||
System.out.println("[Readudp, info ]: received Current Element :" + node.getNodeName()
|
||||
+ "call: " + call + " / " + band + " ----> " + points + " POINTS");
|
||||
@@ -356,83 +235,89 @@ public class ReadUDPbyUCXMessageThread extends Thread {
|
||||
workedCall.setCallSign(call);
|
||||
workedCall.setWorked(true);
|
||||
|
||||
if (gridSquare != null) {
|
||||
workedCall.setQra(gridSquare);
|
||||
}
|
||||
|
||||
Band workedBand = helper_resolveBandFromLoggerBand(band);
|
||||
|
||||
switch (band) {
|
||||
case "50":
|
||||
case "6m":
|
||||
{
|
||||
workedCall.setWorked50(true);
|
||||
break;
|
||||
}
|
||||
|
||||
case "70":
|
||||
case "4m":
|
||||
{
|
||||
workedCall.setWorked70(true);
|
||||
break;
|
||||
}
|
||||
|
||||
case "144":
|
||||
case "2m": //minos contest logger
|
||||
{
|
||||
case "144": {
|
||||
workedCall.setWorked144(true);
|
||||
break;
|
||||
}
|
||||
|
||||
case "432":
|
||||
case "70cm":
|
||||
{
|
||||
workedCall.setWorked432(true);
|
||||
break;
|
||||
}
|
||||
case "432": {
|
||||
workedCall.setWorked432(true);
|
||||
break;
|
||||
}
|
||||
|
||||
case "1240": //ucxlog style
|
||||
case "1296": //used for n1mm / Dxlog
|
||||
case "23cm": //minos contest logger
|
||||
{
|
||||
case "1240": {
|
||||
workedCall.setWorked1240(true);
|
||||
break;
|
||||
}
|
||||
|
||||
case "2300":
|
||||
case "13cm":
|
||||
{
|
||||
case "2300": {
|
||||
workedCall.setWorked2300(true);
|
||||
break;
|
||||
}
|
||||
|
||||
case "3400":
|
||||
case "9cm":
|
||||
{
|
||||
case "3400": {
|
||||
workedCall.setWorked3400(true);
|
||||
break;
|
||||
}
|
||||
|
||||
case "5600":
|
||||
case "6cm":
|
||||
{
|
||||
case "5600": {
|
||||
workedCall.setWorked5600(true);
|
||||
break;
|
||||
}
|
||||
|
||||
case "10G":
|
||||
case "3cm":
|
||||
{
|
||||
case "10G": {
|
||||
workedCall.setWorked10G(true);
|
||||
break;
|
||||
}
|
||||
|
||||
|
||||
default:
|
||||
System.out.println("[ReadUDPFromUCX, Error:] unexpected band value: \"" + band + "\"");
|
||||
break;
|
||||
/**
|
||||
* cases hotfix for MINOS logger, which tells band like "2m", not "144"
|
||||
*/
|
||||
case "2m": {
|
||||
workedCall.setWorked144(true);
|
||||
break;
|
||||
}
|
||||
|
||||
case "70cm": {
|
||||
workedCall.setWorked432(true);
|
||||
break;
|
||||
}
|
||||
|
||||
case "23cm": {
|
||||
workedCall.setWorked1240(true);
|
||||
break;
|
||||
}
|
||||
|
||||
case "13cm": {
|
||||
workedCall.setWorked2300(true);
|
||||
break;
|
||||
}
|
||||
|
||||
case "9cm": {
|
||||
workedCall.setWorked3400(true);
|
||||
break;
|
||||
}
|
||||
|
||||
case "6cm": {
|
||||
workedCall.setWorked5600(true);
|
||||
break;
|
||||
}
|
||||
|
||||
case "3cm": {
|
||||
workedCall.setWorked10G(true);
|
||||
|
||||
}
|
||||
|
||||
default:
|
||||
System.out.println("[ReadUDPFromUCX, Error:] unexpected band value: \"" + band + "\"");
|
||||
break;
|
||||
}
|
||||
|
||||
// if (!client.getMap_ucxLogInfoWorkedCalls().containsKey("call")) {
|
||||
// client.getMap_ucxLogInfoWorkedCalls().put(call, workedCall);
|
||||
|
||||
// } else
|
||||
{
|
||||
/**
|
||||
* That means, the station is worked already but maybe at another band. So we
|
||||
@@ -454,13 +339,7 @@ public class ReadUDPbyUCXMessageThread extends Thread {
|
||||
|
||||
modifyThat.setWorked(true);
|
||||
|
||||
if (workedCall.isWorked50()) {
|
||||
modifyThat.setWorked50(true);
|
||||
|
||||
} else if (workedCall.isWorked70()) {
|
||||
modifyThat.setWorked70(true);
|
||||
|
||||
} else if (workedCall.isWorked144()) {
|
||||
if (workedCall.isWorked144()) {
|
||||
modifyThat.setWorked144(true);
|
||||
|
||||
} else if (workedCall.isWorked432()) {
|
||||
@@ -573,10 +452,6 @@ public class ReadUDPbyUCXMessageThread extends Thread {
|
||||
*/
|
||||
}
|
||||
|
||||
if (workedBand != null && gridSquare != null) {
|
||||
this.client.registerWorkedGrossField(workedBand, gridSquare, workedCall, "UCXLOG");
|
||||
}
|
||||
|
||||
boolean isInChat = this.client.getDbHandler().updateWkdInfoOnChatMember(workedCall);
|
||||
// This will update the worked info on a worked chatmember. DBHandler will
|
||||
// check, if an entry at the db had been modified. If not, then the worked
|
||||
@@ -584,11 +459,7 @@ public class ReadUDPbyUCXMessageThread extends Thread {
|
||||
if (!isInChat) {
|
||||
|
||||
workedCall.setName("unknown");
|
||||
|
||||
if (workedCall.getQra() == null || workedCall.getQra().isBlank()) {
|
||||
workedCall.setQra("unknown");
|
||||
}
|
||||
|
||||
workedCall.setQra("unknown");
|
||||
workedCall.setLastActivity(new Utils4KST().time_generateActualTimeInDateFormat());
|
||||
this.client.getDbHandler().storeChatMember(workedCall);
|
||||
}
|
||||
@@ -626,15 +497,6 @@ public class ReadUDPbyUCXMessageThread extends Thread {
|
||||
} else {
|
||||
list = doc.getElementsByTagName("RadioInfo");
|
||||
|
||||
/*
|
||||
* RadioInfo packets may arrive on the shared UDP port even when automatic
|
||||
* QRG synchronization is disabled. Ignore them unless TRX sync is enabled.
|
||||
*/
|
||||
if (list.getLength() != 0
|
||||
&& !client.getChatPreferences().isTrxSynch_ucxLogUDPListenerEnabled()) {
|
||||
return "";
|
||||
}
|
||||
|
||||
for (int temp = 0; temp < list.getLength(); temp++) {
|
||||
|
||||
Node node = list.item(temp);
|
||||
@@ -688,12 +550,7 @@ public class ReadUDPbyUCXMessageThread extends Thread {
|
||||
// System.out.println("Radio Mode: " + mode);
|
||||
// System.out.println("[ReadUDPFromUCX, Info:] Setted QRG pref to: \"" + qrg + "\"" );
|
||||
|
||||
// this.client.getChatPreferences().getMYQRGFirstCat().set(formattedQRG);
|
||||
|
||||
final String finalFormattedQRG = formattedQRG;
|
||||
helper_runOnFxThread(() ->
|
||||
this.client.getChatPreferences().getMYQRGFirstCat().set(finalFormattedQRG)
|
||||
);
|
||||
this.client.getChatPreferences().getMYQRGFirstCat().set(formattedQRG);
|
||||
|
||||
// System.out.println("[ReadUDPbyUCXTh: ] Radioinfo processed: " + formattedQRG);
|
||||
}
|
||||
@@ -747,28 +604,6 @@ public class ReadUDPbyUCXMessageThread extends Thread {
|
||||
this.socket.close();
|
||||
|
||||
return true;
|
||||
|
||||
}
|
||||
|
||||
/**
|
||||
* Runs UI-bound changes on the JavaFX application thread.
|
||||
*
|
||||
* <p>UCXLog UDP packets are processed in a background thread. Some preference
|
||||
* properties are bound to JavaFX controls, so setting them directly from this
|
||||
* thread can crash JavaFX with "Not on FX application thread".</p>
|
||||
*
|
||||
* @param runnable UI-bound update
|
||||
*/
|
||||
private void helper_runOnFxThread(Runnable runnable) {
|
||||
if (runnable == null) {
|
||||
return;
|
||||
}
|
||||
|
||||
if (Platform.isFxApplicationThread()) {
|
||||
runnable.run();
|
||||
} else {
|
||||
Platform.runLater(runnable);
|
||||
}
|
||||
}
|
||||
|
||||
}
|
||||
@@ -140,9 +140,7 @@ public final class ScoreService {
|
||||
controller.getStationMetricsService().snapshot(nowEpochMs, prefs);
|
||||
|
||||
// 1) Choose one representative per callsignRaw
|
||||
Map<String, List<ChatMember>> variantsByCallRaw = groupMembersByCallRaw(members);
|
||||
Map<String, ChatMember> representativeByCallRaw =
|
||||
chooseRepresentativeMembers(variantsByCallRaw, lastInbound);
|
||||
Map<String, ChatMember> representativeByCallRaw = chooseRepresentativeMembers(members, lastInbound);
|
||||
|
||||
// 2) Compute score once per callsignRaw
|
||||
Map<String, Double> scoreByCallRaw = new HashMap<>(representativeByCallRaw.size());
|
||||
@@ -156,7 +154,6 @@ public final class ScoreService {
|
||||
|
||||
double score = priorityCalculator.calculatePriority(
|
||||
representative,
|
||||
variantsByCallRaw.getOrDefault(callRaw, List.of(representative)),
|
||||
prefs,
|
||||
activeSkeds,
|
||||
metricsSnapshot,
|
||||
@@ -166,15 +163,7 @@ public final class ScoreService {
|
||||
scoreByCallRaw.put(callRaw, score);
|
||||
preferredCategoryByCallRaw.put(callRaw, representative.getChatCategory());
|
||||
|
||||
if (Double.isFinite(score) && score > 0.0) {
|
||||
topAll.add(new TopCandidate(
|
||||
callRaw,
|
||||
representative.getCallSign(),
|
||||
representative.getChatCategory(),
|
||||
score
|
||||
));
|
||||
}
|
||||
|
||||
topAll.add(new TopCandidate(callRaw, representative.getCallSign(), representative.getChatCategory(), score));
|
||||
}
|
||||
|
||||
// 3) Build Top-N
|
||||
@@ -193,28 +182,12 @@ public final class ScoreService {
|
||||
|
||||
// 4) Publish to UI in ONE batched runLater
|
||||
Platform.runLater(() -> {
|
||||
applyScoreSnapshotToChatMembers(snap);
|
||||
topCandidatesFx.setAll(snap.getTopCandidates());
|
||||
updateSelectedScoreFromSnapshot(snap);
|
||||
uiPulse.set(uiPulse.get() + 1);
|
||||
});
|
||||
}
|
||||
|
||||
private Map<String, List<ChatMember>> groupMembersByCallRaw(List<ChatMember> members) {
|
||||
Map<String, List<ChatMember>> byCallRaw = new HashMap<>();
|
||||
|
||||
for (ChatMember member : members) {
|
||||
if (member == null) continue;
|
||||
|
||||
String callRaw = normalizeCallRaw(member.getCallSignRaw());
|
||||
if (callRaw == null || callRaw.isEmpty()) continue;
|
||||
|
||||
byCallRaw.computeIfAbsent(callRaw, ignored -> new ArrayList<>()).add(member);
|
||||
}
|
||||
|
||||
return byCallRaw;
|
||||
}
|
||||
|
||||
/**
|
||||
* Picks one ChatMember object per callsignRaw.
|
||||
* Preference order:
|
||||
@@ -222,9 +195,18 @@ public final class ScoreService {
|
||||
* 2) Most recently active variant (fallback)
|
||||
*/
|
||||
private Map<String, ChatMember> chooseRepresentativeMembers(
|
||||
Map<String, List<ChatMember>> byCallRaw,
|
||||
List<ChatMember> members,
|
||||
Map<String, ChatCategory> lastInboundCategoryByCallRaw
|
||||
) {
|
||||
Map<String, List<ChatMember>> byCallRaw = new HashMap<>();
|
||||
|
||||
for (ChatMember m : members) {
|
||||
if (m == null) continue;
|
||||
String callRaw = normalizeCallRaw(m.getCallSignRaw());
|
||||
if (callRaw == null || callRaw.isEmpty()) continue;
|
||||
byCallRaw.computeIfAbsent(callRaw, k -> new ArrayList<>()).add(m);
|
||||
}
|
||||
|
||||
Map<String, ChatMember> representative = new HashMap<>(byCallRaw.size());
|
||||
|
||||
for (Map.Entry<String, List<ChatMember>> entry : byCallRaw.entrySet()) {
|
||||
@@ -235,11 +217,12 @@ public final class ScoreService {
|
||||
ChatMember chosen = null;
|
||||
|
||||
if (preferredCat != null) {
|
||||
chosen = variants.stream()
|
||||
.filter(Objects::nonNull)
|
||||
.filter(v -> isSameChatCategory(v.getChatCategory(), preferredCat))
|
||||
.max(Comparator.comparingLong(ChatMember::getActivityTimeLastInEpoch))
|
||||
.orElse(null);
|
||||
for (ChatMember v : variants) {
|
||||
if (v != null && v.getChatCategory() == preferredCat) {
|
||||
chosen = v;
|
||||
break;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
if (chosen == null) {
|
||||
@@ -255,39 +238,6 @@ public final class ScoreService {
|
||||
return representative;
|
||||
}
|
||||
|
||||
private static boolean isSameChatCategory(ChatCategory left, ChatCategory right) {
|
||||
return left != null
|
||||
&& right != null
|
||||
&& left.getCategoryNumber() == right.getCategoryNumber();
|
||||
}
|
||||
|
||||
|
||||
/**
|
||||
* Projects the immutable score snapshot back into ChatMember display fields so
|
||||
* the normal station table can sort/filter by score without knowing the score
|
||||
* calculation internals.
|
||||
*
|
||||
* @param snap latest score snapshot
|
||||
*/
|
||||
private void applyScoreSnapshotToChatMembers(ScoreSnapshot snap) {
|
||||
if (snap == null) {
|
||||
return;
|
||||
}
|
||||
|
||||
Map<String, Double> scoreByCallSignRaw = snap.getScoreByCallSignRaw();
|
||||
|
||||
for (ChatMember member : controller.snapshotChatMembers()) {
|
||||
if (member == null || member.getCallSignRaw() == null) {
|
||||
continue;
|
||||
}
|
||||
|
||||
Double score = scoreByCallSignRaw.get(normalizeCallRaw(member.getCallSignRaw()));
|
||||
member.setCurrentPriorityScore(score == null ? 0.0 : score);
|
||||
}
|
||||
|
||||
controller.fireUserListUpdate("Priority scores projected to ChatMember");
|
||||
}
|
||||
|
||||
private void updateSelectedScoreFromSnapshot(ScoreSnapshot snap) {
|
||||
if (snap == null || selectedCallSignRaw == null) {
|
||||
selectedCallPriorityScore.set(Double.NaN);
|
||||
|
||||
@@ -35,11 +35,13 @@ public class ScoreboardUpdateTask extends TimerTask {
|
||||
|
||||
ChatMessage beaconMSG = new ChatMessage();
|
||||
|
||||
MessageVariableResolver variableResolver =
|
||||
new MessageVariableResolver(this.chatController.getChatPreferences());
|
||||
String replaceVariables = variableResolver.resolveGlobalVariables(
|
||||
this.chatController.getChatPreferences().getBcn_beaconTextMainCat()
|
||||
);
|
||||
String replaceVariables = this.chatController.getChatPreferences().getBcn_beaconTextMainCat();
|
||||
// replaceVariables = bcn_beaconText;
|
||||
|
||||
replaceVariables = replaceVariables.replaceAll("MYQRG", this.chatController.getChatPreferences().getMYQRGFirstCat().getValue());
|
||||
replaceVariables = replaceVariables.replaceAll("MYCALL", this.chatController.getChatPreferences().getStn_loginCallSign());
|
||||
replaceVariables = replaceVariables.replaceAll("MYLOCATOR", this.chatController.getChatPreferences().getStn_loginLocatorMainCat());
|
||||
replaceVariables = replaceVariables.replaceAll("MYQTF", this.chatController.getChatPreferences().getActualQTF().getValue() + "");
|
||||
|
||||
|
||||
beaconMSG.setMessageText(
|
||||
|
||||
@@ -2,7 +2,6 @@ package kst4contest.controller;
|
||||
|
||||
import kst4contest.logic.SignalDetector;
|
||||
import kst4contest.model.ChatPreferences;
|
||||
import kst4contest.model.ChatMember;
|
||||
|
||||
import java.util.ArrayDeque;
|
||||
import java.util.Deque;
|
||||
@@ -22,7 +21,7 @@ import java.util.regex.Pattern;
|
||||
public final class StationMetricsService {
|
||||
|
||||
/** /cq <CALL> ... */
|
||||
private static final Pattern OUTBOUND_CQ_PATTERN = Pattern.compile("(?i)^\\s*/cq\\s+([A-Z0-9/-]+)\\b.*");
|
||||
private static final Pattern OUTBOUND_CQ_PATTERN = Pattern.compile("(?i)^\\s*/cq\\s+([A-Z0-9/]+)\\b.*");
|
||||
|
||||
/** Rolling window timestamps for momentum scoring. */
|
||||
private static final int MAX_STORED_INBOUND_TIMESTAMPS = 32;
|
||||
@@ -196,7 +195,7 @@ public final class StationMetricsService {
|
||||
|
||||
private static String normalizeCallRaw(String s) {
|
||||
if (s == null) return null;
|
||||
return ChatMember.normalizeCallSignToBaseCallSign(s);
|
||||
return s.trim().toUpperCase();
|
||||
}
|
||||
|
||||
private static final class StationMetrics {
|
||||
|
||||
@@ -17,20 +17,4 @@ public interface StatusUpdateListener {
|
||||
void onUserListUpdated(String reason);
|
||||
// new: userlist-update
|
||||
|
||||
/**
|
||||
* Called whenever the authoritative ON4KST session changes lifecycle state.
|
||||
*
|
||||
* <p>The callback may originate from a background connection supervisor. A UI
|
||||
* implementation must marshal control changes onto its application thread.</p>
|
||||
*
|
||||
* @param state new connection, authentication or synchronization state
|
||||
* @param detail human-readable progress or failure reason
|
||||
*/
|
||||
default void onConnectionStateChanged(
|
||||
On4KstConnectionState state,
|
||||
String detail
|
||||
) {
|
||||
// Optional for non-UI listeners.
|
||||
}
|
||||
|
||||
}
|
||||
@@ -108,16 +108,6 @@ public class UpdateChecker {
|
||||
|
||||
Element element = (Element) node;
|
||||
updateInfos.setLatestVersionNumberOnServer(Double.parseDouble(element.getElementsByTagName("versionNumber").item(0).getTextContent()));
|
||||
|
||||
NodeList semanticVersionNodes =
|
||||
element.getElementsByTagName("semanticVersion");
|
||||
|
||||
if (semanticVersionNodes.getLength() > 0) {
|
||||
updateInfos.setLatestSemanticVersionOnServer(
|
||||
semanticVersionNodes.item(0).getTextContent()
|
||||
);
|
||||
}
|
||||
|
||||
updateInfos.setAdminMessage(element.getElementsByTagName("adminMessage").item(0).getTextContent());
|
||||
updateInfos.setMajorChanges(element.getElementsByTagName("majorChanges").item(0)
|
||||
.getTextContent());
|
||||
|
||||
@@ -26,14 +26,6 @@ public class UserActualizationTask extends TimerTask {
|
||||
|
||||
Thread.currentThread().setName("UserActualizationTask");
|
||||
|
||||
/*
|
||||
* File-based log synchronization is optional. Do not create, open or parse the
|
||||
* configured file while the feature is disabled.
|
||||
*/
|
||||
if (!client.getChatPreferences().isLogsynch_fileBasedWkdCallInterpreterEnabled()) {
|
||||
return;
|
||||
}
|
||||
|
||||
// System.out.println("[Useract: ] Thread runned now");
|
||||
|
||||
// System.out.println("***********************Useract started");
|
||||
|
||||
@@ -101,143 +101,102 @@ public class Utils4KST {
|
||||
}
|
||||
|
||||
/**
|
||||
* Converts a frequency detected in a chat message into the kHz representation
|
||||
* used by the DX Cluster protocol.
|
||||
* Normalizes a chatmembers frequency-string for cluster usage<br/>
|
||||
* <b>returns a frequency String in KHz like = "144300" or "144300.0" to match DXC protocol needs</b>
|
||||
*
|
||||
* <p>Complete frequencies with two to five MHz digits are supported, for
|
||||
* example 50.200, 144.205, 1296.338, 10368.100 and 24048.100. An optional
|
||||
* second fractional group is retained as sub-kHz precision, for example
|
||||
* 144.205.2 becomes 144205.2 kHz.</p>
|
||||
*
|
||||
* <p>Relative values such as .205 or 205 use the configured fallback-band
|
||||
* prefix. The method only performs this fallback conversion after the general
|
||||
* message parser has already accepted the value as a frequency.</p>
|
||||
*
|
||||
* @param qrgString frequency as detected by the chat parser
|
||||
* @param optionalPrefix fallback MHz prefix for relative frequencies
|
||||
* @return frequency in kHz for a DX Cluster spot, or an empty string if the
|
||||
* value cannot be converted safely
|
||||
* @param optionalPrefix: if there is a value like ".300", it have to be decided, wich ".300": 144.300, 432.300, 1296.300 .... prefix means for example "144."
|
||||
*/
|
||||
public static String normalizeFrequencyString(
|
||||
String qrgString,
|
||||
SimpleStringProperty optionalPrefix
|
||||
) {
|
||||
if (qrgString == null || qrgString.isBlank()) {
|
||||
return "";
|
||||
public static String normalizeFrequencyString(String qrgString, SimpleStringProperty optionalPrefix) {
|
||||
|
||||
// final String PTRN_QRG_CAT2 = "(([0-9]{3,4}[\\.|,| ]?[0-9]{3})([\\.|,][\\d]{1,2})?)|(([a-zA-Z][0-4]{1}[\\d]{2}\\b)([\\.|,][\\d]{1,2}\\b)?)|((\\b[0-4]{1}[\\d]{2}\\b)([\\.|,][\\d]{1,2}\\b)?)";
|
||||
|
||||
try {
|
||||
qrgString = qrgString.replace(" ","");
|
||||
} catch (Exception e) {
|
||||
System.out.println("UTILS: QRG NULL, nothing to convert");
|
||||
// e.printStackTrace();
|
||||
}
|
||||
|
||||
/*
|
||||
* A comma is accepted as a decimal separator. Spaces are removed so older
|
||||
* stored formats such as "432 088" remain usable.
|
||||
*/
|
||||
String normalizedValue = qrgString
|
||||
.trim()
|
||||
.replace(" ", "")
|
||||
.replace(',', '.');
|
||||
|
||||
/*
|
||||
* Complete frequency with an explicit separator:
|
||||
*
|
||||
* 50.200
|
||||
* 144.205
|
||||
* 1296.338
|
||||
* 10368.100
|
||||
* 144.205.2
|
||||
*/
|
||||
Matcher completeFrequencyMatcher = Pattern.compile(
|
||||
"^(\\d{2,5})\\.(\\d{1,3})(?:\\.(\\d{1,2}))?$"
|
||||
).matcher(normalizedValue);
|
||||
final String PTRN_QRG_CAT2_wholeQRGMHz4Digits = "(([0-9]{4}[\\.|,| ]?[0-9]{3})([\\.|,][\\d]{1,2})?)"; //1296.300.3 etc
|
||||
final String PTRN_QRG_CAT2_wholeQRGMHz3Digits = "(([0-9]{3}[\\.|,| ]?[0-9]{3})([\\.][\\d]{1,2})?)"; //144.300.3 etc
|
||||
final String PTRN_QRG_CAT2_QRGwithoutPrefix = "((\\b[0-4]{1}[\\d]{2}\\b)([\\.|,][\\d]{1,2}\\b)?)"; //144.300.3 etc
|
||||
|
||||
if (completeFrequencyMatcher.matches()) {
|
||||
return formatDxClusterFrequency(
|
||||
completeFrequencyMatcher.group(1),
|
||||
completeFrequencyMatcher.group(2),
|
||||
completeFrequencyMatcher.group(3)
|
||||
);
|
||||
String stringAggregation = "";
|
||||
|
||||
if (testPattern(qrgString, PTRN_QRG_CAT2_wholeQRGMHz4Digits)) {//case 1296.200 or 1296.200.2 etc.
|
||||
stringAggregation = qrgString;
|
||||
|
||||
stringAggregation = stringAggregation.replace(".","");
|
||||
stringAggregation = stringAggregation.replace(",","");
|
||||
stringAggregation = stringAggregation.replace(" ", "");
|
||||
|
||||
if (stringAggregation.length() == 8) {
|
||||
String stringAggregationNew = stringAggregation.substring(0, stringAggregation.length()-1) + "." + stringAggregation.substring(stringAggregation.length()-1, stringAggregation.length());
|
||||
stringAggregation = stringAggregationNew + ".0";
|
||||
return stringAggregation;
|
||||
|
||||
} else if (stringAggregation.length() == 9) {
|
||||
String stringAggregationNew = stringAggregation.substring(0, stringAggregation.length()-2) + "." + stringAggregation.substring(stringAggregation.length()-2, stringAggregation.length());
|
||||
stringAggregation = stringAggregationNew;
|
||||
return stringAggregation;
|
||||
}
|
||||
|
||||
} else
|
||||
|
||||
if (testPattern(qrgString, PTRN_QRG_CAT2_wholeQRGMHz3Digits)) { //case 144.300 or 144.300.2
|
||||
stringAggregation = qrgString;
|
||||
|
||||
stringAggregation = stringAggregation.replace(".","");
|
||||
stringAggregation = stringAggregation.replace(",","");
|
||||
stringAggregation = stringAggregation.replace(" ", "");
|
||||
|
||||
if (stringAggregation.length() == 6) {
|
||||
stringAggregation = stringAggregation + ".0";
|
||||
return stringAggregation;
|
||||
}
|
||||
if (stringAggregation.length() == 7) {
|
||||
String stringAggregationNew = stringAggregation.substring(0, stringAggregation.length()-1) + "." + stringAggregation.substring(stringAggregation.length()-1, stringAggregation.length());
|
||||
stringAggregation = stringAggregationNew + ".0";
|
||||
return stringAggregation;
|
||||
|
||||
} else if (stringAggregation.length() == 8) {
|
||||
String stringAggregationNew = stringAggregation.substring(0, stringAggregation.length()-2) + "." + stringAggregation.substring(stringAggregation.length()-2, stringAggregation.length());
|
||||
stringAggregation = stringAggregationNew;
|
||||
return stringAggregation;
|
||||
}
|
||||
}
|
||||
else
|
||||
|
||||
if (testPattern(qrgString, PTRN_QRG_CAT2_QRGwithoutPrefix)) { //case ".050 or .300 or something like that"
|
||||
stringAggregation = qrgString;
|
||||
|
||||
stringAggregation = stringAggregation.replace(".", "");
|
||||
stringAggregation = stringAggregation.replace(",", "");
|
||||
stringAggregation = stringAggregation.replace(" ", "");
|
||||
|
||||
if (stringAggregation.length() == 3) { // like 050 or 300
|
||||
String stringAggregationNew = optionalPrefix.getValue() + stringAggregation;
|
||||
stringAggregation = stringAggregationNew + ".0";
|
||||
return stringAggregation;
|
||||
|
||||
} else if (stringAggregation.length() == 4) { //like 050.2 --> 0502
|
||||
|
||||
stringAggregation = optionalPrefix.getValue() + stringAggregation;
|
||||
String stringAggregationNew = stringAggregation.substring(0, stringAggregation.length() - 1) + "." + stringAggregation.substring(stringAggregation.length() - 1, stringAggregation.length());
|
||||
stringAggregation = stringAggregationNew;
|
||||
return stringAggregation;
|
||||
|
||||
} else if (stringAggregation.length() == 5) { //like 050.20 --> 05020
|
||||
|
||||
stringAggregation = optionalPrefix.getValue() + stringAggregation;
|
||||
String stringAggregationNew = stringAggregation.substring(0, stringAggregation.length() - 2) + "." + stringAggregation.substring(stringAggregation.length() - 2, stringAggregation.length());
|
||||
stringAggregation = stringAggregationNew;
|
||||
return stringAggregation;
|
||||
}
|
||||
}
|
||||
|
||||
/*
|
||||
* Compact complete frequency retained for compatibility:
|
||||
*
|
||||
* 144205
|
||||
* 1296338
|
||||
* 10368100
|
||||
* 432088.2
|
||||
*/
|
||||
Matcher compactFrequencyMatcher = Pattern.compile(
|
||||
"^(\\d{2,5})(\\d{3})(?:\\.(\\d{1,2}))?$"
|
||||
).matcher(normalizedValue);
|
||||
|
||||
if (compactFrequencyMatcher.matches()) {
|
||||
return formatDxClusterFrequency(
|
||||
compactFrequencyMatcher.group(1),
|
||||
compactFrequencyMatcher.group(2),
|
||||
compactFrequencyMatcher.group(3)
|
||||
);
|
||||
}
|
||||
|
||||
/*
|
||||
* Relative frequency. Values above 499 are deliberately rejected, matching
|
||||
* the previous behaviour and preventing a report such as 599 from becoming
|
||||
* a plausible-looking cluster frequency.
|
||||
*/
|
||||
Matcher relativeFrequencyMatcher = Pattern.compile(
|
||||
"^\\.?([0-4]\\d{2})(?:\\.(\\d{1,2}))?$"
|
||||
).matcher(normalizedValue);
|
||||
|
||||
if (!relativeFrequencyMatcher.matches()) {
|
||||
return "";
|
||||
}
|
||||
|
||||
String fallbackPrefix = optionalPrefix == null
|
||||
? null
|
||||
: optionalPrefix.getValue();
|
||||
|
||||
if (fallbackPrefix == null) {
|
||||
return "";
|
||||
}
|
||||
|
||||
fallbackPrefix = fallbackPrefix.trim();
|
||||
|
||||
if (!fallbackPrefix.matches("\\d{2,5}")) {
|
||||
return "";
|
||||
}
|
||||
|
||||
return formatDxClusterFrequency(
|
||||
fallbackPrefix,
|
||||
relativeFrequencyMatcher.group(1),
|
||||
relativeFrequencyMatcher.group(2)
|
||||
);
|
||||
}
|
||||
|
||||
/**
|
||||
* Formats an MHz part, a fractional MHz part and optional sub-kHz digits as a
|
||||
* DX Cluster frequency in kHz.
|
||||
*
|
||||
* <p>The fractional MHz part is padded on the right because 144.2 means
|
||||
* 144.200 MHz, while 144.21 means 144.210 MHz.</p>
|
||||
*
|
||||
* @param mhzPart complete MHz part
|
||||
* @param fractionalMhzPart one to three digits following the first separator
|
||||
* @param subKhzPart optional digits following a second separator
|
||||
* @return DX Cluster frequency in kHz
|
||||
*/
|
||||
private static String formatDxClusterFrequency(
|
||||
String mhzPart,
|
||||
String fractionalMhzPart,
|
||||
String subKhzPart
|
||||
) {
|
||||
String paddedFraction =
|
||||
(fractionalMhzPart + "000").substring(0, 3);
|
||||
|
||||
String subKhz = subKhzPart == null
|
||||
? "0"
|
||||
: subKhzPart;
|
||||
|
||||
return mhzPart
|
||||
+ paddedFraction
|
||||
+ "."
|
||||
+ subKhz;
|
||||
return stringAggregation; //if nothing else helps
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user