Mój UR5EQF_LOG
Konfiguracja, ustawienia, możliwości
Może to coś wyjaśni i pomoże.
A poza tym to zdrowych i spokojnych Świąt Wielkanocnych!


6 kwietnia 2020 r .: Nowa wersja TQSL (v2.5.2) -

Ta wersja Trusted QSL (TQSL) ma nowe funkcje, a także poprawki dla błędów wykrytych od czasu wydania TQSL 2.5.1.

Ta wersja zawiera także aktualizację najnowszego pliku konfiguracyjnego TQSL. Podstawową zmianą dla TQSL 2.5.2 jest funkcja, która pozwala programom rejestrującym, w połączeniu z TQSL, unikać nieprawidłowego przesyłania QSO, a jednocześnie dodaje mechanizmy umożliwiające łatwe przesyłanie logów dla stacji roamingowych. Aby uzyskać więcej informacji, zobacz „Główne dodatki funkcji” poniżej.

TQSL 2.5.2 można zainstalować w celu uaktualnienia dowolnej starszej wersji TQSL.

Najważniejsze dodatki:

Gdy dziennik jest podpisywany przez TQSL, dane stacji (znak wywoławczy, jednostka DXCC, Gridsquare i inne szczegóły QTH podane przez wybraną lokalizację stacji (i certyfikat znaku wywoławczego) są porównywane ze szczegółami dostarczonymi przez dziennik. Stan to jedna wartość, ale lokalizacja stacji daje inną, TQSL odrzuca to QSO. Umożliwi to wykrycie błędów w przypadku nieprawidłowego wyboru lokalizacji stacji. Ta funkcja wymaga, aby dziennik dostarczył szczegółów stacji, które wcześniej nie były używane przez TQSL. program rejestrujący dostarcza je (MY_STATE, MY_DXCC, MY_CQ_ZONE itp.), a następnie TQSL zweryfikuje je w dzienniku. Dzienniki Cabrillo używają teraz pola „Mój znak wywoławczy”, aby sprawdzić, czy QSO są dla prawidłowego znaku wywoławczego.

Opcjonalnie stacja wykonująca operacje roamingowe (wiele pól siatki) może zdecydować, że TQSL przyjmie, że dziennik jest poprawny. Gdy znak dziennika lub QTH zostaną dostarczone z dziennikiem, TQSL automatycznie zaktualizuje szczegóły dotyczące przesyłania do dziennika. To zachowanie można włączyć, wybierając opcję „Zastąp lokalizację stacji szczegółowymi danymi QTH z dziennika” na stronie preferencji „Obsługa dziennika”.

Przesyłając prośby o amerykańskie znaki wywoławcze 1x1, które zawsze muszą być podpisane, upewnij się, że przepływ poprawnie oznacza znak wywoławczy jako 1x1 oraz że wnioskodawca ma ważny certyfikat znaku wywoławczego, którego można użyć do podpisania tego żądania.

Najważniejsze dodatki:

Gdy dziennik jest podpisywany przez TQSL, dane stacji (znak wywoławczy, jednostka DXCC, Gridsquare i inne szczegóły QTH podane przez wybraną lokalizację stacji (i certyfikat znaku wywoławczego) są porównywane ze szczegółami dostarczonymi przez dziennik. Stan to jedna wartość, ale lokalizacja stacji daje inną, TQSL odrzuca to QSO. Umożliwi to wykrycie błędów w przypadku nieprawidłowego wyboru lokalizacji stacji. Ta funkcja wymaga, aby dziennik dostarczył szczegółów stacji, które wcześniej nie były używane przez TQSL. program rejestrujący dostarcza je (MY_STATE, MY_DXCC, MY_CQ_ZONE itp.), a następnie TQSL zweryfikuje je w dzienniku. Dzienniki Cabrillo używają teraz pola „Mój znak wywoławczy”, aby sprawdzić, czy QSO są dla prawidłowego znaku wywoławczego.

Opcjonalnie stacja wykonująca operacje roamingowe (wiele pól siatki) może zdecydować, że TQSL przyjmie, że dziennik jest poprawny. Gdy znak dziennika lub QTH zostaną dostarczone z dziennikiem, TQSL automatycznie zaktualizuje szczegóły dotyczące przesyłania do dziennika. To zachowanie można włączyć, wybierając opcję „Zastąp lokalizację stacji szczegółowymi danymi QTH z dziennika” na stronie preferencji „Obsługa dziennika”.

Przesyłając prośby o amerykańskie znaki wywoławcze 1x1, które zawsze muszą być podpisane, upewnij się, że przepływ poprawnie oznacza znak wywoławczy jako 1x1 oraz że wnioskodawca ma ważny certyfikat znaku wywoławczego, którego można użyć do podpisania tego żądania.

Wady naprawione:

TQSL wyświetla teraz komunikat o błędzie, gdy nierozpoznany plik jest ładowany jako plik certyfikatu znaku wywoławczego. Wcześniej TQSL po prostu ignorował niepoprawny plik.
Gdy TQSL weryfikuje amerykański znak wywoławczy, może się nie powieść i odrzucić żądanie certyfikatu znaku wywoławczego, jeśli dane z FCC zostały uszkodzone. TQSL teraz ignoruje dane w wielu z tych przypadków, wykonując dodatkowe wyszukiwania znanych dobrych znaków wywoławczych, aby sprawdzić, czy dane ULS są prawidłowe. TQSL podaje teraz datę ostatniej aktualizacji bazy danych ULS dla wyświetlanego komunikatu z informacją, że brakuje danych ULS. Gdy pobieranie danych ULS nie powiedzie się, TQSL nie odrzuca już żądań certyfikatu znaku wywoławczego, które mogą działać bez danych adresowych.
TQSL zgłasza teraz, kiedy nie jest w stanie otworzyć plików potrzebnych do połączenia z Logbook. Zdarzały się przypadki, gdy podczas instalacji brakowało krytycznych plików, ale wyświetlany błąd nie dostarczał użytecznych wskazówek dotyczących jego naprawy.


  PRZEJDŹ NA FORUM