Forum Krótkofalarskie PKI

Witam. Po nową wersję proszę na prv, bo z tego co widzę nikt publicznie nie udostępnia.
Pozdrawiam.

HF1D pisze:

Pierwszy tryb, ktory posiada protokół korekcji błędów i tu pewnie pojawią się zastrzeżenia, że program zgaduje, a nie dekoduje.
Natomiast JT9 jest zdecydowanie czulszy.(...)

Czy sugerujesz że poprzednie tryby JT nie posiadały korekcji błędów?

Tak sobie słucham na 14.074 i widzę sporo transmisji tyle tylko że wsjt-x 1.7.1 nic nie dekoduje ciekawe...
Robert

EI2KK pisze:



Moze to juz ten nowszy protokol o ktorym Jurek pisal..

Być może....

Witam. Jest już dostępna wersja 1.8.0:
http://physics.princeton.edu/pulsar/K1JT/wsjtx-1.8.0-rc1-win32.exe

EI2KK pisze:



Oh, takie zgadywanie jest powszechnie i od dawna akceptowane w srodowisku...
Calkem sporo dxpedycji tak wlasnie pracije, swoj znak podaja co kilkanascie minut, a korespondenci zgaduja ze to ta dxpedycja po pileupie i wpisach na dxcluster.. a te wpisy na cluster tez daja ci, ktorzy znaku dxpedycji nie uslyszeli..

Korekcja bledow to nie to samo co zgadywanie, algorytm kodowania pozwala odtworzyc dane pozornie utracone na podstawie danych dodatkowych. Tak wiec informacja zdekodowana, to informacja odebrana, tyle ze w dosc specyficzny sposob kodowana/dekodowana. Kazdy protokol korekcji bledow ma pewien ich poziom, powyzej ktorego juz sobie nie poradzi..

Mozna to zobrazowac w bardzo duzym uproszczeniu na takim przyklsdzie:
przesylamy 4 cyfry i ich sume jako liczbe kontrolna..

odebralismy:
3 5 ? 2 checksume 14

Jakiej cyfry nie odebralismy bezposrednio?
Czy informacja jaka jest brakujaca cyfra zostala przeslana i odebrana?

To bardzo prosty przyklad, tylko jedna cyfra moze zostac utracona, ale pokazuje ze nie ma tu zadnego zgadywania, czysta matematyka, ktora przy bardzo wydajnych algorytmach jest nieco bardziej skomplikowana..

Tak wiec, jesli ktos twierdzi ze korekcja bledow to zgadywanie, to pokazuje tylko ze nie bardzo wie o czym mowi

Nie do końca się zgodzę. Wszystko co napisałeś o korekcji ma oczywiście sens jeśli jedynym źródłem informacji jest odebrany przez antenę sygnał. Jest jednak taka opcja przy łącznościach EME JT65 w WSJT: "deep search" - gdzie program niejako dopasowuje to co odebrał do listy stacji którą ma zaszytą w konfiguracji i to już jest złamanie powyższej zasady. Trwa chyba jeszcze otwarta dyskusja czy to ok czy nie ok bo w sumie człowiek też może zgadywać (Assisted).

http://physics.princeton.edu/pulsar/K1JT/K1JT_eme2006_2.pdf

Zgadza się, DEEP SEARCH pokazuje fikcję, dlatego ja osobiście nigdy nie używam tej opcji.

Dzisiaj testowałem na 6 i 20m. Wszystko gra. Nie jestem pewien jak inne pasma. Wszędzie raczej usb

Od dobrych kilku dni bawię się nową emisją FT8 (trochę zabawy było na początku bo trzeba było sobie skompilować soft - pierwsze QSO 03.07.2017). Kilka wniosków:
1. Dużo szybciej - jeden "komunikat" to teraz ok 15 s
2. Czułość zdecydowanie niższa - nijako wymusza stosowanie "większej" mocy jeśli pracuje się przy około -20dB
3. Większa podatność na zakłócenia...
4. Pojawia się coraz więcej stacji, być może ma to związek z wydaniem wsjtx-1.8.0-rc1
5. eQSL, jak i LotW nie przejmuje jeszcze FT8 (eQSL sam sprawdziłem, LotW jeszcze nie posiadam - więc informacja z internetu). Ma to związek z brakiem tej emisji w standardzie ADIF czy jakoś tak...
Plusem dla mnie to kilka nowych DXCC - w tym TR8CA

Krzysztof SQ4KKG

całkiem spora aktywność, to tylko parę godzin nasłuchu na GP na 20m

Witam. Sprawdziłem i w tej chwili pliki ADIF z FT8 i T10 przyjmują już chyba wszystkie popularne serwisy oprócz eQSL.cc i LoTW.

SQ8N pisze:


Te 15sekund byłby OK ale czas na reakcje krótki. W jt65 jest 48s transmisji i 12 s na reakcje a tu w FT8 jest 13s transmisja i 2 s na nasza rekcje, a to moim zdaniem zdecydowanie za mało.
Najlepiej by było jak by zrobili te 7s na reakcje czyli łącznie nie 15 a 20s i było by git.

Zgadza się...2 sekundy na reakcję to trochę za mało i w praktyce dopiero drugie zawołanie jest skuteczne. 7s na reakcję byłoby w sam raz. Jednak do tego co jest też idzie się przyzwyczaić...powala na kolana szybkość zaliczania QSO w porównaniu z JT65 - w ciągu niecałej godziny zabawy i ćwiczeń na 20m w logu 30 QSO ;-)

Pozdrowienia,
Paweł/SP3SC

EI2KK pisze:

W opjach mozna ustawic ze double click na znak wlacza Tx.. spokojnie mozna zdazyc na pierwsza transmisje.. czujnosc zachowac.. czujnosc i refleks

Coś w tym jest...trzeba zmienić trochę nawyki z JT65 gdzie było więcej czasu na wszystko ;-). BTW jeśli nie było to warto zaktualizować JTAlert do wersji 2.9.10 bo wcześniejsze wersje źle raportują typ emisji (JT9 lub T10 zamiast FT8)

Pozdrowienia,
Paweł

EI2KK pisze:


hyper pisze:

Witam. Sprawdziłem i w tej chwili pliki ADIF z FT8 i T10 przyjmują już chyba wszystkie popularne serwisy oprócz eQSL.cc i LoTW.


Sie wlasnie zastanawialem, czy wysylac na LOTW jako digi, czy jeszcze poczekac.. macie jakies przecieki? Oni tam chyba nie sa za szybcy do zmian... (Tradycja )

Nie liczyłbym na to. Z tego co kojarzę MSK144 funkcjonuje już chyba z rok i dalej nie można wrzucić do LOTW.

EI2KK pisze:


sp8sn pisze:

Dzisiaj testowałem na 6 i 20m. Wszystko gra. Nie jestem pewien jak inne pasma. Wszędzie raczej usb


Czy na 6m freq w programie jest poprawna? 50.313?

Tak 313

niestety ostatnie dni cieniutko

sp8sn pisze:


EI2KK pisze:


hyper pisze:

Witam. Sprawdziłem i w tej chwili pliki ADIF z FT8 i T10 przyjmują już chyba wszystkie popularne serwisy oprócz eQSL.cc i LoTW.


Sie wlasnie zastanawialem, czy wysylac na LOTW jako digi, czy jeszcze poczekac.. macie jakies przecieki? Oni tam chyba nie sa za szybcy do zmian... (Tradycja )


Nie liczyłbym na to. Z tego co kojarzę MSK144 funkcjonuje już chyba z rok i dalej nie można wrzucić do LOTW.

LoTW jak i eQSL są zgodne z najnowszą wersją ADIF.

Najnowsza aktualizacja ADIF jest z lutego, wtedy mało kto słyszał o FT8, ale wtedy dodano też kilka nowych modów np.MSK144 (ale nie tylko).

Z nadchodzącą aktualizacją ADIF będzie dodany mod FT8 i co za tym idzie automatycznie będzie przyjmowany przez eQSL (tam nie można sobie samemu ustawić , trzeba czekać).

Jeżeli chodzi o LoTW ( nie czekając na aktualizację ADIF i TQSL) można z ręki dodać Mod FT8 w ustawieniach, FT8 będzie przypisany do grupy DATA, i do czasu aktualizacji ADIF będzie występował jako DATA w sekcji MODE

więcej tutaj https://lotw.arrl.org/lotw-help_devel_en/pref-adi/

W ten sam sposób można dodać wszystkie inne MOD'Y które rzekomo nie "współpracują" z LoTW, te które są już jako nazwa w specyfikacji ADIF będą występowały po nazwie, te które nie są dodane jeszcze do ADIF będą występowały jako nazwa grupy.

Pozdrawiam, Piotr, SV3RNJ

O dzięki za info, szczerze mówiąc nie wiedziałem, że jest możliwość mapowania modu w TQSL.
Pozdrawiam

Robert,
nie wiem czy obserwujesz wsjt-devel, ale pojawiła się propozycja zmiany timingu protokołu do 15 s TX + 5 s PAUSE.
Trzeba przyznać, ze to bardzo interesująca propozycja i nie powodująca strat czasowych bo co prawda teraz QSO trwa 1'15" a w nowym układzie 1'40, ale de facto teraz traci się jeden cykl i robi się 1'30".
Poza tym gdy będzie czas na reakcję będzie można wrócić do układu: Tx5 = RR 73 HF1D zamiast TX4 RRR i potem osobnego TX5 czyli 73 więc QSO zakończy się po 1'20 sekundach.
Mnie martwi tylko himeryczność nowego protokołu i konieczność operowania suwakami na okienku wodospadu.
JT65 i JT9 wykazują się większą tolerancją na siłę sygnału, a ponadto różnica 6 dB w czułości to jest bardzo dużo.

może zostanie dopracowany, coraz więcej stacji pracuje