sq7m pisze:
Słuszna uwaga
, a ostatecznie jest tak, że Krzysztof miał racje. W przypadku jego łączności to ostatnie QSO powinno być za zero punktów.
SN5N →,, QSO z DA3T (3 wpisów)
Czas Pasmo RST wys. Nr wys. RST odb. Nr odb. Status
20:01 40M 599 67 599 48 OK
20:17 40M 599 106 599 75 OK
20:27 40M 599 130 599 90 ★,, OK
*QSO w tym samym etapie co poprzednie z DA3T, ale DA3T potwierdził w różnych etapach — QSO zaliczone
DA3T →,, QSO z SN5N (3 wpisów)
Czas Pasmo RST wys. Nr wys. RST odb. Nr odb. Status
20:01 40M 599 48 599 67 OK
20:17 40M 599 75 599 106 OK
20:27 40M 599 90 599 130 ★,, OK
QSO w tym samym etapie co poprzednie z SN5N, ale SN5N potwierdził w różnych etapach — QSO zaliczone
To QSO z *OK nie powinno dawać punktu. Już nad tym pracuję. Wyobraźcie sobie jednak taki przypadek. Trochę zmodyfikuję ale za przykład weźmiemy Krzysztofa. Popatrzcie na godziny SN5N (dwa różne etapy) a u DA3T ten sam etap. Czy QSO ma być błędne dla SN5N i DA3T czy może jednak uznać za prawidłowe dla jednego i drugiego operatora?
@Krzysztof tutaj uwaga do Ciebie. Na początku tego wątku napisałeś, że 1 minuta rozbieżności to za bardzo restrykcyjnie, bo nie kązdy synchronizuje zegary (powoływałeś się na doświadczenie z PGA-TEST) - popraw jeśli się mylę. To w takim razie w poniższym przypadku podchodzić mniej restrykcyjnie czy jednak jak sugerujesz patrzeć surowym okiem.
SN5N →,, QSO z DA3T (3 wpisów)
Czas Pasmo RST wys. Nr wys. RST odb. Nr odb. Status
20:01 40M 599 67 599 48 OK
20:15 40M 599 106 599 75 OK
*QSO w tym samym etapie co poprzednie z DA3T, ale DA3T potwierdził w różnych etapach — QSO zaliczone
DA3T →,, QSO z SN5N (3 wpisów)
Czas Pasmo RST wys. Nr wys. RST odb. Nr odb. Status
20:01 40M 599 48 599 67 OK
20:14 40M 599 75 599 106 OK
QSO w tym samym etapie co poprzednie z SN5N, ale SN5N potwierdził w różnych etapach — QSO zaliczone
SP3RXO pisze:
Nie pogubił się, bo algorytmy robią to, co im sie każe a nie to, co aktualnie sobie życzą.
so7na pisze:
Może się algorytm pogubił w tym, że DA3T był najpierw w 3 periodzie (20:01) a potem dwa razy w czwartym (20:17, 20:27) i ten ostatni z czwartego zmiksował z tym z trzeciego
Może się algorytm pogubił w tym, że DA3T był najpierw w 3 periodzie (20:01) a potem dwa razy w czwartym (20:17, 20:27) i ten ostatni z czwartego zmiksował z tym z trzeciego
Nie pogubił się, bo algorytmy robią to, co im sie każe a nie to, co aktualnie sobie życzą.
Słuszna uwaga
, a ostatecznie jest tak, że Krzysztof miał racje. W przypadku jego łączności to ostatnie QSO powinno być za zero punktów.SN5N →,, QSO z DA3T (3 wpisów)
Czas Pasmo RST wys. Nr wys. RST odb. Nr odb. Status
20:01 40M 599 67 599 48 OK
20:17 40M 599 106 599 75 OK
20:27 40M 599 130 599 90 ★,, OK
*QSO w tym samym etapie co poprzednie z DA3T, ale DA3T potwierdził w różnych etapach — QSO zaliczone
DA3T →,, QSO z SN5N (3 wpisów)
Czas Pasmo RST wys. Nr wys. RST odb. Nr odb. Status
20:01 40M 599 48 599 67 OK
20:17 40M 599 75 599 106 OK
20:27 40M 599 90 599 130 ★,, OK
QSO w tym samym etapie co poprzednie z SN5N, ale SN5N potwierdził w różnych etapach — QSO zaliczone
To QSO z *OK nie powinno dawać punktu. Już nad tym pracuję. Wyobraźcie sobie jednak taki przypadek. Trochę zmodyfikuję ale za przykład weźmiemy Krzysztofa. Popatrzcie na godziny SN5N (dwa różne etapy) a u DA3T ten sam etap. Czy QSO ma być błędne dla SN5N i DA3T czy może jednak uznać za prawidłowe dla jednego i drugiego operatora?
@Krzysztof tutaj uwaga do Ciebie. Na początku tego wątku napisałeś, że 1 minuta rozbieżności to za bardzo restrykcyjnie, bo nie kązdy synchronizuje zegary (powoływałeś się na doświadczenie z PGA-TEST) - popraw jeśli się mylę. To w takim razie w poniższym przypadku podchodzić mniej restrykcyjnie czy jednak jak sugerujesz patrzeć surowym okiem.
SN5N →,, QSO z DA3T (3 wpisów)
Czas Pasmo RST wys. Nr wys. RST odb. Nr odb. Status
20:01 40M 599 67 599 48 OK
20:15 40M 599 106 599 75 OK
*QSO w tym samym etapie co poprzednie z DA3T, ale DA3T potwierdził w różnych etapach — QSO zaliczone
DA3T →,, QSO z SN5N (3 wpisów)
Czas Pasmo RST wys. Nr wys. RST odb. Nr odb. Status
20:01 40M 599 48 599 67 OK
20:14 40M 599 75 599 106 OK
QSO w tym samym etapie co poprzednie z SN5N, ale SN5N potwierdził w różnych etapach — QSO zaliczone
Michał,
W TTC są aż trzy warunki czasowe sprawdzania i zaliczenia QSO
1. Sprawdzenie ilości QSO w danym ETAPIE
2. Sprawdzenie różnicy czasu 3 min w danym ETAPIE
3. Sprawdzenie różnicy czasu 3 minut gdy na przejściu z jednego ETAPU do drugiego.
W PGA-TEST jest tylko jeden warunek 3 min i to nie jest jednoznaczne z tymi warunkami TTC
Uważam że najpierw dostosuj ROBOT aby zaliczał QSOs zgodnie z zasadą 1 i 2 kiedy nie ma różnicy czasu
(mam nadzieję że nie będzie skomplikowane).
Natomiast wymyśl jak napisać kod aby sprawdzał czas na przejściu z ETAPU na ETAP w sytuacji że ktoś nie zsynchronizował czasu w komputerze.
Mogę tylko podpowiedzieć zainteresowanych aby zainstalowali program który na bieżąco synchronizuje zegar w komputerze.
Ja od lat używam Network time synchronization i nie mam problemy z czasem w komputerze.
>>>DOPISANE<<<:
Przejrzałem kilka regulaminów zawodów out SP i nie udało mi się znależć aby organizatorzy tak RESTRYKCYJNIE podchodzili i sprawdzali różnicę czasu.
Wydaje mi się że w zawodach krajowych w SP jest to relikt z przeszłości kiedy nie było takich narzędzi jak komputery i niestety trzeba było
ustawiać wskazówki zegara przed zawodami.
Proponuje aby organizator usunął z regulaminu ten zapis Różnica czasu w logach > 3 minuty wzorem innych organizatorów zawodów zagranicznych.
Jak jest opinia innych zawodników i ORGANIZATORA?