OK2PPK » Texty » Technika a provoz » Rozdíly ve výpočtech bodů z VKV závodů | ---

Rozdíly ve výpočtech bodů z VKV závodů

Při bodování podle vzdálenosti

První víkend roku 2025 proběhla na webu OK2KKW diskuse týkající se rozdílů ve vypočtených bodech z VKV závodů. Mezi výpočtem národního vyhodnocovatele ČRK, mezinárodního vyhodnocovatele IARU a původním výpočtem našeho logovacího programu mohou být někdy rozdíly a diskuse se tak týkala samotné podstaty výpočtu bodů ze vzdálenosti lokátorů - jak je to vlastně přesně vypočteno a zda správně, na jakém modelu Země se vzdálenost počítá, zda by to nešlo spočítat přesněji, a padly v ní i další otázky, třeba jak vlastně rozumět údajům uváděným ve výsledkových listinách, např. prezentovaným chybovostem.

Obsah:

• Soubor deníku z VKV závodu ve formátu EDI
• Přesnost předávání polohy pomocí lokátorů
• Výpočet vzdálenosti lokátorů
• Porovnání výsledků výpočtů

Téma diskuse mě zaujalo, protože na finální výpočet bodů u svých deníků používám svůj program Loc a nějaké zásadní rozdíly oproti výsledkům spočteným ČRK a IARU jsem u svých logů nezaznamenal. Ale říkal jsem si, že by mohlo být zajímavé udělat si přepočet i pár logů od jiných stanic, tak abych programem prohnal i nějaké jiné kombinace lokátorů, než ty co mívám ve svých denících. Program Loc ve verzi 2.2 umožňoval snadno porovnat až na úroveň jednotlivých spojení svůj výpočet s původními údaji v deníku, a tak jsem stáhnul z výsledkovek pár jiných EDI souborů a zkusil si je přepočítat a porovnat to s tím, co bylo původně v deníku, a s tím, co bylo dostupné ve výsledcích ČRK a IARU.

Očekával jsem, že uvidím většinou jen pár odchylek na úrovni ±1 bod, a částečně to tak i bylo, ale občas jsem narážel na výrazně větší rozdíly a bylo časově dost náročné dohledávat jejich důvod. Nakonec jsem kvůli tomu přepsal program Loc na verzi 2.3 s rozšířenými možnostmi detekce různých chyb v denících, abych je nemusel stále ručně vyhledávat, a s možností měnit parametry výpočtu jako přesnost nebo použitý algoritmus, a přepočítal jsem jím celou jednu sadu deníků OK stanic z jednoho pásma z jednoho velkého závodu, tak aby šlo data mezi sebou alespoň trochu smysluplně porovnat.

Výsledky byly pro mě docela zajímavé a hlavně jsem se v některých směrech dověděl trochu více o tom, jak se liší údaje prezentované ČRK a IARU. A současně jsem si potvrdil některé předpoklady, které jsem měl o přesnosti samotných výpočtů. Pro mě samotného bylo pak klíčové potvrzení, že výstupy programu Loc se mi shodují velmi dobře s výstupy IARU. Kdo máte zájem, tak níže jsem z toho porovnávání zkusil seskládat svoje poznatky, ale nečekejte žádné senzační odhalení apod., kdo se pohybuje "v branži" a posílá pravidelně deníky ze závodů a sleduje prezentované výsledky nebo si sám i píše programy na výpočet, tak nebude překvapený. Ve více jak dvou desítkách tisíc přepočtených spojení jsem našel jen jedno jediné, u kterého se mi nepodařilo určit, proč bylo ze strany IARU při načítání deníku vlastně smazáno, všechny jiné rozdíly měly nějaký vysvětlitelný důvod. Největší rozdíly vznikají chybami nebo nekorektně provedenými zásahy v datech v deníku EDI v důsledku odlišné interpretace těchto chyb různými vyhodocovacími programy. Odlišnosti způsobené na úrovni samotného výpočty jsou minoritní.

Nevím, jak moc je ten, kdo zabrousí na tuto stránku, znalý podrobností o datech uložených v souboru EDI, detailů o souřadných systémech lokátorů, způsobu výpočtu vzdálenosti lokátorů a problémech spojených s realizací tohoto výpočtu. Pro ty, pro které je logovací program černá skříňka, do které z jedné strany strčí seznam svých spojení a z druhé strany jim vypadne hotový EDI, zde zkusím nejprve dát stručný úvod do dané problematiky.

Základní informace, ze kterých je vhodné vycházet, najdete v IARU R1 VHF Handbooku, v době vzniku této stránky je to konkrétně IARU-R1 VHF Handbook 10.02. Najdete v něm popis struktury souboru EDI, popis systému Lokátorů i informace jak počítat body ze závodů pořádaných v rámci regionu IARU R1. Pro VKV závody vyhlašované na národní úrovni u nás jsou pak dalším zdrojem informací Všeobecné podmínky závodů na VKV.

Soubor deníku z VKV závodu ve formátu EDI

Největším zdrojem rozdílů mezi tím, co nám vypočte náš logovací program, a co vypočtou vyhodnocovací programy ČRK a IARU, jsou chyby v závodním deníku. Nejde ani tak o chyby v přijatém kódu, ty jsou pak při křížové kontrole obvykle posuzovány stejně a je to spíše otázka jaké logy stanic měl na kontrolu k dispozici který vyhodnocovatel, ale jde o různé překlepy nebo i běžné věci jako duplicitní nebo nekompletní spojení, kde může být přístup vyhodocovacích programů k těmto údajům odlišný.

Na zasílání deníků z VKV závodů se v IARU R1 již delší dobu používají soubory ve formátu EDI. Pokud chceme do tohoto souboru ručně zasahovat, tak bychom měli něco vědět o jeho struktuře. Co je vlastně EDI a kde se vzal? Je to formát pro elektronickou výměnu dat pro soutěže nad 30MHz v rámci regionu IARU R1. Práce na návrhu společného formátu pro přenos dat začaly někdy v roce 1992, v roce 1994 byl představen formát NORDACTI pro použití v Nordic Activity Contestu, v roce 1995 již lze nalézt dokumenty IARU R1 komise C.5 týkající se formátu REG1TEST verze 1.1 a na konferenci IARU R1 ve Vídni v únoru 1998 byl formát pro elektronickou výměnu dat přijat v podobě, v jaké ho nyní stále používáme.

Soubor ve formátu EDI je obyčejný textový soubor obvykle s příponou EDI. Jeho základ je poplatný době vzniku, kdy zdaleka ne každý měl přístup k Internetu, takže se na přenos používal také protokol AX.25 a Packet Radio. Takže jsou v něm povoleny pouze znaky 7-bit ASCII z rozsahu 32 až 127 plus řídící znaky 10 a 13 (LF a CR) a délka řádku je omezena na 75 znaků. To se týká všech položek souboru EDI, tj. i těch, kam se zapisují jména, adresy a komentáře k závodu, ani do nich tedy nepatří diakritika. Základní struktura EDI vypadá následovně:

Struktura soubory EDI

[REG1TEST;hodnota]
TName=hodnotaF
TDate=hodnota1;hodnota2
PCall=hodnota
PWWLo=hodnota
PExch=hodnota
PAdr1=hodnotaF
PAdr2=hodnotaF
PSect=hodnotaF
PBand=hodnota
PClub=hodnota
RName=hodnotaF
RCall=hodnota
RAdr1=hodnotaF
RAdr2=hodnotaF
RPoCo=hodnotaF
RCity=hodnotaF
RCoun=hodnotaF
RPhon=hodnotaF
RHBBS=hodnotaF
MOpe1=hodnota nebo více hodnot
MOpe2=hodnota nebo více hodnot
STXEq=hodnotaF
SPowe=hodnotaF
SRXEq=hodnotaF
SAnte=hodnotaF
SAntH=hodnotaF1;hodnotaF2
CQSOs=hodnota1;hodnota2
CQSOP=hodnota
CWWLs=hodnota1;hodnota2;hodnota3
CWWLB=hodnota
CExcs=hodnota1;hodnota2;hodnota3
CExcB=hodnota
CDXCs=hodnota1;hodnota2;hodnota3
CDXCB=hodnota
CToSc=hodnota
CODXC=hodnota1;hodnota2;hodnota3
[Remarks]
hodnotaF
...
[QSORecords;udaj]
záznam spojení
...

Popis "hodnotaF" znamená, že zde může následovat volný text používající všechny výše uvedené znaky ASCII, popis "hodnota" znamená, že zde jsou povoleny dle kontextu daného parametru pouze některé znaky ASCII - typicky velká písmena A až Z, číslice 0 až 9, lomítko u volacích značek, čísla jsou povolena pouze kladná v decimálním tvaru a tam, kde se očekává číselná hodnota, by hodnota neměla zůstat prázdná, údaje by měly být zadávány v jednotkách soustavy SI, atd. Pokud lze u některé položky zadat více hodnot současně, tak se od sebe oddělují znakem středník. Pokud je u položky přímo uvedeno několik hodnot, tak musí být vyplněny všechy. Záznam spojení bude podrobněji rozebrán níže a skládá se celkem z 15 hodnot oddělených od sebe středníky.

Jednotlivé položky souboru EDI se zapisují každá na samostatný řádek a to od začátku tohoto řádku bez jakýchkoliv vložených mezer mezi začátkem řádku a začátkem položky. Na to je dobré dávat pozor pokud vytváříte EDI soubor ručně např. kopírováním jeho částí z jiných výstupů, kde vám "inteligentní" algoritmus řídící označování kopírovaného bloku textu občas přistrčí k tomu, co jste zamýšleli označit, i nějakou mezeru navíc před nebo za tímto blokem. Snadno se to přehlédne. Záleží na konkrétním vyhodnocovacím programu, zda vám mezery navíc a nebo i jiné odchylky od definice formátu EDI odpustí.

[REG1TEST;hodnota]

Soubor EDI se skládá ze tří sekcí, z nichž každá začíná položkou uzavřenou v hranatých závorkách. První sekcí je hlavička začínající položkou [REG1TEST;hodnota], kde REG1TEST je identifikátor typu souboru ve formátu EDI a "hodnota" je číslo verze tohoto formátu (zatím existuje jen verze 1.1 a píše se tam číslo 1). Hlavička pak následně obsahuje řadu položek s různými údaji o závodu, soutěžní stanici a jejích celkových výsledcích. Každá položka hlavičky se zapisuje na samostatný řádek a skládá se z názvu položky ukončeného rovnítkem a hodnoty položky (nebo více hodnot oddělených středníky), která se má dané položce přiřadit. Pokud v názvech položek nedodržíte malá a velká písmena tak, jak jsou uvedene v definici EDI, je opět na benevolenci vyhodnocovacího programu, zda vám toto akceptuje.

[Remarks]

Druhá sekce začíná položkou [Remarks] a obsahuje váš komentář k danému závodu, který chcete sdělit vyhodnocovateli a případně i ostatním účastníkům, protože texty komentářů bývají někdy zveřejňovány přímo na stránkách s výsledky závodů. Komentář začíná řádkem následujícím za položkou [Remarks], může mít teoreticky libovolný počet řádků a končí řádkem předcházejícím položce uvozující třetí sekci souboru EDI. Text komentáře může být libovolný, ale jsou v něm povoleny jen výše uvedené ASCII znaky a maximální délka řádku.

[QSORecords;hodnota]

Druhá sekce končí položkou [QSORecords;hodnota], která uvozuje třetí sekci s vlastními záznamy jednotlivých spojení. Údaj "hodnota" udává počet těchto záznamů, které budou ve třetí sekci následovat. Tato sekce nemá už žádné další označení svého konce, končí koncem souboru. Skutečný počet záznamů spojení v této sekci by měl souhlasit s počtem záznamů deklarovaným na jejím začátku.

[END;hodnota]

Někdy se používá ještě jeden oddělovač sekce ve tvaru [END;hodnota], který bývá umístěn až na samotném konci souboru za posledním záznamem spojení, a údaj "hodnota" v něm obsahuje název a verzi logovacího programu, který byl pro vytvoření souboru EDI použit. Tento oddělovač ale není součástí definice formátu EDI, takže by v souboru správně neměl být, nicméně stal se jakýmsi neoficiálním standardem a je vyhodnocovacími programy obvykle trpěn a mnohdy i jimi přímo využíván pro zobrazení informací o tom, jaké logovací programy byly v závodu použity. Některé logovací programy tuto informaci vkládají do sekce s komentářem, odkud se ale podstatně hůře strojově zpracovává.

Pojmenování souboru EDI

Vyhodnocovatel závodu může mít extra požadavky na pojmenování souboru, ve kterém posíláte svůj log ze závodu. Na naší národní úrovni je způsob pojmenování deníků uveden ve Všeobecných podmínkách VKV závodů - název souboru se skládá z dvoumístného čísla následovaného volací značkou soutěžní stanice, která se uvede ve tvaru dle povolovací listiny. Dvoumístné číslo vyjadřuje pásmo a soutěžní kategorii single nebo multi (popř. 6H) podle následující tabulky:

Číselné značení souborů EDI

Pásmo	SO	MO	6H SO	6H MO
50MHz	50	51	-	-
145MHz	01	02	61	62
435MHz	03	04	63	64
1.3GHz	05	06	-	-
2.4GHz	07	08	-	-
3.4GHz	09	10	-	-
5.7GHz	11	12	-	-
10GHz	13	14	-	-
24GHz	15	16	-	-
47GHz	17	18	-	-
76GHz	19	20	-	-
120GHz	21	22	-	-
134GHz	23	24	-	-
245GHz	25	26	-	-

Hlavička EDI

Podívejme se nyní na jednotlivé položky hlavičky EDI. U některých je striktně požadováno jejich vyplnění, některé jsou volitelné a údaje z některých může vzít vyhodnocovací program jen jako informační a jejich hodnotu si pro finální vyhodnocení přepočítá sám.

První část položek je důležitá a shrnuje základní informace o závodu a kategorii, do které se soutěžní stanice přihlásila, a o předávaných kódech, které stanice v závodu používala. Pak následují položky vesměs nepodstatné pro samotné vyhodnocení závodu, ale shrnující podrobnosti o soutěžní stanici, jako jsou jméno, adresa, seznamy operátorů, informace o použitém zařízení a kontaktní údaje. Poslední část pak obsahuje položky, ve kterých soutěžní stanice deklaruje svůj výsledek v závodě.

TName, TDate

Základní popis závodu, kterého se obsah souboru EDI týká, je uveden v položkách TName a TDate. Do položky TName se uvede název závodu. Vzhledem k tomu, že se obvykle deníky nahrávají buď prostřednictvím nějakého robota, kde se často už při nahrávání volí přímo konkrétní závod, nebo se posílají emailem vyhodnocovateli opět nějakého konkrétního závodu, tak název uvedený v položce TName nebývá obvykle kritický, pokud není v podmínách stanoveno, že se zde musí uvést přesně nějaký konkrétní text. Položka TDate má dvě hodnoty oddělené středníkem. Obě jsou ve formátu RRRRMMDD (RRRR=rok, MM=měsíc, DD=den), kde první hodnota udává datum začátku závodu a druhá datum konce závodu. Nevím, zda toto je kontrolováno, správné nastavení může hrát roli asi hlavně tam, kde se používá na nahrávání univerzální robot sbírající souběžně logy z více závodů. Při přepočtech deníků jsem si všimnul, že v některých denících byla položka TDate nekompletní a přesto byly jak ČRK, tak i IARU vyhodoceny, takže vám chybné vyplnění této položky zřejmě může projít. Např. Atalanta Locator standardně do EDI vždy vyplňuje tento údaj jako dva dny po sobě, ikdyž se jedná o jednodenní závod jako je třeba Provozní aktiv VKV.

PCall, PWWLo, PExch

V záznamech jednotlivých spojení není místo, kam by se dala uložit vyslaná značka, vyslaný lokátor a vyslaný kód výměny. Tyto údaje jsou u všech spojení stejné a zapíší se do hlavičky do položek PCall, PWWLo a PExch. Délka těchto položek musí logicky být ve stejném rozsahu, jako je přípustná délka jim odpovídajících přijatých položek v záznamech pro spojení, tj. vyslaná značka může mít 3 až 14 znaků, vyslaný lokátor 4 nebo 6 znaků a kód výměny nejvýše 6 znaků. Tyto 3 položky musíte vyplnit přesně tak, jak jste je během závodu používali, protože pokud vyhodnocovatel provádí křížovou kontrolu deníků, tak právě odtud si vezme váš údaj jako referenční když ověřuje, zda vaše protistanice od vás přijaly údaje správně. A během závodu tyto tři údaje už nemůžete v rámci jednoho logu měnit. Např. pokud chcete v závodě jet na více značek, tak v tom vám pořadatel závodu obvykle nebrání a je mu to jedno, ten si hlídá spíše unikátnost stanic z důvodu, aby si někdo nepřipisoval do deníku smyšlená spojení, ale pak nemůžete tato spojení navázaná pod různými značkami sečíst do jednoho logu a pro každou značku musíte vést extra deník s číslováním spojení od 001 a každý tento deník se pak vyhodnocuje zvláště.

Ještě se vrátím k položce kódu výměny PExch, kam zapisujete váš vyslaný kód výměny, a v záznamu spojení je to pak položka Received exchange, kam zapisujete kód výměny přijatý od protistanice. Co je kód výměny? Základní předávaný kód v závodech na VKV obvykle obsahuje RST, číslo spojení a lokátor, a na tyto údaje jsou v EDI souboru přímo připraveny položky, kam je zapíšete. Pokud si pořadatel vašeho závodu vymyslí něco dalšího na předávání navíc, třeba okresní znak, tak na to můžete použít právě položku kódu výměny. Ta má k sobě v hlavičce navíc připravené i další položky, kde se podle kódu výměny dají počítat třeba i násobiče. Je to tedy volitelný 4. předávaný údaj bez předem v EDI definovaného významu, který se ale běžně moc nepoužívá, alespoň ne ve velkých VKV závodech. Např. v Moon Contestu se kromě RST, čísla spojení a lokátoru ještě jako 4. údaj předává QTH, a na uložení QTH už v EDI zbývá jen kód výměny, kam by ho šlo zapsat. Takže vaše QTH, které jste předávali stanicím, zapíšete přesně tak, jak jste ho dávali, do položky PExch v hlavičce EDI, a do položek Received exchange v záznamech spojení zapisujete QTH přijatá od protistanic. Tento příklad použití má jednu chybu - kód výměny by měl mít maximálně 6 znaků, ale předávaná QTH mají obvykle znaků mohem více, takže se v tomto případě formát EDI "ohýbá" poněkud nad rámec své původní definice a QTH se zapisují do dotyčných položek ikdyž přesahují jejich přípustnou délku a je případně překročena i maximální přípustná délka celého řádku. Neříkám, zda je to špatně nebo dobře, ale je pak potřeba počítat s tím, že vám takto modifikovaný soubor EDI nemusí načíst program, který se drží striktně původní definice formátu EDI.

PAdr1, PAdr2

Další dvě položky hlavičky jsou PAdr1 a PAdr2. Podrobnosti o vašem stanovišti použitém na závod nepíšete do položek PWWLo a PExch, do nichž patří jen přesně ty údaje, které byly součástí vašeho vyslaného kódu, ale celou skutečnou adresu soutěžního stanoviště uvedete právě do položky PAdr1, a pokud vám jeden řádek k jejímu celému zápisu nestačí, tak můžete pokračovat ještě druhým řádkem v položce PAdr2.

PSect

Následují další dvě důležité položky. Položka PSect obsahuje kód soutěžní kategorie, ve které chcete být hodnoceni. Musí být uveden přesně ve tvaru jak ho stanovil pořadatel závodu ve svých podmínkách. Na VKV závodech se typicky rozlišují kategorie single s jedním operátorem nebo multi s více operátory a pro některá pásma je i další dělení podle výkonu na low power do 100W, QRP do 5W a v závodech 24hodin může být vypsána kategorie 6 hodin. Ale můžou být i další členění, třeba jestli v daném závodě vysíláte z nějakého území anebo mimo něj, jestli jste stanice vysílající z nějaké větší nadmořské výšky apod. Je potřeba dávat dobrý pozor při volbě kategorie např. v závodech, které zvláště vyhodnocuje národní vyhodnocovatel ČRK a zvláště IARU, a kde předáváte svůj deník mezinárodnímu vyhodnocovateli prostřednictvím národního vyhodnocovatele. Jsou zde totiž odlišnosti v kategoriích i zařazování do nich a jednomu vyhodnocovateli může pro vaše správné zařazení do kategorie stačit jen výkon uvedený v položce SPowe, kdežto druhý může vyžadovat explicitní detailní nastavení v položce PSect.

PBand

Další důležitá položka je PBand, tj. soutěžní pásmo. Nelze sem psát libovolnou hodnotu, ale je nutné vyjít z číselníku, který daný pořadatel závodu používá. Obvykle se v této položce kmitočty nad 1GHz uvádějí v GHz a naopak nižší v MHz. Teoreticky správné údaje najdete v popisu formátu EDI ve VHF Handbooku anebo ve Všeobecných podmínkách VKV závodů, ale při bližším zkoumání zjistíte, že v oblasti mikrovln se tyto dva zdroje informací liší. A např. relativně nedávno se měnilo označení pásem 2m a 70cm ze 144 a 432 na 145 a 435MHz, takže někde vám to vezmou postaru, někde ponovu a někde pod obojím. Všeobecné podmínky VKV závodů zmiňují označení pásem následovně - 50 MHz, 70 MHz, 145 MHz, 435 MHz, 1.3 GHz, 2.4 GHz, 3.4 GHz, 5.7 GHz, 10 GHz, 24 GHz, 47 GHz, 76 GHz, 120 GHz, 134 GHz a 245 GHz, s tím, že lze místo desetinné tečky použít i desetinnou čárku. Oproti tomu VHF Handbook v popisu formátu EDI uvádí označení pásem takto - 50 MHz, 70 MHz, 145 MHz, 435 MHz, 1,3 GHz, 2,3 GHz, 3,4 GHz, 5,7 GHz, 10 GHz, 24 GHz, 47 GHz, 76 GHz, 120 GHz, 144 GHz a 248 GHz.

PClub

Položka PClub je značka radioklubu, jehož členem je operátor nebo jsou operátoři, kteří jeli tento závod. Zamýšleno je to tak, že se pak vaše body sčítají v rámci nějaké soutěže tomuto radioklubu. V reálu sem single op stanice obvykle nepíší nic a klubové stanice, které jely na zkrácenou závodní značku, sem obvykle uvádějí normální značku svého radioklubu.

RName, RCall, RAdr1, RAdr2, RPoCo, RCity, RCoun, RPhon, RHBBS

Následuje sada položek, které shrnují údaje o odpovědném operátorovi soutěžní stanice. U nekolektivních stanic jsou to tedy přímo údaje o dotyčném operátorovi, který závod jel, kdežto u kolektivních stanic jsou to údaje o operátorovi, který je za provoz dotyčné stanic odpovědný, tj. nemusel se vlastně za klub závodu ani přímo zúčastnit. Do položky RName se píše jméno a do položky RCall značka odpovědného operátora. Položky RAdr1, RAdr2, RPoCo, RCity a RCoun slouží k zapsání adresy odpovědného operátora včetně poštovního směrovacího čísla, města a země. Do položky RPhon lze uvést jako kontakt na odpovědného operátora telefonní číslo a položka RHBBS sloužila k zadání schránky odpovědného operátora v síti Packet Radio, a dnes se sem obvykle uvádí kontaktní emailová adresa. Pokud vyhodnocovatel závodu zveřejňuje obdržené deníky, tak je potřeba počítat s tím, že údaje, které jste zde v EDI uvedli, mohou být pak někdy volně přístupné všem na internetu. Z výše uvedených údajů se obvykle vždy vyplňuje jméno, značka, alespoň část adresy a v dnešní době bývá důležitá a někdy i přímo vyžadovaná emailová adresa v položce RHBBS, na kterou vám např. může být po nahrání deníku robotem zasláno potvrzení o přijetí logu a přes kterou s vámi bude vyhodnocovatel v případě potřeby komunikovat.

MOpe1, MOpe2

Další dvě položky MOpe1 a MOpe2 slouží pro zapsání seznamu operátorů, kteří obsluhovali soutěžní stanici. Píší se sem značky operátorů, které se oddělují znakem středník. Pokud vám pro celý seznam nestačí první řádek MOpe1, tak se pokračuje na řádku MOpe2. U kolektivních stanic soutěžících v kategorii multi op je to jasné, údaj se vždy vyplňuje, ale u single op stanic zde bývá odlišnost v tom, co chce který vyhodnocovatel vyplnit. Někdy u stanic single op není vyplnění položky MOpe1 vyžadováno, jindy zde musíte svoji značku také zadat, jinak vám robot deník odmítne přijmout.

STXEq, SPowe, SRXEq, SAnte, SAntH

Položky STXEq, SPowe, SRXEq, SAnte a SAntH popisují zařízení soutěžní stanice použité během závodu. STXEq je popis vysílacího zařízení a SRXEq popis příjímacího zařízení. Když používáte transceiver, tj. máte stejné zařízení na příjem i vysílání, tak se obě položky vyplní shodně. Do položky SPowe se zapisuje výkon vysílače jako celé číslo ve wattech a to obvykle bez jednotky W - správné vyplnění může být dost důležité typicky v případě, že vyhodnocovatel podle udaného výkonu automaticky rozděluje ve výsledkové listině stanice do různých výkonových kategorií. Do položky SAnte se uvádí informace o vámi použitém anténním systému. Poslední položka SAntH se vyplňuje dvěma hodnotami oddělenými znakem středník. Obě se uvádějí jako celé číslo v metrech a první hodnota udává výšku antény nad úrovní země a druhá výšku antény nad úrovní moře. Je dobré si všimnout, že se u obou hodnot jedná o výšku antény, nikoliv vašeho stanoviště. Kdo jede závod někde z kopce z portejblu ze stanu, tak sem asi většinou zadá do první položky výšku stožáru a do druhé prostě nadmořskou výšku dotyčného kopce, nicméně správně by tam měla být na druhém místě právě ta nadmořská výška antény. O tom, jak se to má správně vyplnit v případě, že se použije na daném pásmu více antén rozmístěných v různých výškách, popis formátu EDI nic neříká.

U výše popsaných položek popisujících zařízení bych se ještě zastavil. Pokud vyhodnocovatel závodu ve výsledkových listinách uvádí údaje o zařízení a anténách a máte skutečně zájem, aby tyto vaše údaje ostatní viděli kompletně, tak je dobré se podívat, jakým způsobem vyhodnocovatel případně tyto údaje ořezává, pokud jsou texty pro jeho účely příliš dlouhé, a svůj popis zařízení a antén tomu přizpůsobit. A jedna zajímavost - údaje o svém zařízení do logů vždy vyplňuji, nemám žádný důvod je neuvést, a přesto ve výsledkovkách IARU u mě z nějakých záhadných důvodů tyto údaje chybí. Bádal jsem nad tím a došel jsem k názoru, že je tomu tak od doby, kdy jsem logy do vyhodnocení IARU začal posílat přímo a přestal se spoléhat na jejich předání národním vyhodnocovatelem. Je fakt, že při nahrání deníku do robota IARU se mi při potvrzování objeví údaj o anténě a výkonu, ale už nikoliv o zařízení. Viděl jsem nedávno nějaký rozbor, kde se někdo pozastavoval nad tím, proč tolik stanic nedodává údaje o zařízení. Takže ono to nebude tím, že by stanice ten údaj v deníku nevyplnily, nýbrž tím, že vyhodnocovatel ho z neznámých důvodů nepoužil.

CQSOs, CQSOP

Poslední sada položek v hlavičce je souhrnem vámi deklarovaných výsledků v závodě. Je otázka, jak je vlastně vyhodnocovatel použije, protože vyhodnocovací programy mají v dnešní době tendenci si váš log celý přepočítat. Tj. tyto údaje mohou být úplně zahozeny, nebo se ve výsledkovce objeví jako deklarované a vyhodnocovatel z nich sestaví předběžné pořadí platné jen do doby, než provede finální vyhodnocení závodu, anebo mohou být i bez nějaké další kontroly použity přímo pro sestavení finální výsledkové listiny. Měly by být tedy vyplněny kompletně a správně. Obecně platí, že vyplněné má být vše, co se v daném závodě používá. Definice formátu souboru EDI neříká, jak se mají body ze závodu konkrétně vypočítat, dává nám k dispozici pouze určitá pole, kam můžeme vyplnit dílčí hodnoty výpočtu, tak aby se dalo podívat, jak jsme k celkovému výsledku došli. Ale jak se mají body vypočítat určí až podmínky konkrétního závodu.

První položka deklarovaných výsledků je CQSOs. Zadávají se do ní dvě hodnoty oddělené středníkem. První udává počet platných spojení, tj. jen těch, která nemáte v logu označena jako neplatná, a druhá hodnota je násobič pásma. Pokud je pro dané pásmo stanoveno, že se body za spojení na tomto pásmu násobí nějakou hodnotou, tak právě sem uvedete výši tohoto násobiče, který uplatňujete, a současně se násobič aplikuje na body u jednotlivých spojení, tj. v položce s body u každého spojení uvedete body získané za toto spojení vynásobené už tímto násobičem. Pokud se žádny násobič pásma neaplikuje, tak se jako druhá hodnota uvede číslo 1. Položka CQSOP pak udává součet všech bodů deklarovaných v záznamech jednotlivých platných spojení.

CWWLs, CWWLB

Následují tři dvojice položek používané pro násobiče. První dvojice je CWWLs a CWWLB. Položka CWWLs má tři hodnoty. První z nich udává počet nových lokátorů (obvykle se tím myslí tzv. velké lokátory, tj. první 4 znaky lokátoru), do kterých jste navázali spojení, přitom v záznamech spojení označíte každý takovýto nový lokátor v položce New-WWL-(N) znakem N. Pokud je za navázání spojení do každého nového lokátoru stanoven nějaký bodový bonus, tak do druhé hodnoty napíšete výši tohoto bonusu, jinak necháte ve druhé hodnotě číslo 0. Třetí hodnota je násobič, který uplatňujete v souvislosti s počtem nových lokátorů, násobí se jím součet bodů za všechna platná spojení. Pokud se násobič neuplatňuje, tak se jako třetí hodnota uvede číslo 1. Pokud jste uplatňovali nenulový bodový bonus za každý nový lokátor, tak do položky CWWLB pak uvedete celkový součet těchto získaných bonusových bodů, jinak bude v této položce číslo 0. Přesný postup jak aplikovat násobiče a bonusové body je potřeba nastudovat v podmínkách konkrétního závodu. Např. v Provozním aktivu VKV se kromě velkých lokátorů, do kterých jste navázali spojení, jako násobič počítá i váš vlastní velký lokátor ze kterého vysíláte, ikdyž jste do tohoto velkého lokátoru žádné spojení nenavázali. Pak samozřejmě není jak toto označit příznakem v záznamech spojení a je otázka, jak by to pak mělo být správně vykázané v položce CWWLs, když takováto situace nastane, zda by první hodnota měla udávat jen počet WWL kam jste navázali spojení a druhá pak skutečný násobič navýšený o 1 díky započtení vlastního lokátoru, nebo zda mají být obě hodnoty stejné. Atalanta Locator např. u PA VKV vlastně nastavuje jen první hodnotu a třetí nechává vždy 1.

CExcs, CExcB, CDXCs, CDXCB

Následující dvě dvojice položek mají naprosto stejný princip vyplňování jako předchozí dvojice týkající se nových lokátorů. Dvojice položek CExcs a CExcB řeší násobiče a bonusové body za nové kódy výměny a současně se na označování nových kódů výměny v záznamech spojení používá opět znak N ve sloupci New-Exchange-(N), a položky CDXCs a CDXCB řeší totéž podle volacích značek pro nové země DXCC a příznaky nových zemí se v záznamech spojení zapisují znakem N do sloupce New-DXCC-(N).

Obecně by mělo platit, že pokud se v daném závodě výše uvedený systém násobičů nevyužívá, tak dotyčné dvojice položek by nemusely být vyplněny a mohly by zůstat i prázdné, tj. zůstaly by tam u vícenásobých hodnot akorát oddělovací středníky. Ale to už bude záležet na konkrétním vyhodnocovacím programu, jak k tomu přistupuje.

CToSc

Položka CToSc pak udává celkový součet všech bodů, které v daném závodě deklarujete v tomto deníku jako váš výsledek. Pokud se neuplatňují násobiče a bonusové body, tak tato hodnota bude stejná jako součet bodů za všechna spojení uložený v položce CQSOP, jinak to bude typicky součet bodů za všechna spojení v položce CQSOP vynásobený patřičným násobičem a případně povýšený o součet všech získaných bonusových bodů. Např. ve vyhodnocení ČRK se jako váš deklarovaný výsledek zobrazuje hodnota z položky CQSOP a hodnota uvedená v CToSc tedy není vůbec použita.

CODXC

Poslední položka hlavičky je CODXC. Obsahuje informaci o vašem nejdelším spojení v závodě v tomto deníku. Položka má tři hodnoty oddělené středníkem. První je značka stanice, se kterou jste navázali nejdelší spojení, druhá hodnota je lokátor této stanice a třetí udává vzdálenost mezi vámi a touto stanicí a uvádí se jako celé číslo v kilometrech bez jednotky km. Různé logovací programy k vyplnění této třetí položky přistupují různě. Některé zde uvádí přímo bodovou hodnotu dotyčného spojení, a to i v případě, že se body zrovna nepočítají podle vzdálenosti, ale podle pásem velkých lokátorů (takto to dělá např. Atalanta Locator), jiné zde uvádějí bodovou hodnotu daného spojení získanou ze vzdálenosti, tj. včetně používaného způsobu zaokrouhlování z kilometrů na body a tím pádem i s aplikací 1-bodové hodnoty používané paušálně na spojení ve vlastním lokátoru, a jiné zde uvedou obecně vzdálenost nějak zaokrouhlenou na celé kilometry (a jak to pak počítají pro spojení ve vlastním lokátoru nevím). První způsob asi není zcela v duchu definice EDI a druhé dva způsoby jsou vpodstatě rovnocené a liší se vzásadě jen ve způsobu zaokrouhlení, tj. obvykle jde o odchylku ±1 km.

Záznam spojení

Po hlavičce a případném komentáři jsou v souboru EDI uloženy jednotlivé záznamy spojení. Každý záznam je uložen na svém samostatném jednom řádku a celkem obsahuje 15 sloupců s hodnotami oddělenými od sebe znakem středník. Pokud některá hodnota nemusí být vyplněna, protože se v závodě nepoužívá, tak může zůstat prázdná, ale oddělovací znak středník musí být i poté u této hodnoty použit.

Definice EDI přímo neurčuje v jakém pořadí mají být záznamy spojení uvedeny zasebou. V zásadě by ale záznamy měly následovat zasebou chronologicky v pořadí tak, jak jste spojení v čase zasebou skutečně navazovali, a pokud se v daném závodě používá číslování spojení a nedělali jste v číslování chyby, tak spojení tak budou současně i seřazena vzestupně podle vyslaných čísel spojení. Pokud spojení nebudou v souboru EDI správně seřazená, tak záleží na tom, jak k tomu přistoupí který vyhodnocovatel, může vám také chybně zařazená spojení neuznat. Záznam jednoho spojení vypadá následovně:

Struktura záznamu jednoho spojení

DT;TM;CALL;MODE;TXRST;TXNR;RST;NR;EXCH;WWL;PTS;NEXCH;NWWL;NDXCC;DUPL

Význam jednotlivých sloupců a jejich délky

Sloupec	Popis dle EDI	Max. délka	Poznámky
DT	Date	6 znaků	RRMMDD (UTC)
TM	Time	4 znaky	HHMM (UTC)
CALL	Call	14 znaků	3 až 14 znaků
MODE	Mode code	1 znak	0 nebo 1 znak
TXRST	Sent-RST	3 znaky	0, 2 nebo 3 znaky
TXNR	Sent QSO number	4 znaky	0, 3 nebo 4 znaky
RST	Received-RST	3 znaky	0, 2 nebo 3 znaky
NR	Received QSO number	4 znaky	0, 3 nebo 4 znaky
EXCH	Received exchange	6 znaků	0 nebo 1 až 6 znaků
WWL	Received-WWL	6 znaků	0 nebo 4 nebo 6 znaků
PTS	QSO-Points	6 znaků	1 až 6 znaků
NEXCH	New-Exchange-(N)	1 znak	0 nebo 1 znak N
NWWL	New-WWL-(N)	1 znak	0 nebo 1 znak N
NDXCC	New-DXCC-(N)	1 znak	0 nebo 1 znak N
DUPL	Duplicate-QSO-(D)	1 znak	0 nebo 1 znak D

Date, Time

Sloupce Date a Time uvádí datum a čas spojení. Není řečeno, zda je to čas začátku nebo konce spojení, ale počítejte s tím, že typická tolerance při křížové kontrole deníků bývá 10 minut, tj. pokud bude rozdíl mezi časem spojení ve vašem deníku a v deníku protistanice větší, tak vám spojení nebude uznáno. Čas (a tedy i datum) se udává vždy podle času UTC, tj. za normálního času o hodinu a v době letního času o dvě hodiny méně, než je náš středoevropský. Pozor na to při nastavování počítače a logovacího programu - když omylem posunete všechna spojení o hodinu nebo dvě jinak, vyhodnocovatel na to při křížové kontrole deníků přijde a váš deník z vyhodnocení nakonec úplně vyřadí.

Datum se zadává v šestimístném formátu RRMMDD, tj. z roku jen poslední dvě místa (to je rozdíl oproti položce TDate v hlavičce, kde je rok uveden čtyřmístně). Čas se uvádí vždy ve čtyřmístném tvaru HHMM, hodiny se počítají vždy od 00 do 23 a minuty od 00 do 59. Formát těchto dvou údajů si vyhodnocovací programy snadno zkontrolují a pokud tam budete mít nesmysl, tak vám spojení neuznají. Obě položky musí být vždy vyplněny, a to i u neplatných spojení. Vyhodnocovací programy hlídají nejen datum, ale i čas začátku a konce závodu, a tak vám spojení, která nebudou spadat do časového intervalu daného závodu, také neuznají. Pozor na koncový čas - závody se sice vyhlašují např. od 14:00 do 14:00, ale obvykle se tím myslí jakákoliv hodnota stejná nebo větší než počáteční a současně menší než, ale nikoliv už rovná koncové. Takže zatímco čas posledního spojení druhý den závodu ve 14:00 vám třeba ČRK uzná, ale IARU nikoliv.

Velmi nepříjemné a snadno přehlédnutelné chyby vznikají, když přepisujete log až po závodě nebo po závodě v deníku opravujete data na některém řádku. Záleží na tom, jaký máte logovací program, ale někdy vám tam může po vložení údajů logovací program zadat aktuální čas nebo datum až z doby opravy - pokud děláte takovouto opravu, tak si zkontrolujte v EDI souboru před jeho odesláním, že se vám u dotyčného spojení nezměnily čas a datum.

Call

Do sloupce Call se zapisuje značka protistanice. Položka musí být vyplněna a u chybných záznamů se zde místo značky vloží text ERROR. Hodnota musí souhlasit s tím, co uvede protistanice ve svém logu, nicméně vyhodnocovací program může např. ignorovat některé chyby, jako je třeba nesoulad v /P na konci značky, záleží na podmínkách konkrétního závodu.

Mode code

Další sloupec Mode code obsahuje údaj o druhu provozu použitém při spojení. Pokud podmínky závodu nepovažují zaznamenání druhu provozu za podstatné, tak lze sloupec nechat prázdný, jinak se zde druh provozu zakóduje jedním znakem jako číslice 0 až 9 podle následující tabulky:

Význam kódů Mode code

Mode code	Provoz TX	Provoz RX
0	jiný	jiný
1	SSB	SSB
2	CW	CW
3	SSB	CW
4	CW	SSB
5	AM	AM
6	FM	FM
7	RTTY,MGM	RTTY,MGM
8	SSTV	SSTV
9	ATV	ATV

Jak je vidět, tak ne vše, co se používá, v této tabulce najdete. V Moon Contestu jsou povolena např. i spojení DSTAR a C4FM, ale není je jak odlišit od módu MGM. Já na to sám používám kód 0, ale také to není úplně bezproblémové, protože 0 může být považována vyhodnocovacími programy někdy také za nepřípustnou hodnotu, a navíc to řeší jen případ, kdy používáte v závodě jen DSTAR nebo jen C4FM, nikoliv oba módy současně. V Moon Contestu pak některé stanice (nevím proč) používají pro FM provoz v EDI souboru kód 3 místo správného čísla 6.

Správné nastavení druhu provozu je důležité zejména v závodech, kde buď můžete navazovat opakovaná spojení více druhy provozu, nebo spojení různými druhy provozu mají různou bodovou hodnotu. Ve velkých závodech jako jsou subregionály naopak bývá po stránce bodů jedno, jestli jste spojení navázali SSB, CW nebo FM, a pak vyhodnocovací program může být dost benevolentní k tomu, co jste zadali jako druh provozu vy, a co protistanice, jestli je v Mode code 1, 2, 3 nebo 4 bývá pak jedno a druhu provozu nemusí ani odpovídat použité formáty RST a RS.

Sent-RST

Do sloupce Sent-RST se zapisuje vyslaný report. Pokud není použit, tak může být hodnota prázdná, jinak má buď 2 nebo 3 znaky v obvyklém číselném tvaru RS nebo RST včetně případných písmen A, S a M využívaných při některých specifických způsobech šíření signálu. Vyhodnocovací programy IARU i ČRK zde kontrolují souhlas u prvních dvou znaků R a S, poslední znak se ignoruje, tj. 59 a 599 nebo třeba 590 vám uznají jako shodné, ale nikoliv už rozdíl v síle signálu, tj. třeba 59 a 55. Z toho plyne to, co jsem napsal už výše u Mode code - nějaká vazba mezi třeba cross-mode spojeními CW/SSB a SSB/CW a přijatým a vyslaným formátem RS a RST nebývá ve velkých závodech vyhodnocována, řeší se jen nesoulad mezi vyslaným a přijatým R a S. Ale netvrdím, že se stejně chovají vyhodnocovací programy i v jiných závodech, a že tomu tak bude i ve velkých závodech do budoucna, záleží na aktuálně platných podmínkách dotyčného závodu.

Sent QSO number

Do sloupce Sent QSO number se zapisuje vyslané číslo spojení. Pokud se číslování spojení nepoužívá, tak sloupec může zůstat prázdný. Pokud se číslování použije, tak se používá třímístné číslo z rozsahu 001 až 999 nebo čtyřmístné 0001 až 9999 a to vždy včetně úvodních nul. EDI neříká nic o tom, jak mají jít čísla po sobě, protože to už záleží na podmínkách konkrétního závodu. Obecně bývá požadováno, aby číslování začínalo od 001 a šlo vzestupnou řadou s krokem 1 tak, jak navazujete spojení zasebou. Nicméně i u nás se můžete potkat s tím, že se přes sebe překrývají dva závody s různým časem začátku a pak to může vzít pořadatel toho později začínajícího v potaz a povolí začínat od vyššího čísla, když jedete i dříve začínající závod od jeho začátku, a chcete poslat deník i do druhého závodu. Nebo může být společné číslování pro více pásem, apod.

Nelze také vyloučit, že se přehlédnete, a uděláte spojení pod opakovým číslem nebo v číslování omylem nějaké číslo přeskočíte. Záleží na vyhodonocovacím programu, ale neúmyslné ojedinělé chyby většinou nedělají problémy, pokud kódy u dotyčného spojení předané mezi vámi a protistanicí souhlasí. Jiná kapitola ale je, když dáváte jiná čísla spojení, než jaká pak uvedete v deníku, tam vám kromě odečtu dotyčných spojení může hrozit při velkém počtu chyb i vyřazení celého deníku z vyhodnocení.

Received-RST

Sloupec Received-RST slouží pro uložení přijatého reportu. Platí pro něj totéž, co už bylo řečeno u sloupce Sent-RST, tj. hodnota může zůstat prázdná, pokud se nepoužívá, a jinak sem patří buď dvouznakový tvar RS nebo tříznakový RST.

Received QSO number

Do sloupce Received QSO number se zapisuje přijaté číslo spojení. Pokud se číslování nepoužívá, tak může zůstat hodnota prázdná, jinak se zadává buď třímístné nebo čtyřmístné číslo včetně úvodních nul.

Received exchange

Do sloupce Received exchange se uloží přijatý kód výměny. Pokud se nepoužívá, může zůstat hodnota prázdná, jinak má kód výměny 1 až 6 znaků.

Received-WWL

Sloupec Received-WWL slouží pro uložení přijatého lokátoru. Ten má buď 6 nebo 4 znaky. Pokud se lokátor nepoužívá, tak hodnota může zůstat prázdná. Čtyřznakové lokátory jsou v závodech IARU povoleny jen v některých případech - v MGM závodech a dále pak ještě v CW/SSB/FM/PM závodech na 50MHz při přijetí lokátoru od stanic ležících mimo Region 1 (pak se doplňují na 5. a 6. místě o znaky MM). Jinak se používají šestiznakové lokátory.

QSO-Points

Body uplatňované za dotyčné spojení se zapisují do sloupce QSO-Points a je do nich započítán i pásmový násobič. Hodnota musí být vždy zadaná a pokud se jedná o chybný záznam nebo neplatné spojení, tak se zde uvede hodnota 0.

Zde vzniká právě jeden z velkých rozdílů mezi vámi deklarovanými body a tím, co spočte ČRK a co IARU. Pokud např. u duplicitního spojení nebo neplatného spojení nebo chybného záznamu zde uvedete správně hodnotu 0, tak ČRK nebo i IARU vám zde mohou v první fázi započítat nenulovou hodnotu a to dokonce i v případě, že není vyplněn lokátor a není ji tedy vlastně z čeho vypočítat. Více o tom uvedu níže v části zabývající se porovnáním výsledků výpočtů.

New-Exchange-(N), New-WWL-(N), New-DXCC-(N)

Sloupce New-Exchange-(N), New-WWL-(N) a New-DXCC-(N) slouží pro označení dotyčného záznamu spojení, že je v něm navázáno spojení s novým kódem výměny, novým lokátorem nebo novou zemí DXCC. Na označení se zde v takovém případě uvede v příslušném sloupci znak N, jinak se dotyčný sloupec nechá prázdný.

Duplicate-QSO-(D)

Sloupec Duplicate-QSO-(D) slouží pro označení duplicitního spojení. Pokud daný záznam představuje duplicitní spojení, tak se zde uvede znak D, jinak se sloupec nechá prázdný. Samotný popis formátu EDI nedefinuje, kdy je spojení duplicitní, to už záleží na podmínkách konkrétního závodu.

Chybná spojení a chybné záznamy

Jsou popsány tří způsoby označení neplatných spojení nebo chybných záznamů. První se týká duplicitních spojení. Ta se označí výše popsaným způsobem příznakem D v k tomu určeném sloupci a bodová hodnota se u nich nastaví na 0.

Pokud se vám nepodařilo přijmout od protistanice celý předávaný kód, tj. jedná se o nekompletní spojení, tak se do záznamu zapíši nekompletní údaje tak, jak se vám je podařilo přijmout, a bodová hodnota spojení se nastaví na 0.

Třetí možnost se týká případu, kdy potřebujete celý záznam s nějakým číslem spojení označit jako chybný, tj. bude to případ, kdy jsme z nějakého důvodu nějaké číslo spojení přeskočili. Aby se udržela kontinuita ve vyslaných číslech spojení, tak se u takovéhoto záznamu vyplní pouze sloupce pro datum, čas a vyslané číslo spojení, do sloupce pro značku stanice se uvede text ERROR a bodovou hodnotu spojení nastavíme u tohoto záznamu na 0.

Tj. teoreticky by to mělo fungovat tak, že když vyhodnocovací program uvidí ve sloupci s body hodnotu 0, tak tento záznam přeskočí a nebude se jím už dále zabývat, protože vy zde deklarujete, že spojení v tomto záznamu není platné a má nulovou hodnotu. Bohužel tomu tak není. Více k tomu uvedu v části zabývající se porovnáním výsledků výpočtů.

Závěrem k souborům EDI

Soubory ve formátu EDI jsou celkem jednoduché a dají se v nouzi při menším počtu spojení bez problémů sestavit i ručně běžným textovým editorem, ale je potřeba dodržet jejich strukturu a vyplnit správně všechny požadované údaje. Pro správné vyplnění je pak potřeba znát požadavky pořadatele konkrétního závodu, které najdete obvykle shrnuté v podmínkách závodu.

Body deklarované v EDI souboru si v dnešní době často buď už přímo robot sbírající deníky nebo následně vyhodnocovací program přepočítají. Odlišný přístup vyhodnocovacích programů k datům v EDI souboru, např. u označených neplatných spojení, může vést k tomu, že vámi deklarovaný výsledek se bude od vyhodnocovacím programem vypočteného výsledku významněji lišit.

Přesnost předávání polohy pomocí lokátorů

Body za spojení ve VKV závodech stanovené podle vzdáleností stanic se nepočítají z přesných poloh vysílacích stanovišť, ale z poloh středů lokátorů, které si stanice předávají jako svá stanoviště v rámci soutěžního kódu. Takže ikdyž budeme vzdálenost mezi středy lokátorů počítat sebepřesněji, tak rozdíl mezi skutečnou vzdáleností stanic a vypočtenou vzdáleností se stále může lišit (zjednodušeně) až o ± rozměr lokátoru, pomocí kterého jsme polohy stanic určili.

Lokátor je část povrchu Země vymezená ze dvou stran poledníky, tj. body se shodnými zeměpisnými délkami λ a λ+dλ, a ze dvou stran rovnoběžkami, tj. body se shodnými zeměpisnými šířkami φ a φ+dφ. Při vhodném promítnutí povrchu Země do roviny se lokátor může jevit jako čtverec nebo obdélník, ale ve skutečnosti, pokud si tvar Země zjednodušíme na kouli, je to sférický čtyřúhelník, takže zatímco ve směru poledníků je délka jeho stran měřená po povrchu koule stejná, tak ve směru rovnoběžek je jeho strana bližší k rovníku delší a strana bližší k pólu kratší. Pokud povrch koule pokryjeme rovnoměrnou sítí takovýchto lokátorů, tak všechny tyto lokátory budou mít stejnou délku stran ve směru poledníků, ale ve směru rovnoběžky se budou délky jejich stran se zeměpisnou šířkou měnit, od rovníku, kde bude tato délka největší, až po póly, kde bude nulová, protože poledníky zde splynou do jednoho bodu.

 

Pokud se bavíme o rozměru lokátoru, tak zatímco vzdálenost mezi jeho dvěma rohy měřená po poledníku je shodná s nejkratší vzdáleností těchto rohů, tak vzdálenost rohů měřená po rovnoběžce se s výjimkou rovníku od nejkratší vzdálenosti těchto rohů liší. A vzdálenosti za účelem výpočtu bodů měříme jako nejkratší vzdálenosti. Nebude-li řečeno jinak, tak v následujícím textu budu uvádět u lokátorů jejich rozměry jen přibližně pomocí tří rozměrů - všechno to budou nejkratší vzdálenosti mezi dvěma body, kde délka bude měřena mezi středy západní a východní strany lokátoru, šířka mezi středy jižní a severní strany lokátoru a diagonála bude měřena mezi jeho protilehlými rohy.

Systém QRA čtverců

Původní systém lokátorů, který se používal od konce 50. let do poloviny 80. let 20. století v oblasti našeho Regionu 1, je systém známý jako QRA-čtverec, QRA-lokátor, QRA-Kenner nebo později jako QTH-lokátor. Aby mohly stanice ve VKV závodech spočítat překonané vzdálenosti, tak bylo potřeba si předávat informace o svých stanovištích. Pomáhalo k tomu vydávání map se zákresy přihlášených stanic a předávání informací o QTH během závodu až na úrovni informace např. o směru a vzdálenosti od blízkého města u stanic jedoucích z přechodných stanovišť, nicméně i tak posléze nastával často problém se správnou identifikací QTH na mapě při zjišťování vzdálenosti. Postupně se ukázalo, že užitečným způsobem je na mapu zakreslit čtvercovou síť s tím, že stanice upřesňují svoji polohu právě kódem přiděleným dotyčnému čtverečku, ve kterém se nacházejí.

Použitý systém, který byl nakonec přijat na schůzce pracovní skupiny VKV v Haagu v roce 1959, vycházel ze systému navrženého v DL, který představoval síť čtverců s dvojúrovňovým členěním pomocí 4 znaků, která měla začátek na greenwichském poledníku a na 40. stupni severní šířky. Systém byl představen v roce 1958, ale nesetkal se v první fázi s velkou odezvou. Až když radioamatéři v OK vydali jako pomůcku mapu ČSR se zakreslenou sítí, díky které bylo možné systém v reálu vyzkoušet, a v roce 1958 ho v rámci VHF contestu i úspěšně otestovali, tak se pohled na tento systém změnil a v roce 1959 se začal úspěšně šířit po Evropě. Rozhodnutím VKV konference v Turíně v roce 1961 se pak tento kódový systém stal i přímo součástí v závodech předávaného kódu (předtím se předávalo RS(T) a číslo). V roce 1963 byla do systému přidána třetí úroveň dělení představovaná 5. znakem. V materiálech z té doby najdete, že jako 5. znak se používala písmena a až h, tj. označovala se jen poloha mimo střed lokátoru, kdežto střední políčko z těchto devíti se udávalo bez 5. znaku. Ve finální podobě byl pak tento systém používán s tím, že střední políčko se též označovalo, a to nikoliv znakem i, který následuje v řadě po znaku h, ale znakem j.

Popis systému

Systém čtverců začíná svým jihozápadním rohem na souřadnicích 40°N a 0°E a končí svým severovýchodním rohem na souřadnicích 66°N a 52°E. Z povrchu Země tedy popisuje plochu pouze v rozsahu 26° ve směru zeměpisné šířky a 52° ve směru zeměpisné délky. Kód čtverce je sestaven z 5 znaků:

X₁ X₂ X₃ X₄ X₅

První dva znaky X₁ a X₂ představují 1. úroveň členění a rozdělují celou plochu systému na síť 26x26 čtverců. Oba znaky se zapisují velkými písmeny z rozsahu A až Z. Znak X₁ udává polohu čtverce ve směru zeměpisné délky vzestupně ve směru od západu k východu a znak X₂ udává polohu čtverce ve směru zeměpisné šířky vzestupně ve směru od jihu k severu.

Šířka čtverce v 1. úrovni členění je 1° (111.2km), délka je 2° (144.4km) a diagonála má 182.3km (rozměry v km uvedeny pro lokátor IJ).

1. a 2. znak (AA až ZZ)

AZ	BZ	..	YZ	ZZ
AY	BY	..	YY	ZY
..	..	..	..	..
AB	BB	..	YB	ZB
AA	BA	..	YA	ZA

Druhé dva znaky X₃ a X₄ představují 2. úroveň členění a rozdělují čtverce 1. úrovně na daší síť 10x8 čtverců. Oba znaky se zapisují číslicemi a dohromady představují číslo z rozsahu 01 až 80. Číslem 01 je označen čtverec v severozápadním rohu, pak se pokračuje číslováním směrem na východ až po číslo 10, a následně se pokračuje v číslování dalším jižnějším pásem čtverců opět ve směru od západu k východu, a tak dále, až číslo 80 má čtverec v jihovýchodním rohu.

Šířka čtverce ve 2. úrovni členění je 1/8°, tj. 7.5' (13.9km), délka je 2/10°, tj. 12' (14.5km) a diagonála má 20.1km (rozměry v km uvedeny pro lokátor IJ63).

3. a 4. znak (01 až 80)

01	02	..	09	10
11	12	..	19	20
..	..	..	..	..
61	62	..	69	70
71	72	..	79	80

Pátý znak X₅ představuje 3. úroveň členění a rozděluje čtverce 2. úrovně na další síť 3x3 čtverců. Zapisuje se malými písmeny z rozsahu a až h anebo znakem j, znak i se vynechává. Označování čtverců začíná písmenem a pro prostřední čtverec na severní straně a pak se pokračuje podél východní, jižní a západní strany až do severozápadního rohu, kde je čtverec označený h. Prostřednímu čtverci pak náleží písmeno j.

Šířka čtverce ve 3. úrovni členění je 1/(8x3)°, tj. 2.5' (4.6km), délka je 2/(10x3)°, tj. 4' (4.8km) a diagonála má 6.7km (rozměry v km uvedeny pro lokátor IJ63b).

5. znak (a až h, j)

h	a	b
g	j	c
f	e	d

Systém QRA čtverců tedy rozděluje část povrchu Země na síť 780x624 čtverců, které mají v našich zeměpisných šířkách rozměry přibližně 5x5km.

Systém Locator

Systém QRA lokátorů, který byl nakonec přejmenován na QTH-lokátor, měl některé nevýhody. Jeho síť především pokrývala jen část povrchu Země v oblasti Evropy, takže pokud jej chtěli využít radioamatéři i v jiných regionech, tak se stejný systém na Zemi musel několikrát opakovat, takže např. pro spojení na delší vzdálenosti byl hůře využitelný. Dále byl nepříliš konzistentní (především v kódování 3., 4. a 5. znaku) pro počítačové zpracování. V roce 1976 tak byla v rámci Regionu 1 iniciována diskuse o podobě systému, který by stávající systém mohl nahradit. V roce 1978 pak bylo dohodnuto, že aby měl podobný systém naději na celosvětové přijetí, tak bude projednáván i s ostatními regiony, díky čemuž se pak objevilo větší množství návrhů na řešení. Na schůzce VHF pracovní komise v Maidenheadu v roce 1980 byl pak vybrán systém navržený G4ANB, nazývaný dále Maidenhead Locator, resp. jen Locator. Region 2 tento systém přijal v roce 1982, region 3 v roce 1983 a náš region 1 v roce 1984 s termínem zavedení do 1.1.1986. U nás v ČSSR byl do soutěží systém zaveden od 1.1.1985.

Systém lokátorů je oproti dříve používanému systému QRA čtverců výrazně konzistentnější v kódování sítě lokátorů do znaků a popisuje celý povrch Země (formálně se do něj nevejde vlastně pouze nekonečně malý bod severního pólu, nicméně ve VHF Handbooku je to nyní už "ošetřeno" a je v něm uvedeno jaký kód se má na pólu použít). Systém lokátorů začíná svým jihozápadním rohem na souřadnicích 90°S a 180°W a končí svým severovýchodním rohem na souřadnicích 90°N a 180°E.

Při převodu souřadnic geodetického systému na kód lokátoru je nutné si uvědomit jak má tento daný geodetický systém vůči našemu systému lokátorů na zemském povrchu ve skutečnosti nastavený výchozí bod. Geodetických systémů je více a bod, ke kterému se vztahují, se může lišit, takže bod udaný stejnými zeměpisnými souřadnicemi ve dvou různých systémech nemusí ve skutečnosti ukazovat na stejném místo na povrchu Země. Ve VHF Handbooku je jako příklad uváděn rozdíl kolem 300m mezi evropským systémem ED50 a světovým WGS84. Na konferenci v Lillehammeru v roce 1999 bylo dohodnuto, že pro systém Locator se budou používat souřadnice dle geodetického systému WGS84.

Kód lokátoru se skládá z 6 znaků:

X₁ X₂ X₃ X₄ X₅ X₆

První dva znaky X₁ a X₂ představují 1. úroveň členění a rozdělují celou plochu systému na síť 18x18 lokátorů. Oba znaky se zapisují velkými písmeny z rozsahu A až R. Znak X₁ udává polohu lokátoru ve směru zeměpisné délky vzestupně ve směru od západu k východu a znak X₂ udává polohu lokátoru ve směru zeměpisné šířky vzestupně ve směru od jihu k severu.

Šířka lokátoru v 1. úrovni členění je 10° (1112km), délka je 20° (1568km) a diagonála má 1916km (rozměry v km uvedeny pro lokátor JN).

1. a 2. znak (AA až RR)

AR	BR	..	QR	RR
AQ	BQ	..	QQ	RQ
..	..	..	..	..
AB	BB	..	QB	RB
AA	BA	..	QA	RA

Druhé dva znaky X₃ a X₄ představují 2. úroveň členění a rozdělují lokátory 1. úrovně na daší síť 10x10 lokátorů. Oba znaky se zapisují číslicemi z rozsahu 0 až 9. Znak X₃ udává polohu lokátoru ve směru zeměpisné délky vzestupně ve směru od západu k východu a znak X₄ udává polohu lokátoru ve směru zeměpisné šířky vzestupně ve směru od jihu k severu.

Šířka lokátoru v 2. úrovni členění je 10/10°, tj. 1° (111.2km), délka je 20/10°, tj. 2° (144.4km) a diagonála má 182.3km (rozměry v km uvedeny pro lokátor JN89). Tj. lokátory jsou v 2. úrovni členění stejně veliké a stejně položené jako QRA čtverce v 1. úrovni členění a lze je v rozsahu povrchu Země, který je systémem QRA čtverců pokrytý, mezi sebou převádět 1:1. Takto velkým lokátorům se říká "velké lokátory" nebo "velké čtverce" a používají se např. v některých závodech, kde se body určují zjednodušeně podle jejich pásem a nikoliv podle vzdálenosti, a případně se dle nich počítají i násobiče (viz položky pro označení a počítání WWL v souboru EDI). V některých závodech pořádaných IARU R1 na 50MHz pak stanice mimo region R1 mohou předávat jen tyto 4-znakové lokátory.

3. a 4. znak (00 až 99)

09	19	..	89	99
08	18	..	88	98
..	..	..	..	..
01	11	..	81	91
00	10	..	80	90

Třetí dva znaky X₅ a X₆ představují 3. úroveň členění a rozdělují lokátory 2. úrovně na daší síť 24x24 lokátorů. Oba znaky se zapisují velkými písmeny z rozsahu A až X. Znak X₅ udává polohu lokátoru ve směru zeměpisné délky vzestupně ve směru od západu k východu a znak X₆ udává polohu lokátoru ve směru zeměpisné šířky vzestupně ve směru od jihu k severu.

Šířka lokátoru v 3. úrovni členění je 10/(10x24)°, tj. 2.5' (4.6km), délka je 20/(10x24)°, tj. 5' (6.1km) a diagonála má 7.6km (rozměry v km uvedeny pro lokátor JN89AA). Zde je vidět, že zatímco ve směru zeměpisné šířky jsou rozměr i poloha lokátoru ve 3. úrovni členění shodné s QRA čtverci ve 3. úrovni členění, tak ve směru zeměpisné délky tomu tak není a lokátory jsou v tomto směru větší než QRA čtverce. Je to proto, že zatímco ve směru šířky se velký lokátor i velký QRA čtverec dělí na shodných 24 dílů, tak ve směru délky se velký lokátor dělí na 24 dílů, ale velký QRA čtverec na 30 dílů. Proto nelze mezi lokátory a QRA čtverci převádět 1:1 a převod je ve většině případů nejednoznačný, protože jednomu lokátoru často odpovídají ve směru zeměpisné délky dva různé čtverce a naopak jednomu čtverci odpovídají zase dva různé lokátory. Pro jednoznačný převod je potřeba znát přesnou polohu uvnitř lokátoru nebo čtverce.

5. a 6. znak (AA až XX)

AX	BX	..	WX	XX
AW	BW	..	WW	XW
..	..	..	..	..
AB	BB	..	WB	XB
AA	BA	..	WA	XA

Systém 6-znakových lokátorů rozděluje tedy celý povrch Země na síť 4320x4320 lokátorů, které mají v našich zeměpisných šířkách rozměry přibližně 5x6km. Tyto 6-znakové lokátory jsou standardem pro předávaný kód o poloze v rámci VKV závodů.

Šestiznakový systém lokátorů nemusí mít pro některé stanice vyhovující přesnost, např. při spojeních na vysokých kmitočtech, kde se pracuje na kratší vzdálenosti a je potřeba precizně směrovat antény. Na konferenci v De Haanu v roce 1993 byl tedy přijat tzv. Extended locator systém, v rámci kterého se přidala další úroveň členění. Kód rozšířeného lokátoru se skládá z 8 znaků:

X₁ X₂ X₃ X₄ X₅ X₆ X₇ X₈

Čtvrté dva znaky X₇ a X₈ představují 4. úroveň členění a rozdělují lokátory 3. úrovně na daší síť 10x10 lokátorů. Oba znaky se zapisují číslicemi z rozsahu 0 až 9. Znak X₇ udává polohu lokátoru ve směru zeměpisné délky vzestupně ve směru od západu k východu a znak X₈ udává polohu lokátoru ve směru zeměpisné šířky vzestupně ve směru od jihu k severu.

Šířka lokátoru ve 4. úrovni členění je 10/(10x24x10)°, tj. 0.25' (463m), délka je 20/(10x24x10)°, tj. 0.5' (608m) a diagonála má 764m (rozměry v m uvedeny pro lokátor JN89AA00).

7. a 8. znak (00 až 99)

09	19	..	89	99
08	18	..	88	98
..	..	..	..	..
01	11	..	81	91
00	10	..	80	90

Systém 8-znakových lokátorů rozděluje tedy celý povrch Země na síť 43200x43200 lokátorů, které mají v našich zeměpisných šířkách rozměry přibližně 460x610m.

Pokud vám ani tato přesnost nestačí, ta lze pokračovat s přidáváním dalších úrovní členění na stejném principu, tj. střídat sekvence 2 znaků a 2 číslic. Bohužel už u 10-znakových lokátorů jsou dva odlišné systémy. Jeden pokračuje na stávajícím principu a dělí předchozí úroveň členění opět na 24 dílů, ale druhý používá dílů 25. Základ je ale stejný, kód lokátoru se skládá z 10 znaků:

X₁ X₂ X₃ X₄ X₅ X₆ X₇ X₈ X₉ X₁₀

Páté dva znaky X₉ a X₁₀ tedy představují 5. úroveň členění a rozdělují lokátory 4. úrovně na daší síť buď 24x24 nebo 25x25 lokátorů. Oba znaky se zapisují velkými písmeny z rozsahu A až X v prvním případě a A až Y v případě druhém. Znak X₉ udává polohu lokátoru ve směru zeměpisné délky vzestupně ve směru od západu k východu a znak X₁₀ udává polohu lokátoru ve směru zeměpisné šířky vzestupně ve směru od jihu k severu.

Pro uspořádání 24x24 je šířka lokátoru v 5. úrovni členění 10/(10x24x10x24)°, tj. 0.625' (19.3m), délka je 20/(10x24x10x24)°, tj. 1.25' (25.3m) a diagonála má 31.8m (rozměry v m uvedeny pro lokátor JN89AA00AA). Pro uspořádání 25x25 je šířka lokátoru v 5. úrovni členění 10/(10x24x10x25)°, tj. 0.6' (18.5m), délka je 20/(10x24x10x25)°, tj. 1.2' (24.3m) a diagonála má 30.6m (rozměry v m uvedeny pro lokátor JN89AA00AA).

9. a 10. znak (AA až XX, systém 24x24)

AX	BX	..	WX	XX
AW	BW	..	WW	XW
..	..	..	..	..
AB	BB	..	WB	XB
AA	BA	..	WA	XA

9. a 10. znak (AA až YY, systém 25x25)

AY	BY	..	XY	YY
AX	BX	..	XX	YX
..	..	..	..	..
AB	BB	..	XB	YB
AA	BA	..	XA	YA

Systém 10-znakových lokátorů pro uspořádání 24x24 rozděluje tedy celý povrch Země na síť 1036800x1036800 lokátorů, které mají v našich zeměpisných šířkách rozměry přibližně 19x25m, a pro uspořádání 25x25 na síť 1080000x1080000 lokátorů, které mají v našich zeměpisných šířkách rozměry přibližně 18x24m

Závěrem k lokátorům

U 6-znakových lokátorů, které jsou předávány jako soutěžní kód ve VKV závodech, se v našich zeměpisných šířkách může skutečná vzdálenost stanic lišit od vzdálenosti vypočtené ze středů lokátorů i o více jak ±7 km. Pokud použijeme 10-znakový lokátor, tak rozdíl může dosáhnout asi ±30 m.

Při přesnějším udávání polohy než jsou 6-znakové lokátory už začíná být důležité, zda jsme při převodu zeměpisných souřadnic na lokátor použili pro zjištění souřadnic vhodný geodetický systém. Při měření vzdálenosti na úrovni jednoho metru a méně pak začínají hrát roli i další faktory jako je třeba pohyb kontinentálních desek a samotný systém WGS84 už nemusí mít pro naše účely vyhovující přesnost.

Z pohledu přesnosti určení vzdálenosti stanic je otázka, jak přesně jsme třeba schopni vůbec udat svoji skutečnou polohu při použití větších anténních systémů, kdy typicky na pásmu 144MHz mohou být délky antén i kolem 10m, a v soutěžním QTH, které je v podmínkách závodů typicky omezeno kruhem o průměru 500m, může být rozmístěno více anténních systému, které mohou být během závodu i různě přepínány, a to včetně použití odlišného anténního systému na vysílání a na příjem.

A na úplný závěr k lokátorům ještě ukázka, jak se mění velikost lokátorů se zeměpisnou šířkou:

Změna velikosti lokátoru se zeměpisnou šířkou

Lokátor	QTH	Šířka	Délka
JJ00AA	u rovníku	4.633 km	9.266 km
JN78DO	Vyšší Brod	4.633 km	6.127 km
JN89HF	Brno	4.633 km	6.051 km
JO70FC	Praha	4.633 km	5.943 km
JO70MW	Frýdlant	4.633 km	5.839 km
JQ78CB	Špicberky	4.633 km	1.916 km
RR99XX	u severního pólu	4.633 km	0.003 km

Výpočet vzdálenosti lokátorů

Pokud vezmeme stejný deník ze závodu a spočítáme ho dvěma různými programy, tak ikdyž oba budou při výpočtu vzdáleností vycházet ze stejného výpočetního algoritmu a ani jeden z programů nebude mít v sobě chybu způsobující větší odchylky výsledků, tak přesto se body vypočtené oběma programy mohou u některých spojení od sebe lišit, a to typicky o velikost ±1 bod.

Ve skutečnosti za tímto jednobodovým rozdílem budou schované mnohem menší odchylky ve vypočtených vzdálenostech, které jen byly zvýrazněny v důsledku zaokrouhlování ze vzdáleností na celé body, a jejichž původ může mít spoustu příčin. Může to být použitá odlišná přesnost čísel při výpočtech včetně odlišné přesnosti použitých konstant a přesnosti hodnot vstupujících do výpočtu, ale roli může hrát třeba i pořadí matematických operací a interní zaokrouhlování při ukládání mezivýsledků, realizace matematických funkcí v použité SW knihovně nebo v HW jednotce provádějící výpočty s plovoucí řádovou čárkou, atd. Některé tyto rozdíly tak mohou souviset i s kompilátorem programovacího jazyka, který byl použit na přeložení programu, a s knihovnami, které byly ke kompilátoru dodány nebo jsou součástí OS na počítači, kde program spouštíme.

Čísla v plovoucí řádové čárce

Podívejme se nejprve na reprezentaci čísel v paměti počítače při jejich zpracování. Při výpočtech vzdáleností si nevystačíme s celými čísly, ale budeme muset pracovat s čísly reálnými. Jsou různé možnosti v jaké podobě s reálnými čísly při zpracování výpočetní technikou pracovat a některé oblasti výpočtů jako třeba operace s peněžními částkami v bankovnictví mohou vyžadovat specifické postupy, nicméně běžným a rozšířeným způsobem je použití binárních čísel s pohyblivou řádovou čárkou a to konkrétně dle standardu IEEE754.

Obecně budeme moci ve dvojkové soustavě reálné číslo zapsat v takovémto tvaru s pevnou řádovou čárkou:

X_n-1 X_n-2 ... X₁ X₀ . X_-1 X_-2 ... X_-(m-1) X_-m

tj. např. 1001.011101, kde n bude počet míst nalevo od desetinné tečky, m bude počet míst napravo od desetinné tečky a X_i pro i = n-1 až -m budou hodnoty buď 0 nebo 1. Hodnota takto zapsaného čísla bude:

X_n-1*2^n-1 + X_n-2*2^n-2 + .... + X₁*2¹ + X₀ + X_-1*2^-1 + X_-2*2^-2 + ... + X_-(m-1)*2^-(m-1) + X_-m*2^-m

Pokud bychom chtěli v tomto formátu uložit velmi malé nebo velmi velké číslo, tak budeme muset počet míst n a m značně zvýšit tak, aby byly uloženy všechny potřebné číslice. To může zvyšovat nároky na množství zabraného místa v paměti a prodlužovat dobu výpočtu, takže pak může být výhodnější číslo zapsat v exponenciálním tvaru:

mantisa * 2^exponent

Exponent nám nyní umožňuje posouvat řádovou čárkou vlevo nebo vpravo dle potřeby tak, abychom nemuseli kvůli uložení malého nebo velkého čísla přidávat do mantisy další bity. A takto vyjádřené číslo navíc můžeme před uložením normovat změnou exponentu tak, aby v mantise nalevo od desetinné tečky bylo vždy číslo 1. Mantisa normovaného čísla pak bude mít tvar:

1 . X_-1 X_-2 X_-3 ...

Pro uložení celého čísla v plovoucí řádové čárce tedy budeme potřebovat 1 bit pro znaménko čísla, určité množství bitů pro exponent a určité množství bitů pro mantisu. Navíc protože u mantisy víme, že nalevo od desetinné tečky je vždy jen a pouze jediná číslice 1, tak tuto číslici 1 ukládat nemusíme. Ve skutečnosti je to trochu složitější a musíme nějakým způsobem vyjádřit i hodnotu nula, neplatné hodnoty, záporné a kladné nekonečno, denormalizovaná čísla apod.

O přesnosti s jakou můžeme číslo vyjádřit tedy bude rozhodovat počet bitů, které lze uložit do mantisy. Čím v ní bude k dispozici více bitů, tím budeme moci z čísla zaznamenat více číslic. Ve standardu IEEE754 je definováno několik různých přesností pro uložení čísel s plovoucí řádovou čárkou. Ukažme si některé z nich:

Některé formáty čísel v plovoucí řádové čárce

Přesnost	Velikost	Mantisa	Exponent	Počet míst
poloviční	16b	10+1b	5b	3.31
jednoduchá	32b	23+1b	8b	7.22
dvojitá	64b	52+1b	11b	15.95
rozšířená	80b	64b	15b	19.26
čtyřnásobná	128b	112+1b	15b	34.02

Sloupec velikost udává minimální počet bitů potřebný pro uložení dotyčného formátu čísla. To nemusí odpovídat skutečnému místu zabranému v paměti - např. u rozšířené přesnosti na 32bit systému nebude pro takovouto proměnou alokován prostor 80 bitů, ale ve skutečnosti 96 bitů kvůli zarovnání na celistvé násobky 32bitů. Sloupec mantisa udává počet bitů rezervovaných pro uložení mantisy a sloupec exponent počet bitů rezervovaných pro uložení exponentu. Pokud je u mantisy uveden popis ve tvaru něco+1, tak to vyjadřuje fakt, že při této přesnosti se do mantisy neukládá její nejvyšší číslice 1 ležící nalevo od desetinné tečky, takže skutečné rozlišení mantisy je vlastně o 1 bit větší než počet bitů, které se skutečně ukládají. Sloupec počet míst udává kolikatimístné číslo vyjádřené v desítkové soustavě lze do naší mantisy uložit - počet dekadických míst zde nevychází jako celé číslo, což je důsledek převodu čísel mezi desítkovou a dvojkovou soustavou.

Standardně se pro čísla v plovoucí řádové čárce používá dvojitá přesnost, tj. 64bit (např. v jazyce C se proměnné s touto přesností deklarují pomocí klíčového slova double). U rodiny procesorů majících základ v typu x86 je v dnešní době jejich interní součástí i jednotka FPU pro práci s čísly s plovoucí řádovou čárkou, což je následovník dříve externě osazovaného matematického koprocesoru řady x87. Tato jednotka interně vždy pracuje s rozšířenou přesností 80bitů a pouze při plnění nebo vyčítání hodnot do/z jejích registrů se pak hodnota dle potřeby zaokrouhluje na nižší přesnost. HW podpora čísel s přesností 80bit je dispozici pouze při práci s FPU, při použití vektorových instrukcí ze sad SSE2 nebo AVX512 je k dispozici maximálně dvojitá přesnost 64bit. Použití čtyřnásobné přesnosti nemá přímou podporu ze strany HW a musí se realizovat softwarově.

Pokud převádíme z desítkové do dvojkové soustavy celá čísla, tak toto lze provést zcela přesně. Je zde vlastně jen jeden problém, se kterým se musí počítat - v proměnné pro uložení čísla v plovoucí řádové čárce se číslo musí vejít celé do mantisy, pokud nechceme ztratit jeho přesnost. To znamená, že např. příliš velké celé číslo uložené jako 32bitů se při uložení do čísla s plovoucí řádovou čárkou taktéž 32bitů uloží zkrácené na 24bitů dle mantisy.

U desetinných čísel nastává problém s tím, že z celého oboru reálných čísel můžeme při konečném počtu bitů použitelných pro zaznamenání čísla uložit přesně jen malou množinu těchto čísel, a u zbytku musíme číslo zaokrouhlit na nejbližší možnou uložitelnou hodnotu. Desetinnou část čísla v desítkové soustavě budeme vlastně vyjadřovat ve dvojkové soustavě jako součet různých záporných mocnin čísla 2, tj. budeme různě kombinovat čísla 0.5, 0.25, 0.125, 0.0625 atd. Když se nám z nich podaří desetinnou část čísla složit přesně, tak ho můžeme uložit beze ztráty přesnosti, jinak ho budeme muset zaokrouhlit na nejbližší možnou hodnotu. Důsledek je, že mnohé hodnoty, které jsme v desítkové soustavě schopni zapsat zcela přesně, vedou ve dvojkové soustavě na nekonečný rozvoj. Např. číslo 0.1 v desítkové soustavě půjde ve dvojkové soustavě vyjádřit jen nekonečným rozvojem s periodicky se opakující sekvencí bitů jako 0.000110011001100... resp. 1.10011001100...*2^-4. Když máme na uložení dvojkové reprezentace čísla jen omezený počet bitů v mantise, tak ho budeme muset za posledním bitem mantisy uříznout a pak se rozhodnout, kterým směrem je vhodné toto číslo zaokroulit, zda máme mantisu ponechat tak, jak je, nebo ji máme povýšit přičtením 1 na nejméně významném místě. Výsledkem bude, že uložené číslo ve dvojkové soustavě už nebude přesně odpovídat původní dekadické hodnotě 0.1, ale bude ve skutečnosti vyjadřovat číslo o malou hodnotu menší nebo větší.

Pro přesný výpočet vzdálenosti zde tedy nastává první problém, zda bude možné beze ztráty přesnosti do dvojkové soustavy uložit souřadnice bodů, mezi kterými budeme vzdálenosti počítat. A při výpočtech budeme počítat s obloukovými mírami, kde bude nutné pracovat i s Ludolfovým číslem π, které je samo o sobě transcendentní a nepůjde ho vyčíslit přesně, tj. opět budeme mít už na vstupu (a pak i na výstupu) další malý zdroj možných nepřesností. U čísla π může vnést do výpočtu někdy další nepřesnost i sám programátor. Číslo je někdy součástí programovacího jazyka nebo jeho standardních knihoven jako konstanta nebo funkce, která ho vrací, ale jindy k dispozici není a programátor si ho musí sám nadefinovat. Pak je potřeba u čísla π podle použité přesnosti čísel s plovoucí řádovou čárkou zadat dostatečný počet jeho míst, tak aby byla plně využita přesnost s jakou ho lze uložit.

Převod lokátoru na zeměpisné souřadnice

Převod kódu lokátoru na zeměpisnou délku a šířku ve stupních provedeme např. následujícím postupem (tato ukázka i další budou v jazyce C):

Převod celý realizovaný v plovoucí řádové čárce

char loc[] = "JN89HF";

double zdel = -180.0 +
              20.0 * (loc[0]-'A') +
              2.0 * (loc[2]-'0') +
              (1.0/12.0) * (loc[4]-'A') + 
              1.0/24.0; //deg
                 
double zsir = -90.0 +
              10.0 * (loc[1]-'A') +
              1.0 * (loc[3]-'0') + 
              (1.0/24.0) * (loc[5]-'A') +
              1.0/48.0; //deg

Jednotlivé znaky řetězce obsahujícího kód lokátoru jsou nejprve převedeny na celé číslo odpovídajicí pořadí lokátoru vůči výchozímu lokátoru v dané úrovni členění a pak jsou už jako čísla v plovoucí řádové čárce násobena rozměrem lokátoru v této úrovni členění a výsledky pro jednotlivé úrovně členění jsou sečteny, posunuty o hodnotu -180° a -90° vyjadřující počáteční souřadnice systému lokátorů a nakonec jsou ještě posunuty do středu lokátoru, tj. je k nim přičtena polovina velikosti lokátoru v 3. úrovni členění.

Převod prvních 4 znaků lokátoru je přesný, protože výsledkem jsou celá čísla, která se do čísel ve dvojkové soustavě s plovoucí řádovou čárkou uloží přesně. I jejich velikost z hlediska počtu bitů mantisy je vpořádku a vlezou se nám do ní bez ořezání. U posledních dvou znaků už ale budeme přičítat čísla s desetinnými místy, která se neuloží vždy zcela přesně, a navíc ještě musíme přičítat stejně nepřesně převedenou polovinu velikosti lokátoru. A pokud bychom chtěli pracovat např. s 10-znakovými lokátory, tak zde budeme přičítat ještě další dvě nepřesně převedená čísla.

Při sčítání dvou čísel ve dvojkové soustavě se stejně jako v desítkové soustavě musí čísla nejprve zarovnat pod sebe tak, aby se sčítaly shodné řády. Takže pokud sčítáme dvě řádově odlišná čísla, tak o bity mantisy menšího čísla, které zprava přesahují mantisu většího čísla, přijdeme, není je kam uložit a odříznou se. A to může v našem případě převodu souřadnic nastat, protože sčítáme vlastně postupně se zmenšující díly výsledné souřadnice. Pokud počítáme s čísly ve dvojnásobné přesnosti, tak to nemusí být až zase tak problém, mantisa má 53 bitů, ale kdybychom začali počítat s 10-znakovými lokátory, kterých je v jedné ose přes milion, a vzali si na to čísla s jednoduchou přesností, kde mantisa má jen 24 bitů, což je jen něco přes 16 milionů do ní uložitelných kombinací, tak už můžeme narazit na přesnost celého převodu.

Pokud bychom celý součet realizovali v oboru celých čísel, tak bychom mohli veškeré operace prováděné v plovoucí řádové čárce minimalizovat na jediné závěrečné vynásobení vhodnou konstantou, a vše ostatní by proběhlo bez ztráty přesnosti. Mohlo by to vypadat třeba nějak takto:

Převod realizovaný z převážné části v oboru celých čísel

char loc[] = "JN89HF";

double zdel = (double)
              (
                -4320 +
                480 * (loc[0]-'A') +
                48 * (loc[2]-'0') +
                2 * (loc[4]-'A') +
                1
              ) / 24.0; //deg
                 
double zsir = (double)
              (
                -4320 +
                480 * (loc[1]-'A') + 
                48 * (loc[3]-'0') + 
                2 * (loc[5]-'A') + 
                1
              ) / 48.0; //deg

Nyní opět převádíme jednotlivé znaky na pořadová čísla lokátorů, ale dílčí násobení a sčítání se provádí s celými čísly. Převody jednotlivých znaků se nejprve neprovádí na stupně, ale na násobek stupňů zvolený tak, aby i nejmenší přičítaná hodnota, což je polovina velikosti lokátoru, byla celé číslo. Tj. u šířky je to 48x a u délky 24x větší hodnota než je 1 stupeň. Nakonec se tato celočíselná hodnota převede na číslo v plovoucí řádové čárce a vynásobením konstantou 1.0/24.0 nebo 1.0/48.0 (resp. podělením konstantou 24.0 nebo 48.0) se převede na stupně.

Bude mezi těmito dvěma postupy výpočtu rozdíl? Když jsem spočítal s dvojitou přesností čísel v plovoucí řádové čárce oběma postupy souřadnice severovýchodního rohu systému lokátorů pro 10-znakový lokátor, tj. pro RR99XX99XX a posunul je ještě o 1 lokátor severovýchodním směrem tak, abych získal očekávanou hodnotu souřadnic 180°E 90°N, tak hodnota získaná prvním postupem, kdy se sčítala přímo čísla v plovoucí řádové čárce, byla o hodnotu 1 v nejméně významném bitu mantisy menší než hodnota vypočtená přes sčítání celých čísel. Tj. při použití dvojité přesnosti a 6-znakových lokátorů budou oba postupy poskytovat vpodstatě shodné výstupy. Pokud ale použijete jednoduchou přesnost a 10-znakové lokátory, tak už můžete na rozdíly v přesnosti narazit. U druhého postupu s celými čísly je nutné, aby se celé číslo získané sečtením dílčích hodnot dalo beze ztráty přesnosti uložit do mantisy.

Nad postupem převodu z kódu lokátoru na zeměpisné souřadnice má tedy smysl se zamyslet, a výpočet je vhodné optimalizovat s ohledem na konkrétní daný program - záleží s jakou přesností čísel v plovoucí řádové čárce budete pracovat a zda váš program pracuje výhradně s 6-znakovými lokátory nebo i s jejich jinými variantami.

Model Země

Pro výpočet vzdálenosti dvou bodů na povrchu Země budeme potřebovat nějaký její model. A IARU nám ve VHF Handbooku přímo říká, jaký máme použít - je to ta v něm uváděná "magická" převodní konstanta 111.2km/°. Je tím řečeno, že máme použít kouli o konkrétním poloměru, který pro tuto konstantu vychází 6371.2907km. Pokud bychom měli počítat na elipsoidu, tak by ve VHF Handbooku musely být uvedeny jeho parametry - délky poloos, zploštění apod., pro rotační elipsoid budeme potřebovat znát alespoň 2 hodnoty, nikoliv 1 jako u koule.

Kde se ta podivná hodnota kolem 6371km vzala? Všichni známe poloměr Země jako 6378km. Jenže Země není koule, ale taková ve směru sever - jih trochu sešlápnutá koule, která se dá idealizovat právě rotačním elipsoidem.

 

Tento elipsoid má dle systému WGS84 jednu poloosu, tu mezi středem Země a rovníkem, o délce 6378.137km, což je nám obvykle známý poloměr Země. Protože se jedná o rotační elipsoid, tak i druhá poloosa mezi středem Země a rovníkem, kolmá na tu první, je s ní shodná a má také délku 6378.137km. Třetí poloosa, mezi středem Země a póly, je kratší a má délku 6356.7523km, tj. Země je na pólech trochu zploštělá. Geodetické výpočty na trojosém elipsoidu jsou velmi složité a i na dvojosém to není jednoduché. Ale ukázalo se, že mnohé výpočty lze jednodušeji a přitom stále s dostatečnou přesností provádět, pokud elipsoid Země zaměníme za náhradní těleso v podobě koule s vhodným poloměrem. Při přístupu jak toto náhradní těleso stanovit se používá více úvah - elipsoid se nahradí koulí tak, aby obě tělesa měla stejný objem, nebo stejný povrch, nebo se poloměr koule vypočte jako aritmetický průměr všech tří poloos elipsoidu (v našem případě máme dvě poloosy ze tří shodné):

R = (2 * a + b) / 3

Když do tohoto vzorečku dosadíme délky poloos a a b z modelu WGS84, tak nám vyjde R = 6371.0088km a z toho už můžeme snadno určit naši "magickou" převodní konstantu jako 111.1951km/°, což je po zaokrouhlení právě těch výše uvedených 111.2km/°.

Výpočet vzdálenosti

Výpočet vzdálenosti mezi dvěmi stanicemi, jejichž polohu jsme získali jako středy jimi udávaných lokátorů, budeme tedy počítat na náhradním modelu Země v podobě koule. Nejkratší spojnice dvou bodů na kouli je geodetická křivka na kouli - ortodroma. Výpočet délky této spojnice a azimutů v koncových bodech je tzv. druhá základní nebo též inverzní geodetická úloha. Základem jejího řešení je řešení sférického trojúhelníka.

 

Známe souřadnice λ1 a φ1 bodu P₁, λ2 a φ2 bodu P₂ a poloměr koule R a hedáme délku oblouku mezi body P₁ a P₂. Označme střed Země C a pól N. Pak díky zadaným souřadnicím známe i úhly trojúhelníků P₁CN, P₂CN a P₁NP₂. Z těchto hodnot lze vypočítat úhel δ v trojúhelníků P₁CP₂. A ze znalosti úhlu δ a poloměru R (resp. naší převodní konstanty 111.2km/°) můžeme určit hledanou délku oblouku délku P₁P₂, protože ortodroma je hlavní kružnicí na kouli, takže její poloměr je shodný s poloměrem koule.

Matematické funkce, které budeme na výpočet používat v jazyce C, nepracují se stupni, ale s radiány, tj. nejprve na ně budeme muset zeměpisné vzdálenosti vypočtené ve stupních ze středů lokátorů převést. A současně z nákresu výše už víme, že nám budou stačit jen tři hodnoty - obě zeměpisné šířky a pak už jen rozdíl obou zeměpisných délek. M_PI je v ukázce níže Ludolfovo číslo z hlavičkového souboru math.h standardní matematické knihovny jazyka C.

Převod ze stupňů na radiány

double s1 = zsir1 * M_PI/180.0; //rad
double s2 = zsir2 * M_PI/180.0; //rad

double d21 = (zdel2 - zdel1) * M_PI/180.0; //rad

Vidíme, že zde budeme už tak možná ne zcela přesné údaje zeměpisných souřadnic násobit ne zcela přesný Ludolfovým číslem a pak ještě prozměnu dělit větším číslem. A v případě, kdy se budou obě zeměpisné délky jen nepatrně lišit, tak se dostáváme do situace, kdy odečítáme dvě velmi blízká čísla v plovoucí řádové čárce, a o takovémto výpočtu je známo, že jeho výsledek může být zatížen velkou chybou.

Nyní můžeme vyčíslit vzdálenost a azimut ve výchozím bodě podle vztahu, který získáme z řešení sférického trojúhelníku:

Výpočet vzdálenosti podle 1. algoritmu

double adist = acos(
                 sin(s1) * sin(s2) + cos(s1) * cos(s2) * cos(d21)
               ); //rad
               
double dist = (111.2*180/M_PI) * adist; //km

double azi12 = (180.0/M_PI) * 
               asin(
                 sin(d21) * cos(s2) / sin(adist)
               ); //deg

Vzdálenost i azimut obdržíme z cyklometrických funkcí acos() a asin() samozřejmě opět v radiánech, takže je musíme přepočítat na stupně a vzdálenost pak ještě převést pomocí naší "magické" konstanty 111.2 ze stupňů na finální kilometry. Úhel azi12 je azimut pod jakým vychází spojnice z bodu P₁ do bodu P₂. Pokud bychom chtěli znát i azimut obrácený, tj. z bodu P₂ do bodu P₁, tak je potřeba si uvědomit, že ortodroma narozdíl od loxodromy protíná jednotlivé poledníky pod různým úhlem, tj. azimut v bodě P₂ nelze zjistit prostým otočením v bodě P₁ o 180°, ale musí se explicitně vypočítat pro souřadnice bodu P₂. A dále u azimutu je nutné si uvědomit, že nám funkce asin() vrátí hodnoty jen ve dvou kvadrantech, ale my azimut potřebujem vyčíslit ve všech čtyřech, takže ještě budeme muset dle potřeby na základě porovnání zeměpisných šířek obou bodů provést případný posun azimutu o 180° do správného kvadrantu.

Výše uvedený postup vnáší do přesnosti výpočtu další místa, kde se mohou v rámci různé implementace celého výpočtu nasbírat rozdíly. Používáme zde goniometrické a cyklometrické funkce, které jsou v oboru reálných čísel transcendentní. Na jejich vyčíslení se používá obvykle nějaká forma aproximace pomocí mocninných řad, např. Taylorův rozvoj, nebo pomocí předpočítaných tabulek jako je třeba algoritmus CORDIC. Tj. jejich výpočet bude zatížený určitou malou chybou a když do těchto funkcí dosadíme naše hodnoty, ve kterých už se nějaká drobná nepřesnost také projevila, tak ve výsledku se nám pak můžou tyto různé drobné odchylky kumulovat.

Vyloženě problematická je zde cyklometrická funkce acos() ve výpočtu vzdálenosti při malých vzdálenostech. Když si představíme průběh funkce acos() tak vidíme, že se její hodnota blíží nule (ke které se dostáváme právě při malých vzdálenostech) tehdy, když se její argument blíží hodnotě 1. A to je problém. Zatímco pokud by se argument měl blížit nekonečnu, tak máme rozsáhlé možnosti jak velká čísla jemně škálovat pomocí exponentu, tak pro přiblížení k číslu 1 můžeme využít jen a pouze rozlišení dané počtem bitů v mantise. A zde nám velmi brzy bity dojdou. Např. když vezmeme jednoduchou přesnost čísel v plovoucí řádové čárce, kde do mantisy uložíme v desítkové soustavě asi 7 číslic, tj. argument funkce acos() bude nabývat nejvýše hodnoty 0.9999999, tak nám vyjde tomu odpovídající úhel kolem 0.0256°, resp. vzdálenost na povrchu Země asi 2.8km. I kdybychom zkusili vzít ještě o jednu desítkovou číslici více, tj. argument 0.99999999, tak tomu odpovídající vzdálenost bude stále asi 0.9km. Tj. chceme-li počítat malé vzdálenosti přesněji, tak bude nutné se vyhnout číslům pouze s jednoduchou přesností.

Lepších výsledků pro malé vzdálenosti při nižší přesnosti použitých čísel s plovoucí řádovou čárkou lze dosáhnout výpočtem pomocí haversinu. Haversinus je kvadrát sinu polovičního argumentu a při navigaci se dříve používal v tabelované podobě, kdy zjednodušoval následující výpočty. Nicméně i tento výpočet trpí určitými problémy. Thaddeus Vincenty se už někdy v roce 1975 zabýval úpravami výpočtů vzdáleností na elipsoidu, kde se mu podařilo odvodit iterační postupy, které i při použití čísel s menším rozlišením a při dosažení malé velikosti výsledného kódu vedly na dobrou přesnost výsledků. Když upravíme Vincentyho algoritmus pro elipsoid použitím stejné hlavní i vedlejší poloosy, tak dostaneme postup výpočtu, který vede k přesnějším výsledkům pro všechny vzdálenosti oproti výše popsanému postupu. Tento výpočet přepsaný do jazyka C vypadá následovně:

Výpočet vzdálenosti podle 2. algoritmu

double dist = (111.2*180/M_PI) * 
  atan2(
    hypot( 
      cos(s2) * sin(d21), 
      cos(s1) * sin(s2) - sin(s1) * cos(s2) * cos(d21) 
    ),
    sin(s1) * sin(s2) + cos(s1) * cos(s2) * cos(d21)
  ); //km

double azi12 = (180.0/M_PI) *
  atan2(
    sin(d21),
    cos(s1) * tan(s2) - sin(s1) * cos(d21)
  ); //deg

//kde atan2(y,x) = atan(y/x) a hypot(x,y) = sqrt(x*x+y*y)

Ve výpočtu jsou využity dvě možná pro někoho méně známé funkce ze standardní matematické knihovny jazyka C. Funkce hypot() počítá délku přepony pravoúhlého trojúhelníka z délek jeho stran a funkce atan2() počítá úhel sklonu této přepony. Oproti použití obyčejné funkce atan() aplikované na předem vypočtený podíl obou argumentů je zde výhoda, že funkce atan2() pracuje ve všech 4 kvadrantech, takže úhel, který z ní obdržíme, můžeme přímo použít. A dále nemusíme u ní sami ošetřovat dělení nulou. U funkce atan2() bych upozornil na fakt, že v některých jiných programovacích jazycích může mít oproti zde uvedenému příkladu použití prohozený význam argumentů.

Právě použití funkce arkustangents místo původní arkuscosinus je výhodné při výpočtech malých vzdáleností, kdy se argument funkce arkustangents blíží také nule narozdíl od funkce arkuscosinus.

Následující dvě tabulky ukazují vliv algoritmu výpočtu a přesnosti použitých čísel na vypočítanou hodnotu při různých vzdálenostech. Jsou zde spočítány vzdálenosti a azimuty z lokátoru JN89HF do tří různých lokátorů, které leží všechny západně od něho na stejné zeměpisné šířce. První lokátor je sousední JN89GF, tj. ve vzdálenost asi 6.05km, druhý je JN79VF v 10x větší vzdálenosti (cca 60.5km) a třetí je JN49DF ve 100x větší vzdálenosti (cca 605km).

Výpočet označený KmAlg=1 je podle výše uvedeného méně přesného algoritmu 1, výpočet označený KmAlg=2 je podle výše uvedeného přesnějšího algoritmu 2 a pro srovnání je ještě uveden výpočet označený KmAlg=3 provedený nikoliv na kouli, ale dle Vincentyho iteračního postupu na elipsoidu WGS84. Ve sloupci Prec32 jsou výpočty s použitím čísel s plovoucí řádovou čárkou s jednoduchou přesností 32bit, ve sloupci Prec64 je to dvojitá přesnost 64bit, ve sloupci Prec80 je to rozšířená přesnost 80bit a ve sloupci Prec128 jsou výpočty pro čtyřnásobnou přesnost 128bit.

Vzdálenost [km] z JN89HF

LOC	KmAlg	Prec32	Prec64	Prec80	Prec128
JN89GF	1	6,2219638824463	6,0514589136058	6,051458914829	6,0514589148286
JN89GF	2	6,0515055656433	6,0514589148285	6,0514589148286	6,0514589148286
JN89GF	3	6,0696716308594	6,0696250111899	6,06962501119	6,06962501119
JN79VF	1	60,56457901001	60,514286284586	60,514286284638	60,514286284638
JN79VF	2	60,514259338379	60,514286284638	60,514286284638	60,514286284638
JN79VF	3	60,69592666626	60,695946339066	60,695946339066	60,695946339066
JN49DF	1	604,84301757813	604,83977189872	604,83977189872	604,83977189872
JN49DF	2	604,83978271484	604,83977189872	604,83977189872	604,83977189872
JN49DF	3	606,65551757813	606,6554617883	606,6554617883	606,6554617883

Azimut [°] z JN89HF

LOC	KmAlg	Prec32	Prec64	Prec80	Prec128
JN89GF	1	283,44250488281	270,03153429044	270,03155532553	270,03155531838
JN89GF	2	270,03179931641	270,03155531838	270,03155531838	270,03155531838
JN89GF	3	270,03155517578	270,03155531838	270,03155531839	270,03155531839
JN79VF	1	272,35684204102	270,31555552344	270,31555553231	270,31555553231
JN79VF	2	270,31546020508	270,31555553231	270,31555553231	270,31555553231
JN79VF	3	270,31555175781	270,31555553912	270,31555553912	270,31555553912
JN49DF	1	273,1633605957	273,15790452931	273,15790452932	273,15790452932
JN49DF	2	273,15789794922	273,15790452932	273,15790452932	273,15790452932
JN49DF	3	273,1579284668	273,15791133888	273,15791133888	273,15791133888

V tabulkách je vidět, že zatímco algoritmus 1 se při jednoduché přesnosti u nejkratší vzdálenosti rozchází s výsledky spočtenými s vyšší přesností čísel v řádu stovek metrů, tak algoritmus 2 se odchyluje už jen v řádu metrů. Při dvojnásobné a vyšší přesnosti jsou už rozdíly zanedbatelné u obou algoritmů. A při větších vzdálenostech jsou odchylky při použití nejnižší přesnosti u obou algoritmů několikanásobně menší. U třetího algoritmu počítajícího vzdálenost na elipsoidu je naopak vidět, jak při malých vzdálenostech lze rozdíl mezi oběma modely vpodstatě zanedbat, a naopak se vzrůstající vzdáleností se hodnoty vypočtené na elipsoidu liší od hodnot vypočtených na náhradní kouli už v řádu kilometrů.

Zaokrouhlení vzdálenosti na body

Vypočtenou vzdálenost je potřeba nakonec správným postupem převést na body, které se udávají jako celé číslo. Postup převodu stanovuje IARU opět ve svém VHF Handbooku a má se provést tak, že se nejprve z vypočtené vzdálenosti odřízne desetinná část, tj. zůstane jen část nalevo od desetinné tečky, a k ní se přičte hodnota 1. Tím je současně "elegantně" vyřešen i výpočet bodů při spojení ve vlastním lokátoru, kde vzdálenost vyjde 0km - po zaokrouhlení je za spojení ve vlastním lokátoru započítán 1 bod. V jazyce C lze toto zaokrouhlení provést následovně:

body = ((int) dist) + 1

Nejprve se vzdálenost v proměnné dist, která je uložená jako číslo s plovoucí řádovou čárkou, přetypuje na celé číslo, tím dojde k jejímu převodu z čísla v plovoucí řádové čárce na celé číslo způsobem, při kterém se desetinná místa zahodí, a pak už se k výsledku uloženému jako celé číslo přičte celočíselná konstanta 1.

A v tomto zaokrouhlení se právě i malá odchylka ve vypočtené vzdálenosti třeba na úrovni i milimetrů může projevit změnou hodnoty o 1 bod, tj. vlastně o celý 1km. Stačí aby jedním výpočtem vyšla hodnota těsně pod hodnotou celého čísla a druhým těsně nad a ta první bude zaokrouhlena na o 1bod nižší hodnotu než ta druhá. A skutečně se to tak v reálu děje. Když jsem dohledával některé jednobodové rozdíly ve výpočtech, tak to pokaždé byly vzdálenosti pohybující se těsně kolem nějakého celého čísla.

Když jsem přepočítával s různými variantami výpočtů velké množství vzdáleností, tak bylo vidět, že nebyl až tak velký rozdíl mezi tím, zda se zaokrouhlení provedlo výše uvedeným postupem, nebo zda byl postup proveden v rozporu s doporučením IARU obráceně, tj. nejprve se přičetla k číslu v plovoucí řádové čárce konstanta 1.0 a teprve poté se odřízla desetinná část. Zato znatelný rozdíl byl, pokud se místo tohoto zaokrouhlení použilo běžné zaokrouhlení na sudo - vycházela pak odchylka o 1bod u zhruba poloviny vypočtených vzdáleností.

Závěrem k výpočtu vzdálenosti

Při výpočtu vzdálenosti je vhodné použít čísla s plovoucí řádovou čárkou s dvojitou přesností, tj. 64bit. Nižší rozlišení už může způsobovat větší odchylky, naopak použití větší přesnosti není vyloženě nutné a nevede už k výraznému zvýšení přesnosti. Při použití čísel s menší přesností je možné vliv této menší přesnosti částečně eliminovat použitím vhodného algoritmu výpočtu.

Porovnání výsledků výpočtů

Na porovnání výsledků výpočtů bodů ze závodů jsem použil data OK stanic z Polního den 2024 z pásma 145MHz. Data jsou anonymizována, takže zde nikde nenajdete značky stanic, jejich lokátory a z přepočtů deníků jsou zde uváděny jen výsledné sumární údaje, nikoliv detailní údaje o jednotlivých spojeních. Jednotlivé deníky jsou zde označeny náhodně zvoleným pořadovým číslem.

Celkem bylo porovnáváno 151 logů s 23949 spojeními, které představovaly souhrnnou vzdálenost asi 6.5 milionu km. Z tohoto počtu pak bylo po první fázi porovnání z dalšího zpracování vyřazeno 7 logů kvůli v nim obsaženým chybám, které by silně zkreslovaly další výsledky. V následující fázi tak byly porovnávány výpočty vzdáleností u 22768 spojení ve 144 denících, a při porovnání výsledků výpočtů s výsledky vyhodnocovatele IARU bylo ještě nutné vyřadit logy stanic, které nebyly ve výsledcích IARU uvedeny. Přepočet logů byl opakován celkem se 42 různými nastaveními programu Loc 2.3, které se lišily použitím různých přesností čísel v plovoucí řádové čárce, různými algoritmy výpočtu vzdálenosti a převodu z lokátorů na souřadnice a různým způsobem zaokrouhlování, takže v souhrnu byly přepočítávány vzdálenosti více jak 1 milionu spojení.

Předem ještě uvedu, že některé níže ukazované detaily přístupu vyhodnocovacích programů ČRK a IARU k určitým datům v denících jsou vlastně i přímo popisované v materiálech pořadatelů VKV závodů - stačí si na webu najít a prostudovat materiály "Všeobecné podmínky závodů na VKV" (ČRK) nebo "Quote for a VHF/UHF contest robot IARU-R1" (IARU) a najdete v nich řadu detailů týkajících se vyhodonocování deníků. Dále - materiály na této stránce byly sestaveny na jaře 2025 dle podkladů z roku 2024, tj. jsou poplatné tehdejší době a je možné, že se v průběhu času některé postupy vyhodnocovacích programů při zpracování deníků změní.

Mým cílem nebylo porovnávat finální výsledky po křížové kontrole, to je otázka nikoliv přesnosti výpočtu bodů na základě vzdálenosti, ale porovnání přijatých a vyslaných údajů. Proto mě zajímaly především deklarované výsledky, tj. jak výsledky spočítal program, kterým byl EDI soubor vytvořen, a pak výsledky vypočtené nad stejnými spojeními vyhodnocovacími programy ČRK a IARU. A zde jsem hned na začátku narazil na rozdíly v tom, která spojení ČRK a IARU započtou, a v jaké podobě hodnotu, kterou vypočetli, zveřejní.

Robot ČRK uvádí v přehledu výsledky deklarované v deníku EDI a je možné se tam podívat i přímo na původní soubor EDI v podobě, jak byl zaslán stanicí. Ve výstupu deklarované výsledky tam najdete ve sloupci body celkem hodnotu, která byla deklarována v hlavičce souboru EDI v položce CQSOP. Ve sloupci počet qso pak není uvedena deklarovaná hodnota počtu platných spojení z hlavičky EDI z položky CQSOs, ale celkový počet záznamů, tj. včetně spojení, která jste deklarovali jako neplatná.

Ve výstupu výsledky je hodnota z CQSOP uvedena ve sloupci body deklarované. Pokud si ve výstupu výsledky rozkliknete odkazem uloženým ve značce stanice její ERROR LOG, tak se tato hodnota objeví nahoře v položce Declared score a ve sloupci body deklarované jsou zde pak vypisovány deklarované hodnoty bodů ze souboru EDI u jednotlivých zde vypsaných chybných spojení. Ve sloupci body skutečné jsou pak u těchto spojení vypisovány počty bodů tak, jak je vypočítal vyhodnocovací program, a nahoře v položce Correct declared score pak vidíte celkový součet bodů vypočtených vyhodnocovacím programem za všechna spojení, tj. za ta v ERROR LOGu vypsaná, i za ta v něm nevypsaná, která jsou bez chyb.

Při vyhodonocení deníků po křížové kontrole je pak od této hodnoty Correct declared score odečtena suma bodů za chybná spojení, která je v ERROR LOGu uvedena vespod sloupce body skutečné a nahoře v položce Sum of lost points, a to je pak finální bodový výsledek, podle kterého se vytvoří konečné pořadí stanic. Hodnota Sum of lost points podělená hodnotou Correct declared score je pak nahoře vyčíslena v procentech jako Error points. Ve výstupu výsledky je pak ve sloupci počet QSO uveden počet všech záznamů, tj. včetně spojení, která jste dekarovali v EDI jako neplatná, a hodnota vyřazeno QSO pak obsahuje počet záznamů, které jsou uvedeny jako chybné v ERROR LOGu a procentně je to ve stejném sloupci uvedeno jako tento počet chybných spojení podělený hodnotou ve sloupci počet QSO.

Vyhodnocovací program ČRK má specifický přístup ke spojením, která jste označili jako neplatná, tj. nastavili jste jim bodovou hodnotu 0, a spojení označili příznakem D jako duplicitní nebo textem ERROR do značky. Vyhodnocovací program u těchto spojení vezme ze záznamů v EDI sloupec s přijatým lokátorem a prostě z něj bodovou hodnotu vyčíslí a oproti vámi deklarované hodnotě 0 ji přiřadí dotyčnému záznamu spojení a přičte vám ji samozřejmě i do položky Correct declared score. Takže ikdyž jste u tohoto spojení třeba přijali lokátor chybně, tak vám pro něj vypočte body. A nejen to, on vám je vypočte ikdyž máte položku s lokátorem prázdnou - váš bodový zisk za takovéto spojení s nevyplněným lokátorem se zvýší o hodnotu řádově více jak 5 tisíc bodů (konkrétní hodnota závisí na vašem QTH). Může se vám tedy stát, že oproti bodům, které jste deklarovali, bude hodnota, kterou najdete ve sloupci Correct declared score, i o tisíce bodů vyšší. Nicméně samozřejmě při následné křížové kontrole budou takováto spojení vyřazena, ikdyž u duplicitních spojení může nastat i případ, že je vám nakonec uznáno spojení, které jste označili jako duplicitní a to druhé k němu neduplicitní, které jste původně chtěli uznat, je vám odečteno, to už záleží na tom, co měla v deníku vaše protistanice. Má to ten efekt, že když se spletete a označíte jako duplicitní spojení to druhé, než které jste zamýšleli, tak o body za něj ve vyhodnocení nemusíte přijít. Jenže ty body, které vám byly přičteny do Correct declared score a pak ve finále zase odečteny, a ty záznamy, které vám takto byly uměle převedeny z neplatných na platné a pak zase vyřazeny, jsou vám započítany do zobrazovaných chybovostí. Pak to vypadá, že někdo měl velikou chybovost, ale ve skutečnosti to není pravda a měl jen smůlu, že vyhodnocovací program kouzlil s jeho daty a znovu započítával spojení, která dotyčný zcela správně označil jako neplatná.

Z vyhodnocení ČRK lze tedy snadno získat informaci o původně deklarovaných údajích až na úroveň jednotlivých spojení, ale jak byla jednotlivá spojení vypočtena vyhodnocovacím program lze zjistit jen u těch, která se kvůli chybám objevila v chybovém výpisu, u platných spojení to zjistit nejde. Celková hodnota vypočtená vyhodonocovacím programem za všechna spojení je zkreslená tím, že jsou do ní zahrnuta jako platná i spojení, která byla původně v deníku deklarovaná jako neplatná s nulovou hodnotou.

U robota IARU se o deklarovaných výsledcích v souboru EDI nic nedovíte. Původní soubor EDI není k dispozici. Pokud se podíváte na výstup Participants, tak ve sloupci Claimed score je hodnota nikoliv z původního deníku, ale až ta, která byla spočtena robotem (pozor, ono to je trochu složitější, upřesním to později). Při zpracování deníku jsou rovnou vyřazena některá chybná spojení, mezi nimi např. i ta, která jste označili jako duplicitní. Sloupec Claimed QSOs uvádí počet robotem nevyřazených záznamů, nikoliv jejich původně deklarovaný počet. Pokud si rozkliknete pro konkrétní stanici výstup QSOs, tak je zde ve sloupci Claimed score opět hodnota spočtená robotem, takže ve sloupci Computed score uvidíte stejnou hodnotu (pozor, bude to zase ještě upřesněno níže), a nejsou zobrazena spojení, která byla vyřazena hned při načítání - o nich se už nedá nic zpětně zjistit. Hodnota Cross checked score pak už ve výstupech shodně uvádí finální výsledek po křížové kontrole deníků.

A jak je to s uváděnou chybovostí? Tu najdete shodně ve výstupech Results Table i Participants ve sloupci % error score, a je vyčíslena v procentech jako rozdíl mezi Cross checked score a Computed score podělený Cross checked score.

I robot IARU si u některých spojení dokáže trošku vymýšlet. Když označíte spojení jako neplatné s nulovou hodnotou a do značky dáte hodnotu ERROR, tak spojení není hned při načítání vyřazeno, ale je nejprve zpracováno obdobně jako to dělá robot ČRK. U tohoto spojení je vám započtena nejprve bodová hodnota nikoliv nula, ale vypočtená podle údaje uvedeného ve sloupci s přijatým lokátorem. Pokud je sloupec s lokátorem prázdný, tak je vám započtena hodnota 1. A následně při křížové kontrole je vám pak hodnota za toto spojení zase odečtena (v chybovém výpisu se vám dokonce objeví údaje z reverzního deníku vytvářeného pro stanici se značkou ERROR). Navýšená hodnota se objeví ve výstupu QSOs ve sloupci Claimed score a hodnota následně ponížená ve sloupci Computed score. Právě u logů s takovýmito spojeními se objeví zajímavý rozpor mezi sloupci Claimed score ve výstupech QSOs a Participants. Ve výstupu Participants je totiž hodnota ve sloupci Claimed score shodná se součtem bodů ze sloupce Computed score a nikoliv ze sloupce Claimed score ve výstupu QSOs. Tj. ve výsledné chybovosti se vám ta započtená a nakonec zase odečtená hodnota u neplatného spojení nakonec neprojeví.

Z vyhodnocení IARU tedy nelze získat informaci o původně deklarovaných údajích. Jsou k dispozici jen už robotem přepočtené údaje. Pokud jsou některá spojení ze zpracování vyřazena už při načítání, ta se o nich nedá nic zjistit. Některá spojení, která jsou označena jako neplatná, jsou při načítání zahrnuta jako platná a je jim přiřazena bodová hodnota, ikdyž měla deklarovanou bodovou hodnotu nula.

Mezi oběma vyhodnocovacími programy jsou i další rozdíly, ale hlavně tyto výše uvedené mi způsobovaly problémy s tím, aby šla data mezi sebou porovnat. Protože ani u jednoho z obou vyhodnocovatelů nelze ze zveřejněných výsledků vlastně získat současně informace o deklarovaných i vypočtených bodech u všech jednotlivých spojení, tak jsem neměl možnost udělat porovnání na úrovni jednotlivých spojení, ale musel jsem srovnávat celkové součty bodů, což znamenalo vypořádat se nějak s rozdílným započítáváním některých spojení. Z výsledků ČRK se dají zjistit vypočtené bodové hodnoty jen u spojení vypsaných v chybovém logu a ve výsledcích IARU zase některá spojení z výsledků úplně zmizí a informace o bodech deklarovaných původně v deníku nejsou zjistitelné vůbec a musel bych jen předpokládat, že logy zaslané ČRK a IARU byly u všech stanic shodné.

Nejprve tedy bylo nutné prohnat deníky prvním přepočtem, shromáždit si z toho údaje včetně detailů o výsledcích a chybách u jednotlivých spojení, pak to porovnat se vším, co bylo nějak dostupné ve výsledcích ČRK a IARU, a pokusit se zrekonstruovat vypočtené výsledky, které by zřejmě vyhodnocovací programy ČRK a IARU ukázaly, pokud by k různým problematickým záznamům přistupovaly shodně. U dat z ČRK se nejprve daly najít v chybových výpisech všechna spojení, která měla původně hodnotu 0 a započtena byla s nějakou jinou hodnotou, a z výsledků vypočtených ČRK je odečíst. Nicméně takto nešlo postihnou spojení, která byla také započtena místo 0 s jinou hodnotou, ale nebyla vypsána mezi chybami - to byla např. spojení označená v logu jako duplicitní, která pak ale byla při vyhodnocení prohozena se svým původně neduplicitním záznamem a byla uznána. Takže se musely odečítat dvě korekční hodnoty, kdy ta druhá se získala až dohledáváním zbylých rozdílů po aplikování první korekce. U výsledků IARU pak bylo potřeba podobně korigovat případy, kdy bylo spojení při načítání narozdíl od ČRK rovnou vyřazeno, a vrátit jeho bodovou hodnotu zpět. Tj. u výsledků IARU se prováděla jen jedna korekce. Nakonec jsem tedy získal tři už porovnatelné součty bodů za spojení - jeden pocházející z programu, kterým byl původně deník spočten, druhý jako předpokládaný výstup výpočtu ČRK a třetí jako předpokládaný výsledek výpočtu IARU. A další hodnotou pak byl ještě výpočet z programu Loc, u kterého bylo možné porovnávat jak celkové součty, tak i hodnoty vypočtené u jednotlivých spojení s původními hodnotami deklarovanými u nich v deníku.

Porovnání výsledků z logovacích a vyhodnocovacích programů

V první tabulce, kterou zde uvedu, jsou shrnuty právě výstupy z této první fáze zpracování. Na základě údajů z této tabulky pak byla prováděna některá následující porovnání výsledků. Pro umístění v HTML formě zde na stránce jsem musel kvůli omezené šířce stránky v tabulce řadu sloupců vypustit nebo informace z nich sloučit do jednoho, ale přikládám ji zde i v podrobnější verzi jako stažitelný soubor CSV se sloupci oddělenými středníky s variantami v kódování CP1250, UTF8 anebo jako ASCII s odstraněnou diakritikou. Pro správné načtení do nějakého tabulkového procesoru budete potřebovat takový, který zvládne v buňce texty i delší než 255 znaků (texty ve sloupcích Dif Qsopts LOC - EDI a Remarks mohou být delší):

cmplog-cp1250.csv (CP1250, 26kB)

cmplog-utf8.csv (UTF8, 26kB)

cmplog-ascii.csv (ASCII, 26kB)

Význam sloupců v tabulce je následující. Sloupec Log obsahuje označení deníku náhodným číslem. Sloupec EDI pts obsahuje součet bodů deklarovaných v původním deníku u jednotlivých spojení. Sloupec CRK comp udává body vypočtené původně robotem ČRK dle položky Correct declared score. Ve sloupci CRK cor1 a CRK cor2 jsou moje korekční hodnoty zjištěné výše popsaným způsobem a sloupec CRK pts = CRK comp - CRK cor1 - CRK cor2. Obdobně ve sloupci IARU comp je původně vypočtená hodnota dle IARU z položky Claimed score, sloupec IARU cor obsahuje moji korekci a IARU pts = IARU comp - IARU cor. Sloupec LOC pts obsahuje body vypočtené programem Loc při nastavení gcsalg2, kmalg2, precs64 a roundiaru a sloupec LOC pts rkm body spočtené programem Loc při stejném nastavení, ale při použití odlišného zaokrouhlování roundkm, tj. při zaokrouhlování nasudo - ukázalo se, že v některých denících se zřejmě zaokrouhlovalo tímto způsobem, protože když se výsledky v nich porovnaly s tímto druhým výpočtem, tak se významně snížil počet odchylek ve vypočtených bodech u jednotlivých spojení.

Další sloupce vyčíslují rozdíly mezi údaji v předchozích sloupcích. Sloupec Dif CRK - EDI comp udává rozdíl mezi ČRK původně vypočteným výsledkem a výsledkem deklarovaným v EDI souboru. Obdobně sloupec Dif IARU - EDI comp udává rozdíl mezi výsledkem vypočteným původně IARU a body deklarovanými v EDI. Tj. tyto dvě hodnoty jsou zatíženy někdy velkými rozdíly způsobenými započtením odlišných sad spojení. Další dva sloupce již udávají tyto rozdíly srovnané na stejné sady spojení, tj. sloupec Dif CRK - EDI je rozdílem mezi korigovaným výpočtem ČRK a údajem z EDI a sloupec Dif IARU - EDI je rozdílem mezi korigovaným výpočtem IARU a údajem v EDI.

Pak následují porovnání s výsledky programu Loc. Sloupec Dif LOC - EDI udává rozdíl mezi výpočtem Loc se zaokrouhlením dle IARU a údajem v EDI, sloupec Dif LOC - CRK mezi stejným výpočtem Loc a korigovaným výpočtem ČRK a sloupec Dif LOC - IARU rozdíl mezi stejným výpočtem Loc a korigovaným výpočtem IARU. Předchozí hodnoty byly při výpočtu programu Loc dle algoritmu kmalg2. Další tři sloupce Dif LOC alg1 - EDI, Dif LOC alg1 - CRK a Dif LOC alg1 - IARU uvádějí obdobné srovnání mezi Loc, EDI a korigovanými výpočty ČRK a IARU, když se programu Loc změní algoritmus výpočtu vzdálenosti na kmalg1. Další sloupec Dif LOC rkm - EDI udává rozdíl mezi výpočtem programu Loc s výše uvedeným zaokrouhlování roundkm, tj. nasudo, a deklarovaným výsledkem z EDI souboru. Sloupec Dif Qsopts LOC - EDI obsahuje poznámky k detailnímu porovnání výpočtů u jednotlivých spojení mezi programem Loc a deklarovanými údaji v EDI. Typicky je zde uvedeno u kolika spojení byla zjištěna odchylka mezi výpočtem programu Loc (s nastavením gcsalg2, kmalg2, precs64 a roundiaru) a deklarovanou hodnotou, a jak byla obvykle veliká, tj. např. údaj "10x -1b" znamená, že u deseti spojení program Loc vypočetl bodovou hodnotu o 1 nižší, než bylo deklarováno v původním souboru EDI. Předposlední sloupec Remarks obsahuje další poznámky k porovnání, jako např. informace o důvodech, proč byly u tohoto logu použity uvedené korekční hodnoty, a informace o zjištěných rozdílech anebo různých problémech v datech v EDI souboru. Poslední sloupec Logname pak obsahuje údaj o programu, kterým byl deník zřejmě vytvořen, a to podle údajů nalezených v souboru EDI buď v položce [END] nebo v sekci [Remarks].

Pro zjednodušené zobrazení zde na stránce v HTML jsou z těchto všech údajů použity jen sloupce Log, Dif CRK - EDI comp, Dif IARU - EDI comp, Dif CRK - EDI, Dif IARU - EDI a Dif LOC - EDI. Sloupec Remarks je zde pak sestaven sloučením obsahů původních dvou sloupců Dif Qsopts LOC - EDI a Remarks.

Při dohledávání rozdílů jsem hlavně zpočátku často tápal, musel jsem zjistit z jakých dílčích hodnot jednotlivých spojení se nějaká sumární rozdílná hodnota skládá, program Loc 2.3 zpočátku neuměl vypisovat upozornění na mnohé různé problémy, to jsem do něj doplňoval postupně tak, jak jsem na různé takové případy přicházel, takže to znamenalo hodně ručního hledání a porovnávání a dělal jsem si v souvislosti s tím samozřejmě řadu poznámek o různých odchylkách v denících, které se pak třeba nakonec ukázaly jako nepodstatné. V tabulce ve sloupci Remarks jsem tyto poznámky v silně zestručněné podobě zachoval pro toho, koho by zajímalo, jaké různé odchylky se v denících EDI vyskytovaly, nicméně pro samotný výpočet bodové hodnoty spojení jsou tyto poznámky jako např. "v PExch data" nebo "rozdíl mode/rst" nebo "u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí" nepodstatné a ani nepředstavují chybu z pohledu vyhodnocovatelů.

Tabulka s výsledky porovnání pro jednotlivé deníky

Log	Dif CRK - EDI comp	Dif IARU - EDI comp	Dif CRK - EDI	Dif IARU - EDI	Dif LOC - EDI	Remarks
1	-1	-2	-1	-2	-2	2x -1b
2	0	-224	0	0	0	0x 0b, 1 qso se špatným časem (224b) - iaru smazáno, črk započteno, u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí
3	-1	-1	-1	-1	-1	1x -1b
4	0	0	0	0	0	0x 0b, chybný formát CWWLB, CExcB, CDXCB, CExcs a CDXCs v záhlaví, chybný počet WWL
5	-1	-1	-1	-1	-1	1x -1b
6	1455	0	1	0	0	0x 0b, 3 dupl qso s pts=0 (1454b) - iaru smazáno a črk započteno
7	-1	0	-1	0	0	0x 0b, v hlavičce chybný formát CWWLB, CExcB, CDXCB, CExcs, CDXCs, u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí
8	4	0	4	0	0	0x 0b, deklarován odx 805km - deklarované i spočtené pts pro toto qso jsou 806
9	1153	-46	-34	-46	-46	46x -1b, 2 dupl qso s pts=0 (485b, 702b) - iaru smazáno a črk započteno, rozdíl mode/rst
10	-6	-7	-6	-7	-7	7x -1b
11	160	-4	-3	-4	-4	4x -1b, 1 dupl qso s pts=0 (163b) - iaru smazáno a črk započteno, rozdíl mode/rst
12	64	-3	-1	-3	-3	3x -1b, 1 dupl qso s pts=0 (65b) - iaru smazáno a črk započteno, v hlavičce jsou různé hodnoty v CQSOP a CToSc
13	6	0	6	0	0	0x 0b
14	0	0	0	0	0	0x 0b, v PExch data
16	-10	-17	-10	-17	-17	17x -1b, rozdíl mode/rst
17	0	0	0	0	0	0x 0b
18	-22	-30	-22	-30	-30	32x +/-1b, rozdíl mode/rst
19	1	0	0	0	0	0x 0b, 1 qso deklarováno s call=ERROR a pts=0 - iaru započteno s pts=1, črk započteno s pts=1, deklarován odx 819km - deklarované i spočtené pts pro toto qso jsou 820, v hlavičce je v CToSc a CQSOP jiná hodnota než je součet pts u qso
20	0	0	0	0	0	0x 0b, u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí
21	1	1	1	1	1	1x +1b, u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí, v PExch data
23	-7	-7	-7	-7	-7	7x -1b
24	1	0	1	0	0	0x 0b
26	-13	-15	-13	-15	-15	15x -1b
27	12	-1	12	-1	-1	1x -1b, rozdíl mode/rst
28	0	0	0	0	0	0x 0b, u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí, v PExch data
29	-1	0	-1	0	0	0x 0b
30	-1	-3	-1	-3	-3	3x -1b
31	0	0	0	0	0	0x 0b, u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí, v PExch data
32	-5	-4	-5	-4	-4	4x -1b, chybný formát edi - před [REG1TEST;1] je mezera navíc
33	1	0	1	0	0	0x 0b, u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí
34	3	0	3	0	0	0x 0b, deklarován odx 738km - deklarované i spočtené pts pro toto qso jsou 739, rozdíl mode/rst
35	-1	0	-1	0	0	0x 0b
36	2	0	2	0	0	0x 0b
37	1	0	1	0	0	0x 0b
38	-7	-6	-7	-6	-6	6x -1b, rozdíl mode/rst
39	2	2	2	2	2	2x +1b, u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí, v PExch data
40	5	-470	5	3	3	3x +1b, 1 qso má chybný čas, qso před ním vypadá vpořádku a je i v deníku protistanice - iaru smazána obě qso (323b, 150b) a črk jsou obě započtena a nakonec jen to druhé z nich neuznáno, v PExch data
41	261	-2	-1	-2	-2	2x -1b, 1 dupl qso s pts=0 (262b) - iaru smazáno a črk započteno
42	1419	-1065	-23	-24	-24	24x -1b, 2 qso se špatným časem (1041b), 5 dupl qso s pts=0 (1442b) - iaru smazáno, črk započteno, rozdíl mode/rst
43	3	0	3	0	0	0x 0b, deklarován odx 793km - deklarované i spočtené pts pro toto qso jsou 794
44	5	0	5	0	0	0x 0b, u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí
45	-1	-1	-1	-1	-1	1x -1b
46	-3	-2	-3	-2	-2	2x -1b
47	95	0	-3	0	0	0x 0b, 1 dupl qso s pts=0 (98b) - iaru smazáno a črk započteno, u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí, v CQSOs je započteno i dupl qso
48	414	78	76	78	78	76x +1b, 1x +2b, zřejmě chybné zaokrouhlování - pokud se na srovnání vezme přepočet se zaokrouhlováním na sudo, tak rozdíly klesnou, 3 dupl qso s pts=0 (338b) - iaru smazáno a črk započteno, nesouhlasí součet pts u qso s hodnotami CQSOP a CToSc v hlavičce
49	116	-8	-8	-8	-8	8x -1b
50	565	-1	1	-1	0	0x 0b, 2 dupl qso s pts=0 (564b) - iaru smazáno a črk započteno
51	-1	0	-1	0	0	0x 0b, u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí, v PExch data, rozdíl mode/rst
52	0	0	0	0	0	0x 0b, u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí, v PExch data
53	687	0	12	0	0	0x 0b, 2 dupl qso s pts=0 (261b, 414b) - iaru smazáno a črk započteno, rozdíl mode/rst
54	0	0	0	0	0	0x 0b, u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí
55	0	0	0	0	0	0x 0b, u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí
56	-1	-1	-1	-1	-1	1x -1b
57	-10	-14	-10	-14	-14	16x +/-1b
58	0	0	0	0	0	0x 0b, deklarován odx 861km - deklarované i spočtené pts pro toto qso jsou 862
59	-23	-28	-23	-28	-28	28x -1b
60	-3	-2	-3	-2	-2	2x -1b
61	1	0	1	0	0	0x 0b, u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí, v PExch data
62	-3	-4	-3	-4	-4	4x -1b
63	1708	0	14	0	0	0x 0b, 8 dupl qso s pts=0 (1694b) - iaru smazáno a črk započteno
64	-1	-3	-1	-3	-3	3x -1b, rozdíl mode/rst
65	-2	-1	-2	-1	-1	1x -1b
66	-2	0	-2	0	0	0x 0b
67	0	0	0	0	0	0x 0b
68	-15	-14	-15	-14	-14	14x -1b
69	-2	-3	-2	-3	-3	3x -1b
70	-7	-8	-7	-8	-8	8x -1b
71	0	-31	0	0	0	0x 0b, 1 qso se špatným časem (31b) - iaru smazáno, črk započteno
72	0	0	0	0	0	0x 0b, u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí
74	464	0	2	0	0	0x 0b, 1 dupl qso s pts=0 (462b) - iaru smazáno a črk započteno
75	1	1	1	1	1	1x +1b, u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí, v PExch data
76	110	-24	-23	-24	-24	24x -1b, 1 dupl qso s pts=0 (133b) - iaru smazáno a črk započteno
77	0	0	0	0	0	0x 0b
78	-8	-107	-8	-8	-8	8x -1b, 1 qso s nekompletním přijatým kódem a s pts=99 - iaru smazáno a črk započteno, rozdíl mode/rst
79	-1	0	-1	0	0	0x 0b, pts u qso souhlasí, ale souhrnné údaje v hlavičce jsou zcela chybné (počty qso, sumy pts i odx)
80	192	0	-2	0	0	0x 0b, 2 dupl qso s pts=0 (194b) - iaru smazána, črk započtena, u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí
81	10	10	10	10	10	10x +1b, zřejmě chybné zaokrouhlování - pokud se na srovnání vezme přepočet se zaokrouhlováním na sudo, tak rozdíly klesnou k 0, u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí
82	81	-22	-16	-22	-22	22x -1b, 1 dupl qso s pts=0 (97b) - iaru smazáno a črk započteno, rozdíl mode/rst
84	0	0	0	0	0	0x 0b
85	-8	-6	-8	-6	-6	6x -1b
87	2	2	2	2	2	2x +1b, v hlavičce je chybný formát položek CWWLB, CExcB, CDXCB, CExcs a CDXCs, v položce CWWLs je v počtu WWL hodnota 1 ikdyž příznaky nového WWL je označeno 12 qso
89	-6	-7	-6	-7	-7	7x -1b
91	-3	-5	-3	-5	-5	5x -1b, v hlavičce je chybný formát údajů v SAntH
92	899	-101	23	0	0	0x 0b, v hlavičce různé hodnoty v CQSOP a CToSc, 3 dupl qso s pts=0 (421b, 134b, 321b), 1 qso (121b) zařazeno mezi záznamy na zcela jinou pozici - iaru smazáno a črk započteno
93	3	0	3	0	0	0x 0b, deklarován odx 382km - deklarované i spočtené pts pro toto qso jsou 383
94	-1	-203	-1	-1	-1	1x -1b, 1 qso se špatným formátem časem (202b) - iaru smazáno, črk započteno
95	-15	-11	-15	-11	-11	11x -1b
96	174	0	5	0	0	0x 0b, 1 qso deklarováno s call=ERROR a pts=0 - iaru započteno s pts=169, črk započteno s pts=169, deklarován odx 969km - deklarované i spočtené pts pro toto qso jsou 970
97	0	0	0	0	0	0x 0b, pts u qso souhlasí, ale souhrnné údaje v hlavičce jsou zcela chybné (počty qso, sumy pts i odx)
98	-15	-13	-15	-13	-13	13x -1b, nesouhlasí počet qso v hlavičce v CQSOs
99	0	0	0	0	0	0x 0b, u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí
100	194	0	8	0	0	0x 0b, 1 dupl qso s pts=0 (186b) - iaru smazáno a črk započteno
101	11476	120	122	120	120	120x +1b, zřejmě chybné zaokrouhlování - pokud se na srovnání vezme přepočet se zaokrouhlováním na sudo, tak rozdíly klesnou k 0, 2 qso deklarována s call=ERROR a pts=0 - iaru započteny s pts=1, črk započteny s pts=5677, u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí, nesouhlasí QSORecords s počtem záznamů
102	0	0	0	0	0	0x 0b, deklarován odx 819km - deklarované i spočtené pts pro toto qso jsou 820
103	1	0	1	0	0	0x 0b, deklarován odx 754km - deklarované i spočtené pts pro toto qso jsou 755
107	20	0	20	0	0	0x 0b, deklarován odx 994km - deklarované i spočtené pts pro toto qso jsou 995, v hlavičce jsou různé hodnoty v CQSOP a CToSC, rozdíl mode/rst
108	0	0	0	0	0	0x 0b, v PExch data, chybný formát TDate
109	-5	-539	-5	-4	-4	6x +/-1b, 1 qso druhý den závodu v čase 14:00 (535b) - iaru smazáno a črk započteno
111	-1	-3	-1	-3	-3	3x -1b
112	6	0	6	0	0	0x 0b, u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí
114	-1	-285	-1	0	0	0x 0b, 1 qso druhý den závodu v čase 14:00 (285b) - iaru smazáno a črk započteno, u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí, v PExch data
115	-7	-8	-7	-8	-8	8x -1b
116	221	-1069	0	-1	-1	1x -1b, 3 dupl qso s pts=0 (119b, 24b, 78b), 9 qso (z PDM) před závodem (1068b) - iaru smazáno a črk započteno
117	5815	0	0	-1	-1	0x 0b, 1 qso s chybným rxloc (nula místo písmene O) a s pts= 1 - iaru započteno s pts=1 a črk započteno s pts=5816
119	-21	-24	-21	-24	-24	142x +/-1b (hodně 1b rozdílů na obě strany), chybný formát CDXCB a CDXCs
120	0	0	0	0	0	0x 0b, u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí
121	-6	-6	-6	-6	-6	6x -1b
122	-5	-12	-5	-12	-12	14x +/-1b
124	164	-696	145	141	141	141x +1b, zřejmě chybné zaokrouhlování - pokud se na srovnání vezme přepočet se zaokrouhlováním na sudo, tak rozdíly klesnou, 1 dupl qso s pts=0 (19b), u 2 qso s pts=572 a pts=264 chybí rxrst a rxnr - iaru smazána, črk započtena, v hlavičce jsou chybné názvy položek RAdr1, RAdr2 a MOpe2
125	1	0	1	0	0	0x 0b, u jednoho qso je deklarován formálně správný, ale jinak chybný (loc neodpovídá zemi) rxloc (NN místo JN) a pro něj pts=5287 - iaru i črk započteno
127	0	1	0	1	1	1x +1b, u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí, v PExch data
128	7	0	7	0	0	0x 0b, u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí, v PExch data, u 4 qso posun txnr o +2, rozdíl mode/rst
129	0	0	0	0	0	0x 0b, u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí
130	0	0	0	0	0	0x 0b
131	0	0	0	0	0	0x 0b, deklarován odx 683km - deklarované i spočtené pts pro toto qso jsou 684, rozdíl mode/rst
132	138	132	138	132	132	132x +1b, zřejmě chybné zaokrouhlování - pokud se na srovnání vezme přepočet se zaokrouhlováním na sudo, tak rozdíly klesnou, v hlavičce jsou chybné názvy položek RAdr1, RAdr2 a MOpe2
133	-6	-7	-6	-7	-7	7x -1b
135	93	-19	-19	-19	-19	19x -1b, 1 dupl qso s pts=0 (112b) - iaru smazáno a črk započteno, rozdíl mode/rst
136	-2	-3	-2	-3	-3	3x -1b
137	1	0	1	0	0	0x 0b, u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí, v PExch data
138	86	-202	-4	-4	-4	4x -1b, 2 qso se špatným časem (198b), 1 dupl qso s pts=0 (90b) (složitější problém - dupl ke qso s chybným časem) - iaru smazáno črk započteno
139	-2	-2	-2	-2	-2	2x -1b, rozdíl mode/rst
140	90	0	0	0	0	0x 0b, 1 dupl qso s pts=0 (90b) - iaru smazáno a črk započteno, deklarován odx 737km - deklarované i spočtené pts pro toto qso jsou 738, rozdíl mode/rst, chybný formát SAntH
141	1104	0	20	0	0	0x 0b, 2 dupl qso s pts=0 (1084b) - iaru smazána, črk započtena, deklarován odx 1072km - deklarované i spočtené pts pro toto qso jsou 1073, rozdíl mode/rst
142	-32	-37	-32	-37	-37	37x -1b
143	-12	-7	-12	-7	-7	9x +/-1b
144	218	0	2	0	0	0x 0b, 3 qso deklarována s call=ERROR a pts=0 - iaru započteny s pts=56, 147 a 13, črk započteny s pts=56, 147 a 13, deklarován odx 762km - deklarované i spočtené pts pro toto qso jsou 763
145	3	4	3	4	4	4x +1b, u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí, v PExch data
146	0	0	0	0	0	0x 0b, v hlavičce je chybný formát údajů v položce TDate, u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí, v PExch data
147	-1	-1	-1	-1	-1	1x -1b
148	0	0	0	0	0	0x 0b, v PExch data
149	0	0	0	0	0	0x 0b
150	-4	0	-4	0	0	0x 0b, deklarován odx 824km - deklarované i spočtené pts pro toto qso jsou 825, rozdíl mode/rst
151	7	7	7	7	7	7x +1b, zřejmě chybné zaokrouhlování - pokud se na srovnání vezme přepočet se zaokrouhlováním na sudo, tak rozdíly klesnou k 0
Deníky u kterých nebyly pro porovnání k dispozici výsledky dle IARU
15	0	-	0	-	0	0x 0b
25	5727	-	-3	-	-2	10x +/-1b, chybný formát CDXCB a CDXCs
83	-2	-	-2	-	0	0x 0b, u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí, v PExch data
86	0	-	0	-	0	0x 0b, u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí
90	-1	-	-1	-	0	0x 0b, u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí
104	0	-	0	-	0	0x 0b
106	0	-	0	-	0	0x 0b
110	-1	-	-1	-	-1	1x -1b
113	4	-	4	-	0	0x 0b
123	-1	-	-1	-	0	0x 0b, u qso nejsou vyznačeny nové WWL, ale celkový počet WWL souhlasí
Deníky vyřazené z dalšího porovnávání kvůli zcela chybnému výpočtu nebo nekorektním opravám
22	-18	-15	-5	-15	-15	4x -1b, 2x +1b, u dalších dvou qso velký rozdíl (+5b, -18b), nesouhlasí součty v záhlaví se součtem pts u qso (zřejmě dodatečná změna rxloc v edi bez opravení součtů pts)
73	11133	11135	11133	11135	11135	u všech qso jsou body vypočteny podle pásem velkých WWL
88	12010	10610	12010	12006	12006	u qso jsou body vypočteny podle pásem velkých WWL, ale u 4 qso (160b, 143b, 406b a 687b) jsou spočteny podle km, nesouhlasí součty bodů i body u qso (zřejmě dodatečná změna rxloc v edi bez opravení součtů), u dotyčných 4 qso je chybné datum den po závodě - iaru smazáno, črk započteno, chybný formát SAntH
105	580	97	98	97	97	81x -1b, u dalších dvou qso velký rozdíl (+43b, -27b), zřejmě chybné zaokrouhlování - pokud se na srovnání vezme přepočet se zaokrouhlováním na sudo, tak rozdíly klesnou, 1 dupl qso s pts=0 (482b) - iaru smazáno a črk započteno, nesouhlasí součty v záhlaví (zřejmě dodatečná změna v edi bez opravení pts a součtů pts)
118	310	81	100	81	81	u 8 qso velký rozdíl (+2, -211, +18, +465, -31, -128, -47, +13b), 1 dupl qso s pts=0 (210b) - iaru smazáno a črk započteno, u 1 qso chybný formát rxrst - započteno iaru i črk, nesouhlasí body u 8 qso a součty pts s vypočtenými hodnotami (zřejmě dodatečná změna rxloc v edi bez opravení pts a součtů pts), v hlavičce není vyplněná položka CODXC, u qso nejsou vyznačeny nové WWL a nesouhlasí ani celkový počet WWL, rozdíl mode/rst
126	271	104	-4	104	104	8x -1b, u dalšího jednoho qso velký rozdíl (+108b), 1 dupl qso s pts=0 (167b) - iaru smazáno a črk započteno, nesouhlasí body u 1 qso a součty pts s vypočtenými hodnotami (zřejmě dodatečná změna rxloc v edi bez opravení pts a součtů pts), rozdíl mode/rst
134	-149	-	-149	-	-149	u 2 qso velký rozdíl (+41b, -190b), nesouhlasí body u 2 qso a součty pts s vypočtenými hodnotami (zřejmě dodatečná změna rxloc v edi bez opravení pts a součtů pts), v PExch data, u 1 qso chybný formát RXNR

Poznámky k tabulce

Než přejdu k porovnání výsledků, tak zde ještě shrnu některé poznatky získané při přípravě podkladů v předchozí tabulce.

Nejprve se znovu vrátím k duplicitním spojením. Robot IARU záznamy označené jako duplicitní spojení rovnou zahodí. Tj. pokud jste omylem označili jako duplicitní opačné spojení než vaše protistanice, tak o spojení přijdete, pokud se nejedná o případ, kdy se obě spojení vejdou do maximálního intervalu pro rozdíl v časech spojení a současně vám souhlasí takto do kříže i přijaté a vyslané údaje s protistanicí.

Robot ČRK spojení označené jako duplicitní nejprve započte jako platné s body dle údaje ve sloupci s přijatým lokátorem. Pokud není k dispozici log protistanice, tak je vám pak toto duplicitní spojení zase odečteno. Pokud log protistanice je k dispozici, tak vám je odečteno to spojení, které se nepodařilo s daty v logu protistanice spárovat (tj. když označíte omylem jako duplicitní opačné spojení než protistanice a přitom vám takto do kříže údaje souhlasí, tak je vám spojení označené původně jako duplicitní uznáno a odečteno naopak to druhé).

Tj. pozor na duplicitní spojení. U IARU můžete při chybném označení o spojení úplně přijít. U ČRK může robot vaši chybu v označení vyretušovat, ale zase vám zde bude každé duplicitní spojení zkreslovat celkovou chybovost.

U záznamů označených jako chybné textem "ERROR" ve sloupci pro značku a bodovou hodnotou 0 vám roboti ČRK i IARU takové spojení nejprve započtou s body určenými dle údaje ve sloupci s přijatým lokátorem, a to i v případě, že je tento sloupec prázdný. U nevyplněného lokátoru vypočte IARU bodovou hodnotu jako 1, u ČRK to záleží na vašem QTH - dosazená bodová hodnota bude u stanic v oblasti naší republiky přes 5 tisíc bodů. Při křížové kontrole vám pak tyto body budou zase odečteny, ale u ČRK se vám započtou do celkové chybovosti.

Při zpracování logů jsem myslím nepotkal třetí variantu chybného spojení, tj. nekompletní spojení s vyplněnou značkou a body nastavenými na 0, tj. nevím, jak oba roboti postupují v tomto případě. Ale pro dva výše uvedené případy je jasné, že vám to u ČRK vždy zkreslí chybovost a jediná možnost, která mě napadá, jak by se dalo takovému ovlivnění chybovosti vyhnout, je dát do přijatého lokátoru takový, kde budou uměle dosazené body nejmenší, tj. dát tam vlastní lokátor, který je za 1 bod. Druhá možnost je takovéto chybové záznamy v deníku vůbec nemít, jenže tomu se člověk někdy nevyhne.

Oba roboti, ale v daném případě i program, který vytvářel jeden ze souborů EDI, byly podivně benevolentní ke zcela zřejmému nevalidnímu formátu lokátoru. Stanice měla překlep v přijatém lokátoru, záměna písmene O za nulu (místo JO.... zapsáno J0....). Program vytvářející soubor EDI do něho spojení zapsal jako platné s bodovou hodnotou 1. Robot IARU ho nejprve také započetl, a také s bodovou hodnotou 1, ale nakonec spojení konečně vyřadil kvůli chybě v lokátoru. Robot ČRK spojení započetl s bodovou hodnotou přes 5 tisíc bodů a pak ho vyřadil s důvodem, že údaj nesouhlasil s údajem protistanice, a že si neodpovídala kombinace země a lokátoru.

Pokud uděláte chybu v číslování a některé číslo spojení omylem přeskočíte, tak se nic neděje a oba roboti spojení uznají, samozřejmě jen když souhlasí vaše údaje s údaji od protistanice.

Pokud vám v záznamu spojení chybí některé údaje, např. RXNR, tak robot IARU obvykle spojení rovnou zahodí a tento záznam se vůbec neobjeví ve výpisu spojení a není započten. Robot ČRK takovéto spojení nejprve započte, a až pak vyřadí. Občas jsem přemýšlel, proč vlastně dotyčný logovací program při exportu do EDI některé nekompletní nebo i zjevně chybné údaje pustil dál a neřval hned na obsluhu, že jsou v datech chyby. Stanice zbytečně přišly o body za dotyčná spojení. Některé z těch chyb by šlo snadno odhalit, stačilo by kontrolovat alespoň formální správnost údajů v jednotlivých sloupcích před vyexportováním do EDI. Viděl jsem třeba přijaté údaje, které se posunuly o sloupec vlevo, apod.

Spojení, u kterých nejde čas po sobě vzestupně, robot IARU rovnou vyřadí a nezapočte. Robot ČRK je v tomto benevoletnější, spojení nejprve započte a pak záleží na tom, co měla v deníku vaše protistanice. Když vám souhlasí spárované údaje a vejdete se do maximálního časového intervalu pro rozdíl v časech spojení, tak vám spojení bude uznáno, a to i v případě, že se např. jedná o záznamy, které byly v deníku přesunuty zcela na jiné místo, než by chronologicky měly být zařazeny. U robota IARU jsem potkal jeden zajímavý případ spojení, kde šla zasebou spojení s časem 9:27, 10:16, 10:11 a 10:34. Chybné bylo spojení v 10:11, kde byl překlep v čase a protistanice udávala 10:22, a ostatní spojení byla vpořádku a souhlasila s daty v denících protistanic. Robot ČRK vyřadil spojení v 10:11 kvůli chybě při spárování času, ale robot IARU z nějakých důvodů rovnou vyřadil (takže obě nebyla vůbec uvedena v seznamu spojení) jak spojení v 10:16, tak i v 10:11. A to byla jediná věc z těch všech projítých logů, kde jsem nedokázal přijít na důvod vyřazení spojení v 10:16. Snad to nějak souviselo s 6H kategorií, do které ten log spadal, ale ani pravidla pro 6H mi to nedokázala osvětlit. Spojení v logu je tedy potřeba mít seřazena chronologicky vzestupně, jinak narazíte u robota IARU, a obecně je dobré se vyvarovat překlepům v časech spojení, člověk může přijít i o více než jen o to jedno spojení.

Spojení s časem mimo dobu závodu ČRK napřed započte a pak vyřadí. IARU je rovnou zahodí. Je odlišný přístup robotů k času ukončení závodu. Zatímco IARU vám spojení udělaná druhý den závodu ve 14:00 zahodí, tak ČRK ho uzná.

U reportů musí souhlasit první dva znaky, na třetí se nehledí. Taktéž nějaká vazba mezi zadaným druhem provozu CW, SSB, CW/SSB nebo SSB/CW a tvarem poslaného a přijatého reportu RS nebo RST se zřejmě (naštěstí) nehlídá.

V denících EDI byly občas chyby v samotném formátu, jako záměny malých a velkých písmen v názvech položek hlavičky a nekompletní vyplnění údajů, nebo vyplnění údajů, které stanice ve skutečnosti v daném typu závodu vůbec nepředávala, nicméně oba roboti jsou k tomu zřejmě dost benevolentní.

Některé stanice spočítaly log místo podle kilometrů podle pásem velkých lokátorů, v jednom případě to bylo vylepšené následnými opravami udělanými asi až dodatečně po závodě, kdy tato spojení byla prozměnu vypočtena podle kilometrů. Zásahy provedené v lozích dodatečně až po vygenerování EDI souboru jsem viděl ve více případech a byla to jedna z příčin, která mi hlavně zpočátku stěžovala provední porovnání, protože nebyly korektně opraveny všechny údaje a objevovaly se mi tam pak veliké rozdíly mezi výpočty, u kterých bylo potřeba dohledat důvod a nějak je ošetřit. Část takovýchto logů jsem musel nakonec z dalšího porovnání úplně vyřadit.

Zajímavé byly některé odlišnosti logovacích programů ve vyplnění některých údajů v souboru EDI. Např. některé programy do hlavičky EDI uváděly počet WWL, takže je počítaly, ale v záznamech spojení už nové WWL neoznačovaly. To samozřejmě není chyba, jelo se na kilometry bez násobičů dle WWL. Nebo některé programy uváděly vzdálenost ODX dle bodů u dotyčného spojení, tj. zaokrouhlenou dle IARU, a jiné pro ODX extra vypočítávaly jiným způsobem zaokrouhlenou vzdálenost, apod.

Při porovnání deklarovaných údajů v EDI s výpočtem programu Loc jsem se mohl dívat nejen na rozdíly v celkových vypočtených bodech, ale i na rozdíly u jednotlivých spojení. Po odstranění vlivu různých už výše popsaných problémů byly odchylky vesměs jen ±1bod u menšího počtu spojení, ale u některých logů jich bylo více, někdy byly až u skoro poloviny spojení. Zkusil jsem tedy přepočítávat deníky s různým nastavením programu Loc, zda se mi nepodaří přijít na postup, jak byly dané deníky spočteny. A samozřejmě jsem se hned zaměřil na způsob zaokrouhlování a byla to trefa do černého. Když se některé z těchto logů přepočítaly se zaokrouhlováním nasudo, tak rozdíly klesly k nule nebo se výrazně snížily. Nutno dodat, že tento problém se týkal vesměs logů, u kterých nebyla k dispozici informace o logovacím programu, u známých programů takové odchylky většinou nebyly.

Porovnání souhrnných výsledků

Je diskutabilní říci, že některý z výsledků výpočtů je zrovna správný a některý zrovna chybný, jen na základě takovéhoto jednoduchého porovnávání údajů, na to by byl potřeba referenční program, který by prošel nejlépe nějakým odborným auditem, co se stránky přesnosti týče, včetně porovnání jeho výstupů s nějakými jinými ověřenými referenčními údaji. Ale můžeme si alespoň porovnat výstupy různých logovacích programů s výsledky počítanými ČRK a IARU a získat představu, jak se s těmito dvěma vyhodnocovateli logovací programy shodují, a zda je zde nějaká větší skupina programů, které dávají podobné výstupy.

S výjimkou programu Loc, kterým jsem mohl přepočítat všechny logy, tak ostatní logovací programy počítaly jen určité omezené množství logů. Ve srovnání je potřeba si tedy uvědomit, že když byl programem spočten pouze jediný log a shodou okolností se tento výsledek shodoval, tj. v tabulce je vykázána shoda 100%, tak je to údaj zatížený velikou chybou, stačí např. aby stejný program spočítal ještě jeden log a u něj se výsledek prozměnu zase neshodoval a hned jsme na 50%. Tj. relevantnější jsou výsledky porovnání u těch programů, kterými bylo spočteno větší množství logů.

Ve výše uvedené tabulce už je vidět, že výsledky vyhodnocovacích programů ČRK a IARU se od sebe mírně liší a je větší shoda mezi výstupy části logovacích programů s výsledky IARU než mezi logovacími programy a ČRK. Lépe to bude vidět v následujících dvou tabulkách. V nich jsou data z předchozí tabulky shrnuta tak, že je uvedeno u kolika deníků se deklarovaný výsledek v EDI spočtený logovacím programem shodoval s korigovaným výpočtem spočteným programem ČRK resp. IARU. Pro každý logovací program je dále vyčísleno kolik deníků bylo celkem tímto programem zpracováno a kolik procent z nich se s ČRK resp. IARU shodovalo. Data jsou pak seřazena podle této procentní hodnoty shody. Pro program Loc jsou zde uvedeny výsledky se dvěma nastaveními - podbarveno je jeho defaultní nastavení s algoritmem 2 pro výpočet vzdálenosti a druhé nastavení bylo s algoritmem 1 pro výpočet vzdálenosti.

První tabulka porovnává výstupy logovacích programů a robota ČRK. Je tady už dobře vidět, že mezi logovacími programy a ČRK nějaká extra veliká shoda nepanuje. A jsou i dost rozdíly mezi procentní shodou u jednotlivých logovacích programů. Zkoušel jsem různě měnit nastavení programu Loc i včetně některých modifikací programového kódu nad rámec toho, co jde změnit jen nastavením, ale nenašel jsem žádnou variantu, kde bych mohl říci, že jsem se s robotem ČRK zcela shodnul.

Shoda logů s výpočtem ČRK

Logname	Logů	Shoda s ČRK	Rozdíl s ČRK	Shoda %
Minos	1	1	0	100
Online EDI Generator ok2kjt.net	8	6	2	75
VHFCtest4Win	2	1	1	50
KJTlog	14	6	8	43
TUCNAK-linux	8	3	5	38
LOC gcsalg2 kmalg1 precs64	144	53	91	37
LOC gcsalg2 kmalg2 precs64	144	53	91	37
Win-Test	3	1	2	33
TUCNAK-msvc	10	3	7	30
neuvedeno	30	8	22	27
MOONlog	6	1	5	17
DXLog.net	7	1	6	14
VUSC	29	4	25	14
Atalanta Locator	24	1	23	4
HamRacer	2	0	2	0

Druhá tabulka porovnává výstupy logovacích programů s robotem IARU. Je v ní vidět, že je zde docela veliká skupina logovacích programů, které se dobře shodují s výstupem IARU. A procentní shoda mezi těmito logovacími programy je také dost podobná. Tj. vypadá to, že výpočty těchto programů jsou prováděny velmi shodným postupem a výsledky z nich obdržené se budou také velmi dobře shodovat. Nelze sice vyloučit, že ve skutečnosti akorát všechny tyto programy počítají body stejně špatně jako IARU, nicméně ta konzistence ve shodě mě přesvědčuje, že to je spíše důsledek toho, že se robot IARU a tyto logovací programy blíží správnému výsledku. Zkoušel jsem zase experimentovat s nastavením programu Loc a zkusil odhadnout, jakým způsobem body počítá robot IARU - při nastavení algoritmu 1 pro výpočet vzdálenosti a při dvojité přesnosti čísel s plovoucí řádovou čárkou jsem se shodnul s robotem IARU u úplně všech logů, s alogoritmem 2 jsem se u jednoho logu neshodnul.

Shoda logů s výpočtem IARU

Logname	Logů s IARU daty	Shoda s IARU	Rozdíl s IARU	Shoda %
LOC gcsalg2 kmalg1 precs64	134	134	0	100
DXLog.net	7	7	0	100
Online EDI Generator ok2kjt.net	6	6	0	100
Win-Test	3	3	0	100
VHFCtest4Win	2	2	0	100
LOC gcsalg2 kmalg2 precs64	134	133	1	99
KJTlog	12	11	1	92
TUCNAK-msvc	10	9	1	90
TUCNAK-linux	8	7	1	88
neuvedeno	27	14	13	52
Atalanta Locator	24	4	20	17
VUSC	28	2	26	7
MOONlog	6	0	6	0
HamRacer	1	0	1	0

Porovnání výpočtů na úrovní jednotlivých spojení

Výše uvedené porovnání je ošemetné v tom, že se pracuje jen se součty bodů za všechna spojení. Tj. když u jednoho spojení bude hodnota jiná o +1 bod a u druhého o -1 bod, tak v součtu je rozdíl 0. Zkusil jsem proto udělat ještě jedno detailnější srovnání výsledků logovacích programů, které by toto možné vynulování některých rozdílů eliminovalo. Ale protože jsem neměl z vyhodnocovacích robotů k dispozici kompletní údaje o vypočtených bodech u jednotlivých spojení, tak jsem mohl porovnat deklarované údaje z logů jen s výpočtem programu Loc. Ten jsem přitom nastavil do režimu co nejvíce shodného s výpočtem vyhodonocovacího programu IARU, tj. na použití čísel s dvojitou přesností a na algoritmus 1 na výpočet vzdálenosti. Při porovnání jsem pak počítal u kolika záznamů spojení v daném logu se body vypočtené programem Loc neshodovaly s deklarovnými body. V HTML níže z toho zde uvedu jen výslednou sumární tabulku, ale kompletní tabulku ve formátu CSV s údaji rozpracovanými až na jednotlivé logy si můžete stáhnout zde:

cmplogdifnr.csv (4kB)

Ve sloupci Log je v ní označení logu náhodným číslem (shodné s označením logů v tabulce s výsledky porovnání pro jednotlivé deníky výše), ve sloupci LogName je název logovacího programu, ve sloupci QsoRec je celkový počet záznamů spojení v dotyčném logu a ve sloupci DifNr je počet záznamů v tomto logu, u kterých se bodová hodnota spojení vypočtená logovacím programem neshodovala s výpočtem programu Loc s výše popsaným nastavením.

V tabulce níže pak najdete tytéž hodnoty sumarizované podle jednotlivých logovacích programů. Seřazeny jsou podle procentní hodnoty získané podělením počtu záznamů, u kterých byl zjištěn rozdíl, počtem všech záznamů zpracovaných daným logovacím programem.

Porovnání podle rozdílů u jednotlivých spojení

LogName	QsoRec	DifNr	DifNr %
DXLog.net	1860	0	0,000
Win-Test	950	0	0,000
Online EDI Generator ok2kjt.net	370	0	0,000
Minos	52	0	0,000
VHFCtest4Win	25	0	0,000
TUCNAK-msvc	3590	1	0,028
KJTlog	2072	1	0,048
TUCNAK-linux	1199	1	0,083
Atalanta Locator	4017	176	4,381
VUSC	4068	239	5,875
MOONlog	172	12	6,977
neuvedeno	3905	557	14,264
HamRacer	488	152	31,148

V tabulce je vidět, že ikdyž se na porovnání místo sumárních údajů za celé logy vezmou detailnější údaje o rozdílech výpočtů u jednotlivých spojení, tak to vychází opět velmi podobně jako při porovnávání souhrnných údajů s robotem IARU výše. Oproti robotu ČRK jsem to takto porovnat nemohl, protože jsem nenašel takové nastavení programu Loc, které by se s výstupem ČRK shodovalo, a dalo by se tedy jako referenční použít.

Porovnání s výsledky různých algoritmů výpočtu

Výše jsem už párkráte zmiňoval, že jsem prováděl porovnání výsledků s různým nastavením programu Loc. Zde jsou z toho nějaké výstupy. První porovnání bylo prováděno mezi výstupem různě nastaveného programu Loc a údaji deklarovanými v původním EDI souboru, spočtenými ČRK a spočtenými IARU. Celkem existovalo 42 sad nastavení:

Použité sady nastavení pro program Loc

Sada	GcsAlg	KmAlg	Precs	Round
01	1old	1	64	iaru
02	1old	2	64	iaru
03	1	1	32	iaru
04	1	1	64	iaru
05	1	1	80	iaru
06	1	1	128	iaru
07	1	2	32	iaru
08	1	2	64	iaru
09	1	2	80	iaru
10	1	2	128	iaru
11	1	3	32	iaru
12	1	3	64	iaru
13	1	3	80	iaru
14	1	3	128	iaru
15	2	1	32	iaru
16	2	1	64	iaru
17	2	1	80	iaru
18	2	1	128	iaru
19	2	2	32	iaru
20	2	2	64	iaru
21	2	2	80	iaru
22	2	2	128	iaru
23	2	3	32	iaru
24	2	3	64	iaru
25	2	3	80	iaru
26	2	3	128	iaru
27	1	1	32	oth
28	1	1	64	oth
29	1	2	32	oth
30	1	2	64	oth
31	2	1	32	oth
32	2	1	64	oth
33	2	2	32	oth
34	2	2	64	oth
35	1	1	32	km
36	1	1	64	km
37	1	2	32	km
38	1	2	64	km
39	2	1	32	km
40	2	1	64	km
41	2	2	32	km
42	2	2	64	km

Údajů z toho porovnání bylo veliké množství, a když jsem se na ně podíval, tak se ukázalo, že rozdíly výsledků mezi nastaveními gcsalg1, gcsalg1old a gcsalg2 jsou naprosto minoritní. V sadách 27 až 42 to žádné rozdíly nezpůsobovalo a u sad 1 až 26 se díky tomu lišily výsledky jen asi u 3 logů a to vždy jen u jednoho spojení a rozdíl byl 1 bod, takže jsem nakonec pro porovnání pro zjednodušení použil jen výsledky ze sad s nastavením gcsalg2, tj. sady 15 až 26, 31 až 34 a 39 až 42, tj. celkem 20 sad nastavení. Z toho sadu 16, která měla výsledky nejvíce shodné s IARU, jsem používal jako referenční, a řádek s ní je pak v tabulkách níže podbarvený.

Když jsem hledal rozdíly mezi výpočty dle algoritmů gcsalg1, gcsalg1old a gcsalg2 tak bylo zajímavé, že u dvou z celkem nalezených tří záznamů se rozdíl týkal případu, kdy vzdálenost vycházela shodně 139km, a u toho třetího záznamu to bylo 417km, tj. přesně trojnásobek hodnoty 139km, přitom se jednalo o tři dvojice zcela různých lokátorů. A když jsem dohledával při porovnání výsledků programu Loc s výpočtem IARU vzniklý jediný jednobodový rozdíl mezi výpočty s nastavením kmalg1 a kmalg2, tak to zrovna opět byl záznam spojení shodný s jedním z předchozích tří a zase se jednalo o vzdálenost 139km.

Algoritmus kmalg1 výpočtu vzálenosti je klasický výpočet dle sférického trojúhelníku, algoritmus kmalg2 je přesnější výpočet, ale též na kouli. Algoritmus kmalg3 je pak iterační výpočet na elipsoidu. Přesnosti precs32, 64, 80 a 128 udávají použitou přesnost čísel v plovoucí řádové čárce v bitech. Zaokrouhlovací algoritmus roundiaru je zaokrouhlení dle IARU, roundoth je obdobný postup, ale provedený naopak - napřed přičtením 1.0 a pak oříznutím na celé číslo, a roundkm je zaokrouhlení nasudo. Algoritmy gcsalg1, gcsalg1old a gcsalg2 udávají způsob převodu lokátorů na souřadnice, kde gcsalg1old znamená starší postup dle programu Loc 2.2 s postupným sčítáním čísel v plovoucí řádové čárce a nepatrným posunutím souřadnic o hodnotu zajišťující korektní zpětný převod ze souřadnic na lokátory, algoritmus gcsalg1 je stejný postup, ale bez tohoto malého posunutí souřadnic, a gcsalg2 je postup převodu se sčítáním nejprve celých čísel a až finálním převodem na čísla v plovoucí řádové čárce. Více informací k těmto nastavením najdete výše v částí zabývající se převody souřadnic na lokátory a výpočty vzdáleností a v popisu programu Loc 2.3.

Z tohoto porovnání zde níže ve formě HTML opět uvedu jen sumární tabulky upravené tak, aby se vešly na šířku stránky, a podrobnější údaje, na základě kterých byly vytvořeny, je možné si stáhnout z následujících odkazů ve formě souborů CSV se sloupci oddělenými znakem středník. Tabulka cmpmtd1 obsahuje data za jednotlivé logy a tabulka cmpmtd1sum pak jejich souhrn podle jednotlivých sad nastavení. V této druhé tabulce jsou některé procentní údaje uloženy jako čísla s desetinnými místy, takže ke stažení ji zde dávám ve dvou tvarech těchto čísel - s desetinnou čárkou nebo s desetinnou tečkou:

cmpmtd1.csv (64kB)

cmpmtd1sum-comma.csv (desetinná čárka, 3kB)

cmpmtd1sum-dpoint.csv (desetinná tečka, 3kB)

První 4 řádky tabulky cmpmtd1 obsahují informace nastavení programu Loc pro vypočtené hodnoty ve sloupcích 6 a dále. Sloupec Log je opět označení deníku náhodným číslem (shodným s číslem použitým v předchozích tabulkách), sloupec EDI rec udává počet záznamů v dotyčném logu, sloupec EDI pts deklarovaný součet bodů v logu, sloupec CRK pts korigovaný vypočtený součet dle ČRK a sloupec IARU pts korigovaný vypočtený součet dle IARU. Pak následují sloupce DifNr, PtsSum, Rtime, DifEDIpts, DifCRKpts a DifIARUpts s vypočtenými hodnotami. Pro každou tuto hodnotu je zde celkem 20 různých výsledků pro různé sady nastavení a jsou označeny číslem této sady. Hodnota DifNr udává u kolika záznamů spojení se vypočtené body lišily od deklarované hodnoty, hodnota PtsSum udává vypočtený celkový součet bodů, hodnota DifEDIpts je rozdíl mezi PtsSum a EDI pts, hodnota DifCRKpts je rozdíl mezi PtsSum a CRK pts a hodnota DifIARUpts je rozdíl PtsSum a IARU pts. Poslení dva řádky tabulky SumAll a SumIsIaru jsou součty údajů v daném sloupci, kde první udává součet za všechny záznamy a druhý jen za záznamy, u kterých byly k dispozici data z vyhodnocení IARU. Sloupec Rtime udává dobu zpracování daného logu v milisekundách. Tady musím upozornit, že doba zpracování je jen orientační, je to údaj kvantovaný po určitých krocích, časy kratší než 1ms nebyly rozlišovány, a není to jen doba samotného výpočtu, ale zahrnuje celý proces zpracování logu včetně načtení dat a jejich uložení.

Tabulka cmpmtd1sum obsahuje údaje z předchozí tabulky sumarizované podle sad nastavení. Je rozdělena na tři části. První čtyři sloupce obsahují údaje o dané sadě nastavení. Pak následují sloupce s údaji sečtenými za všechny záznamy a nakonec sloupce, kde jsou součty jen za záznamy, u kterých byly k dispozici i údaje z vyhodnocení IARU. Význam sloupců je shodný s tabulkou cmpmtd1, akorát sloupce DifEDIpts, DifCRKpts a DifIARUpts jsou nyní označeny jen jako DifEDI, DifCRK a DifIARU, a dále jsou nyní vyčísleny i procentní hodnoty - sloupec DifNr % je podíl sloupců DifNr a EDI rec, sloupce DifEDI % je podíl sloupců DifEDI a EDI pts, sloupec DifCRK % je podíl sloupců DifCRK a CRK pts a sloupec DifIARU % je podíl sloupců DifIARU a IARU pts.

Jako první výstup zde uvedu porovnání rozdílů výpočtů u jednotlivých spojení mezi výstupy různě nastaveného programu Loc a body deklarovanými u jednotlivých spojení v EDI souborech. Data jsou seřazena podle údajů ve sloupci DifNr %.

Porovnání sad podle rozdílů u jednotlivých spojení

Set	KmAlg	Precs	Round	EDI rec	DifNr	DifNr %
21	2	80	iaru	22768	1137	4,99
22	2	128	iaru	22768	1137	4,99
17	1	80	iaru	22768	1138	5,00
20	2	64	iaru	22768	1138	5,00
34	2	64	oth	22768	1138	5,00
16	1	64	iaru	22768	1139	5,00
18	1	128	iaru	22768	1139	5,00
32	1	64	oth	22768	1139	5,00
19	2	32	iaru	22768	1140	5,01
33	2	32	oth	22768	1140	5,01
15	1	32	iaru	22768	1295	5,69
31	1	32	oth	22768	1295	5,69
23	3	32	iaru	22768	9411	41,33
24	3	64	iaru	22768	9414	41,35
25	3	80	iaru	22768	9414	41,35
26	3	128	iaru	22768	9414	41,35
40	1	64	km	22768	11663	51,23
41	2	32	km	22768	11667	51,24
42	2	64	km	22768	11669	51,25
39	1	32	km	22768	11730	51,52

Je zde vidět, že pro algoritmy výpočtu vzdálenosti 1 a 2 při zaokrouhlování dle IARU nebo i opačným způsobem, než se má dle IARU provádět, jsou pro přesnosti čísel 64, 80 a 128 výstupy skoro shodné. Pro přesnost 32bitů jsou rozdíly jen nepatrně větší. Pro algoritmus výpočtu vzdálenosti 3, kdy se vzdálenost nepočítá na kouli, ale na elipsoidu, se počet rozdílů výrazně zvýší na asi 40%, a nejvíce rozdílů, kolem 50%, pak vzniká v případě, kdy se vzdálenosti zaokrouhlují nasudo.

V další tabulce si můžeme znovu porovnat výsledky výpočtů s různými nastaveními s hodnotami deklarovanými v EDI souborech, ale nyní nikoliv podle dílčích rozdílů u jednotlivých spojení, ale podle rozdílů v celkových součtech bodů. Ve sloupci EDI pts je součet bodů z logů, ve sloupci PtsSum součet bodů za stejné logy s daným nastavením výpočtu, ve sloupci DifEDI je rozdíl těchto hodnot a ve sloupci DifEDI % je podíl sloupců DifEDI a EDI pts. Data jsou seřazena podle sloupce DifEDI %.

Porovnání sad podle součtů bodů s deklarovanými údaji

Set	KmAlg	Precs	Round	EDI pts	PtsSum	DifEDI	DifEDI %
39	1	32	km	6205314	6193788	-11526	-0,185744
42	2	64	km	6205314	6193850	-11464	-0,184745
41	2	32	km	6205314	6193852	-11462	-0,184713
40	1	64	km	6205314	6193856	-11458	-0,184648
15	1	32	iaru	6205314	6205248	-66	-0,001064
31	1	32	oth	6205314	6205248	-66	-0,001064
17	1	80	iaru	6205314	6205313	-1	-0,000016
19	2	32	iaru	6205314	6205313	-1	-0,000016
33	2	32	oth	6205314	6205313	-1	-0,000016
16	1	64	iaru	6205314	6205314	0	0,000000
18	1	128	iaru	6205314	6205314	0	0,000000
21	2	80	iaru	6205314	6205314	0	0,000000
32	1	64	oth	6205314	6205314	0	0,000000
20	2	64	iaru	6205314	6205315	1	0,000016
34	2	64	oth	6205314	6205315	1	0,000016
22	2	128	iaru	6205314	6205316	2	0,000032
23	3	32	iaru	6205314	6215748	10434	0,168146
24	3	64	iaru	6205314	6215750	10436	0,168178
25	3	80	iaru	6205314	6215750	10436	0,168178
26	3	128	iaru	6205314	6215750	10436	0,168178

V tabulce je vidět, že rozdíly v celkových součtech jsou ve skutečnosti velmi malé. Při chybném zaokrouhlování nasudo (roundkm) vychází deklarované body viditelně nadhodnocené. Při algoritmu kmalg1 a nízké přesnosti čísel 32bit jsou výsledky v EDI také o něco nadhodnocené. Pro ostatní nastavení rozdíly klesnou na zcela mizovou hodnotu, s výjimkou výpočtu dle kmalg3 na elipsoidu, kde dle očekávání jsou výsledky v EDI naopak podhodnocené.

Následující tabulka pak porovnává vypočtené součty bodů při různých nastaveních s výsledky vypočtenými ČRK. Výstup je podobný jako předchozí, akorát je vidět, že ta část nastavení, která se v předchozí tabulce takřka shodovala s deklarovanými daty, tak má nyní rozdíly maličko větší, ale celkově jsou rozdíly zase velmi malé, někde na úrovni tisícin procenta.

Porovnání sad podle součtů bodů s výpočtem ČRK

Set	KmAlg	Precs	Round	CRK pts	PtsSum	DifCRK	DifCRK %
39	1	32	km	6205538	6193788	-11750	-0,189347
42	2	64	km	6205538	6193850	-11688	-0,188348
41	2	32	km	6205538	6193852	-11686	-0,188316
40	1	64	km	6205538	6193856	-11682	-0,188251
15	1	32	iaru	6205538	6205248	-290	-0,004673
31	1	32	oth	6205538	6205248	-290	-0,004673
17	1	80	iaru	6205538	6205313	-225	-0,003626
19	2	32	iaru	6205538	6205313	-225	-0,003626
33	2	32	oth	6205538	6205313	-225	-0,003626
16	1	64	iaru	6205538	6205314	-224	-0,003610
18	1	128	iaru	6205538	6205314	-224	-0,003610
21	2	80	iaru	6205538	6205314	-224	-0,003610
32	1	64	oth	6205538	6205314	-224	-0,003610
20	2	64	iaru	6205538	6205315	-223	-0,003594
34	2	64	oth	6205538	6205315	-223	-0,003594
22	2	128	iaru	6205538	6205316	-222	-0,003577
23	3	32	iaru	6205538	6215748	10210	0,164530
24	3	64	iaru	6205538	6215750	10212	0,164563
25	3	80	iaru	6205538	6215750	10212	0,164563
26	3	128	iaru	6205538	6215750	10212	0,164563

Ještě si můžeme udělat obdobné porovnání, ale oproti IARU. Další tabulka tedy porovnává vypočtené součty bodů při různých nastaveních s výsledky vypočtenými IARU. A výstup je zase podobný jako oba předchozí, jen oproti srovnání s ČRK jsou rozdíly zase maličko menší.

Porovnání sad podle součtů bodů s výpočtem IARU

Set	KmAlg	Precs	Round	IARU pts	PtsSum	DifIARU	DifIARU %
39	1	32	km	6032458	6021287	-11171	-0,185182
42	2	64	km	6032458	6021348	-11110	-0,184170
41	2	32	km	6032458	6021350	-11108	-0,184137
40	1	64	km	6032458	6021354	-11104	-0,184071
15	1	32	iaru	6032458	6032390	-68	-0,001127
31	1	32	oth	6032458	6032390	-68	-0,001127
17	1	80	iaru	6032458	6032457	-1	-0,000017
19	2	32	iaru	6032458	6032457	-1	-0,000017
33	2	32	oth	6032458	6032457	-1	-0,000017
16	1	64	iaru	6032458	6032458	0	0,000000
18	1	128	iaru	6032458	6032458	0	0,000000
21	2	80	iaru	6032458	6032458	0	0,000000
32	1	64	oth	6032458	6032458	0	0,000000
20	2	64	iaru	6032458	6032459	1	0,000017
34	2	64	oth	6032458	6032459	1	0,000017
22	2	128	iaru	6032458	6032460	2	0,000033
23	3	32	iaru	6032458	6042596	10138	0,168058
24	3	64	iaru	6032458	6042598	10140	0,168091
25	3	80	iaru	6032458	6042598	10140	0,168091
26	3	128	iaru	6032458	6042598	10140	0,168091

Následující tabulka porovnává dobu zpracování logů mezi jednotlivými sadami nastavení. Čas je uveden v milisekundách. Jak jsem již uvedl výše, hodnoty nezahrnují jen samotnou dobu výpočtu a jsou jen orientační, ale je vidět, že počítat vzdálenosti na elipsoidu anebo s přesností čísel 128bitů zabere dle očekávání přeci jen o něco více času.

Srovnání doby zpracování jednotlivých sad

Set	KmAlg	Precs	Round	Rtime
41	2	32	km	16828
40	1	64	km	17045
16	1	64	iaru	17400
42	2	64	km	17560
20	2	64	iaru	17577
21	2	80	iaru	17639
33	2	32	oth	17716
24	3	64	iaru	17717
34	2	64	oth	17924
32	1	64	oth	18008
19	2	32	iaru	18036
17	1	80	iaru	18338
39	1	32	km	18616
25	3	80	iaru	19053
31	1	32	oth	19088
18	1	128	iaru	19508
15	1	32	iaru	20435
23	3	32	iaru	20536
22	2	128	iaru	22124
26	3	128	iaru	24071

Porovnání výsledků různých algoritmů výpočtu mezi sebou

Poslední porovnání se týká srovnání jednotlivých algoritmů výpočtu mezi sebou. Při něm jsem se chtěl zbavit vlivu logovacích programů na výsledky, protože při výše prováděných srovnáních byly detailní výpočty pro jednotlivá spojení s různými algoritmy programu Loc porovnávány s hodnotami z původních logů, které byly pro různé logy počítány různými programy různým postupem. Tj. nyní jsem si nejprve programem Loc přepočítal logy tak, abych získal jednotným způsobem vypočtenou výchozí hodnotu, a tu jsem pak porovnával s výsledky výpočtů s jiným nastavením. Pro stanovení výchozí hodnoty jsem použil nastavení programu Loc tak, aby dával výsledky co nejvíce shodné s robotem IARU, tj. nastavení gcsalg2, kmalg1, precs64 a roundiaru (zde v tabulkách uváděné jako sada nastavení číslo 16).

Celou tabulku s daty rozpracovanými na úroveň jednotlivých logů si můžete stáhnout ve formě souboru CSV zde:

cmpmtd2.csv (41kB)

První 4 řádky v této tabulce opět shrnují nastavení výpočtu pro jednotlivé sloupce hodnot. Sloupec Log opět označuje log náhodným číslem shodným s předchozími tabulkami. Sloupec QsoVal udává počet záznamů s platnými spojeními, sloupec DifNr udává počet spojení, u kterých byl rozdíl v bodové hodnotě, sloupec DifSum obsahuje součet rozdílů za všecha spojení, sloupec DifMin udává nejmenší bodový rozdíl, který byl u spojení zjištěn, a sloupec DifMax naopak největší bodový rozdíl. Vypočtené hodnoty jsou vždy porovnávány s hodnotami výpočtu dle sady 16. Na posledním řádku tabulky jsou pak součty jednotlivých sloupců.

Z těchto dat pak byla sestavena následující sumární tabulka se součty za jednotlivé sady nastavení. Sloupec DifNr % je vypočten jako podíl sloupce DifNr a sloupce QsoVal. Data jsou seřazena dle hodnot ve sloupci DifSum. Referenční sada 16 je v tabulce podbarvena.

Porovnání sad mezi sebou

Set	KmAlg	Precs	Round	QsoVal	DifNr	DifNr %	DifSum	DifMin	DifMax
39	1	32	km	23889	12108	50,684	-12108	-1	0
42	2	64	km	23889	12040	50,400	-12040	-1	0
41	2	32	km	23889	12038	50,391	-12038	-1	0
40	1	64	km	23889	12034	50,375	-12034	-1	0
15	1	32	iaru	23889	219	0,917	-75	-1	1
31	1	32	oth	23889	219	0,917	-75	-1	1
17	1	80	iaru	23889	1	0,004	-1	-1	0
16	1	64	iaru	23889	0	0,000	0	0	0
18	1	128	iaru	23889	0	0,000	0	0	0
32	1	64	oth	23889	0	0,000	0	0	0
21	2	80	iaru	23889	2	0,008	0	-1	1
19	2	32	iaru	23889	6	0,025	0	-1	1
33	2	32	oth	23889	6	0,025	0	-1	1
20	2	64	iaru	23889	1	0,004	1	0	1
34	2	64	oth	23889	1	0,004	1	0	1
22	2	128	iaru	23889	2	0,008	2	0	1
23	3	32	iaru	23889	9825	41,128	11033	-1	3
24	3	64	iaru	23889	9829	41,144	11036	-1	3
25	3	80	iaru	23889	9829	41,144	11036	-1	3
26	3	128	iaru	23889	9829	41,144	11036	-1	3

Výsledek porovnání je podobný jako ve výše uvedených srovnáních. Při použití chybného zaokrouhlování nasudo (roundkm) je u skoro poloviny záznamů bodová hodnota o 1 bod menší než referenční. Méně přesný algoritmus výpočtu vzdáleností 1 spolu s přesností čísel v plovoucí řádové čárce vede na menší, ale viditelný počet odchylek bodů u spojení o ±1 bod. Jiné kombinace výpočtů podle algoritmů kmalg1 a kmalg2 s různými přesnostmi čísel vedou na minimální rozdíly, akorát při použití čísel s přesností 32bitů je celkový počet rozdílů lehce vyšší. Pokud se použije výpočet vzdálenosti kmalg3, tj. na elipsoidu, tak očekávaně výrazně naroste počet rozdílů v bodech u jednotlivých spojení k 40% a rozpětí těchto rozdílů se pohybuje mezi -1 a +3 body.

U výpočtů vzdálenosti na elipsoidu budou rozdíly oproti výpočtu na kouli se vzdáleností narůstat, tj. výše uvedené poměrně nízké rozpětí je poplatné obvyklé délce závodních spojení na VKV někde kolem několika set kilometrů s maximy pod 1.5 tisíce kilometrů. Např. při vzdálenosti něco přes 5 tisíc km je už rozdíl kolem +16km.

Závěrem k porovnání výsledků výpočtů

Rozdíly způsobené samotným způsobem výpočtu jsou mezi výstupy různých logovacích programů a mezi výstupy vyhodnocovacích programů poměrně malé. Odchylka u jednotlivých spojení bývá v rozpětí ±1 bod. Největší vliv má použití chybného zaokrouhlování, které může způsobit 1-bodové rozdíly až u poloviny spojení, naopak použití čísel v plovoucí řádové čárce pouze s jednoduchou přesností v kombinaci s použitím neoptimalizovaného algoritmu pro výpočet vzdálenosti nevede na nějaké výrazné zvýšení rozdílů. Přepočet bodů podle vzdáleností na elipsoidu místo na kouli vede samozřejmě na zvýšení počtu rozdílů, ale pro menší vzdálenosti se pohybujeme opět na úrovni 1-bodových rozdílů.

Lze najít poměrně dobrou shodu mezi výsledky produkovanými větší skupinou logovacích programů a výsledky robota IARU.

Největší odchylky, řádově i několikanásobně větší než ty způsobené samotným výpočtem, mezi body deklarovanými v souborech EDI a výpočty vyhodnocovacích programů vznikají v důsledku různého přístupu vyhodnocovacích programů k některým chybám v denících anebo v důsledku nekorektně provedených úprav v souborech EDI, kdy nebyly aktualizovány všechny související údaje.