mirror of
https://github.com/praktimarc/kst4contest.git
synced 2026-08-26 20:16:54 +02:00
88 lines
2.5 KiB
Markdown
88 lines
2.5 KiB
Markdown
# Domain, callsigns and bands
|
|
|
|
## Chat-member identity
|
|
|
|
Full callsign variants can be distinct chat identities.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
DN9APW
|
|
DN9APW-2
|
|
DN9APW-70
|
|
```
|
|
|
|
Do not globally strip suffixes when identifying chat members.
|
|
|
|
Category is also part of identity. A practical key is conceptually equivalent to:
|
|
|
|
```text
|
|
FULL_CALLSIGN|CATEGORY
|
|
```
|
|
|
|
Do not allow messages from one category to attach to a same-looking member in another category.
|
|
|
|
## Base-call operations
|
|
|
|
Some features intentionally operate on the base callsign.
|
|
|
|
Confirmed examples:
|
|
|
|
### Worked state
|
|
|
|
Worked status is shared across suffix variants of the same base call.
|
|
|
|
If the base station has been worked on the relevant basis, variants such as `CALL-2`, `CALL-70`, `CALL-144`, `CALL-432` should not become independent worked identities merely because of the suffix.
|
|
|
|
### Monitoring
|
|
|
|
Monitoring a station entered as `DN9APW-2` or `DN9APW-70` should monitor the base call `DN9APW`.
|
|
|
|
This is intentional: a user monitoring another station's skeds should not have to create one monitor entry per SSID.
|
|
|
|
Do not extend base-call matching to unrelated features without approval.
|
|
|
|
## Suffix semantics
|
|
|
|
Do not assume a suffix always means a band or category.
|
|
|
|
Historical examples have shown the same base calls with different suffix conventions in different chat categories.
|
|
|
|
Therefore:
|
|
|
|
- preserve exact full-call identity where needed;
|
|
- normalize only for explicitly approved base-call features;
|
|
- never infer missing band/category semantics from the suffix alone.
|
|
|
|
## Categories
|
|
|
|
KST4Contest's central VHF/UHF usage focuses on ON4KST categories 2 and 3.
|
|
|
|
However, other categories can occur.
|
|
|
|
Rules:
|
|
|
|
- unsupported/uninteresting categories must be ignored or handled safely;
|
|
- they must not produce index, switch or null errors;
|
|
- do not let their values contaminate category-2/category-3 band logic.
|
|
|
|
## Band availability
|
|
|
|
Band activity can be derived from several signals including name/text parsing and explicit/manual information.
|
|
|
|
Confirmed invariant:
|
|
|
|
`NOT-QRV` overrides positive availability indications.
|
|
|
|
Known-active-band and `B+` handling should use one consistent interpretation across the program.
|
|
|
|
Do not implement separate slightly different parsers in multiple UI/features if a shared existing mechanism is available.
|
|
|
|
## Current QRG
|
|
|
|
Features that depend on propagation/band/frequency should use the current relevant QRG or the approved band calculation.
|
|
|
|
Never silently reintroduce a universal hardcoded 144 MHz fallback.
|
|
|
|
When a frequency is ambiguous and no approved fallback exists, ask rather than guessing.
|