Zrozumienie ustawień dekodera FT8 w WSJT-X 3.1 improved

JTDX od dawna oferuje przydatne wyjaśnienia dotyczące działania ustawień dekodera. Te poradniki zawsze były wartościowe, ponieważ bardzo jasno pokazują jedną ważną rzecz:

To jest kluczowa zasada.

Jednak w 2026 roku, jeśli zależy nam na wydajności w FT8/FT4, dyskusja wygląda już inaczej.

WSJT-X 3.1 improved nie jest już tylko „standardowym WSJT-X z kilkoma dodatkowymi funkcjami”. Wprowadzono do niego wiele praktycznych koncepcji dekodera — także takich, które będą bardzo znajome użytkownikom JTDX. Na tym etapie proste porównywanie go z WSJT-X 2.7 lub starszymi wersjami nie mówi już zbyt wiele.

Mówiąc wprost: dla przeciętnego operatora WSJT-X 3.1 improved zasługuje dziś na bardzo poważne traktowanie jako pierwszy wybór.

Czekanie na kolejne wydanie GA JTDX jest oczywiście jedną z możliwych strategii. Jeśli jednak priorytetem są praktyczna wydajność dekodera, dostępne funkcje, aktywność aktualizacji i to, co faktycznie można dziś zainstalować i używać, bardziej racjonalne jest korzystanie z rozwiązania już dostępnego i mocnego.

Nie oznacza to, że JTDX nie ma już swojego miejsca. Jeśli ktoś jest mocno przywiązany do interfejsu JTDX, to całkowicie uzasadniony powód, aby przy nim pozostać. To jednak inna kwestia niż możliwości dekodera i praktyczna optymalizacja.

Ten artykuł nie ma być kolejną listą zalecanych ustawień. Chcę raczej zbadać głębsze pytanie:

Co właściwie oznacza optymalizacja dekodera FT8? A konkretniej: co naprawdę robi ustawienie „Decode Start” w WSJT-X 3.1 improved?

Najpierw wniosek praktyczny

Zacznij od Normal. Jeśli masz zapas CPU, wypróbuj 3-Stage. Użyj Early, jeśli ważniejszy jest margines czasowy.

Zacznijmy od praktycznego wniosku.

Najważniejszą zasadą strojenia dekodera FT8 nie jest:

„Używaj najcięższych dostępnych ustawień.”

Lecz:

„Używaj najbardziej agresywnych ustawień, które Twój system potrafi niezawodnie zakończyć w 15-sekundowym cyklu.”

To zupełnie inny sposób myślenia.

Jako punkt wyjścia dla wielu stacji rozsądna będzie konfiguracja podobna do tej:

To nie musi być odpowiedź ostateczna, ale jest to solidny punkt startowy. Jeśli CPU ma zapas, można iść w bardziej agresywnym kierunku. Gdy pojawią się opóźnienia, późne kończenie lub niestabilność, należy cofnąć ustawienia.

W przypadku Decode Start praktyczne podsumowanie wygląda tak:

To jest praktyczne podsumowanie. Jednak powód, dla którego to ustawienie ma znaczenie, jest ciekawszy niż samo podsumowanie.

Decode Start nie jest jedynie preferencją „zacznij wcześniej albo później”. Jest ściśle związany z liczbą etapów używanych przez dekoder, ich rozmieszczeniem w czasie oraz sposobem rozdzielenia wysiłku obliczeniowego w cyklu FT8.

To właśnie jest sedno problemu.

Dlaczego WSJT-X 3.1 improved zasługuje dziś na poważną uwagę

Aby zrozumieć, dlaczego to ważne, warto zrobić krok wstecz i spojrzeć szerzej.

W ostatnich latach WSJT-X improved stał się czymś znacznie większym niż boczną gałęzią z dodatkowymi opcjami. Rozwinął się w praktyczną platformę dla rzeczywistych koncepcji dekodera, elastycznego UI i udoskonaleń nastawionych na praktyczną pracę.

Po dłuższym używaniu współczesnych wersji improved jedna rzecz staje się oczywista:

stare pytanie „Jak to wypada w porównaniu ze standardowym WSJT-X 2.7?” nie jest już najbardziej użyteczne.

Bardziej trafne pytania brzmią teraz:

• Jak dobrym praktycznym narzędziem do FT8/FT4 jest dziś WSJT-X 3.1 improved?
• Ile rzeczywistego doświadczenia z dekodowaniem zostało w nim wykorzystane?
• I jak operator powinien dostroić go do własnej stacji, CPU i priorytetów?

Dlatego ten artykuł nie dotyczy przede wszystkim tabel porównawczych. Dotyczy inteligentnego używania oprogramowania.

Gdy dyskusja przechodzi z „jakie ustawienia istnieją?” na „jak należy ich używać?”, trzeba zapytać, co te ustawienia naprawdę oznaczają w 15-sekundowym cyklu FT8.

Rola poszczególnych ustawień

„Bardziej agresywne” nie oznacza automatycznie „lepsze”

Zanim skupimy się na Decode Start, warto wyjaśnić, jak ogólnie należy rozumieć ustawienia dekodera FT8.

Bardzo częstym nieporozumieniem jest przekonanie:

cięższe ustawienia muszą oznaczać lepszą wydajność.

Brzmi to logicznie, ale FT8 tak nie działa.

Ponieważ FT8 działa w cyklach 15-sekundowych, naprawdę liczy się równowaga między czterema rzeczami:

1. Jak długo czekamy na sygnał przed dekodowaniem
2. Jak głęboko szukamy wiadomości-kandydatów
3. Czy wszystko zdąży zakończyć się na czas
4. Ile fałszywych dekodowań jesteśmy gotowi zaakceptować

W takim ujęciu optymalizacja FT8 nie polega na „maksymalnej mocy”. Chodzi o sposób przydzielania ograniczonego czasu przetwarzania.

Ta perspektywa zmienia sposób patrzenia na każde ustawienie.

Number of threads

Dla większości operatorów Auto nadal jest najlepszym punktem startowym. Samo wymuszenie większej liczby wątków nie gwarantuje lepszego wyniku. Znaczenie mają harmonogram systemu operacyjnego, obciążenie w tle, topologia rdzeni i ogólne zachowanie systemu.

Number of decode passes

Większa liczba przebiegów może zwiększyć szansę odzyskania słabszych lub bardziej niejednoznacznych sygnałów, ale kosztuje czas CPU. Na mocnym systemie 3 przebiegi mogą mieć sens. Dla wielu stacji 2 jest najrozsądniejszą wartością domyślną. Na ograniczonym sprzęcie 1 może być bezpieczniejsze.

Decoder Sensitivity

Praktyczna interpretacja jest prosta:

• Minimum jest lżejsze
• Low thresholds jest zrównoważone
• Subpass jest bardziej agresywne, ale cięższe

Subpass nie daje wydajności za darmo. To dodatkowa praca w zamian za możliwość odzyskania słabszych lub trudniejszych sygnałów.

Uwaga o Fast / Normal / Deep a Multithreaded FT8 Decoder

To część szczególnie łatwa do błędnego zrozumienia. Ponieważ Fast / Normal / Deep znajduje się na tym samym ekranie co Multithreaded FT8 decoder, naturalne jest założenie, że to różne wersje tego samego sterowania. Kod źródłowy sugeruje jednak, że są to różne rodzaje ustawień.

Po pierwsze, Fast / Normal / Deep to tradycyjne ustawienie głębokości dekodowania: sposób określenia, jak głęboko dekoder ma szukać. W konwencjonalnej, jednowątkowej ścieżce FT8 ta głębokość jest bezpośrednio związana z ciężarem dekodowania i agresywnością przeszukiwania.

Multithreaded FT8 decoder to natomiast zupełnie inna oś. Zasadniczo chodzi o to, z której rodziny silnika dekodera korzystamy. W kodzie głębokość dekodowania i multithreaded FT8 są obsługiwane jako oddzielne parametry, a nie dwie nazwy tego samego.

Najważniejszy niuans pojawia się dalej. Gdy FT8 rzeczywiście działa z włączonym dekoderem wielowątkowym, program wchodzi w dedykowaną ścieżkę MTD zamiast starszej konwencjonalnej ścieżki FT8. W tej ścieżce zachowaniem dekodera naprawdę sterują ustawienia specyficzne dla MTD, a nie stare poziomy Fast / Normal / Deep:

• Decoder Sensitivity
• Decode Start
• Number of decode passes
• QSO Rx Frequency Sensitivity

Najdokładniej można to ująć tak: Fast / Normal / Deep nadal istnieje i pozostaje częścią szerszej logiki głębokości dekodowania programu, ale w pracy FT8 MTD nie jest głównym pokrętłem określającym agresywność dekodera. W praktycznym strojeniu najważniejsze są elementy ukierunkowane na MTD — zwłaszcza Decoder Sensitivity, Decode Start, Number of decode passes i QSO Rx Frequency Sensitivity.

Innymi słowy, przy poważnym strojeniu WSJT-X 3.1 improved do FT8 z włączonym dekoderem wielowątkowym lepiej myśleć w kategoriach specyficznych dla MTD regulatorów zachowania niż zakładać, że Fast / Normal / Deep nadal jest głównym wyznacznikiem charakteru dekodera. Stare ustawienie głębokości pozostaje częścią projektu; po prostu nie jest już najważniejszą praktyczną dźwignią w ścieżce FT8 MTD.

QSO Rx Frequency Sensitivity

To nie jest jedynie ustawienie szybkości. Wpływa na to, jak agresywnie dekoder bada aktywność w rejonie częstotliwości związanej z QSO oraz pobliskie kandydatury.

• Low jest zachowawcze
• Medium jest zrównoważone
• High jest agresywne

Jak można się spodziewać, większa agresywność może też przynieść więcej wątpliwych kandydatów i więcej szumu dekodowania.

Reduce False Decodes

To ustawienie zasługuje na większą uwagę. Znalezienie większej liczby sygnałów nie jest automatycznie lepsze, jeśli dodatkowe wyniki stają się coraz mniej wiarygodne. Na zatłoczonych pasmach i w niejednoznacznych warunkach kontrola fałszywych dekodowań jest bardzo ważna.

Łącznie te ustawienia nie konkurują ze sobą o miano „najsilniejszego”. Każde wyraża inną odpowiedź na to samo podstawowe pytanie:

co dekoder powinien priorytetowo robić w bardzo ograniczonym 15-sekundowym oknie?

A spośród nich Decode Start jest jednym z najbardziej przejrzystych i pouczających przykładów.

Główne pytanie

Co właściwie robi „Decode Start”?

Tutaj temat staje się naprawdę interesujący.

W interfejsie użytkownika Decode Start oferuje pięć wyborów:

• 2-Stage
• 3-Stage
• Early
• Normal
• Late

Na pierwszy rzut oka wygląda to jak prosta kontrola czasu:

zacznij dekodować wcześniej albo później.

Ale to nie cała historia.

Patrząc na rzeczywistą implementację WSJT-X 3.1 improved, tryby te są wewnętrznie obsługiwane jako:

• 0 = 2-Stage
• 1 = 3-Stage
• 2 = Early
• 3 = Normal
• 4 = Late

Podczas pracy FT8 program używa wartości takich jak m_hsymStop, m_earlyDecode i m_earlyDecode2 do określania, kiedy uruchamiane są poszczególne etapy dekodowania.

To od razu mówi nam:

Aby łatwiej to zrozumieć, zacznijmy od prostszych trzech trybów — Early, Normal i Late — a następnie przejdźmy do bardziej interesujących 2-Stage i 3-Stage.

Early / Normal / Late

Najpierw trzy prostsze tryby

Zacznijmy od bardziej bezpośrednich opcji.

Przy włączonym Multithreaded FT8 decoder wewnętrzne punkty zatrzymania wynoszą w przybliżeniu:

• Early → 48
• Normal → 49
• Late → 50

W przybliżeniu czasowym odpowiada to:

• Early → około 13,8 s
• Normal → około 14,1 s
• Late → około 14,4 s

Podstawowe znaczenie jest intuicyjne:

• Early poświęca odrobinę czasu zbierania sygnału w zamian za większy margines CPU
• Late czeka dłużej, aby zebrać nieco więcej informacji przed dekodowaniem
• Normal znajduje się pośrodku

Gdyby Decode Start składał się tylko z tych trzech trybów, nadal byłoby to użyteczne ustawienie — ale nic szczególnie niezwykłego.

Znacznie ciekawsze jest to, co następuje dalej:

2-Stage i 3-Stage.

Dodatkowa uwaga techniczna

Czym naprawdę są 2-Stage i 3-Stage

Nie tylko „wcześniej” lub „później”, lecz etapowa strategia dekodowania łącząca STD i MTD

Dziennik zmian WSJT-X improved opisuje tryby 2-stage i 3-stage jako takie, które „inteligentnie łączą oba dekodery”, zapewniając — jak to określono — najlepszą dotąd wydajność dekodowania FT8.

Innymi słowy, oprogramowanie jawnie przedstawia je jako sposób połączenia tradycyjnego dekodera STD (jednowątkowego) z nowszym dekoderem MTD (wielowątkowym).

Dziennik zmian nie wyjaśnia jednak dokładnej kolejności wykonania ani relacji czasowej między nimi. Staje się to jasne dopiero po przyjrzeniu się implementacji.

Wtedy widać, że 2-Stage i 3-Stage nie są tylko różnymi czasami rozpoczęcia. To wieloetapowe strategie dekodowania, a poszczególne etapy nie pełnią tej samej roli.

Podział pracy między STD i MTD

STD oznacza tutaj tradycyjny jednowątkowy dekoder FT8. MTD oznacza wielowątkowy dekoder FT8 wprowadzony w linii improved.

Z implementacji wynika, że tryby etapowe działają mniej więcej tak:

• wcześniejsze etapy używają STD
• końcowy etap używa MTD

To jest kluczowa idea projektowa.

Najlepiej rozumieć to jako świadome rozdzielenie:

• wcześniejszego, lżejszego i szybszego spojrzenia
• od późniejszego, bardziej kompletnego przebiegu dekodowania

To bardzo ważne rozróżnienie.

Prostszy projekt mógłby czekać do końca okresu odbioru i wtedy wykonać jeden ciężki przebieg. WSJT-X improved tego nie robi. Zamiast tego wykonuje pośrednie wyszukiwania kandydatów przed etapem końcowym, a następnie kończy poważniejszym dekodowaniem.

Wyraźnie pokazuje to, że projekt bardzo uważnie traktuje jeden główny problem:

Perspektywa programisty: do czego naprawdę służy wstępny przebieg STD

Według Uwe Risse / DG2YCB wstępny przebieg STD nie jest tylko dodatkowym dekodowaniem wstępnym. Jego ważną rolą jest przeniesienie do przepływu MTD zalety wczesnego dekodowania znanej z tradycyjnego dekodera STD.

Podczas rozwoju testowano kilka kombinacji STD i MTD wraz z różnymi parametrami nzhsym. Obecne podejście — STD jako przebieg wstępny i MTD jako główny przebieg końcowy — dało najlepsze wyniki praktyczne.

To kluczowa kwestia. 2-Stage i 3-Stage nie są po prostu mechanizmami „uruchomienia dekodera więcej niż raz”. Zaprojektowano je tak, aby połączyć lekkie wczesne dekodowanie STD z bardziej kompletną końcową mocą MTD i dzięki temu efektywniej wykorzystać ograniczony czas CPU w 15-sekundowym cyklu FT8.

Uwe zauważa również, że 2-Stage osiąga około 99,5% skuteczności dekodowania 3-Stage przy znacznie mniejszym zapotrzebowaniu na moc obliczeniową. Wyjaśnia to, dlaczego 2-Stage jest tak mocną praktyczną rekomendacją dla większości użytkowników, a 3-Stage pozostaje opcją maksymalnej wydajności dla bardzo szybkich komputerów.

Co naprawdę oznacza 2-Stage

Podczas rzeczywistego dekodowania z eteru 2-Stage składa się z jednego wstępnego przebiegu STD przy nzhsym=41, po którym następuje końcowy przebieg MTD przy nzhsym=49.

Rzeczywista sekwencja to:

• wstępny STD @ nzhsym=41 — około 11,8 s
• końcowy MTD @ nzhsym=49 — około 14,1 s

Kluczowe jest to, że drugi wstępny przebieg STD przy nzhsym=46 nie należy do 2-Stage podczas dekodowania na żywo. Ten dodatkowy przebieg występuje wyłącznie w 3-Stage.

Innymi słowy, 2-Stage jest dobrze zrównoważonym trybem: wykonuje jedno wczesne rozpoznanie, a następnie kończy głównym etapem MTD przy nzhsym=49.

Ponieważ równowaga między skutecznością dekodowania a kosztem CPU jest tak dobra, 2-Stage jest trybem, który najpierw poleciłbym większości użytkowników. Według Uwe Risse / DG2YCB osiąga około 99,5% skuteczności 3-Stage przy znacznie mniejszej mocy obliczeniowej. To bardzo mocny kompromis praktyczny.

Co naprawdę oznacza 3-Stage

3-Stage dodaje drugi wstępny przebieg STD przy nzhsym=46 przed końcowym przebiegiem MTD.

Podczas dekodowania na żywo sekwencja jest następująca:

• wstępny STD @ nzhsym=41 — około 11,8 s
• wstępny STD @ nzhsym=46 — około 13,2 s
• końcowy MTD @ nzhsym=50 — około 14,4 s

3-Stage najpierw wykonuje więc wczesny przebieg rozpoznawczy przy 41, następnie dodatkowy wstępny przebieg STD przy 46, a na końcu główny przebieg MTD przy 50.

Dzięki temu 3-Stage jest trybem FT8 o najwyższej wydajności dostępnym w WSJT-X 3.1 improved.

Potrzebne jest jednak ważne ostrzeżenie praktyczne. Dodatkowy zysk dekodowania w 3-Stage nie jest proporcjonalny do dodatkowego użycia CPU. Uwe Risse / DG2YCB zauważa, że 2-Stage już osiąga około 99,5% skuteczności 3-Stage, więc pozostały zysk jest niewielki w porównaniu z dodatkową mocą obliczeniową.

Na słabszych komputerach dodatkowy wstępny przebieg STD przy nzhsym=46 może zużyć zbyt dużo czasu i w najgorszym przypadku zakłócić kluczowy końcowy etap MTD przy nzhsym=50. Dlatego 3-Stage należy traktować jako tryb high-end: jest opcją maksymalną dla użytkowników z mocnym sprzętem, ale nie automatycznie najlepszym zaleceniem dla wszystkich.

Należy to rozumieć jako „najpierw STD, na końcu MTD”, a nie „najpierw MTD, potem STD”

To jedna z najłatwiejszych do błędnego zrozumienia kwestii.

Ponieważ dziennik zmian mówi, że 2-Stage i 3-Stage łączą STD i MTD, niektórzy czytelnicy mogą wyobrażać sobie taki model:

• najpierw działa MTD
• potem STD uzupełnia to, czego MTD nie znalazł

Ale zachowanie podczas dekodowania na żywo na to nie wskazuje.

Dokładniejsza interpretacja jest odwrotna:

• STD wykonuje wcześniejszy, lżejszy przebieg lub przebiegi rozpoznawcze
• MTD wykonuje końcowe, poważniejsze dekodowanie

W pracy na żywo różnica wygląda tak:

• 2-Stage: STD @41 → końcowy MTD @49
• 3-Stage: STD @41 → STD @46 → końcowy MTD @50

To rozróżnienie ma znaczenie. 3-Stage oferuje najwyższą możliwą wydajność dekodowania, ale 2-Stage jest bardziej praktycznym zaleceniem dla większości użytkowników, ponieważ unika dodatkowego kosztu CPU drugiego przebiegu STD przy nzhsym=46.

Dlaczego w ogóle używać STD we wcześniejszych etapach?

To również dużo wyjaśnia.

Gdyby celem było wyłącznie „uruchomić dekoder więcej razy”, można by oczekiwać powtarzania MTD na każdym etapie. Program jednak tego nie robi.

Prawdopodobny powód jest prosty:

wcześniejsze etapy mają być lekkie i szybkie.

W tych wcześniejszych punktach odbiór nie jest jeszcze kompletny. Dostępna ilość informacji jest mniejsza niż w etapie końcowym. Uruchamianie za każdym razem najcięższej logiki dekodowania z pełną mocą nie musi być najefektywniejszym wykorzystaniem ograniczonego czasu CPU.

Dlatego program używa STD do szybkiego i oszczędnego spojrzenia wcześniej, a MTD zachowuje na końcowy, bardziej istotny przebieg.

To nie jest jedynie szczegół implementacyjny. Odzwierciedla filozofię dekodowania bardzo dobrze dopasowaną do FT8 jako krótkiego, impulsowego i wrażliwego czasowo obciążenia.

Kod sugeruje też, że wcześniejsze etapy używają nieco bardziej ograniczonego przetwarzania niż etap końcowy. Wspiera to tezę, że nie są to po prostu powtarzane przebiegi, lecz stopniowy proces, w którym każdy przebieg ma inną rolę.

Istotą 2-Stage i 3-Stage jest przydział czasu

W gruncie rzeczy 2-Stage i 3-Stage dotyczą jednej rzeczy:

jak rozdzielić wysiłek obliczeniowy wewnątrz 15-sekundowego cyklu.

• Czy dekoder powinien spojrzeć wcześniej?
• Czy powinien wykonać dodatkowe spojrzenie w środku?
• Czy powinien czekać do końca na najbardziej kompletne podejście?

Właśnie o tym decydują tryby etapowe.

Dlatego 2-Stage i 3-Stage nie należy traktować jako prostych korekt czasu. Lepiej rozumieć je jako różne sposoby rozłożenia działania dekodera FT8 w czasie.

Jak interpretować je w rzeczywistej pracy?

Po przełożeniu na język operatorski różnica staje się bardzo praktyczna.

2-Stage

• dość dobrze zachowuje responsywność
• dodaje wcześniejsze spojrzenie
• utrzymuje etap końcowy w okolicy czasu Normal
• poprawia odzyskiwanie kandydatów bez skrajnego obciążania CPU

Innymi słowy, to zrównoważona strategia etapowa.

3-Stage

• sprawdza wcześnie
• sprawdza ponownie w środku
• zachowuje końcowy przebieg MTD mniej więcej przy czasie Late
• mocniej dąży do ograniczenia pominiętych dekodowań
• ale odpowiednio zwiększa obciążenie CPU

3-Stage jest więc najbardziej ambitnym i agresywnym trybem etapowym.

Jeśli CPU ma odpowiedni zapas, może być bardzo atrakcyjny. Jeśli CPU jest już blisko granic czasowych, teoretyczna przewaga ma mniejsze znaczenie niż samo pewne zakończenie procesu.

W tym momencie znaczenie tych trybów staje się znacznie jaśniejsze:

Jeszcze jedna ważna kwestia

Tryby etapowe nie są tylko „wieloma dekodowaniami”; różne etapy mają różne role

Z szerszej perspektywy to, co czyni 2-Stage i 3-Stage interesującymi, nie sprowadza się do uruchamiania dekodowania więcej niż raz.

Głębsza idea polega na tym, że każdy etap odgrywa inną rolę.

• wcześniejsze etapy są lżejsze i szybsze
• etap końcowy jest bardziej kompletny
• wysiłek CPU jest rozłożony po cyklu zamiast zużywany jednorazowo

To znakomicie pasuje do FT8.

W zasadzie można by poczekać do końca i podjąć jedną końcową decyzję. Jednak realną wartość ma wcześniejsze poszukiwanie możliwych do odzyskania kandydatów, a potem powrót do problemu z większą ilością informacji i cięższym przetwarzaniem.

Dlatego zrozumienie trybów etapowych nie jest tylko zrozumieniem jednego ustawienia. To tak naprawdę zrozumienie, co oznacza sama optymalizacja FT8.

Interpretacja praktyczna

Jak właściwie używać każdego trybu?

Po wszystkich szczegółach technicznych warto wrócić do języka praktycznej pracy.

2-Stage

Bardzo praktyczny. Zachowuje responsywność, a jednocześnie wykonuje wcześniejsze spojrzenie. Etap końcowy nie jest tak późny jak Late, więc nie staje się niepotrzebnie wymagający.

3-Stage

Najbardziej ambitny tryb — w dobrym sensie.

Sprawdza wcześnie, potem ponownie później i nadal zachowuje mocny przebieg końcowy. Jeśli dostępny jest zapas CPU i priorytetem jest ograniczenie pominiętych dekodowań, to jedno z najciekawszych ustawień całego panelu.

Early

Nie należy go lekceważyć jako rozwiązania awaryjnego dla słabego CPU. To także bardzo racjonalna strategia stabilności. Jeśli ważniejsze jest uniknięcie przejścia pracy na kolejny cykl niż wyciśnięcie ostatniego fragmentu sygnału, Early może być idealnym wyborem.

Normal

Punkt odniesienia. Dla większości użytkowników testowanie powinno zacząć się tutaj. Ułatwia to porównanie z innymi trybami.

Late

Poczekaj dłużej, dekoduj później i podejmij końcową decyzję z nieco większą ilością informacji. Teoretycznie może to pomóc. W praktyce ma sens tylko wtedy, gdy system nadal niezawodnie kończy pracę.

Łącznie trybów Decode Start nie należy rozumieć jako „kwestii gustu”. To raczej różne strategie czasowe.

Co więc tak naprawdę optymalizujemy?

Nie średnią wydajność, lecz wykorzystanie czasu CPU w 15-sekundowym cyklu

W tym momencie ogólna zasada powinna być już jasna.

Optymalizacja FT8 nie polega po prostu na robieniu wszystkiego „mocniej”.

Polega na decyzji:

• jak długo czekać
• jak często sprawdzać
• gdzie wykonywać lżejsze przebiegi
• gdzie wykonywać cięższy przebieg końcowy
• i czy cały proces pozostaje stabilny z cyklu na cykl

Innymi słowy, chodzi o to, jak wykorzystywana jest wydajność CPU, a nie tylko ile jej istnieje.

Z tej perspektywy Decode Start jest jednym z najważniejszych ustawień całego panelu dekodera. To, co wygląda jak mała opcja UI, w rzeczywistości jest bezpośrednim wyrazem strategii czasowej.

Dlatego zrozumienie Decode Start jest czymś więcej niż wyjaśnieniem ustawienia. To sposób na zrozumienie filozofii przydziału obliczeń w FT8.

Bardziej osobista uwaga

Dlaczego w ogóle to piszę

Do tej pory starałem się utrzymać dyskusję na poziomie ogólnym i technicznym. Dla kontekstu powinienem jednak jasno określić własną pozycję.

Nie dlatego, że JTDX nie ma wartości. Oprogramowanie należy jednak oceniać również według tego, co jest praktycznie dostępne, wystarczająco dojrzałe do testów i użyteczne właśnie teraz.

Jeśli ktoś pozostaje przy JTDX, bo naprawdę woli jego interfejs, jest to całkowicie zrozumiałe. Jeśli jednak pytanie dotyczy dzisiejszych możliwości dekodera i praktycznej wartości w pracy, WSJT-X 3.1 improved zasługuje na poważną uwagę.

Moja własna filozofia pracy

Do tej pory koncentrowałem się na zasadach ogólnych. Warto jednak wyjaśnić, dokąd moje własne rozumowanie prowadzi w praktyce.

Mój główny komputer stacyjny używa Core i9-9900K. Ten szczegół ma znaczenie — ale nie tylko dlatego, że jest to stosunkowo mocny CPU.

Znaczenie ma również sposób konfiguracji maszyny.

W ustawieniach zasilania Windows ustawiam minimalny stan procesora na 100%. Nie czekam więc, aż CPU zwiększy taktowanie po pojawieniu się obciążenia dekodowania. Wolę, aby już pracował z wysoką częstotliwością, gotowy i oczekujący. W moim przypadku praktycznie stale jest to 4,7 GHz.

Powód jest prosty.

Dekodowanie FT8 nie przypomina długiego renderowania wideo, gdzie stałe obciążenie trwa długo. Bardziej przypomina krótki impuls skoncentrowanej pracy, powtarzany w przewidywalnych odstępach.

W takim obciążeniu średnia wydajność benchmarkowa nie mówi wszystkiego. Liczy się początkowa reakcja.

Jeśli CPU znajduje się w niższym stanie energetycznym, system musi:

• wykryć obciążenie
• zmienić stan wydajności
• zwiększyć taktowanie
• dostosować napięcie
• i pozwolić zareagować harmonogramowi

Te opóźnienia mogą być nieistotne przy długotrwałych obciążeniach. W krótkich, wrażliwych czasowo impulsach mogą jednak mieć większe znaczenie, niż się wydaje.

Dlatego uważam, że:

Oczywiście taki wybór ma swoje kompromisy.

• wyższe zużycie energii
• więcej ciepła
• niższa efektywność
• mniej elegancji z punktu widzenia oszczędzania energii

Ale na komputerze stacyjnym responsywność i stabilność dekodowania uważam za ważniejsze niż idealną efektywność energetyczną.

Dlaczego celowo używam agresywnych ustawień

Ponieważ 50 MHz jest dla mnie ważne

Moje ustawienia dość wyraźnie odzwierciedlają tę filozofię.

• Decoder Sensitivity: Subpass
• QSO Rx Frequency Sensitivity: High
• CPU już czeka z wysokim taktowaniem

Nie jest to konfiguracja zachowawcza i nie udaję, że tak jest.

Ale jest ku temu powód:

50 MHz ma dla mnie ogromne znaczenie.

Na 6 metrach:

• warunki mogą zmieniać się szybko
• aktywność może nagle wzrosnąć
• słabe i silne sygnały często współistnieją
• a krótkie otwarcie może sprawić, że stracone okazje są szczególnie frustrujące

Dlatego jestem gotów zużywać zasoby CPU, aby ograniczyć pominięte dekodowania.

Dlatego używam:

• Subpass, aby szukać głębiej
• High sensitivity, aby bardziej agresywnie odzyskiwać kandydatów
• oraz konfiguracji zasilania utrzymującej CPU w gotowości przed nadejściem impulsowego obciążenia

To nie jest po prostu „włącz wszystko na maksimum, bo więcej musi być lepsze”.

To świadoma strategia operatorska oparta na:

• nacisku na 50 MHz
• wystarczającym zapasie CPU
• znaczeniu szybkości reakcji
• i gotowości do wymiany efektywności na szansę

Podsumowanie

Prawdziwe pytanie nie brzmi „Który program jest właściwy?”, lecz „Jaka filozofia strojenia pasuje do Twojej stacji?”

Gdybym miał sprowadzić całą tę dyskusję do jednego zdania, brzmiałoby ono tak:

Z tej perspektywy WSJT-X 3.1 improved jest bardzo interesującym programem. Nie dlatego, że po prostu oferuje więcej opcji, lecz dlatego, że daje operatorowi realną kontrolę nad strategią czasową dekodera.

Decode Start jest jednym z najjaśniejszych tego przykładów.

2-Stage, 3-Stage, Early, Normal i Late nie są tylko kosmetycznymi etykietami. Reprezentują różne sposoby rozdzielania wysiłku dekodowania w cyklu FT8.

A jeśli przyjrzeć się trybom etapowym dokładniej, widać pod nimi szczególnie elegancki pomysł:

Na koniec powiem to jako osoba, która naprawdę ceni JTDX:

Jeśli przywiązanie do JTDX wynika z jego interfejsu, to jedna sprawa. Jeśli jednak liczą się dzisiejsze możliwości dekodera w rzeczywistych warunkach pracy, nie ma wielu powodów do wahania.