Witam
Niedawno testowałem program JTDX, który był tu polecany: http://sp7pki.iq24.pl/podglad_posta.asp?id_komentarza=2431264
On faktycznie potrafi dużo zdekodować, a ZTCW, właśnie po to wymyślono JT65, żeby móc odczytać komunikat z prawie niesłyszalnego sygnału. Wcześniej testowałem JT65-HF, ale wydaje mi się, że mniej on dekoduje.
Testowałem na dwóch komputerach (stacjonarny z Windows 8 oraz tablet x86 z Windows 10). W obu przypadkach, zdekodowane komunikaty pojawiały się praktycznie przez cały czas przerwy (od ok. 46 sekundy do końca minuty), a zdarzało się, że pojawiały się kolejne po rozpoczęciu następnej minuty. W obu komputerach ręcznie ustawiałem czas tak, żeby sygnały JT65 rozpoczął się krótko po wybiciu pełnej minuty (na stacjonarnym testowałem z holenderskim WebSDR i uwzględniłem opóźnienie sygnału). Na tablecie testowałem z TRX FT-991. W obu przypadkach testowałem w paśmie 20m
W przypadku samego nasłuchu, to żaden problem, ale problem jest wtedy, gdy zechce się przeprowadzić łączność.
Czy to jest kwestia ustawień liczby przebiegów (passes) i prób (attempts) dekodowania, czy coś innego trzeba ustawić? Zauważyłem, że przy mniejszej liczbie prób czasem szybciej kończy dekodowanie, ale wyświetla mniej komunikatów.
Oczywiście, w takiej sytuacji nie da się przeprowadzić standardowej łączności, w której w co drugiej minucie wysyła się komunikat, a w pozostałych się odbiera komunikat wysyłany przez korespondenta.
Czy praktykuje się minutowe opóźnienie w odpowiedzi, tzn, że w pierwszej minucie słucham komunikatu, w końcówce pierwszej minuty lub na początku drugiej pojawia się komunikat (np. CQ lub CQ DX, który mnie zainteresuje lub komunikat kierowany bezpośrednio do mnie), a w trzeciej minucie wysyłam odpowiedź? Czy może tak jest, że jeżeli nie zdołam wysłać odpowiedzi w drugiej minucie, to wysyła się w czwartej, zgonie z zasadą, że podczas jednej łączności nadawanie przebiega w parzystych minutach, a odbiór w nieparzystych (lub odwrotnie)?
Czy po prostu w takiej sytuacji nie da się przeprowadzić łączności?