Articole > Concursuri si diplome     Comentati acest articol    Tipariti

NOU DESPRE CONCURSURI ŞI FORMATELE DE LOG Gheorghe Oproescu - Tavi YO4BKM Concursurile "în eter" sunt din ce în ce mai diversificate pe toate planurile: frecvenţe, mod de lucru, durată de desfăşurare, mod de evaluare, categorii de participare, arie de cuprindere (naţionale, continentale, regionale, globale) şi cine ştie ce va mai apare. Evaluarea participării oricărui concurent a progresat de la confruntarea manuală a fişelor de participare la confruntarea lor electronică, fapt ce a dus la trecerea de la formatul pe hârtie unic şi internaţional valabil cu cele două fişe ale sale, numite SUMMARY şi CONTEST LOG (care încă mai sunt folosite!), la o mulţime foarte diversificată de formate electronice, care dau bătăi de cap multor participanţi la concursuri, fie ei radioamtori sau organizatori deopotrivă. Varietatea de formate electronice s-a impus ca o necesitate izvorâtă din a exploata cât mai eficient resursele calculatorului în folosul organizatorilor, dar şi al concurenţilor. Formatele elctronice s-au modificat atât ca structură (CABRILLO, EDI, ADIF, ADIX, CSV, chiar şi TEXT, EXCEL sau WORD) dar şi ca versiuni ale aceleaşi structuri, atât ca urmare a perfecţionarea tehnicilor din domeniul IT, dar şi a folosirii experienţei acumulate pe parcurs. Dacă vechile fişe SUMMARY şi CONTRST LOG se completau de mână sau la maşina de scris în spaţii marcate pe hârtie, noile formate electronice se generează folosind softuri specializate (numite şi editoare de log). Cine este familiarizat cu dactilografierea poate încerca să completeze logul electronic şi direct, ca fişier text, dar munca îi va fi mult îngreunată cu poziţionarea înregistrărilor şi cu folosirea foarte repetată a unor caractere speciale caracteristice tipului de log. Am văzut destule astfel de loguri unde poziţionarea se face cu tabulatorul (tasta Tab) care, din păcate, generează coduri incompatibile cu codurile ASCII acceptate de formatele de log şi, ca urmare, imposibil sau dificil de citit. Din nefericire aceste coduri nu se văd pe ecran decât cu comenzi speciale (cum ar fi Show/Hide ¶) şi de aceea sunt greu de depistat şi corectat de orgnizatori. În cele ce urmează mi-am propus ca, sub o formă sintetică şi comparativă să prezint caracteristicile fiecărui format din cele trei mai des folosite (CABRILLO, EDI, ADIF) şi adaptabilitatea lor la diferite competiţii. Dacă vechiul format unic de log pe hârtie era adaptabil pe vremuri la toate tipurile de competiţii, în principiu această adaptabilitate o poate asigura şi oricare format electronic de azi, dar cu eficienţă evident diferită de la o competiţie la alta. Noul este întotdeauna primit cu rezervă. Abia ne-am obişnuit cu logul electronic în format CABRILLO (dar, ne-am obişnuit oare, nu cumva încă mai "plouă" cu greşeli?) şi iată că deschid aici o pledoarie pentru mai multe formate de log electronic. Dar situaţia o cere, ele au fost create din necesitate şi sunt folosite deoarece aduc un confort sporit mai ales la lucrul în marile concursuri (verifică dacă legătura este înregistrată corect, permit înscrierea unei varietăţi mai largi de informaţii, folosesc baze de date cu privire la ţara, regiunea sau zona oricărui radioamator, permit o evaluare rapidă făcută de arbitri sau organizatori), sunt deja impuse participanţilor, aşa că nu scăpăm de ele. De aceea este bine să ştim ce înseamnă aceste formate, măcar cele mai des folosite, astfel ca organizatorii de concursuri să-şi reevalueze regulamentele pentru a le face cât mai adaptate unui format de log electronic, dar şi concurenţii să fie în cunoştinţă de cauză privind ce îi aşteaptă. Formatul CABRILLO Este printre primele formate electronice pentru competiţiile de radioamator. Ca să nu mai ocup loc aici cu descrierea lui pe larg, se poate consulta excelenta prezentare făcută de [1] din care se poate afla orice se doreşte. Deşi poate fi utilizat pentru orice bandă de frecvenţe, se preferă folosirea lui doar pentru frecvenţele mai mici de 30MHz. Structura sa seamănă foarte mult cu vechile fişe SUMMARY şi CONTEST LOG care au servit drept model, ambele asamblate într-un singur format, în care SUMMARY a devenit partea de început la CABRILLO cunoscută sub numele de "header" sau "preambul" şi care se încheie în loc de "Remarks" cu "Soapbox", iar CONTEST LOG a devenit o serie de rânduri cu lungimea impusă la 82 de caractere, fiecare rând începe cu 4 caractere QSO: urmate de un şir de grupuri de caractere cu poziţie fixă care poartă numele generic de "cuvinte" deoarece sunt separate între ele prin cel puţin un spaţiu. Fiecare cuvânt are impus numărul de caractere, trebuie să aibe cel puţin un caracter şi nu sunt acceptate cuvinte vide (fără niciun caracter). Pe aceste rânduri se identifică, aliniate pe verticală în poziţii fixe, coloanele cu banda (5 caractere), modul de lucru (2 caractere), data (10 caractere), timpul (4 caractere), indicativul propriu (13 caractere), RS(T) propriu (3 caractere), controlul transmis (6 caractere), indicativul corespondentului (13 caractere), RS(T) primit (3 caractere), controlul recepţionat (6 caractere), ID-ul emiţătorului (2 caractere). Între cuvinte se lasă un singur spaţiu şi, dacă un cuvânt este mai scurt decât numărul de caractere rezervate, se completează cu spaţii la capătul din dreapta. Fişierul are structura unui fişier text şi poate avea extensia log, cbr, txt, se poate deschide cu Notepad, Wordpad sau orice utilitar pentru fişiere text. Fiind foarte asemănător cu un format pe hârtie, cu coloane perfect aliniate, poate fi citit cu uşurinţă pe ecranul calculatorului şi se pot face intervenţii în el precum în orice text. Din acest motiv şi mai ales pentru loguri scurte el se poate scrie şi fără editor specializat, direct de la tastatură, dar fără să se folosească Tab pentru poziţionare. Acest format a evoluat în timp numai în privinţa headerului. La cele mai multe competiţii, mai ales YO, este obligatoriu (şi suficient) să se completeze doar etichetele CALLSIGN:, CATEGORY:, OPERATORS:, opţional (nu influenţează evaluarea şi arbitrarea) se mai completează CONTEST:, NAME:, CLUB:. Diversificarea competiţiilor a făcut ca unele rubrici să fie detaliate în plus, apar de exemplu CATEGORY-OPERATOR:, CATEGORY-BAND:, CATEGORY-POWER:, CATEGORY-ASSISTED:, CATEGORY-MODE:, după cerinţele arătate în regulamente. Din experienţa de aproape 20 de ani de când am început să elaborez softuri de evaluare-arbitrare am constatat că la eticheta CATEGORY: se produc cele mai multe abateri de la regumanentele de concurs, dar nu numai din vina competitorilor. La cele mai multe competiţii YO nu există categorii de putere, de bandă, de mod asistat sau neasistat, cel mult sunt categorii cu unul sau mai multi operatori, apar în schimb categorii precum juniori, seniori, staţii speciale etc. De aceea mulţi organizatori de competiţii prind în regulament o codificare a categoriilor prin A, B, C etc (juniori, seniori, individual, echipe etc) urmate de explicaţii, în loc de SOP, MOP, LP, HP care reprezintă single operator, multi operator, low power, high power sau altele. Softul de eveluare-arbitrare trebuie să identifice corect categoriile pentru a edita listele cu clasamentele corespunzătoare. De cele mai multe ori am observat că nu se respectă indicarea categoriei conform regulamentului organizatorilor, apar toate variantele posibile care există în lume şi chiar combinaţii ale lor, ceea ce face ca organizatorul să trudească din greu pe loguri străine şi să le corecteze la aceste rubrici conform regulamentului elaborat de el. Aci trebuie ca atât competitorii să dea atenţie modului cum sunt formulate categoriile în regulament şi să completeze logul întocmai, dar şi organizatorii trebuie să dea explicaţii mai detaliate, inclusiv exemple de header corect scris, conform regulamentului lor. O altă sursă majoră de erori, cu efecte asupra preluării corecte a datelor de către soft, apare în liniile QSO:. Cuvintele din aceste linii pot fi "citite" de softul de confruntare-evaluare-erbitrare în două moduri distincte: - fie începând cu poziţia impusă de format pentru fiecare cuvânt (citire "pe poziţii"); - fie începând cu primul caracter care urmează după spaţiu sau spaţii (citire "pe cuvinte"); În formatul CABRILLO după controlul RS(T) emis sau recepţionat trebuie să urmeze un "cuvânt" care cuprinde controlul schimbat, scris pe 6 caractere (lungime impusă). Acest control trebuie să conţină pe trei caractere numărul de control (serial, ştafetă, fix) urmat imediat de un alt cod, care trebuie definit şi explicat de organizator, căruia îi sunt rezervate celelalte trei caractere. De cele mai multe ori din aceste trei caractere sunt folosite doar 2 deoarece ele desemnează judeţul (zona). Cu ce se completează al treilea caracter? Evident că cu un spaţiu gol, nu este interzis, numai că plasarea acestuia crează confuzii. Dacă se plasează înaintea celor două caractere frecvent utilizate controlul se "rupe" în două cuvinte aparent distincte, dacă se plasează după cele două caractere (conform regulii) controlul va fi format dintr-un singur cuvânt. Cum este corect? Ambele moduri ar putea fi corecte numai dacă se respectă cu stricteţe poziţia la care începe fiecare cuvânt, lucru care nu se prea întâmplă. Dacă nu se respectă cu stricteţe poziţiile de început ale cuvintelor lucrurile se complică deoarece softul va trebui să citească rândurile "pe cuvinte", în care caz va ţine cont de delimitările produse de spaţii şi astfel pot apare două cuvinte în plus, respectiv cele două judeţe (zone) ale celor doi corespondenţi care formează QSO-ul, în cazul în care spaţiul se pune înaintea celor două caractere ale judeţului (zonei). Am întâlnit cazuri în care unul din controale (de exemplu cel propriu) forma un singur cuvânt, precum 465BV, pe când controlul receptionat era pe 2 cuvinte, precum 372 AB. Cum se poate construi un soft care să citească un număr de loguri la care apar diferenţe, de la log la log, atât prin poziţiile cuvintelor (funcţie de editorul mai mult sau mai putin improvizat) cât şi prin modul cum sunt compuse cuvintele, adică loguri cu erori de la formatul corect? Pentru că erori de la formatul corect am întâlnit şi la dată, la timp, la bandă sau la modul de lucru. Este unul din motivele pentru care organizatorii care folosesc un robot care preia şi verifică logurile trimit automat înapoi logurile care nu corespund cu formatul original, respectiv nu au cuvinele puse pe poziţiile corecte sau au cuvintele scrise gresit, producând erori de sintaxă. Pentru astfel de cazuri eu unul nu am găsit soluţie şi, pentru că cele mai multe loguri au un spaţiu între numărul de control şi judeţ (zonă), am ales citirea "pe cuvinte" în care caz toate logurile trebuie să aibe obligatoriu acest spaţiu între numărul de control şi presurtarea judeţului (sau zonei). Iată un alt motiv ca organizatorii să trudească an de an pe loguri străine. Analizând logurile primite la competiţiile organizate de Clubul Sportiv al Radioamatorilor din judeţul Brăila, YO4KAK, am observat următoarele, funcţie de editorul folosit pentru log: - Hamware/YO9HSW versiunea 2.0 poate fi considerat corect; - UcxLog 5.53 versiunea 2.0 este corect; - YODXLog/DL5MHR versiunea 2.0 nu respectă poziţiile începând cu numnărul de control transmis; - LOGIX versiunea 2.0 are erori de poziţionare începând cu banda de frecvenţe; - YO9HG fără versiune are erori din poziţia indicativului partenerului. Acestea sunt versiunile întâlnite în loguri, pot exista şi altele, eu nu mă pot pronunţa decât asupra celor consultate de mine. Din cele de mai sus ar rezulta că singurele editoare care pot fi folosite citind datele de pe poziţii sunt primele două. Cu toate acestea apar diferenţe şi între ele. La Hamware/YO9HSW în cuvântul care arată codul, zona ocupă ultimele două caractere din cele trei rezervate (deci cu spaţiu între număr de control şi zonă, dacă s-ar fi respectat regula completării cu spaţii goale acesta ar fi trebuit să fie la sfârşit), pe când la UcxLog zona ocupă primele două carctere din cele trei, spaţiul plasându-se cum este corect, la final. Dacă ar fi numai această „abatere” softul ar rezolva uşor neajunsul testând unde apare spaţiu gol în cuprinsul celor şase caractere care compun controlul schimbat. Dar putem spera că vor fi folosite numai astfel de editoare? Şi pentru că indicat ar fi să existe un singur format utilizat, eu recomand UcxLog. Dacă totuşi alţi programatori doresc să-şi lanseze produsele proprii, personalizate d.p.d.v. grafic sau de interfaţă, trebuie să aibe grijă să poziţioneze câmpurile în conformitate cu UcxLog care se poate găsi la [2]. Folosind un editor care crează loguri cu cuvintele poziţionate corect, ar fi posibil să se omită cuvintele care nu sunt necasare (locul lor se umple cu spaţii), cum ar fi de exemplu omiterea RS(T) şi a controlului la unele concursuri gen maraton. În cazul citirii pe cuvinte (cuvintele nu ocupă locul consacrat) nu se pot înlocui cuvintele inutile prin spaţii. Datorită rigidităţii sale, fiind alcătuit pe baza cuvintelor de lungime impusă şi pe poziţii strict precizate, formatul CABRILLO începe să pună probleme la competiţiile moderne, cum ar fi la codificarea modului de lucru pe 2 caractere. Fiind inspirat din fişele SUMMARY şi CONTEST LOG când nu existau decât două moduri codificate PH sau CW, azi nu mai pot fi codificate cu uşurinţă modurile digitale cu toate variantele lor. Ca să nu mai spun de modurile care nu vizează forma semnalului ci modul de propagare (EME, satelit, reflexii pe avioane etc). O altă problemă apare la numărul de control când se formează serial şi apar mai mult de 999 de legături, precum la concursurile internaţionale, nu există spaţiu pentru a fi scrise. De aceea formatul CABRILLO cedează teren în favoarea altor formate care să nu mai aibe astfel de dezavantaje. Formatul EDI Formatul EDI, însemnând Electronic Data Interchange, este destinat pentru concursurile din Regiunea 1 pe benzile de frecvenţe peste 30MHz. Descrierea sa excelent de bine detaliată se găseşte la [3] Ca şi formatul CABRILLO are un header (fostul SUMMARY) care se termină de data asta cu [Remarks] şi o zonă cu QSO-urile. Fişierul, cu structură de fişier text, are extensia edi, nu se acceptă alte extensii precum log sau txt ca la CABRILLO. Dacă headerul se poate citi uşor ca orice text pe ecranul calculatorului, liniile cu QSO-uri (fiecare QSO pe câte un rând cu 15 cuvinte) sunt greu de descifrat deoarece cuvintele au lungimi diferite de la un rând la altul, au poziţii diferite în cadrul rândului, dependente de lungimea cuvintelor aflate în faţă iar separările între cuvinte se fac cu caracterul "semicolon" (punct şi virgulă) pus o singură dată după fiecare cuvânt. După ultimul cuvânt (care este de fapt o singură literă, D, care marchează că legătura este dublă) nu se mai scrie separatorul. Unele cuvinte pot lipsi (ceea ce nu este permis la CABRILLO), în acest caz apar separatoarele punct şi virgulă unul după altul, între care este cuvântul vid. Iată câteva exemple de QSO-uri înregistrate în EDI, se vede lipsa alinierii pe verticală precum şi lipsa unor cuvinte: 130504;1419;HG7B;1;59;002;59;028;;JN97LW;300;;;; 130504;1403;HA2R;1;59;003;59;003;;JN87UE;122;;N;N; 950304;1826;OZ9SIG;1;59;026;59;006;;JO65ER;0;;;;D Headerul formatului EDI este mai complicat decât la formatul CABRILLO deoarece conţine mai multe etichete. În zona cu QSO-ri permite însă scrierea de cuvinte cu lungimi neimpuse şi chiar omiterea lor. Acestea fac dificilă completarea unui log în format EDI direct de la tastatură (fug ochii), fără editor specializat sau de intervenit în conţinutul lui ca într-un fişier text. Fiind mai flexibil, în formatul EDI nu apar atât de des erori ca la formatul CABRILLO. În plus, citirea QSO-urilor de către soft se face comod şi sigur, numai pe cuvinte, urmărind separatorul punct şi virgulă. Cea mai frecventă eroare care se poate întâlni aici, dar cu o frecvenţă mult mai redusă decât erorile din logurile CABRILLO, este necoincidenţa dintre numărul de legături (de fapt numărul de rânduri, fiecare rând însemnând căte un QSO) care se declară într-o etichetă cu care începe lista cu QSO-uri şi numărul de rânduri înscrise în continuare. De cele mai multe ori aceste erori sunt generate chiar de concurent care şterge liniile care conţin legături duble (dar care se pot marca că sunt duble şi astfel nu produc penalizări) fără să corecteze numărul de legături. Mai sunt editoare de log care încheie lista destinată QSO-urilor cu un rând în plus, care nu face parte din formatul EDI şi care nu conţine nimic legat de vreo legătură radio. Sau acest rând este pus de concurnt ca o remarcă. Pentru editoare de log EDI se poate apela la [4]. Formatul ADIF Însemnând Amateur Data Interchange Format formatul ADIF, deşi este cel mai puţin cunoscut la noi, este totodată formatul cel mai flexibil şi mai puţin pretenţios, care poate fi folosit la orice gen de concurs, fără nicio limitare. Oferă posibilitatea de a înscrie în log orice consideră organizatorul (sau radioamatorul) că este important, cum ar fi ora de început şi ora de sfârşit a legăturii (sau numai una din ele, puse de radioamator sau de calculatorul care asistă ON-LINE staţia radio), dacă a primit sau trimis QSL, orientarea antenei în azimut şi elevaţie, E-QSL, E-Mail, coordonatele geografice şi multe altele. Dacă în log apar înscrisuri care nu sunt cerute de organizator acestea nu afectează evaluarea şi arbitrarea, important este să nu lipsească informaţiile cerute de regulamentul concursurilor. Headerul acestui format este extrem de sumar şi se referă doar la autorul softului de editare şi versiunile softului. Orice înregistrare în fişier se face folosind cuvântul care o defineşte, numit şi etichetă (de exemplu programversion, operator, date, time, band etc) scris între paranteze unghiulare împreună cu o specificare care arată pe câte caractere apare în continuare respectiva înregistrare. Dar, mai clar este să dau câteva exemple: Headerul poate arăta precum: ADIF Export from ADIFMaster v[2.1] http://www.dxshell.com Copyright (C) 2005 - 2014 Igor V. Tolmachev (UU0JC) File generated on 04 Aug, 2014 at 16:49 <ADIF_VER:4>3.0 <PROGRAMID:10>ADIFMaster <PROGRAMVERSION:3>2.1 <EOH> unde eticheta <EOH> înseamnă End Of Header. QSO-urile pot apare pe ecran fie câte unul pe un rând, precum: <QSO_DATE:8>20140724 <TIME_ON:4>0345 <BAND:3>80m <CALL:6>YO1XXX <EOR> <QSO_DATE:8>20140725 <TIME_ON:4>0427 <BAND:2>6m <CALL:5>YO1AA <EOR> <QSO_DATE:8>20140725 <TIME_ON:4>1633 <BAND:4>160m <CALL:8>YO1BBB/P <EOR> fie pe mai multe rânduri separate prin Enter (cod ASCII 13): <QSO_DATE:8>20140724 <TIME_ON:4>0352 <FREQ:5>3.705 <MODE:3>SSB <RST_SENT:2>59 <RST_RCVD:4>58-9 <CALL:6>YO1XXX <NAME:3>ION <COMMENT:5>3 pts <EOR> Fiecare QSO se încheie cu eticheta <EOR>, adică End Of Record. Între înregistrările de pe un rând se lasă un spaţiu (după ce se scrie ceea ce este arătat între parantezele unghiulare se lasă un spaţiu până se deschide iar paranteza unghiulară <). În cadrul unui fişier toate QSO-urile trebuie să aibe acelaşi număr de înregistrări cu aceleaşi etichete puse între parantezele unghiulare, chiar dacă lungimea lor variază ca urmare a lungimii diferite a cuvintelor. Un soft simplu de utilizat pentru editare se găseşte la [5] Editarea logului este simplă, softul oferind o grilă (tabel) unde operatorul îşi fixează capetele de coloană atâtea câte doreşte, în ce ordine doreşte precum şi ce să conţină (de exemplu să conţină numai data, timpul, banda, modul, RST transmis şi recepţionat şi indicativul partenerului) din peste 100 de variante oferite de soft. Iată cum arată un astfel de tabel: şi cum arată logul: <QSO_DATE:8>20140724 <TIME_ON:4>0345 <BAND:3>80m <FREQ:5>3.705 <MODE:3>SSB <RST_SENT:3>59+ <RST_RCVD:2>58 <CALL:6>YO9HMP <EOR> <QSO_DATE:8>20140724 <TIME_ON:4>0350 <BAND:3>80m <FREQ:5>3.705 <MODE:3>SSB <RST_SENT:2>59 <RST_RCVD:4>58-9 <CALL:6>YO5AMF <EOR> <QSO_DATE:8>20140724 <TIME_ON:4>0352 <BAND:3>80m <FREQ:5>3.705 <MODE:3>SSB <RST_SENT:2>59 <RST_RCVD:4>58-9 <CALL:6>YO7FBM <EOR> <QSO_DATE:8>20140724 <TIME_ON:4>0355 <BAND:3>80m <FREQ:5>3.705 <MODE:3>SSB <RST_SENT:2>58 <RST_RCVD:5>59+25 <CALL:6>YO2OCP <EOR> <QSO_DATE:8>20140724 <TIME_ON:4>0358 <BAND:3>80m <FREQ:5>3.705 <MODE:3>SSB <RST_SENT:2>58 <RST_RCVD:3>59+ <CALL:6>YO9FDX <EOR> <QSO_DATE:8>20140724 <TIME_ON:4>0401 <BAND:3>80m <FREQ:5>3.705 <MODE:3>SSB <RST_SENT:3>59+ <RST_RCVD:3>59+ <CALL:6>YO6PEG <EOR> Formatul a evoluat, ediţiile mai noi adăugând cuvinte noi şi recunoscând structura formatelor mai vechi. Conversia de la un format la altul Există softuri care convertesc logurile dintr-un format în altul. Dar, deoarece structura lor nu este asemănătoare, conversiile sunt aproximative şi informative. Iată un exemplu: un log în format ADIF completat pentru un maraton, unde lipseşte controlul şi raportarea recepţiei nu va putea da, prin conversie, un log CABRILLO corect, unde este obligatorie completarea tuturor cuvintelor. Nici un log CABRILLO nu se poate converti într-un log EDI corect deoarece CABRILLO nu are cuvinte pentru locatorul corespondentului sau nu are codificate toate modurile de lucru din EDI. În general conversia spre CABRILLO pornind de la orice alt format este cea mai imprecisă, deoarece CABRILLO are un număr exact de cuvinte care în alte formate pot lipsi. În privinţa headerului, sunt puţine elemente comune de la un format la altul, am arătat că formatul ADIF nu are decât un header formal. După conversie, în caz că reuşeşte, logul nou obţinut trebuie verificat şi, eventual, "toaletat". Recomandări Am arătat mai sus că sunt competiţii la care nu se cer categoriile de participare, numerele de control, zonele, raportarea RS(T), precum maratoanele, recenta aniversare a 10 ani de la Radioamator.ro, mai sunt şi altele la care se cere să se înscrie în log numele propriu, numele partenerului, orientarea antenei. Categoriile de participare sunt definite extrem de diversificat, de multe ori ele fiind definite de organizator în regulamentul concursurilor. Formatul CABRILLO nu se poate folosi decât la competiţiile la care se cere completarea tuturor cuvintelor impuse în format. Dacă se doreşte acest format şi la competiţii unde o serie de informaţii nu sunt necesare, organizatorul trebuie să precizeze în regulament ca în locul lor să se scrie orice, la modul formal, numai să corespundă formatului cuvântului respectiv. Deoarece multe editoare de log CABRILLO existente pe piaţă nu respectă poziţia cuvintelor, informaţiile lipsă nu pot fi înlocuite cu spaţii deoarece citirea logului se face "pe cuvinte", asta presupunând să existe toate cuvintele d.p.d.v. fizic. Folosirea unui format ADIF simplifică mult lucrurile deoarece conţinutul lui se poate configura după dorinţă. Acest lucru ar trebui să intre în atenţia tuturor organizatorilor de competiţii care, la întocmirea regulamentului, trebuie să cunoască foarte bine cerinţele formatului de log pe care îl solicită şi, în caz că unele informaţii nu sunt luate în considerare dar formatul logului le impun, să ceară completarea lor formală (dar obligatoriu) sau să indice formatul de log (de exemplu ADIF în loc de CABRILLO) cu precizarea etichetelor obligatorii. Personal nu văd nicio problemă în a evalua şi arbitra un concurs la care concurenţii pot trimite amestecat, după dorinţă şi pricepere, loguri în format CABRILLO, EDI sau ADIF, personal m-am "jucat" realizând astfel de softuri şi este pe deplin posibil la orice concurs din zona YO. Dar, înainte de toate, un lucru consider că este foarte important: prezentarea în regulamentele de competiţii a unuia sau mai multor exemple privind modul în care trebuie să arate headerul şi partea cu QSO-uri la logul cerut, asta ar face să dispară multe din problemele cu care se confruntă la arbitrare chiar cei care au întocmit regulamentul. La fel de importantă este şi indicarea de către organizatori, tot în regulament, a sursei de descărcare a editorului de log pe care îl preferă deoarece s-au convins că satisface în totalitate prevederile din regulament şi softul de arbitrare, asta cu condiţia ca organizatorii să cunoască în detaliu ce se află pe piaţa editoarelor de log şi să fi făcut chiar ei testări ale editoarelor, în urma cărora s-au orientat asupra unuia anume. De preferat ar fi să se folosească editoarele care generează loguri în format acceptat şi la concursuri organizate de alte ţări, acestea sunt cele mai corecte şi, dacă cineva tot se dotează cu un editor, măcar să fie cel mai bun. Bibliografie [1] http://www.kkn.net/~trey/cabrillo/ [2] http://www.softpedia.com/get/Internet/Other-Internet-Related/UcxLog.shtml [3] http://www.ari.it/index.php?option=com_content&view=article&id=451%3Astandard-format-for-e-contest-log&catid=122%3Asoftware〈=en [4] http://www.radioamator.ro/contest/software/ [5] http://www.softpedia.com/get/Internet/Internet-Radio-TV-Player/ADIF-Master.shtml Gheorghe Oproescu - Tavi YO4BKM Articol aparut la 25-9-2014 8042 Inapoi la inceputul articolului

Comentarii (17)
Postat de Vasile - YO9FEH la 2014-09-26 06:43:31 (ora Romaniei) Excelent articolul,dar din pacate este pentru cei care sunt foarte familiarizati cu calculatorul.Si mai au si mult timp sa se joace cu calculatorul ! HI ! Eu am lucrat cu CABRILLO al Domnului Margarit,dar acum nu stiu ce a patit vechiul laptop care are Windows XP si nu-l mai pot folosi !Din 2011 noembrie am un HP cu Windows 7 si nu am reusit sa introduce Cablillo DL5MHR!Din acest motiv nu mai lucrez in concursurile YO si mai rar in cele internationale ,cand un coleg din Ploiesti are timp si bunavointa sa facem logul si sa-l trimitem ! Sper ca pana in iarna sa reusesc sa introduc si programul de digitale ca sa-l tai pe "laudarosul" YO9AGN Nick....care m-a facut vanat de "invidie" cu eQSL-urile lui pe care le primeste a II-a zi dupa un concurs international ! Multumiri autorului !73 !
Postat de Miki - YO5AJR (yo5ajr) la 2014-09-26 09:31:59 (ora Romaniei) O tema bine venita dr om Tavi. In radioamatorism nu sunt de acord ca septuagenarii sau octogenarii sa nu ralieze la folosirea PC. Radioamatorismul prin excelenta tine in miscare neuronii, lucru benefic de a ne pastra tonusul de sanatate generala. Am incercat mai mult softuri de a lungul anilor si eu am parere ca pentru conteste dar si pentru QSO - urile normale "UcxLog" - ul este foarte prietenos si intuitiv. (costa doar 20 de Eu.) Pentru concursurile interne prefer "Hamware" dar din pacate autorul nu mai "upgradeaza". O alegere gresita in special pentru IARU consider ca "WriteLog" - ul nu este chiar ideal fata de care "N1MM" este mult mai prietenos si mai practic (este si free") La initiativa lui YO5OHO care are "masterat" in acest soft am incercat intr-un gup de 10, interconectat si m-a fascinat posibilitatile de comunicare intre noi prin net in timpul operatiuni. Am incercat si in IARU in acest an cu echipa de vanatori din Satu Mare, iar restul echipelor lucrau cu "WriteLog". Ar fi benefic ca in marile conteste in viitor sa foloseasca acest "N1MM". 73 de yo5ajr
Postat de Gheorghe Oproescu - Tavi - YO4BKM (yo4bkm) la 2014-09-26 10:48:17 (ora Romaniei) Folosirea PC pentru a asista o staţie de radio este, pentru mulţi vârstnici, o noutate la fel de dificilă precum operarea unei staţii de radio acum 50-60 de ani, dificultate pe care septuagenarii sau octogenarii de azi au învins-o atunci, de ce nu ar face acelaşi lucru şi acum? Atunci ne alăturam codului lui Paul Segal W9EEA (1926) care arată la regula a treia: "THREE. The Amateur is Progressive . . . He keeps his station abreast of science...", tocmai pentru că radioamatorii au înţeles de la bun început chestia cu neuronii arătată de Miki YO5AJR. Nu cred că interesul a scăzut cu vârsta, am trecut şi eu prin revoluţia calculatorului electronic chiar de la apariţia lui (cartele perforate, unităţi de lucru cât camera etc) şi am impresia că lumea a fost speriată pe atunci de faptul (real) că asimila calculatorul cu cunoştinţe deosebite în domeniul matematicii, logicii etc. Numai că lucrurile au evoluat, singura "dificultate" de azi fiind obişnuirea cu tastataura şi cu o nouă terminologie, la fel ca obişnuirea cu telegrafia şi codurile de trafic cu decenii în urmă. Mai aduc o comparaţie: acum 80-90 de ani în urmă mulţi posesori de automobil aveau şofer angajat, din cauza teribilei noutăţi pe care nu o puteau înţelege, azi permisul de conducere îl obţine oricine doreşte, automobilul devenind mai prietenos ca atunci. Dar, pentru a te putea apropia de ceva, mai întâi trebuie să îl înţelegi, aşa este şi cu calculatorul alăturat staţiei de radio. Cât priveşte logurile mele, le editez cu softuri proprii (pot fi folosite OFF-LINE dar şi ON-LINE, pun automat ora, data, verifică sintaxa etc), le-am pus şi la dispoziţia celor doritori, dar am impresia ca sunt de preferat cele străine, că au alt "iz", foarte bine şi aşa, numai să fie corect. Cat priveste editoarele recomandate de mine, am facut-o pe baza a ce am avut la dipoziţie din partea concurenţilor, interesându-mă în primul rând compatibilitatea lor cu formatul original de log. N1MM este o forţă în software, nu este însă singurul şi de aceea am încercat să arăt cum se prezintă un log corect şi pe unde se fac cele mai dese greşeli. Odată cunoscute aceste lucruri, oricine poate să verifice dacă logul editat de el este corect sau nu. 73!
Postat de Vasile - YO9FEH la 2014-09-26 11:14:42 (ora Romaniei) Dr.OM TAVI !Referitor la "azi permisul de conducere il obtine oricine il doreste" nu este chiar asa !Eu am dat de 2 ori si am picat...in Florida !!!! HI !Acolo intrebarile sunt "parsive" si au de multe ori 2 sensuri !Adaug ca am permis de conducere romanesc din 1985 ! HI !Referitor la log.NIMM se pare ca este preferat de f.multi ! O sa incercam eu cu colegul din Ploiesti sa intoducem log Cabrillo in HP Pavilion g series ca sa pot lucre si eu online ! 73 !
Postat de Liviu Soflete - YO2BCT la 2014-09-26 20:18:27 (ora Romaniei) La concursurile de UUS la care particip, obisnuiesc sa trimit logul in format EDI la organizatori din OE, 9A, S5, LZ, OK (daca am lucrat statii din tarile respective). Primirea si verificarea initiala se face de un robot care semnaleaza eventualele neconcordante si te atentioneaza unde ai gresit. Iti poti corecta si retrimite logul, pana cand robotul il accepta: atunci stii ca e corect ca format, cuvinte cheie in campurile obligatorii, etc. De obicei timpul rezervat pentru trimitere este de 7 - 10 zile, dupa care nu se mai primesc loguri electronice. Clasamentul se face automat, fiind excluse orice interventii ale "arbitrilor". Dupa publicarea clasamentului, logurile fiecarui corespondent si error log (lista erorilor depistate la controlul incrucisat) devin accesibile pentru oricine e curios. In acest fel poti sa vezi unde ai gresit si sa te corectezi data viitoare. Toata treaba e foarte transparenta, nu ai de ce sa te superi si nici pe cine (poate doar pe calculator...), n-am auzit de contestatii si nici de fraude. Inca o observatie: regulamentul nu se schimba in fiecare an. 73 si sa ne auzin in benzile de UUS!
Postat de STOLNICU Petrica - YO9RIJ la 2014-09-26 22:45:58 (ora Romaniei) Felicitari pentru articol Dr OM Tavi! Acest material face parte din ceea ce eu numesc "Educatia Concurentului in Campionatele Nationale organizate de FRR" (si nu numai!)! Am constatat in asentimentul articolului, ca sunt multi participanti dar putini concurenti la un concurs. Spun asta pentru ca foarte putini colegi dau atentie la produsul final al unei participari intr-un concurs. Faptul ca robotul corecteaza orice greseala si iti returneaza log-ul de nenumarate ori pana cand prin corectia proprie log-ul arata ok, nu ne spune decat ca mai avem de invatat si de upgrad-at cunostintele noastra in domeniu ca si concurenti. Perfectionarea nu trebuie sa fie indreptata doar la tactici de lucru! Foarte putini dintre noi prefera sa ignore noutatile in domeniu doar pentru ca pare o chestie prea meticuloasa si bineinteles plicticoasa desi este poate cea mai importanta! Hi!Succes tuturor in concursuri! Fie ca corectitudinea sa primeze! 73! de YO9RIJ
Postat de Miki - YO5AJR (yo5ajr) la 2014-09-27 01:08:16 (ora Romaniei) Aceata tema ar merita "disecata" undeva pe un forum pentru ca este de mare interes. De ex. Liviu aminteste de soft folosit la UUS. Contestele de UUS doar seamana cu cele din US prin faptul ca la UUS de multe ori se cere QRB, locatorul si altele. Ritmul este iar altfel. Pentru mine "scurtist convins" doar in CW a fost un efort sa ma adaptez la un soft de UUS. Am cautat softuri practice pt. UUS dar aici nu abunda asa ca in US. Ori - cum - parerea mea ca softul "Vuska" pentru UUS este excelenta dar este nevoie de multa rabdare pana te familiarizezi cu el. Enjoi.....(in special cei varstnici) la folosirea PC. Amintesc cu piosenie de prietenul meu,regretatul YO4HW Radu care in anii 90 mi a dat cadou programul TR4 cu toata documentatia si un optocuplor sa lucrez cu el la statia mea. 73 de Miki
Postat de Gheorghe Oproescu - Tavi - YO4BKM (yo4bkm) la 2014-09-27 07:47:19 (ora Romaniei) DR OM Liviu, YO2BCT, TNX pentru comentariu şi pentru detaliile aduse modului de exploatare a facilităţilor logurilor electronice. Asemenea încercări s-au făcut - şi se fac - şi la noi. La toate competiţiile la care am elaborat eu programul de evaluare-arbitrare (şi sunt peste 20), în lista cu rezultate apar şi fişierele de gen "error log" unde se arată cum s-a atribuit punctajul pe fiecare QSO, ce erori au fost detectate la confruntarea tuturor legăturilor în stilul "fiecare cu fiecare" sau "toate cu toate", ca să mă exprim pe scurt şi, acolo unde apar erori între înscrisurile celor doi concurenţi, se scrie imediat sub QSO-ul respectiv cum arată QSO-ul martor de la corespondent. Orice contestaţie se rezolvă între parteneri şi nu între organizator şi participanţi. Am făcut şi câteva versiuni de robot care analizează logurile primite, care să fie operaţional direct pe server, numai că aici am nevoie de ajutor din partea administratorilor de sait pentru instalarea sa, ajutor promis cam cu reticienţă de fiecare dată. O versiune simplificată a acestui robot funcţionează în toate programele de evaluare-arbitrare făcute de mine. Programul poate fi apelat de câte ori este necesar, are o opţiune de verificare-triere a logurilor înainte de confruntare-evaluare-arbitrare şi trimite logurile în două foldere (loguri corecte sintactic şi loguri cu erori, detaliind şi în ce constă eroarile), evaluarea şi arbitrarea făcându-se ulterior numai pe logurile corecte. Astfel organizatorul concursului poate avertiza participanţii cu privire la corectitudinea logului timis. Se pot face multe în acest domeniu şi salut ideea lui Miki de a fi un subiect de discuţii pe forum. 73!
Postat de Pit - YO3JW la 2014-09-27 08:46:59 (ora Romaniei) Salut Ma bucura faptul ca pana la urma Tavi ia "taurul de coarne" si incearca sa puna in discutie modul de abordare a unui element ce face parte integrata din participarea in concurs, si anume "LOGUL" Asa cum arata si Petrica multi nu dau importanta acestui aspect. Astfel apar loguri care mai de care mai ciudate. Faptul ca un anume program de concurs genereaza automat un log in formatul dat nu inseamna ca poate fi si 100% OK. Practic ar trebui ca dupa ce logul a fost generat de program sa ne aruncam un "ochi" asupra vizualizarii cu "Notepad" sau alt editor de text. Sunt numeroase erori de "tastatura" ca de exemplu "0" tastat ca "O" sau judete ciudate. In urma cu multi ani s-a incercat o oarecare standardizare a regulamentelor de concurs din YO. S-au stabilit atunci trei variante: RST+cod constant(3 semne), RST+numar crescator(serial number) si RST + cod stafeta. Pe parcurs au aparut numeroase alte variante care dpdv al verificari cu ajutorul programelor dedicate ridica probleme. De fapt pana nu ajunge la organizator logul concursul nu s-a terminat pentru participant! Dealungul timpului mai multi au contribuit la realizarea unor programe de verificare. Ar trebuie si doresc sa multumesc pentru voluntariatul lor. Majoritatea lor au fost create de fosti programatori sau de cei cu cunostinte in domeniu, pensionari azi, care au dedicat din timp lor acestei actiuni. Intre timp capacitatea de lucru a calculatoarelor au evoluat, au aparut facilitati noi. Din pacate nu prea au aparut si noi doritori de a participa voluntar. Probe sunt, dar parca fara final! Sau unii s-au retras din "n" motive! Altii mai incearca.... Consider ca ar fi normal ca sa existe cat de cat un sablon in care concursurile sa se desfasoare astfel ca un program realizat sa poata fi folosit pentru cat mai multe. Pe de alta parte ar fi minunat ca sa apara din partea celor care fac verificari(programe de verificare) cat mai multe materiale privitoare la probleme intampinate in procesul de prelucrare, chiar cu exemple edificatoare, pe intelesul tuturor, astfel ca cei care participa la concurs si fac fisele(log) sa poata sa isi indrepte greselile. De asemenea cei care fac programe pentru participare sa aduca imbunatatiri acolo unde este cazul.
Postat de Gheorghe Oproescu - Tavi - YO4BKM (yo4bkm) la 2014-09-28 09:10:11 (ora Romaniei) Şi eu mă bucur că Pit a punctat în privinţa atenţei acordate logului, inclusiv o verificare a lui după editare folosind un editor de text care există în orice sistem de operare şi nu necesită bani pentru achiziţie. Îmi amintesc că la concursurile organizate de el atrăgea atenţia în regulament asupra verificării logului după editare, pe lângă prezentarea de exemple privind înscrisurile corecte în log. Cât priveşte o reglementare cadru în privinţa regulamentelor de concurs, invocată de mai multe ori de-a lungul timpului, sunt slabe şanse. În primul rând trebuie să se implice la modul extrem de profesional o autoritate coordonatoare, spun că extrem de profesional pentru ca prin reglementări să nu strice mai rău actuala situaţie cu care ne-am obişnuit cât de cât, dar este nevoie şi de disciplină, cunoaştere corectă a problemei şi respectarea opiniei specialistului tehnocrat în contra "aerelor" date de pe alte poziţii. Această reglementare trebuie să cuprindă obligaţii (nu indicaţii!) începând cu modul cum se formează numele fişierului cu log, până la reguli de formare a controalelor şi a versiunii de log, funcţie de tipul competiţiei. Pentru asta trebuie să se implice o echipă formată din radioamatori experimentaţi în marile concursuri din zilele noastre, cunoscători în detaliu a tot ce există în materie de formate de log şi creatori de programe pentru prelucrarea logurilor. Un fel de păsări rare, după părerea mea prea puţin cultivate pe meleagurile noastre. 73!
Postat de Zoli - YO2LZA la 2014-09-29 06:52:07 (ora Romaniei) Discutia asta referitoare la intocmirea si verificarea logului online sau offline (in timpul sau dupa terminarea unui contest) cred ca ar fi bine sa fie dezbatuta pe Forum. Mi-am permis sa deschid topicul "Intocmirea si verificarea logului", va invit acolo pentru dezbateri. Zoli
Postat de Adrian Voica - YO2BPZ (yo2bpz) la 2014-09-29 09:00:36 (ora Romaniei) Incepand de anul trecut, la solicitarea mea si strict benevol, Tavi ne-a realizat softul de arbitraj pentru "Ziua telecomunicatiilor Fair Play US" si "Memorial YO7VS" 50 si 144 MHz, care au usurat extrem de mult arbitrarea concursurilor si corectitudinea acestor arbitraje. Tavi m-a ajuta punctual de fiecare data cnd am avut probleme cu unele loguri care dadeau erori de sintaxa si apareau ca "nearbitrabile" ( iar eu mi-am facut din toate explicatiile pe care mi le-a dat un document cu remedierea acestor erori). In plus, Tavi a avut bunavointa sa adapteze "din mers" softurile, functie de problemele neprevazute care apareau si a celor care nu erau clar stipulate in regulamentele concursurilor, astfel ca acum pot spune ca avem un program de arbitraj complet si corect, extem de usor de utilizat si de rapid, care da imediat clasamentele pe categorii, lista participantilor, lista statiilor "lipsa log" si logurile evaluate ale ficarei statii participante ( si care, bineinteles, a trimis logul de concurs!). In numele colegilor de la YO HD ANTENA DX GRUP Deva tinem sa ii multumim si pe aceasta cale lui Tavi, si sa ii dorim in continuare multa putere de munca (ca de pasiune si cunostinte in domeniu nu duce lipsa!) As mai mentiona si meritele participantilor, care au inteles importanta utilizarii logurilor electronice (Cabrillo si EDI). Am primit doar trei loguri pe hartie la ZT US (loguri pe care le-am scris eu Cabrillo, altfel ele nu folosec nici ca "Check Log", neputand da puncte concurentilor), si absolut toate logurile de la UKW in format EDI (sau apropiate, relativ usor de facut EDI),principalele greseli aparand in header la categoria de participare, lucru pe care l-am corectat imediat si logurile au devenit automat arbitrabile). Ce a fost mai greu, a rezolvat Tavi, inca nu am suficienta experienta pentru a vedea "din prima" greselile de sintaxa mai ascunse!). Inca odata multumiri lui Tavi pentru acest excelent material documentar, usor de priceput pentru cei care au rabdarea sa il citeasca si sa il inteleaga. 73 de Adrian, YO2BPZ
Postat de Gheorghe Oproescu - Tavi - YO4BKM (yo4bkm) la 2014-09-29 10:29:14 (ora Romaniei) TNX Adrian YO2BPZ, meritul este al clubului YO HD ANTENA care de ani (sau decenii) ţine sus drapelul perseverenţei şi al calităţii. Dacă nu ar fi vrut, dacă nu ar fi ştiut ce vrea, nu am fi realizat atătea lucruri împreună. Am mai fost solicitat pentru elaborare de softuri şi de alte organizaţii dar unele, poate cele mai importante pentru noi, au arătat că nu ştiu ce vor, nu au înţeles nici măcar cum fac alţii şi nici nu au acceptat părerea celor mai experimentaţi ca ei, de accea plutesc încă în mister. AGN TNX, 73!
Postat de Nicky - DL5MHR la 2014-10-07 21:33:17 (ora Romaniei) Am citit cu mult interes acest material , in care pe linga majoritatea problemelor reale, au aparut si citeva probleme cu care nu sint de acord. De peste 10 ani corectez logurile la YODX Contest si la Concursul Bucuresti. In primul rind, asezarea pe coloana nu poate fi asa rigida cum scrie Tavi. Practic in softurile de log nici nu este. Aceasta nu are importanta, deoarece programul de arbitrare trebuie sa citeasca "pe cuvinte" si aceasta este foarte simplu de facut. Mi s-a intimplat destul de des ca un indicativcare eventual are sui QRP sa nu poata fi scris in spatiul asa zis fix. Prpogramul de citire citeste fiecare rins indiferent de spatiile diontre ele. Pina acum am avut probleme doar cu logurile care foloseau in loc de "SPATII" ,caracterul "TAB". Noroc ca am gasit programul LM care citeste si aceste loguri si le transforma in loguri cu "SPACE". In plus, cu o problema nu sint de acord. Un log Cbr trebuie sa aibe 12 coloane ceace inpune ca controlul sa fie format din 2 cuvinte si anume 599 BU sau 599 1275. Deja aici se vede ca nr. de caractere intre BU respectiv 1275 este diferit, ceace face obligatoriu citirea pe cuvinte si nu pe pozitii fixe ale coloanelor. In plus , ceace nu s-a amintit, Headerul 2.0 este inlocuit cu Headerul 3.0 care nu mai are linia CATEGORY: si aceasta duce la probleme mari la determinarea automata de catre Soft a categoriei de participare reale deoarece daca un concurent are in Headet modul CW si a lucrat numai pe 20 m. problema este , ce vrea el SO-SB-20 sau SO-AB-CW-LP ? Aici arbitrul va trebui sa decida sau sa intrebe HI. Pe aceasta tema se mai pot scrie multe dar deocamdata atit. Ceace este important este ca softul sa citeasca pe cuvinte si fiecare rind sa aibe un numar fix de coloane cu spatiu intre RST si NUMAR CONTROL sau JUDET. In ce priveste problema cititului de catre soft pe cuvinte nu prezinta dificultati si nu ingradeste de fel scrierea logului. 73! Nicky DL5MHR
Postat de Gheorghe Oproescu - Tavi - YO4BKM (yo4bkm) la 2014-10-08 12:38:27 (ora Romaniei) @DL5MHR, bei mir sehet man ganz anderes aus, la mine se vede cu totul altfel. Asa cum arati, cu dispunere pe cuvinte, logul are 13 coloane, nu 12! Sa le numaram: 1=QSO:, 2=Banda, 3=Mod, 4=Data, 5=Timp, 6=Call, 7=RST, 8=Numar, 9=Zona, 10=Call, 11=RST, 12=Numar, 13=Zona. Cat priveste formatul standard la CABRILLO pentru US http://www.kkn.net/~trey/cabrillo/qso-template.html este aratat la sfarsitul comentariului meu, din pacate nu poate fi scris pe randuri separate, dar se poate intelege. Dupa cum se vede grupul exch (acolo unde se cere asa ceva, ca la "DARC Worked All Europe", este compus din 6 caractere, fara spatii intre ele. Primele trei caractere formeaza numarul (serial, stafeta etc), ultimele trei pot forma orice (zona din 2 caractere cu spatiu la sfarsit, niciun cuvant nu incepe cu un gol sau formeaza cod de trei caractere ca la actualul CN US SSB). Si daca este reglementat in standard ca se aloca 6 caracere pentru codul schimbat care formeaza un singur cuvant, nu ne putem permite sa il impartim in doua coduri. Si cum se va citi pe cuvinte daca cineva, care respecta norma (cum face si editorul UcxLog)are pe liniile QSO: doar 11 cuvinte? Adica il dam la corectat sau il respingem pe cel care a respectat normele (pentru ca ne permitem sa inventam alte norme) si acceptam pe cel care le incalca? Ciudata optica de a motiva interventiile in loguri. Si eu am facut programe de arbitrare la peste 20 de concursuri, (inclusiv cu trierea si identificarea erorilor de sintaxa) care se aplica, vad cum organizatorii muncesc pe loguri straine sa aranjeze coloanele pe 13 cuvinte (sau 14 daca apare si ID-ul emitatorului), desi standardul este clar, 11 coloane (12 cu ID-ul emitatorului). Sustinerea ideii de a ignora normele face ca niciodata sa nu se poata arbitra complet automat, in beneficiul cui?. Sunt si formate Cabrillo destinate anumitor cometitii precum "NAQP", "RSGB IOTA Contest" etc, care arata in regulament ce format necesita, de exemplu cer mai multe grupe "exch" dar, la modul neprecizat, formatul arata ca cel facut de editorul UcxLog. Si iata cum este explicitat formatul CABRILLO standard: QSO: freq mo date time call rst exch call rst exch. Adica, scris cu carcatere generice in succesiunea aratata, apare QSO: ***** ** yyyy-mm-dd nnnn ************* nnn ****** ************* nnn ******. Asa ca asezarea pe coloane nu este facultativa, este rigida, contine 11 cuvinte (sau 12 daca sa adauga si ID-ul emitatorului). Inainte de a incheia, un detaliu: eu imi fac singur programele, inclusiv care schimba Tab cu spatiu, asa cum si programele de arbitrare sunt facute integral "de la alfa la omega" fara sa asamblez piese disparate facute de altii. 73!
Postat de Nicky - DL5MHR la 2014-10-08 17:45:27 (ora Romaniei) Am vazut raspunsul tau la cele scrise de mine. Putin cam dur, dar asta este. In ce priveste spatiul intre RST si Nr.Control (care o fi acela9 iata ce scrie ARLL-ul QSO: freq mo date time call rst exch call rst exch QSO: ***** ** yyyy-mm-dd nnnn ************* nnn ****** ************* nnn ****** QSO: 3799 PH 2003-03-23 0711 YB1AQS 59 700 DL8WPX 59 001 Dar cine stie,poate mai gresesc si ei. Am avut un log care avea ca indicativ UA9/dl8uzt/qRP iar asta ori cit l-ai chinui nu incape in spatiul asa zis fix si normat, deci acesta nu va putea participa la concursuri HI. Oricum, cu spatiul dupa RST, anul acesta am avut de corectat cam 1100 de loguri (oricum mai mult ca la concursurile interne, cele peste 20), si din multimea de loguri, numai 2 nu au avut acel spatiu. In ce priveste TAB este posibil sa faci si in softul propriu recunoasterea acestui TAB dar a fost mai simplu (pentru 1 log din 1100) sa ma folosesc de programul LM.. In ce priveste numarul de coloane, mea culpa, sint 13 (vezi si ARRL). In ce priveste detaliile ca iti faci singur programele, asta e frumos, asa ca dupa 12 ani de verificat la YODX (de fiecare data cu rugamintea FRR) acum ca stiu ca sint si altii care pot face acest lucru ( nu e mare lucru sa treci de la 100 la peste 1000), la anul vei ramine singur. 73 Nicky DL5MHR ex YO2BK
Postat de Gheorghe Oproescu - Tavi - YO4BKM (yo4bkm) la 2014-10-08 21:30:40 (ora Romaniei) Roger, cu o precizare. In 2012 a fost folosit la YO DX HF programul meu, am si acum in calculator cele peste 1000 de loguri, unele cu peste 1300 de legaturi. Verificarea incrucisata, identificarea tarilor (facusem si un link catre o baza de date cu toate prefixele tarilor, zona, continentul), calculul scorului, ordonarea pe categorii in ordinea scorului, editarea listelor, toate au durat cca 40 de minute. Stiu ce este sa treci la peste 1000 de loguri, numai ca nu ma voi mai angaja la vreo lucrare oficiala pentru FRR, vorba cu ciorba si cu iaurtul. La cluburi particip cu mare placere, trebuie sa ne ajutam intre noi. 73!

Copyright © Radioamator.ro. Toate drepturile rezervate. All rights reserved Articole | Concursuri | Mica Publicitate | Forum YO | Pagini YO | Call Book | Diverse | Regulamentul portalului | Contact