| Strona: 1 / 2>>> strony: [1]2 |
Emisja JT65 i program JTDX | |
| | SP3ANL | 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 | 12.12.2024 00:50:22 |
|
| | | 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 |
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 | 12.12.2024 00:50:22 |
|
| | | 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
|
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 | 12.12.2024 00:50:22 |
|
|
| Strona: 1 / 2>>> strony: [1]2 |
Aby pisac na forum musisz sie zalogować !!! |
|