Emisja JT65 i program JTDX

08.08.2017 11:14:05

Grupa: Użytkownik

Posty: 147 #2450593
Od: 2017-5-29

Ilość edycji wpisu: 3

Witam

Niedawno testowałem program JTDX, polecany przez SP6AB: http://sp7pki.iq24.pl/default.asp?grupa=78615&temat=455270&nr_str=1#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?

Electra

13.12.2024 07:40:16

sq2hcz

08.08.2017 11:44:41

Grupa: Użytkownik

QTH: Bydgoszcz

Posty: 840 #2450599
Od: 2009-12-30

Ilość edycji wpisu: 1

Cześć. Pracuje od kilku lat na JT65HF i widać wyraźnie że proces dekodowania ma spore zapotrzebowanie na moc obliczeniową.
Szczególnie jest to widoczne gdy na pasmie mamy spory ruch w tej emisji. Gdy trzeba zdekodować sygnał od 8 do 12 stacji mobilny procesor I5 (dwa rdzenie, 4 wątki) ma sporo do roboty i potrzebny jest czas około 5-7 sekund. Pozostałe -3-5 sekund wystarcza na klikniecie odpowiedzi. Procesor dualcore (mobilny) w podobnych sytuacjach miał problem aby się wyrobić i nie było czasu na odpowiedź. Dlatego dwa lata temu zdecydowałem się na zmianę komputera na nieco silniejszy.
W JT65-HF-HB9HQX-Edition można zmienić czas kiedy komputer zaczyna dekotować i zyskac kilka sekund kosztem nieodebrania słabszych stacji - tak rbiłem na słabszym komputerze. Obecnie dekodowanie zaczynam po odebraniu całego przekazu.

Z tymi minutowymi przerwami będzie problem - korespondent będzie przekonany że albo CIę nie słyszą albo że nie nadajesz i powtórzy wywołanie gdy będziesz nadawał z opóźnieniem. Czyli nadajecie jednocześnie i z wymiany raportów nici

.
_________________
http://sq2hcz.wordpress.com
http://www.eo.net.pl

sp8sn

08.08.2017 11:47:51

Grupa: Użytkownik

QTH: KO11FI

Posty: 228 #2450602
Od: 2017-3-13

Cześć. Sporo czasu używam JTDX i uważam, że dekoduje najlepiej ze wszystkich dostępnych. Ma również przyjemny interface.
Generalnie sygnał nadaje się w minutach parzystych lub nieparzystych. Zaczyna się od początku minuty, a kończy ok 46 sekundy. Więc od 46 sekundy do końca minuty będzie cisza. Na przykład:
08:00 - 08:46 nadajesz CQ
09:00 - 09:46 stacja odpowiada Ci podając lokator lub czasami od razu raport np -05
10:00 - 10:46 Ty odpowiadasz potwierdzając raport np R-03
11:00 - 11:46 Twój korespondent odpowiada RRR (lub RR73)
12:00 - 12:46 ty przesyłasz 73
i po łączności. Te 14-15 sekund to czas na dekodowanie, jeśli ktoś ma wolniejszy komputer, dożo sygnałów, słabe, dekodowanie może trwać kilka sekund.
Nie bardzo rozumiem Twoje pytanie "czy praktykuje się minutowe opóźnienie". Oczywiście nie bo wszystko by się rozjechało. Cyba, że poczekasz kolejną minutę i nadasz w swojej, ustalonej minucie - oczywiście korespondent musiałby czekać. Nie wiem czy o to Ci chodziło. Pozdrawiam.
_________________
Robert SP8SN

sp8sn

08.08.2017 11:55:59

Grupa: Użytkownik

QTH: KO11FI

Posty: 228 #2450606
Od: 2017-3-13

sq2hcz pisze:

sq2hcz pisze:

Cześć. Pracuje od kilku lat na JT65HF i widać wyraźnie że proces dekodowania ma spore zapotrzebowanie na moc obliczeniową.
Szczególnie jest to widoczne gdy na pasmie mamy spory ruch w tej emisji. Gdy trzeba zdekodować sygnał od 8 do 12 stacji mobilny procesor I5 (dwa rdzenie, 4 wątki) ma sporo do roboty i potrzebny jest czas około 5-7 sekund. Pozostałe -3-5 sekund wystarcza na klikniecie odpowiedzi. Procesor dualcore (mobilny) w podobnych sytuacjach miał problem aby się wyrobić i nie było czasu na odpowiedź. Dlatego dwa lata temu zdecydowałem się na zmianę komputera na nieco silniejszy.
W JT65HF można zmienić czas kiedy komputer zaczyna dekotować i zyskac kilka sekund kosztem nieodebrania słabszych stacji - tak rbiłem na słabszym komputerze. Obecnie dekodowanie zaczynam po odebraniu całego przekazu.

Z tymi minutowymi przerwami będzie problem - korespondent będzie przekonany że albo CIę nie słyszą albo że nie nadajesz i powtórzy wywołanie gdy będziesz nadawał z opóźnieniem. Czyli nadajecie jednocześnie i z wymiany raportów nici .

jak pisałem Twojego wpisu jeszcze nie było

_________________
Robert SP8SN

sq2hcz

08.08.2017 12:33:30

Grupa: Użytkownik

QTH: Bydgoszcz

Posty: 840 #2450617
Od: 2009-12-30

Się pisały razem

_________________
http://sq2hcz.wordpress.com
http://www.eo.net.pl

sp6efy

08.08.2017 13:04:57

Grupa: Użytkownik

QTH: Wrocław JO72ox

Posty: 1082 #2450633
Od: 2011-6-19

Istotny jest dokładny czas..

Tu jest programik do ustawiania czasu atomowego :
"Allzeit atomzeit"
https://de.softonic.com/download/allzeit-atomzeit/post-download?sl=1
_________________
433.500,145.350,70.260 Janusz, Barlinek JO72ox

SP3ANL

08.08.2017 13:16:56

Grupa: Użytkownik

Posty: 147 #2450636
Od: 2017-5-29

sp8sn pisze:

Cześć. Sporo czasu używam JTDX i uważam, że dekoduje najlepiej ze wszystkich dostępnych. Ma również przyjemny interface.
Generalnie sygnał nadaje się w minutach parzystych lub nieparzystych. Zaczyna się od początku minuty, a kończy ok 46 sekundy. Więc od 46 sekundy do końca minuty będzie cisza. Na przykład:
08:00 - 08:46 nadajesz CQ
09:00 - 09:46 stacja odpowiada Ci podając lokator lub czasami od razu raport np -05
10:00 - 10:46 Ty odpowiadasz potwierdzając raport np R-03
11:00 - 11:46 Twój korespondent odpowiada RRR (lub RR73)
12:00 - 12:46 ty przesyłasz 73
i po łączności. Te 14-15 sekund to czas na dekodowanie, jeśli ktoś ma wolniejszy komputer, dożo sygnałów, słabe, dekodowanie może trwać kilka sekund.
Nie bardzo rozumiem Twoje pytanie "czy praktykuje się minutowe opóźnienie". Oczywiście nie bo wszystko by się rozjechało. Cyba, że poczekasz kolejną minutę i nadasz w swojej, ustalonej minucie - oczywiście korespondent musiałby czekać. Nie wiem czy o to Ci chodziło. Pozdrawiam.

Zgadza się, że każda łączność JT65 powinna wyglądać właśnie tak, jak napisałeś. Problem w tym, że prawie całe 12 sekund zajmuje odczytywanie komunikatów i pierwsze komunikaty pojawią się od razu, a ostatnie pojawiają się najwcześniej pod koniec minuty (zostaje 2-3 sekundy czasu na kliknięcie odpowiedzi), a zdarza się, że jeszcze później a także po rozpoczęciu następnej (kiedy już musi być podjęta decyzja, na jakiej częstotliwości dźwięku i jaki komunikat chcę nadać). Właśnie w tej sytuacji wypada się z rytmu i ogólnej zasady prowadzenia takiej łączności. Jakby dekodowanie trwało 3-5 sekund za każdym razem, to problem by nie istniał. Pytając o to samo w innych słowach: Załóżmy, że jako ostatni komunikat jest CQ od stacji, która mnie interesuje. Czy w takiej sytuacji można odpowiedzieć w kolejnej minucie lub dwie minuty później, czy trzeba uznać, że łączność z tą stacją nie jest możliwa? Domyślam się (tego jeszcze nie testowałem), że w trakcie nadania odpowiedzi można włączyć przycisk "Filter" i wtedy kolejne komunikaty będą dekodowane znacznie szybciej, bo z wąskiego wycinka (chyba po to jest ta funkcja).

Skoro masz doświadczenie w JTDX, to czy testowałeś różne ustawienia dekodowania JT65 w oknie "Settings", zakładka "Advanced" i ramka "JT65 decoding parameters"? Chodzi o głównie liczbę prób i liczbę przebiegów dekodowania. Jak masz to ustawione, czy też odpowiednio "3" i "4", czy to zmieniałeś? Zauważyłem, że jak zmienię liczbę prób na 1, to program szybciej kończy wyświetlanie komunikatów, ale jest ich mniej, ale nie wiem, według jakiej reguły program dekoduje. Zauważyłem, że nie jest to prawda, że zaczyna od najsilniejszych komunikatów. Nie bardzo rozumiem, o co chodzi, że program próbuje kilka razy zdekodować to samo (domyślnie 3 razy).

Wolę zapytać kogoś doświadczonego oprócz czasochłonnego testowania działania na nagraniach z eteru, gdzie jeden test z jednym nagraniem jednej minuty trwa co najmniej dwie minuty (pierwsza na odtworzenie nagrania uruchomionego dokładnie w pełnej minucie i obserwacja zdekodowanych komunikatów, a druga na sprawdzenie, co program odczytał i zmianę ustawień do następnego testu).

sp6ab

08.08.2017 13:21:42

Grupa: Użytkownik

QTH: Lubin

Posty: 272 #2450637
Od: 2016-4-5

Ilość edycji wpisu: 2

Ja mam laptop Lenovo X201 z procesorem i7 i powiem, że czasami jak jest dużo słabych sygnałów to też się nie wyrobi w czasie dekodowania. Zawsze można kliknąć te 1-2 sekundy później jak inaczej nie można, z doświadczenia wiem, że program u korespondenta sobie raczej poradzi. Nie polecam natomiast czekania całej minuty, jeden korespondent powtórzy ostatni komunikat a inny niecierpliwy zacznie nadawać CQ.
BTW. słyszałem, że WSJT-X w nowej wersji ma już też poprawione dekodowanie JT65 ale jeszcze tego nie weryfikowałem.

P.S. Czasu nie synchronizuj ręcznie, są do tego programy np http://www.thinkman.com/dimension4/ lub https://www.meinbergglobal.com/english/sw/ntp.htm Klient NTP wbudowany w Windows nie radzi sobie dobrze z synchronizacją.
_________________
Artur

SP3ANL

08.08.2017 13:27:09

Grupa: Użytkownik

Posty: 147 #2450638
Od: 2017-5-29

Ilość edycji wpisu: 1

sp6efy pisze:

Istotny jest dokładny czas..

Tu jest programik do ustawiania czasu atomowego :
"Allzeit atomzeit"
https://de.softonic.com/download/allzeit-atomzeit/post-download?sl=1

Spróbuję z tym programem i innymi do synchronizacji czasu. Czas miałem ustawiony tak:
1. W komputerze stacjonarnym zsynchronizowałem czas za pomocą funkcji wbudowanej w Windows.
2. W tablecie (od zakupu nigdy nie podłączany do internetu) ustawiłem ręcznie czas co do sekundy i odchylenie sekund jest praktycznie niewidoczne.
3. W komputerze stacjonarnym do testów z WebSDR przesunąłem zegar do tyłu o kilka sekund tak, żeby spóźniał się na tyle, ile wynosi opóźnienie sygnału z WebSDR.

Czy rozsynchronizowanie czasu (maksymalnie pół sekundy w stosunku do czasu rzeczywistego, a właściwie do czasu sygnału) może być przyczyną wyraźnego spowolnienia, ale poprawnego dekodowania? Z drugiej strony, to nie może mieć znaczenia, bo różne filtry cyfrowe w transceiverach i odbiorniki SDR powodują nieznaczne opóźnienie sygnału (niesłyszalne na ucho, ale pewnie jakieś są).

Tablet mogę ewentualnie podłączyć przez WiFi i na nim też zsynchronizować zegar tymi programami.

sp8sn

08.08.2017 14:50:59

Grupa: Użytkownik

QTH: KO11FI

Posty: 228 #2450675
Od: 2017-3-13

Ilość edycji wpisu: 1

Jeśli zaczniesz 5 sekund później w swojej minucie nic się nie stanie.
Chodzi mi o to, że jeśli stacja woła CQ od np. 9:00 do 9:46 a Ty zdekodujesz np o 10:05 nie przejmuj się. Kliknij na nią i tyle. Nawet 30 sekund sygnału wystarczy do poprawnego zdekodowania (nie testowałem ile najmniej). Także jeśli w takiej sytuacji zaczniesz odpowiadać o 10:05 nic się nie stanie, powinno być ok. Lepiej spróbować bo jeśli będziesz czekał, stacja wołająca zobaczy pustkę przez 10sec i zrobi qsy lub wyłączy radio i pójdzie spać HI, nie będzie czekać. Nawet jeśli zobaczy jakiś ślad i nie zdekoduje, poczeka na kolejną próbę. Jeśli natomiast Ty wołasz CQ, ktoś odpowie, ale nie zdążysz zdekodować i zaczniesz wołać znowu CQ, nie przejmuj się, kliknij jak najszybciej na zdekodowany znak i zacznij mu odpowiadać. Jeśli nawet o 10:00 zaczniesz wołać CQ, a w międzyczasie zdekodujesz i klikniesz, zmieni się wysyłana wiadomość o np. 10:07 - powinna dotrzeć. W JT65 czas nie jest krytyczny co do sekundy. Oczywiście lepiej jak jest. Gorzej jest w np. FSK przy łącznościach MS bo tam przy 5sec możesz całkowicie stracić wiadomość. Jeśli chodzi o ustawienia to podeślę jak będę w domu.
_________________
Robert SP8SN

sp8sn

08.08.2017 17:18:58

Grupa: Użytkownik

QTH: KO11FI

Posty: 228 #2450701
Od: 2017-3-13

moja konfiguracja

_________________
Robert SP8SN

Electra

13.12.2024 07:40:16

SP3ANL

08.08.2017 20:22:34

Grupa: Użytkownik

Posty: 147 #2450734
Od: 2017-5-29

Ilość edycji wpisu: 1

sp8sn pisze:

moja konfiguracja

Dzięki, widzę, że posługujesz się ustawieniami domyślnymi. Wyczytałem, że są 3 warianty JT65, których główną różnicą jest szerokość pasma. Czy warianty JT65B i JT65C też się używa? Z tego, co widzę, programy, które testowałem, obsługują wyłącznie wariant JT65A.

sp8sn

08.08.2017 20:58:55

Grupa: Użytkownik

QTH: KO11FI

Posty: 228 #2450748
Od: 2017-3-13

aha a do pilnowania czasu używam NetTime - http://www.timesynctool.com/
mały i lekki
_________________
Robert SP8SN

usuniety8_02_2021

08.08.2017 21:08:25

Grupa: Użytkownik

QTH: Suszec JO90JB

Posty: 9221 #2450754
Od: 2008-10-24

Ja używam tego programu do synchronizacji czasu

http://www.maniaradio.it/en/bkttimesync.html

sp7iit

08.08.2017 21:32:18

Grupa: Użytkownik

QTH: Krzysztof Kielce

Posty: 782 #2450764
Od: 2008-11-17

JTDX najlepszy program do jt65 jaki do tej pory używałem. W połączeniu z JTAlert i HamSpots i odpowiednim ustawieniu TCP z Logger32 daje pełen komfort pracy. Przy słabszym komputerze i dużym ruchu na paśmie mogą występować pewne opóźnienia przy dekodowaniu ale to nie problem. Czekam kilka sekund i odpowiadam stacji która minie interesuje. Przy dawaniu CQ można włączyć filtr i wtedy wszystko się wyrabia.
_________________

http://sp7iit.wixsite.com/krzysztof
https://www.qrz.com/db/SP7IIT

sp8sn

08.08.2017 21:39:03

Grupa: Użytkownik

QTH: KO11FI

Posty: 228 #2450769
Od: 2017-3-13

sp7iit pisze:

JTDX najlepszy program do jt65 jaki do tej pory używałem. W połączeniu z JTAlert i HamSpots i odpowiednim ustawieniu TCP z Logger32 daje pełen komfort pracy. Przy słabszym komputerze i dużym ruchu na paśmie mogą występować pewne opóźnienia przy dekodowaniu ale to nie problem. Czekam kilka sekund i odpowiadam stacji która minie interesuje. Przy dawaniu CQ można włączyć filtr i wtedy wszystko się wyrabia.

raz jeszcze potwierdzam, szkoda tylko, że nie ma FT8, używam zamiennie WSJT-X czasami
PS -> sp7iit - odbierałem ładnie CQ RTTY na 60m
_________________
Robert SP8SN

usuniety8_02_2021

08.08.2017 22:22:50

Grupa: Użytkownik

QTH: Suszec JO90JB

Posty: 9221 #2450782
Od: 2008-10-24

Robert

Podejrzewam że FT8 pojawi się w JTDX w niedługim czasie.

Kolega Igor dostaje monity o ten Mode od kolegów.

sp7iit

09.08.2017 06:57:44

Grupa: Użytkownik

QTH: Krzysztof Kielce

Posty: 782 #2450815
Od: 2008-11-17

Robert to czemu nie zawołałeś ? Co do FT8 to Janek ma rację to kwestia czasu...

_________________

http://sp7iit.wixsite.com/krzysztof
https://www.qrz.com/db/SP7IIT

sp7iit

09.08.2017 07:03:46

Grupa: Użytkownik

QTH: Krzysztof Kielce

Posty: 782 #2450816
Od: 2008-11-17

A może kogoś zainteresuje ??

Dear Fellow Radio Amateurs,

Russian Digital Radio Club announces a new event which is planned to be held annually at the end of summer. We invite fans of digital modes of radio communication to JT9 Activity Days «Make haste slowly» which will take place from
00:00 UTC Friday August 25 to 23:59 UTC Sunday August 27, 2017
on all HF-bands from 160 to 10 meters. Repeated QSO can be made on different bands. The obligatory condition of each QSO is to preserve in adif file of the Log: the received locator; distance to the correspondent in kilometers which we recommend to write down in the "Comments" field. To display the distance in kilometers (not in miles), in the settings of the program "File-Setting-General" there should be no "tick" in the "Display distance in miles". Only those QSO in which the above information is indicated are taken into account. The occupied places will be distributed according to the sum of the distances to correspondents. The result of each participant in the totals will be presented in the overall standings, including separately by bands.

We announce the following prize contests:
• «A picture is worth a thousand words» - The winner of the contest will be awarded RDRC pennant for the largest number of QSOs with correspondents who are at a distance of more than 10.000 kilometers. If the number of QSO is equal for two or more participants, when determining the winner the sum of the distances will be taken into account first, and then the number of bands on which these QSOs were made.
• «As the call, so the echo» - One pennant of the RDRC will be drawn in a lottery between the participants in this competition with a result of over 100,000 kilometers.
• «Half a loaf is better than no bread» - One pennant of the RDRC will be drawn in a lottery between the participants in this competition who will show the best results on each of the bands.

Recommended frequency bands, see the Rules for Activity Days «01-10». We recommend using the JTDX program, new versions are available at qrz.lt/ly3bg/JTDX. JTDX and other programs you can also download on the website of RDRC in the section Program Archive. Reports in adif-format (.adi) should be sent to e-mail address 01-10(at)rdrclub.ru before 23:59 UTC on August 31, 2017. The report file should be named by your callsign (for example RK3DSW.adi). In your letter specify the last name, first name, patronymic, postal home address.

We are waiting for you on August 25, 26 and 27 on the band frequencies for JT9!
JT9 Activity Days «Make haste slowly» : RULES http://www.rdrclub.ru/dni-aktivnosti-rtsrk/825-jt9-activity

_________________

http://sp7iit.wixsite.com/krzysztof
https://www.qrz.com/db/SP7IIT

sp8sn

09.08.2017 07:30:37

Grupa: Użytkownik

QTH: KO11FI

Posty: 228 #2450821
Od: 2017-3-13

sp7iit pisze:

Robert to czemu nie zawołałeś ? Co do FT8 to Janek ma rację to kwestia czasu...

Nie zdążyłem wyregulować sobie sprzętu. Używam wzmacniacza na to pasmo i trudno mi wyregulować tak aby wychodziła mała moc. Mam to dopracowane w JTDX i WSJT, a w RTTY i FLDIGI jeszcze nie nadawałem.
FLDIGI nie ma suwaka poziomu wyjściowego na wierzchu i muszę pokombinować z poziomem w sterowniku karty dźwiękowej. Nie chciałem przyładować kilkuset W przez przypadek.
Nie nadaję samym radiem (IC746) na 60m bo boję się o filtry LPF. Nie są zaprojektowane na to pasmo i mogą się grzać nawet przy małej mocy. Gdzieś czytałem opinie aby nie nadawać na 60m IC746, wolę nie ryzykować.
Filtry LPF we wzmacniaczu sam robiłem i wiem, że sekcja z 40m pracuje ok na 60m. W zestawieniu ze wzmacniaczem z radia wystarczą mW.
_________________
Robert SP8SN

Electra

13.12.2024 07:40:16