Materialul as vrea sa-l incep cu cateva cifre:
Loguri intrate: 574
Loguri YO intrate: 142
Nr.tari (DXCC): 61
Nr. continente: 6
Nr. inscrieri linii in loguri: 88154 (nr de verificari incrucisat facute)
Aceste date sint facute fara a tine seama de datele din CHECK _Loguri.
In concurs au participat mai multe statii decit cele de mai sus insa cca 30% nu au trimis loguri dintre care din pacate si destul de multe statii din YO cu un numar mare de QSO-uri efectuate.
De asemenea (dupa evidenta mea) au sosit un numar de cca 120 loguri manuale (nu electronice), loguri care au trebuit fi transformate si introduse manual in computer. Aici am avut un ajutor de mare pret in YO3APG (cu o grupa care l-au ajutat), YO3JW (introdus cca 15 loguri), YO2DFA (14 loguri), YO9CWY (21 loguri), YO9HP (10 loguri) si YO3APJ, YO9BPX, YO7CKP. Daca am omis pe cineva imi cer scuze dar am un alt calculator, nu cel cu care am inceput (care si-a dat sufletul - HI) si nu mai am toate evidentele. Oricum, multumesc tuturor care m-au ajutat.
Pentru a nu pierde datele primare, am stabilit cu Alex YO9HP (A45WD) sa ii transmit toate datele primare si el sa le arhiveze in computerul sau pentru ca in caz de ceva, sa le am la dispozitie relativ simplu.
Deasemenea, m-am apucat ca pe tot parcursul verificarii, din cind in cind, sa fac un backup pe un alt computer de rezerva pentru a nu trebui sa reincep verificarea in cazul cind computerul principal isi da sufletul (HI). Pentru aceasta, am facut o mica retea interna care punea in legatura cele 2 computere si care imi permitea in fiecare seara , transpunerea datelor pe computerul de rezerva.
Se pare ca a fost cam multa munca pentru asigurarea datelor dar...
Spre marea mea deceptie, pe la mijlocul verificarii, computerul principal si-a dat sufletul. Daca nu faceam ceace am facut pentru asigurarea lucrului, acum puteam sa-i cer lui Alex sa-mi transmita datele primare si puteam sa iau totul de la inceput.
Asa insa, am pierdut numai munca pe cca 2 zile (de la ultimul Backup) si am putut continua pe computerul de rezerva care insa era mult mai incet si cu memorie mai mica , ceace a dus la prelungirea timpului de verificare.
Primele loguri au intrat in mijlocul lui Septembrie (cca 40 de loguri) pe care le-am prelucrat relativ rapid. Dupa aceia pina la mijlocul lui Octombrie nu a mai intrat nimic.
Pentru a intelege tehnologia de verificare, as vrea sa o descriu.
Fiecare log electronic, se verifica in ce format este (teoretic Cabrillo insa practic, incepind de la BIN pina la EXCEL si ADIF au fost de toate, nemaivorbind de Cabrillo care in multe cazuri nu prea semana HI). Daca era Cabrillo, se verifica daca are toate coloanele, daca indicativul scris in Header era corect respectiv daca avea categoria de participare conforma cu cea data de regulament. Aceasta a fost cazul la cca jumatate din loguri, ceilalti au scris cum o da domnul .
START-OF-LOG: 2.3
CREATED-BY: TR Log POST Version 6.79
CALLSIGN: RA6CZ
CATEGORY: B
CLAIMED-SCORE: 469098
NAME: ALEKSANDR SHIBANOV
ADDRESS: VINOGRADNAJA 152-35
ADDRESS: SOCHI
ADDRESS: 354008
ADDRESS: RUSSIA
OPERATORS: RA6CZ
QSO: 14000 CW 2005-08-27 1201 RA6CZ UT2UB 599 599 2 UR
QSO: 14000 CW 2005-08-27 1201 RA6C YO2GL 599 599 Timis
QSO: 14000 CW 2005-08-27 1202 RA6CZ YO7BGA 599 599 Dolj
Acest log a fost facut cu programul TR LOG. Se observa ca nu are RST respectiv Nr transmis si ca judetele YO sint scrise asa cum se vede. De asemenea categoria de participare este B ceace la statii Not YO ...Asta a dus la necesitatea corectarii logului care la 700 de QSO-uri a fost ceva munca. In plus cca 150 de statii au folosit acest program si au trimis logul ca atare.
Un alt exemplu:
QSO: 14000 CW 2005-08-27 1203 DL5RBR 599 - YO6BHN 599 CV 0
QSO: 14000 CW 2005-08-27 1205 DL5RBR 599 - YO5CBX 599 BN 0
QSO: 14000 CW 2005-08-27 1207 DL5RBR 599 - YT1BB 599 06 0
Si la acest log a trebuit introdus Nr. transmis.
Categoria de participare nu era cea prevazuta de regulament. De ex. o statie din YO a scris SO la categorie, ceace m-a obligat sa ghicesc daca are categoria Seniori (A) sau Juniori (B). Daca am gresit, asta este.
Aceste loguri verificate (in limita posibilului (de ce scriu asta se va vedea mai tirziu)), erau transpuse in tabele ACCES in baza de date. Fiecare log (statie) avea un tabel denumit dupa indicativul lui (de ex. YO3JW avea logul in tabelul denumit YO3JW).
Programul facea in timpul transpunerii verificarea, daca data calendaristica era conforma cu formatul Cabrillo (YYYY.MM.DD) ca si verificarea daca ora ca format era corecta respectiv putea fi recunoscuta de computer ca atare.
QSO: 14000 PH 2004-08-27 1317 SP5BB 59 001 YO2KBB 59 AR
QSO: 14000 PH 2004-08-27 1323 SP5BB 59 002 YO8RAA 59 SV
QSO: 14000 PH 2004-08-27 1324 SP5BB 59 003 YO5TP 59 CJ
Dupa acest log, concursul a avut loc in anul 2004 si la verificare toate QSO-urile din acest log, pentru ambii parteneri de legatura vor da BAD TIME pentru ca diferenta de minute era egala cu numarul de minute dintr-un an.
Din pacate si aici am gasit destul de multe loguri unde data era in format aiurit (YYYY.DD.MM) si care nu era recunoscut de program si ceace a obligat remedierea acestei coloane. Tot aici se verifica daca formatul are toate coloanele de date conform formatului Cabrillo (ceace eventual ar fi putut scapa la verificarea vizuala .
Dupa terminarea introducerii TUTUROR logurilor se trece la verificarea efectiva a logurilor si anume se face verificarea primului log (de ex YO3JW) Se cauta prima linie din log (ex. legatura cu DL5MHR), computerul cauta tabelul DL5MHR si verifica daca gaseste in acest log legatura cu YO3JW. Daca da, compara datele inscrise in cele 2 loguri si determina daca legatura este corecta sau daca apar penalizari si din
ce cauza. Daca legatura era corecta, scrie in tabelul lui YO3JW "OK" si trece la legatura urmatoare.
Aceasta legatura se mai verifica odata la verificarea logului lui DL5MHR cind rezultatul verificarii "OK" sau altceva, se srie in tabelul lui DL5MHR. Practic, fiecare legatura se verifica de 2 ori.
In cazul cind tabelul lui DL5MHR nu exista, in tabelul lui YO3JW se scrie "NOLOG". In cazul in care tabelul DL5MHR exista dar in el nu se gaseste legatura cu YO3JW pe banda respectiva, in tabelul YO3JW se scrie "NIL".
In acest fel, se verifica TOATE legaturile din tabelul YO3JW dupa care se trece la un nou log (tabel).
In timpul acestei verificari au aparut alte dracii de ex o statie scrie in Header ca este XX2XX/P dar transmite indicativul fara acel /P deci XX2XX. Programul face tabelul dupa header deci XX2XX/P Urmarea este ca la cautarea legaturii cu statia XX2XX/P in logul corespondentului, aceasta nu se gasea din cauza ca era XX2XX deci NIL La verificarea logului statiei corespondente, se cauta tabelul statiei corespondente XX2XX dar tabelul era XX2XX/P ceace ducea la NOLOG.
Deci toate legaturile erau anulate. Aceasta m-a obligat sa remediez logul statiei XX2XX/P si sa il fac XX2XX.
De asemenea si aici au aparut tot felul de probleme cu ora. O statie a facut prima zi de concurs in anul 2005 iar ziua doua cu un an mai devreme (daca era invers as fi inteles dar asa...HI) ceace a dus la anularea tuturor legaturilor din ziua a doua la ambele statii, ceace m-a obligat la noi corecturi.
Concluzia ce se trage este aceia ca este mult mai usor sa lasi verificarea propiului log in seama celui ce arbitreaza (ca de aia s-a apucat) in loc sa iti verifici singur propriul log si sa-l modifici. E drept ca era cam mult de lucru (sa zicem 500 QSO-uri) in timp ce arbitrul avea de verificat 100000 de QSO-uri (dar de aia ia banii HI).
Dupa prima verificare totala, am ajuns la concluzia ca multe loguri au trebuit corectate sau completate in timpul verificarii. Prin verificarea logului modificat prin program, acesta era deacum corect insa toate verificariile logurilor statiilor care au avut QSO-uri cu statile cu logurile modificate, nu mai erau corecte. Spre norocul meu, modificariile nu le-am facut in tabelele Acces ale statiilor respective ci efectiv in log ceea ce a usurat oarecum munca.
In urma acestor modificari, am trebuit sa sterg toate verificarile facut, sa convertesc din nou TOATE logurile primare modificate in tabele Acces si sa refac TOATE cele 570 de verificari de loguri (deci sa reiau munca de la inceput). Dupa aceasta a doua verificare, toate verificarile facute au aratat ca rezultatele sint corecte iar clasamentele sint cele reale.
Dupa trimiterea clasamentelor respectiv creierea unor clasamente ordonate diferit, verificarea a fost considerata terminata.
Concluzie pentru viitor: Daca se doreste verificarea cu acest program, va trebui facuta o echipa care sa transpuna eventualele loguri manuale, iar arbitrul principal sa colecteze, sa corecteze logurile, sa le introduca in baza de date si sa faca de 2 ori munca de verificare. Insa dupa aceasta exista convingerea verificarii si corectarii 100% a tuturor QSO-urilor, creierea automata de clasamente, respectiv existenta in computer a logurilor corectate care pot fi oricind vizualizate. In concluzie, practic, rezultatele sint corecte, fara mici modificari pe ici, colea ca sa iasa ce trebuie HI.
Cea mai multa munca a fost data de nerespectarea formatului Cabrillo, trimiterea unor loguri cu formate aiurite respectiv aparitia a prea multe loguri trasmise prin posta. Culmea a fost ca au aparut loguri facute cu calculatorul insa liparite si trimise prin posta. Asta a fost o chestiune pe care nu am priceput-o dar ma rog...
Felicit pe castigatori respectiv le doresc tuturor participantiilor toate cele bune si la reauzire in concursul din 2006.
N.R. Clasamentele la Campionatul de Unde Scurte Multiband al Romaniei - YO DX HF Contest pot fi gasite in aceasta pagina
- Nicky Kintsch DL5MHR
-
