Autor: SP5UAF
Ostatnia aktualizacja: 2019-07-06

Jednym z najważniejszych zbiorów wykorzystywanym przez współczesne programy contestowe jest baza danych, zawierająca informacje o podmiotach DXCC/WAE. Informacje zawarte w tym zbiorze opisują m.in., w której strefie CQ oraz ITU znajduje się dany podmiot. Aktualność takiej bazy danych ma zasadnicze znaczenie dla wyniku, który widzimy w naszym programie contestowym, kiedy logujemy kolejne łączności. Ten wynik (wynik zgłoszony) jest traktowany jedynie informacyjnie i nie ma praktycznego znaczenia dla wyniku końcowego, który zobaczymy po ogłoszeniu wyników zawodów przez organizatora. Jednak nie zawsze tak było.

Aby to wszystko wyjaśnić, cofniemy się na chwilę w przeszłość. Omówimy także bazy danych, z których korzystają współczesne programy contestowe, wskażemy, w jaki sposób wpływają na wynik prezentowany w naszym contestowym logu. Powiemy także nieco o podmiotach DXCC/WAE.

Nieco historii. Logi papierowe

W czasach „przed komputerami” w contestingu używano wyłącznie dzienników papierowych. Prawie każde zawody posiadały dedykowane formularze, które należało wypełnić ręcznie i wysłać do organizatora zwykłą pocztą. Wzory formularzy były drukowane w wynikach zawodów (wyniki najczęściej były papierową publikacją) lub w pismach krótkofalarskich. Następnie były powielane i w ten sposób krążyły mniej lub bardziej oficjalnymi drogami w krótkofalarskim środowisku contestowym.

Uczestnicy zwykle mieli 30 dni na przygotowanie dzienników „na czysto” i wysłanie. Organizator gromadził nadesłane dzienniki i dokonywał ich weryfikacji. Była to ręczna praca. Sposób przygotowania logów papierowych był obwarowany szczegółowymi zapisami regulaminów zawodów, np.:

• wynik musiał być dokładnie obliczony,
• konieczne było podanie ilości mnożników i punktów na poszczególnych pasmach,
• zwykle wymagano, aby wykaz łączności był wykonany wg. pasm
• często wymagano, aby dziennik zawierał także alfabetyczną listę stacji, z którymi nawiązano łączności (oczywiście oddzielnie dla każdego pasma),
• zwykle wymagano także, aby do dziennika był dołączony alfabetyczny wykaz mnożników dla każdego pasma.
• konieczne było wyraźne, jednoznaczne zaznaczenie w logu wszystkich duplikatów – za zaliczenie do końcowego wyniku dużej ilości duplikatów groziła dyskwalifikacja.
• papierowy log musiał zawierać podpisane oświadczenie operatora o przestrzeganiu regulaminu zawodów.
• itd.

Już samo przygotowanie dziennika było uciążliwe, czasochłonne i wymagało aptekarskiej dokładności. Dlatego też termin przeznaczony na wysłanie dzienników zwykle wynosił właśnie 30 dni od daty zakończenia zawodów (decydowała data stempla pocztowego). Niejednokrotnie podczas przepisywania dziennika „na czysto” zdarzały się błędy. Wtedy bardzo przydawał się korektor i inne tego rodzaju akcesoria.

Wraz z pojawieniem się komputerów,  Internetu i poczty elektronicznej coraz częściej komisje zawodów umożliwiały wysyłanie dzienników w formie plików elektronicznych. W początkowej fazie pliki takie jedynie zastępowały dzienniki papierowe, a weryfikacja logów przez komisje zawodów nadal odbywała się w sposób ręczny.

Manualny sposób weryfikacji dzienników powodował, że na końcowe wyniki zawodów trzeba było czekać czasem ponad rok. Proces weryfikacji był niezwykle mozolny i długotrwały.

Miałem okazję oglądać kiedyś film, dokumentujący ogromną fińską wyprawę na zawody CQWW z 1990 roku. Stacja PJ9A/PJ9W (jeden znak był używany w części CW, drugi w części SSB zawodów) pracowała w kategorii Multi-Multi. To była ogromna wyprawa – fińscy krótkofalowcy na Antylach Holenderskich zbudowali od podstaw ogromną stację contestową. Większość sprzętu (w tym anteny i maszty) dotarła z Finlandii (wtedy rozkwitała firma NOKIA i Finowie mogli sobie pozwolić na realizacje wielu szalonych pomysłów). W filmowym dokumencie widać, że operatorzy na poszczególnych stanowiskach zapisywali łączności w logach papierowych. Niektórzy z uczestników wyprawy byli odpowiedzialni za bieżące zbieranie tych papierowych dzienników i ich przepisywanie do dziennika komputerowego. Ten komputerowy dziennik (choć tworzony w czasie zawodów) służył jedynie do wtórnego przepisywania łączności, aby mieć możliwość tworzenia zestawień mnożników, punktów i obliczania wyniku. Komputer oczywiście nie był podłączony do żadnego ze stanowisk operatorskich.

Taki sposób pracy to już oczywiście historia.

Wyprawa PJ9A/PJ9W z 1990 roku została opisana w miesięczniku QST z listopada 1991. Ta relacja jest dostępna na stronie amerykańskiego krótkofalowca K8ND: http://www.k8nd.com/Radio/CQ_1991Nov_PJ9A_PJ9W.pdf – naprawdę warto poczytać.

Dzienniki elektroniczne. Format Cabrillo

Powszechne wymaganie przesyłania dzienników elektronicznych to kwestia ostatnich kilku czy kilkunastu lat. Przełomem stało się upowszechnienie oprogramowania, pozwalającego na sterowanie transceiverami (CAT = Computer Assisted Technology), rozpowszechnienie programów contestowych, wykorzystujących technologię CAT oraz następnie opracowanie formatu Cabrillo przez amerykańskiego krótkofalowca N5KO.

Pierwszy dwa z wspomnianych czynników w znaczny sposób wpłynęły na pracę w zawodach, a z perspektywy przygotowania dzienników sprawiły, że log zaczął powstawać praktycznie w momencie przeprowadzenia i logowania łączności. Przestało być konieczne pisanie na papierze, a następnie uciążliwe przepisywanie do wymaganego formularza.

Z kolei format Cabrillo zmienił całkowicie sposób rozliczania zawodów. Początkowo był stosowany w największych zawodach amerykańskich (CQWW, CQ WPX, ARRL), ale dzięki swoim zaletom szybko przyjął się na całym świecie i jest powszechnie wykorzystywany przez większość organizatorów międzynarodowych zawodów.

Format Cabrillo to nic innego, jak określony standard opisu informacji, które znajdują się w elektronicznym dzienniku za zawody. Ten standard określa, co powinno się znajdować w nagłówku pliku, jak opisać kategorię uczestnictwa, jak zapisywać łączności, jak oznaczać pasma, emisje, daty, godziny itd.

A skoro już pojawił się w miarę ujednolicony standard opisu danych w logu za zawody, bezpośrednio wynikającym z tego krokiem było powstanie dedykowanego oprogramowania, które potrafi przetworzyć zbiór nadesłanych elektronicznie dzienników i automatycznie dokonać ich wzajemnej weryfikacji (cross-­checking).

W miarę wzrostu popularności formatu Cabrillo w przypadku wielu zawodów miał miejsce okres przejściowy, kiedy komisje zalecały przesyłanie dzienników elektronicznych w tym formacie, ale wciąż dopuszczały wysyłanie logów papierowych (większość z nich była przepisywana przez komisje do postaci elektronicznej). Z biegiem czasu większość organizatorów zawodów zaczęła restrykcyjnie wymagać przesyłania dzienników elektronicznych – w formacie Cabrillo. W przypadku większości zawodów skrócił się także dopuszczalny okres wysyłania dzienników, np. za zawody CQWW, CQ WPX czy ARRL dzienniki należy wysłać w ciągu 5 dni. Oczywiście skrócił się także czas opracowania i oublikowania wyników końcowych przez organizatorów zawodów.

Wynik. Liczyć czy nie liczyć?

Jeżeli do pracy w zawodach używamy programu contestowego, wynik jest automatycznie na bbieżąco obliczany w czasie pracy, a po wygenerowaniu pliku Cabrillo jest w nim umieszczony.

Ten wynik jest ważny dla operatora – pozwala porównać się z konkurencją czy też z własnymi wynikami z poprzednich lat, ułatwia także podejmowanie bieżących decyzji, dotyczących strategii pracy. Jednakże wynik, który prezentuje nasz program contestowy jest praktycznie bez znaczenia dla końcowego rezultatu, który zobaczymy w wynikach ogłoszonych przez organizatora zawodów. Równie dobrze możemy zgłosić wynik zerowy (0 punktów), ale jeśli nasz log będzie zgłoszony do określonej kategorii (nie będzie logiem do kontroli), organizator obliczy nasz rzeczywisty końcowy wynik. Dokładnie rzecz biorąc dokona tego używane przez komisję danych zawodów oprogramowanie.

Wyliczenie wyniku każdego uczestnika przez organizatora odbywa się zawsze: niezależnie od tego czy nasz log będzie miał obliczony wynik czy też będzie miał wykazane zero punktów. Poza procesem wzajemnej weryfikacji dzienników oprogramowanie sprawdzające nadesłane logi dokonuje wyliczenia punktów i mnożników na podstawie bazy danych podmiotów DXCC/WAE wykorzystywanej przez daną komisję zawodów.

Wynik, który widzimy w naszym logu podczas zawodów, zależy od aktualności bazy danych, z której nasz program korzysta. Jeśli nawet mamy aktualną bazę danych, nie daje to stuprocentowej pewności poprawnego punktowania, ponieważ czasem w zawodach pojawiają się stacje o nietypowych znakach.

Posłużmy się przykładem i wyobraźmy sobie, że w zawodach niespodziewanie pojawia się stacja o znaku 4U0A. Nie wiaodmo, czy ta stacja pracuje siedziby ITU z Genewy (wtedy jako kraj należy zaliczyć ITU HQ), czy z siedziby United Nations (wtedy jako kraj należy zaliczyć UN HQ) czy może jest to stacja z Austrii (należy ją zaliczyć jako OE), a może jest to pirat. Jest bardzo prawdopodobne, że nasz program contestowy niepoprawnie zaliczy tę stację lub też w ogóle nie uwzględni jej jako np. nowy mnożnik. Nie wiadomo, jak zachowają się w tym względzie programy wykorzystywane przez poszczególnych uczestników.

Natomiast komisja zawodów z pewnością zweryfikuje, skąd nadawała stacja 4U0A: jeżeli był to pirat, nikt nie otrzyma punktów ani mnożników za łączności; jeżeli okaże się, że stacja pracowała z siedziby ITU, każdy jej korespondent otrzyma punkty i mnożnik za ITU HQ itd. Inaczej mówiąc: wszyscy zostaną potraktowani w jednakowy sposób, jedną miarą – niezależnie od tego, jak łączność zakwalifikował program contestowy uczestnika.

To właśnie m.in. z wspomnianych powyżej powodów nie ma znaczenia, czy nasz dziennik będzie zawierał obliczony wynik zgłoszony czy nie. Ten wynik jest potrzebny przede wszystkim operatorowi, a nie komisji zawodów. Oprogramowanie weryfikujące dzienniki, poza samym procesem weryfikacji dokonuje także wyliczenia wyniku – zawsze w odniesieniu do ujednoliconej, takiej samej dla wszystkich uczestników zawodów bazy danych o podmiotach DXCC/WAE.

Dlaczego „podmiot” a nie „kraj”? Dlaczego DXCC/WAE?

W krótkofalarskiej terminologii posługujemy się raczej pojęciem „podmiot” niż terminem „kraj”. Określenie „podmiot” wywodzi się z programu dyplomowego DXCC (angielskie „entity”). Program DXCC, prowadzony przez ARRL, ściśle określa krótkofalarskie zasady podziału świata na podmioty. Można więc powiedzieć, że „podmiot” to określenie krótkofalarskiego kraju (czy też kraju w sensie krótkofalarskim). Jednakże podział na podmioty DXCC w wielu wypadkach nie pokrywa się z administracyjnym, politycznym podziałem świata na kraje.

Zasady określone w programie dyplomowym DXCC (można je znaleźć na stronie http://www.arrl.org/dxcc-rules) są przyjęte i stosowane przez krótkofalowców całego świata, także przez organizatorów zawodów. Jest to światowy standard. Skąd zatem wzięło się określenie DXCC/WAE?

Otóż w wielu zawodach (np. CQWW czy WAE) w przypadku stacji z Europy w uzupełnieniu do reguł DXCC stosowane są zasady dyplomu Worked All Europe (WAE). W myśl tych zasad, niektóre obszary Europy są traktowane jako niezależne podmioty WAE, choć nie stanowią odrębnych podmiotów DXCC. Przykłady takich podmiotów to:

• 4U1V – stacje pracujące z Międzynarodowego Centrum ONZ w Wiedniu. Stanowią oddzielny podmiot WAE, a w DXCC są zaliczane jako Austria (OE);
• GM/S – Shetland Islands. Oddzielny podmiot WAE, w DXCC zaliczany jako Szkocja (GM);
• IT – Sycylia. Podmiot WAE, w DXCC zaliczany jako Włochy (I);
• JW/B – Bear Island. Niezależny podmiot WAE, w DXCC zaliczany jako Spitzbergen Island (JW)

Reasumując: jeżeli w odniesieniu do jakichś zawodów mówimy o liście DXCC/WAE, należy rozumieć, że w przypadku Europy wykorzystywany jest podział na podmioty zgodny z zasadami WAE, a w przypadku pozostałych kontynentów stosowane są zasady podziału określone przez DXCC.

Zasady WAE można znaleźć na stronie z regulamin dyplomu Worked All Europe: https://www.darc.de/en/der-club/referate/committee-dx/diplome/wae-award/.

Bazy danych WL_CTY.dat, CTY.dat itd.

Jeżeli używamy programu contestowego, powinniśmy zadbać, aby posiadał aktualną bazę danych podmiotów DXCC. W zależności od używanego oprogramowania procedura aktualizacji takiej bazy danych jest nieco odmienna. W omówionym poniżej przykładzie posłużymy się programem N1MM Logger+.

WL_CTY.dat

Program N1MM Logger+ wykorzystuje bazę danych podmiotów zapisaną w pliku WL_CTY.dat. Plik zawiera informacje, które sprawiają, że program N1MM Logger+ jest w stanie poprawnie interpretować logowane łączności – tzn. na podstawie wpisywanego znaku program potrafi określić podmiot DXCC oraz strefę CQ i strefę ITU. To z kolei pozwala na prawidłowe zaliczanie mnożników i punktów za łączności.

Skąd wziąć aktualny plik wl_cty.dat

Pliki z bazami danych podmiotów do programów contestowych można znaleźć na stronie Contry Files, prowadzonej przez AD1C: http://www.country-files.com/. Pliki dostępne na tej stronie są na bieżąco aktualizowane. Warto zatem przed każdymi zawodami pobrać odpowiedni plik i zaktualizować bazę danych naszego programu contestowego.

Aktualizacja bazy danych w programie N1MM Logger+

Po pobraniu aktualnego pliku wl_cty.dat, w programie N1MM Logger+ należy wybrać menu [Tools], a następnie wybrać opcję [Import country list from downloaded file].

Następnie należy wskazać odpowiedni katalog na dysku i wskazać zapisany tam plik. Po wykonaniu tej operacji program poinformuje nas o wykonaniu ładowania pliku.

To właściwie wszystkie czynności, które należy wykonać. Proste!

Oczywiście najlepszą praktyką jest wykonywanie aktualizacji bazy danych podmiotów przed zawodami. Jeżeli jednak zapomnimy o wykonaniu tej operacji, można to wykonać także w czasie zawodów czy nawet po zawodach. W takiej sytuacji po wykonaniu aktualizacji należy ponownie wejść w menu [Tools], a następnie wybrać opcję [Rescore Current Contest] – to spowoduje ponowne przeliczenie wyniku w logu, ale już na podstawie zaktualizowanej bazy danych.

Inne programy contestowe, np. WriteLog czy Win-Test mają nieco odmienne procedury aktualizacji bazy podmiotów. Niezależnie jednak od tego, jakiego programu używamy, należy tę opcję odnaleźć, poznać sposób wykorzystywania i używać przed każdymi zawodami. Doświadczeni operatorzy często tworzą osobistą listę kontrolną czynności, które należy wykonać przed zawodami. Aktualizacja bazy podmiotów zawsze znajduje się na takiej liście.

Struktura pliku WL_CTY.dat

Konieczność samodzielnej, ręcznej edycji pliku WL_CTY.dat zdarza się sporadycznie, ale czasem jednak taka konieczność zachodzi. Warto więc wiedzieć nieco więcej o jego zawartości i budowie.

Jest to zwykły plik tekstowy (plain text), a więc może być otwierany i edytowany nawet w zwykłym notatniku. Plik zawiera informacje o ściśle określonej strukturze: to oznacza, że w takim pliku poszczególne rodzaje informacji są umieszczone w ściśle określonych pozycjach i są oddzielane ściśle określonymi symbolami. Przyjrzyjmy się niektórym fragmentom takiego pliku. Dla lepszej czytelności opisu na przykładzie dodano numery kolejnych kolumn (znaków) tekstu. Oznaczono je kolorem czerwonym – w rzeczywistym pliku WL_CTY.dat tych oznaczeń nie ma.

         1         2         3         4         5         6         7
1234567890123456789012345678901234567890123456789012345678901234567890123456
Sov Mil Order of Malta:   15:  28:  EU:   41.90:   -12.43:    -1.0:  1A:
    1A;
Spratly Islands:          26:  50:  AS:    9.88:  -114.23:    -8.0:  1S:
    9M0,BM9S,BN9S,BO9S,BP9S,BQ9S,BU9S,BV9S,BW9S,BX9S;
Monaco:                   14:  27:  EU:   43.73:    -7.40:    -1.0:  3A:
    3A;
Agalega & St. Brandon:    39:  53:  AF:  -10.45:   -56.67:    -4.0:  3B6:
    3B6,3B7;
Mauritius:                39:  53:  AF:  -20.35:   -57.50:    -4.0:  3B8:
    3B8;
Rodriguez Island:         39:  53:  AF:  -19.70:   -63.42:    -4.0:  3B9:
    3B9;
Equatorial Guinea:        36:  47:  AF:    1.70:   -10.33:    -1.0:  3C:
    3C;
Annobon Island:           36:  52:  AF:   -1.43:    -5.62:    -1.0:  3C0:
    3C0;
Fiji:                     32:  56:  OC:  -17.78:  -177.92:   -12.0:  3D2:
    3D2;
Conway Reef:              32:  56:  OC:  -22.00:  -175.00:   -12.0:  3D2/c:
    =3D2CR;
Rotuma Island:            32:  56:  OC:  -12.48:  -177.08:   -12.0:  3D2/r:
    =3D2RI;

• Pierwszy wiersz rekordu danych. Tutaj znajdują się podstawowe informacje podmiocie (kraju). Każdy rodzaj informacji ma określoną maksymalną liczbę znaków i jest zakończony znakiem „:” (dwukropek). Dla oprogramowania, które wykorzystuje plik WL_CTY.dat wystąpienie znaku „:” oznacza, że jest to koniec informacji danego rodzaju.
  • Znaki od 1 do 26. Tutaj umieszczana jest pełna słowna nazwa podmiotu.
  • Znaki od 27 do 31. Numer strefy CQ podmiotu.
  • Znaki od 32 do 36. Numer strefy ITU podmiotu.
  • Znaki od 37 do 41. Oznaczenie (skrót) kontynentu dla podmiotu.
  • Znaki od 42 do 50. Szerokość geograficzna (znakiem „-” poprzedzane są szerokości południowe).
  • Znaki od 51 do 60. Długość geograficzna (znakiem „-” poprzedzane są długości wschodnie).
  • Znaki od 61 do 69. Przesunięcie czasu względem czasu GMT.
  • Znaki od 70 do 76. Główny prefiks DXCC podmiotu. Znakiem „*” są poprzedzane prefiksy krajów zaliczanych do listy WAE. Kraje takie zaliczane są w zawodach organizowanych przez DARC oraz magazyn CQ, ale nie są zaliczane w zawodach organizowanych przez ARRL.
• Drugi wiersz rekordu danych i kolejne wiersze. Tutaj znajdują się informacje dotyczące głównego prefiksu (powtórzenie) oraz innych prefiksów i znaków. Są oddzielane przecinkami. Lista dodatkowych prefiksów może być umieszczona w wielu wierszach. Znak „;” (średnik) umieszczony po informacji oznacza, że jest to ostatni prefiks w wykazie dla danego kraju. Prefiks poprzedzony znakiem „=” (znak równości) oznacza, że program contestowy powinien interpretować informację jako pełny znak, a nie jako prefiks. Na powyższym przykładzie dla Conway Reef będzie sprawdzany dokładnie znak 3D2CR, ale np. dla Spratly Islands będą sprawdzane wymienione prefiksy, a więc program contestowy poprawnie zinterpretuje takie znaki jak np. 9M0S, BM9SI, BN9SXZ itp. i zaliczy łączności z takimi znakami jako Spratly Islands.

Plik WL_CTY.dat zawiera także informacje, które pozwalają na poprawną interpretację w przypadku takich krajów, gdzie mogą istnieć wątpliwości dotyczące prawidłowego zaliczenia strefy CQ lub ITU. Przyjrzyjmy się innej części pliku, tym razem dotyczącej Chin.

W przypadku Chin mamy całą listę dodatkowych prefiksów poprzedzonych znakiem „#” oraz znakiem głównego prefiksu z dwukropkiem. Umieszczenie takiej informacji rozpoczyna listę ze zmianami w porównaniu do informacji zawartych w pierwszym (głównym) wierszu. Mamy tutaj na przykład zapis BY0A(23)[42]. To oznacza, że wszystkie stacje z prefiksem BY0A będą miały przypisaną strefę CQ numer 23 (umieszczona w nawiasach okrągłych) oraz strefę ITU numer 42 (umieszczona w nawiasach kwadratowych). Z kolei zapis BY2M[33] oznacza, że stacje z prefiksem BY2M będą miały przypisaną strefę ITU numer 33 (umieszczona w nawiasach kwadratowych), natomiast strefa CQ zostanie pobrana z głównych informacji z pierwszego wiersza danych, a więc będzie to zawsze strefa CQ numer 24.

China:                    24:  44:  AS:   36.00:  -102.00:    -8.0:  BY:
#   BY: BY0A(23)[42],BY0B(23)[42],BY0C(23)[42],BY0D(23)[42],BY0E(23)[42],
        BY0F(23)[42],BY0G(23)[42],BY0H(23)[42],BY0I(23)[42],BY0J(23)[42],
        BY0K(23)[42],BY0L(23)[42],BY2A[33],BY2B[33],BY2C[33],BY2D[33],
        BY2E[33],BY2F[33],BY2G[33],BY2H[33],BY2I[33],BY2J[33],BY2K[33],
        BY2L[33],BY2M[33],BY2N[33],BY2O[33],BY2P[33],BY3G(23)[33],
        BY3H(23)[33],BY3I(23)[33],BY3J(23)[33],BY3K(23)[33],BY3L(23)[33],
        BY6Q[43],BY6R[43],BY6S[43],BY6T[43],BY6U[43],BY6V[43],BY6W[43],
        BY6X[43],BY7A[43],BY7B[43],BY7C[43],BY7D[43],BY7E[43],BY7F[43],
        BY7G[43],BY7H[43],BY7Q[43],BY7R[43],BY7S[43],BY7T[43],BY7U[43],
        BY7V[43],BY7W[43],BY7X[43],BY8A[43],BY8B[43],BY8C[43],BY8D[43],
        BY8E[43],BY8F[43],BY8G[43],BY8H[43],BY8I[43],BY8J[43],BY8K[43],
        BY8L[43],BY8M[43],BY8N[43],BY8O[43],BY8P[43],BY8Q[43],BY8R[43],
        BY8S[43],BY8T[43],BY8U[43],BY8V[43],BY8W[43],BY8X[43],BY9A[43],
        BY9B[43],BY9C[43],BY9D[43],BY9E[43],BY9F[43],BY9G(23)[43],
        BY9H(23)[43],BY9I(23)[43],BY9J(23)[43],BY9K(23)[43],BY9L(23)[43],
        BY9M(23)[43],BY9N(23)[43],BY9O(23)[43],BY9P(23)[43],BY9Q(23)[43],
        BY9R(23)[43],BY9S(23)[42],BY9T(23)[42],BY9U(23)[42],BY9V(23)[42],
        BY9W(23)[42],BY9X(23)[42];    3H,3I,3J,3K,3L,3M,3N,3O,3P,3Q,3R,3S,3T,3U,B0,B2,B3,B4,B5,B6,B7,B8,B9,BA,
    BD,BG,BH,BI,BJ,BL,BT,BY,BZ,XS,B1,=BD7LPD/UT3GF;

Samodzielna edycja pliku WL_CTY.dat

Jak już zostało wspomniane, w praktyce sporadycznie edytuje się plik, ale można wyobrazić sobie sytuację, kiedy taka konieczność zachodzi i jest jak najbardziej uzasadniona.

Posłużmy się wykorzystywanym wcześniej przykładowym znakiem 4U0A. Wyobraźmy sobie następującą sytuację. Mamy zamiar startować w CQWW. Do zawodów nie zostało wiele czasu. Zaktualizowaliśmy dane o krajach (tj. pobraliśmy najnowszą wersję pliku i załadowaliśmy), ale podczas lektury zapowiedzi wypraw contestowych zauważyliśmy, że ktoś zamierza wystartować w zawodach z United Nations HQ i będzie używał znaku 4U0A. Nietypowy znak, pracujący z poszukiwanego kraju powinien od razu obudzić naszą czujność i skłonić do przejrzenia pliku WL_CTY.dat. Dla podmiotu United Nations HQ możemy zobaczyć tam np. następujące informacje:

United Nations HQ:        05:  08:  NA:   40.75:    73.97:     5.0:  4U1U:
     =4U1UN;

Przegląd tych zapisów wskazuje, że nasz program contestowy prawdopodobnie będzie miał problem z prawidłowym zakwalifikowaniem łączności ze stacją 4U0A. Konieczna więc będzie edycja pliku i dodanie informacji o tym nietypowym znaku. Po wykonaniu takiej edycji i zapisaniu zmian wpis dla UN HQ będzie wyglądał następująco:

 United Nations HQ:        05:  08:  NA:   40.75:    73.97:     5.0:  4U1U:
     =4U1UN;=4U0A; 

Po zapisaniu zmian ponownie ładujemy informacje z pliku WL_CTY.dat do programu N1MM Logger+. Teraz, jeśli w czasie zawodów zalogujemy łączność ze stacją 4U0A, na pewno program contestowy zinterpretuje znak jako odpowiedni kraj (United Nations HQ) oraz podpowie odpowiednią strefę CQ (05).

Contestowa praktyka. Dlaczego to wszystko jest ważne?

Jak napisano na wstępie, jeśli wyślemy nasz dziennik do organizatorów (nie do kontroli) nawet z błędnie obliczonym lub w ogóle nie obliczonym wynikiem, to i tak nasz wynik zostanie wyliczony przez komisję. Jeżeli zawody traktujemy na zupełnym luzie i rezultat jest dla nas drugorzędny, nie ma to znaczenia. Jeśli jednak zależy nam na podnoszeniu swoich umiejętności, poprawianiu wyników i efektywnej pracy, jeśli chcemy porównywać się z innymi: posiadanie aktualnej bazy podmiotów w programie contestowym jest elementem bezwzględnie wymaganym. To jest, można by tak powiedzieć, contestowe przedszkole.
Dlatego też aktualizacja baz danych z podmiotami DXCC/WAE jest jedną z podstawowych czynności wykonywanych przed zawodami przez każdego operatora, dla którego contestowy wynik jest ważny.

Jeżeli masz jakieś uwagi do tekstu publikacji (sugestie, pomysły, korekty-tekstu itp.), będziemy wdzięczni za przekazanie ich w komentarzu. Jeśli to możliwe, prosimy o podpisanie komentarza swoim znakiem. Znaki wszystkich osób, których uwagi zostaną wykorzystane, będą umieszczone w nagłówku publikacji.