WSJT-X 3.1 improved İçindeki FT8 Dekoder Ayarlarını Anlamak

JTDX uzun süredir dekoder ayarlarının nasıl çalıştığını açıklayan yararlı bilgiler sunuyor. Bu rehberler her zaman değerliydi, çünkü çok önemli bir noktayı açıkça gösteriyorlar:

Temel ilke budur.

Ancak 2026’da odak noktanız FT8/FT4 işletim performansıysa, tartışma değişti.

WSJT-X 3.1 improved artık yalnızca “birkaç ek özelliği olan standart WSJT-X” değildir. JTDX kullanıcılarına oldukça tanıdık gelecek fikirler de dahil olmak üzere, önemli miktarda pratik dekoder yaklaşımı anlamlı biçimde içine alınmıştır. Bu noktada onu WSJT-X 2.7 veya daha eski sürümlerle yüzeysel biçimde karşılaştırmak artık pek bilgi vermiyor.

Daha açık söylemek gerekirse: ortalama bir operatör için WSJT-X 3.1 improved artık ilk seçenek olarak ciddi biçimde değerlendirilmelidir.

Bir sonraki JTDX GA sürümünü beklemek elbette bir seçenek. Ancak önceliğiniz pratik dekoder performansı, mevcut özellikler, güncelleme etkinliği ve bugün gerçekten kurup kullanabileceğiniz şeyler ise, zaten mevcut ve güçlü olanı kullanmak daha rasyonel yoldur.

Bunların hiçbiri JTDX’in artık yeri olmadığı anlamına gelmez. Birisi JTDX arayüzüne güçlü biçimde bağlıysa onunla devam etmek tamamen geçerli bir tercihtir. Ancak bu, dekoder yeteneği ve pratik optimizasyondan farklı bir sorudur.

Bu makale yalnızca bir başka önerilen ayarlar listesi değildir. Bunun yerine daha derin bir soruyu incelemek istiyorum:

FT8 dekoder optimizasyonu gerçekte ne anlama gelir? Ve özellikle WSJT-X 3.1 improved içindeki “Decode Start” ayarı gerçekte ne yapar?

Önce pratik sonuç

Normal ile başlayın. CPU payınız varsa 3-Stage’i deneyin. Zamanlama marjı daha önemliyse Early kullanın.

Pratik sonuçla başlayalım.

FT8 dekoder ayarında en önemli kural şu değildir:

“Mevcut en ağır ayarları kullan.”

Asıl kural şudur:

“Sisteminizin 15 saniyelik çevrim içinde güvenilir biçimde tamamlayabildiği en agresif ayarları kullanın.”

Bu oldukça farklı bir düşünce biçimidir.

Başlangıç noktası olarak pek çok istasyon için aşağıdakine benzer bir yapı mantıklıdır:

Bu mutlaka son cevap değildir, ancak sağlam bir başlangıç noktasıdır. CPU’nuzda pay varsa buradan daha agresif yöne gidebilirsiniz. Gecikme, geç tamamlanma veya kararsızlık görmeye başlarsanız geri adım atarsınız.

Decode Start için pratik özet şöyledir:

Pratik özet budur. Ancak bu ayarın neden önemli olduğu, özetin tek başına söylediğinden daha ilginçtir.

Decode Start yalnızca “daha erken veya daha geç başlat” tercihi değildir. Dekoderin kaç aşama kullandığı, bu aşamaların zaman içinde nereye yerleştirildiği ve çözme çabasının FT8 çevrimi boyunca nasıl dağıtıldığıyla yakından ilgilidir.

Meselenin gerçek özü budur.

WSJT-X 3.1 improved neden artık ciddi ilgiyi hak ediyor

Bunun neden önemli olduğunu anlamak için biraz geri çekilip büyük resme bakalım.

Son birkaç yılda WSJT-X improved, ek seçenekler içeren yan bir daldan çok daha fazlasına dönüştü. Gerçek işletim koşullarına yönelik dekoder fikirleri, UI esnekliği ve operatör odaklı iyileştirmeler için pratik bir platform haline geldi.

Güncel improved sürümleriyle biraz zaman geçirdiğinizde bir şey belirginleşiyor:

eski “Bu, standart WSJT-X 2.7 ile nasıl karşılaştırılır?” sorusu artık en yararlı soru değil.

Artık daha ilgili sorular şunlardır:

• WSJT-X 3.1 improved bugün pratik bir FT8/FT4 işletim aracı olarak ne kadar iyi?
• Gerçek dünya dekoder düşüncesinin ne kadarı içine yerleştirildi?
• Ve bir operatör onu kendi istasyonu, CPU’su ve işletim önceliklerine göre nasıl ayarlamalı?

Bu nedenle makale esas olarak karşılaştırma tabloları hakkında değildir. Yazılımı akıllıca nasıl kullanacağımız hakkındadır.

Tartışma “hangi ayarlar var?”dan “bu ayarlar nasıl kullanılmalı?”ya kaydığında, bu ayarların 15 saniyelik FT8 çevriminin içinde gerçekte ne anlama geldiğini sormak gerekir.

Her ayarın rolü

“Daha agresif” otomatik olarak “daha iyi” demek değildir

Decode Start’a odaklanmadan önce FT8 dekoder ayarlarının genel olarak nasıl anlaşılması gerektiğini netleştirmek yararlı olur.

Çok yaygın bir yanlış anlama şudur:

daha ağır ayarlar mutlaka daha iyi performans demektir.

Kulağa mantıklı gelir, fakat FT8 böyle çalışmaz.

FT8 15 saniyelik çevrimlerle çalıştığı için gerçekten önemli olan dört şey arasındaki dengedir:

1. Çözmeden önce ne kadar sinyal beklendiği
2. Aday mesajların ne kadar derin arandığı
3. Bütün bunların zamanında bitip bitmediği
4. Kaç yanlış çözümü tolere etmeye hazır olduğunuz

Bu açıdan FT8 optimizasyonu “maksimum güç” değildir. Sınırlı işlem süresinin nasıl dağıtılacağıdır.

Bu bakış açısı her ayarın nasıl değerlendirilmesi gerektiğini değiştirir.

Number of threads

Çoğu operatör için Auto hâlâ en iyi başlangıç noktasıdır. Daha fazla thread’i zorlamak daha iyi sonucu garanti etmez. İşletim sistemi zamanlayıcısı, arka plan yükü, çekirdek topolojisi ve sistemin genel davranışı önemlidir.

Number of decode passes

Daha fazla pass, daha zayıf veya daha belirsiz sinyalleri kurtarma şansını artırabilir; ancak CPU zamanı da tüketir. Sisteminiz güçlüyse 3 pass yararlı olabilir. Birçok istasyon için 2 en mantıklı varsayılandır. Sınırlı donanımda 1 daha güvenli seçim olabilir.

Decoder Sensitivity

Pratik okuması basittir:

• Minimum daha hafiftir
• Low thresholds dengelidir
• Subpass daha agresiftir, fakat daha ağırdır

Subpass ücretsiz performans değildir. Daha zayıf veya daha zor sinyalleri kurtarma olasılığı karşılığında ek iştir.

Fast / Normal / Deep ile Multithreaded FT8 Decoder hakkında bir not

Bu bölüm özellikle kolay yanlış anlaşılır. Fast / Normal / Deep, Multithreaded FT8 decoder ile aynı ekranda göründüğü için bunların aynı kontrolün farklı sürümleri olduğunu varsaymak doğaldır. Ancak kaynak kod bunların aynı tür ayar olmadığını gösteriyor.

Öncelikle Fast / Normal / Deep geleneksel decode-depth ayarıdır; yani dekodere ne kadar derin arama yapacağını söylemenin bir yoludur. Geleneksel tek iş parçacıklı FT8 çözme yolunda bu derinlik, çözmenin ne kadar ağırlaşacağı ve aramanın ne kadar agresif sürdürüleceğiyle doğrudan bağlantılıdır.

Buna karşılık Multithreaded FT8 decoder tamamen farklı bir eksendir. Temelde hangi dekoder motor ailesinin kullanıldığı sorusudur. Kod içinde decode depth ve multithreaded FT8, aynı şeyin iki adı olarak değil ayrı parametreler olarak ele alınır.

Önemli nüans bundan sonra gelir. FT8 gerçekten multithreaded decoder etkin olarak çalıştığında program eski geleneksel FT8 yolunun yerine özel MTD yoluna girer. Bu yolda dekoder davranışını gerçekten yöneten ayarlar eski Fast / Normal / Deep seviyeleri değil, MTD’ye özgü olanlardır:

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

En doğru düşünme biçimi şudur: Fast / Normal / Deep hâlâ vardır ve programın genel decode-depth mantığının parçasıdır; ancak FT8 MTD işletiminde dekoderin ne kadar agresif davranacağını belirleyen başlıca kontrol değildir. Pratik ayarda gerçekten önemli olanlar MTD odaklı kontrollerdir — özellikle Decoder Sensitivity, Decode Start, Number of decode passes ve QSO Rx Frequency Sensitivity.

Başka bir deyişle, multithreaded decoder açıkken WSJT-X 3.1 improved’ı FT8 için ciddi biçimde ayarlıyorsanız, Fast / Normal / Deep’in hâlâ dekoder karakterinin ana belirleyicisi olduğunu varsaymak yerine MTD’ye özgü davranış kontrolleri açısından düşünmek daha doğrudur. Eski depth ayarı tasarımın parçası olmaya devam eder; FT8 MTD yoluna girdikten sonra pratikte en önemli kaldıraç değildir.

QSO Rx Frequency Sensitivity

Bu yalnızca hız ayarı değildir. Dekoderin QSO ile ilişkili frekans bölgesi ve yakındaki adaylar çevresindeki etkinliği ne kadar agresif incelediğini etkiler.

• Low tutucudur
• Medium dengelidir
• High agresiftir

Beklendiği gibi daha fazla agresiflik, daha şüpheli adaylar ve daha fazla çözme gürültüsü de getirebilir.

Reduce False Decodes

Bu ayar bazen gördüğünden daha fazla ilgiyi hak eder. Ek çıktılar giderek güvensizleşiyorsa daha fazlasını bulmak otomatik olarak daha iyi değildir. Kalabalık bantlarda ve belirsiz koşullarda yanlış çözüm kontrolü çok önemlidir.

Birlikte ele alındığında bu ayarlar hangisinin “en güçlü” olduğu konusunda birbirleriyle yarışmıyor. Her biri aynı temel soruya farklı bir yanıt veriyor:

çok sınırlı 15 saniyelik pencere içinde dekoder neyi önceliklendirmeli?

Ve bunların arasında Decode Start en açık ve en öğretici örneklerden biridir.

Ana soru

“Decode Start” gerçekte ne yapıyor?

Konu burada gerçekten ilginçleşiyor.

Kullanıcı arayüzünde Decode Start beş seçenek sunar:

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

İlk bakışta basit bir zamanlama kontrolü gibi görünür:

çözmeye daha erken başla veya daha geç başla.

Fakat bütün hikâye bu değildir.

Gerçek WSJT-X 3.1 improved uygulamasına bakıldığında bu modlar dahili olarak şöyle ele alınır:

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

FT8 işletimi sırasında program, çözme aşamalarının ne zaman tetikleneceğini belirlemek için m_hsymStop, m_earlyDecode ve m_earlyDecode2 gibi değerleri kullanır.

Bu bize hemen şunu söylüyor:

Anlamayı kolaylaştırmak için önce daha basit üç moddan — Early, Normal ve Late — başlayalım, sonra daha açıklayıcı 2-Stage ve 3-Stage modlarına geçelim.

Early / Normal / Late

Önce daha basit üç mod

Daha doğrudan seçeneklerden başlayalım.

Multithreaded FT8 decoder etkin olduğunda dahili durma noktaları yaklaşık şöyledir:

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

Yaklaşık zaman karşılıkları şöyledir:

• Early → yaklaşık 13,8 saniye
• Normal → yaklaşık 14,1 saniye
• Late → yaklaşık 14,4 saniye

Temel anlam sezgiseldir:

• Early biraz sinyal toplama süresinden vazgeçerek daha fazla CPU marjı sağlar
• Late çözmeden önce biraz daha fazla bilgi toplamak için daha uzun bekler
• Normal ortada yer alır

Decode Start yalnızca bu üç moddan oluşsaydı yine yararlı bir ayar olurdu — ama çok sıra dışı olmazdı.

Özelliği çok daha ilginç yapan şey sıradaki kısımdır:

2-Stage ve 3-Stage.

Ek teknik not

2-Stage ve 3-Stage gerçekte nedir?

Yalnızca “daha erken” veya “daha geç” değil, STD ve MTD’yi birleştiren aşamalı bir çözme stratejisi

WSJT-X improved değişiklik günlüğü 2-stage ve 3-stage modlarını “her iki dekoderi akıllıca birleştiren” ve bugüne kadarki en iyi FT8 çözme performansını sağlayan modlar olarak açıklar.

Başka bir deyişle yazılım bunları geleneksel STD dekoderi (single-threaded) ile daha yeni MTD dekoderini (multithreaded) birleştirme yolu olarak açıkça sunar.

Değişiklik günlüğünün açıklamadığı şey tam yürütme sırası veya ikisi arasındaki zamanlama ilişkisidir. Bu ancak uygulamaya bakıldığında netleşir.

Ve baktığınızda 2-Stage ile 3-Stage’in yalnızca farklı başlangıç zamanları olmadığı anlaşılır. Bunlar çok aşamalı çözme stratejileridir ve aşamaların hepsi aynı rolü oynamaz.

STD ile MTD arasındaki iş bölümü

Burada STD geleneksel tek iş parçacıklı FT8 dekoderini, MTD ise improved hattında tanıtılan çok iş parçacıklı FT8 dekoderini ifade eder.

Uygulamaya bakıldığında aşamalı modlar kabaca şöyle çalışır:

• erken aşamalar STD kullanır
• son aşama MTD kullanır

Ana tasarım fikri budur.

Başka bir deyişle bunu şu iki unsur arasında bilinçli bir ayrım olarak anlamak en doğrusudur:

• daha erken, daha hafif ve daha hızlı bir bakış
• ve daha geç, daha eksiksiz bir çözme geçişi

Bu çok önemli bir ayrımdır.

Daha basit bir tasarım alım aralığının sonuna kadar bekleyip tek bir ağır çözme geçişi yapabilirdi. WSJT-X improved bunu yapmaz. Bunun yerine son aşamadan önce ara aday aramaları yapar ve daha sonra daha ciddi bir çözmeyle tamamlar.

Bu, tasarımın merkezi bir probleme çok dikkat ettiğini açıkça gösterir:

Geliştirici bakışı: STD ön geçişi gerçekte ne için?

Uwe Risse / DG2YCB’ye göre STD ön geçişi yalnızca ek bir ilk çözme değildir. Önemli rolü, geleneksel STD dekoderinden bilinen erken çözme avantajını MTD iş akışına taşımaktır.

Geliştirme sırasında farklı nzhsym parametreleriyle birlikte çeşitli STD ve MTD kombinasyonları denendi. Mevcut yaklaşım — STD’yi ön geçiş, MTD’yi ana son geçiş olarak kullanmak — en iyi pratik sonuçları verdi.

Bu kilit noktadır. 2-Stage ve 3-Stage yalnızca “dekoderi birden fazla çalıştırma” mekanizmaları değildir. STD’nin hafif erken çözme davranışını MTD’nin daha kapsamlı son çözme gücüyle birleştirerek 15 saniyelik FT8 çevrimindeki sınırlı CPU süresini daha verimli kullanmak üzere tasarlanmıştır.

Uwe ayrıca 2-Stage’in 3-Stage’in çözme veriminin yaklaşık %99,5’ine çok daha az işlem gücüyle ulaştığını belirtiyor. Bu, 2-Stage’in çoğu kullanıcı için neden güçlü bir pratik öneri olduğunu ve 3-Stage’in neden çok hızlı bilgisayarlarda maksimum performans seçeneği olarak kaldığını açıklar.

2-Stage gerçekte ne demek?

Canlı havadan çözmede 2-Stage, nzhsym=41’de bir STD ön geçişinden ve ardından nzhsym=49’da son MTD çözme geçişinden oluşur.

Gerçek sıra şöyledir:

• STD ön geçişi @ nzhsym=41 — yaklaşık 11,8 saniye
• son MTD @ nzhsym=49 — yaklaşık 14,1 saniye

Kilit nokta, nzhsym=46’daki ikinci STD ön geçişinin canlı çözmede 2-Stage’in bir parçası olmamasıdır. Bu ek ön geçiş yalnızca 3-Stage’e aittir.

Başka bir deyişle 2-Stage iyi dengelenmiş bir moddur: bir erken keşif geçişi yapar, ardından nzhsym=49’daki ana MTD çözme adımıyla tamamlar.

Çözme verimi ile CPU maliyeti arasındaki denge çok iyi olduğu için çoğu kullanıcıya önce 2-Stage’i öneririm. Uwe Risse / DG2YCB’ye göre 3-Stage’in çözme veriminin yaklaşık %99,5’ine çok daha az işlem gücüyle ulaşır. Bu onu çok güçlü bir pratik uzlaşma haline getirir.

3-Stage gerçekte ne demek?

3-Stage, son MTD çözme geçişinden önce nzhsym=46’da ikinci bir STD ön geçişi ekler.

Canlı havadan çözmede sıra şöyledir:

• STD ön geçişi @ nzhsym=41 — yaklaşık 11,8 saniye
• STD ön geçişi @ nzhsym=46 — yaklaşık 13,2 saniye
• son MTD @ nzhsym=50 — yaklaşık 14,4 saniye

Böylece 3-Stage önce 41’de erken bir keşif geçişi, sonra 46’da ek bir STD ön geçişi yapar ve en sonunda 50’de ana MTD çözme geçişini çalıştırır.

Bu, 3-Stage’i WSJT-X 3.1 improved içinde mevcut en yüksek performanslı FT8 çözme modu yapar.

Ancak burada önemli bir pratik uyarı gerekir. 3-Stage’in ek çözme kazancı, ek CPU kullanımına orantılı değildir. Uwe Risse / DG2YCB, 2-Stage’in zaten 3-Stage’in çözme veriminin yaklaşık %99,5’ine ulaştığını belirtiyor; dolayısıyla kalan kazanç gereken ek işlem gücüne göre küçüktür.

Daha zayıf bilgisayarlarda nzhsym=46’daki ek STD ön geçişi fazla zaman tüketebilir ve en kötü durumda nzhsym=50’deki kritik son MTD çözme adımına engel olabilir. Bu nedenle 3-Stage high-end bir mod olarak düşünülmelidir: güçlü donanımı olan kullanıcılar için en üst seçenektir, ancak herkes için otomatik olarak en iyi öneri değildir.

“Önce STD, en son MTD” olarak anlaşılmalı; “önce MTD, sonra STD” değil

Bu, en kolay yanlış anlaşılan noktalardan biridir.

Değişiklik günlüğü 2-Stage ve 3-Stage’in STD ile MTD’yi birleştirdiğini söylediği için bazı okuyucular şu modeli düşünebilir:

• önce MTD çalışır
• sonra STD, MTD’nin kaçırdıklarını tamamlar

Fakat canlı çözme davranışı bunu göstermiyor.

Daha doğru yorum bunun tersidir:

• STD daha erken ve daha hafif keşif geçişini/geçişlerini yapar
• MTD son ve daha ciddi çözmeyi yapar

Canlı işletimde fark şöyledir:

• 2-Stage: STD @41 → son MTD @49
• 3-Stage: STD @41 → STD @46 → son MTD @50

Bu fark önemlidir. 3-Stage mümkün olan en yüksek çözme performansını sunar; fakat 2-Stage, nzhsym=46’daki ikinci STD ön geçişinin ek CPU maliyetinden kaçındığı için çoğu kullanıcı açısından daha pratik öneridir.

Erken aşamalarda neden STD kullanılıyor?

Bu da tasarım hakkında çok şey söylüyor.

Amaç sadece “dekoderi daha çok çalıştırmak” olsaydı yazılımın her aşamada MTD’yi tekrar tekrar çalıştırması beklenebilirdi. Ama yaptığı bu değildir.

Muhtemel neden oldukça basittir:

erken aşamaların hafif ve hızlı olması amaçlanmıştır.

Bu erken noktalarda alım henüz tamamlanmamıştır. Kullanılabilir bilgi miktarı son aşamadakinden hâlâ daha azdır. Her seferinde en ağır çözme mantığını tam güçle çalıştırmak, sınırlı CPU süresinin en verimli kullanımı olmayabilir.

Bu nedenle yazılım erken noktalarda hızlı ve ekonomik bakış için STD’yi kullanır; MTD’yi ise son ve daha önemli geçiş için saklar.

Bu yalnızca uygulama detayı değildir. FT8’in kısa, burst benzeri ve zamanlamaya duyarlı bir iş yükü olmasına son derece uygun bir çözme felsefesini yansıtır.

Kod ayrıca erken aşamaların son aşamaya göre biraz daha sınırlı işlem kullandığını düşündürüyor. Bu da modların yalnızca tekrarlanan geçişler değil, her geçişin farklı rol oynadığı aşamalı bir süreç olduğu fikrini destekliyor.

2-Stage ve 3-Stage’in özü zaman tahsisidir

Temelde 2-Stage ve 3-Stage tek bir şey hakkındadır:

15 saniyelik çevrim içinde hesaplama çabasının nasıl dağıtılacağı.

• Dekoder daha erken bir bakış atmalı mı?
• Ortada ek bir bakış daha yapmalı mı?
• En kapsamlı son deneme için sona kadar beklemeli mi?

Aşamalı modların karar verdiği şey budur.

Bu nedenle 2-Stage ve 3-Stage basit zaman ayarları olarak görülmemelidir. Bunları FT8 dekoderini zaman eksenine farklı biçimlerde yayma yolları olarak anlamak daha doğrudur.

Gerçek işletimde nasıl yorumlanmalı?

İşletim diline çevrildiğinde fark oldukça pratiktir.

2-Stage

• tepki kabiliyetini oldukça iyi korur
• daha erken bir bakış ekler
• son aşamayı yaklaşık Normal zamanlamasında tutar
• CPU yükünü uç noktaya taşımadan aday kurtarmayı iyileştirir

Başka bir deyişle dengeli bir aşamalı stratejidir.

3-Stage

• erken bakar
• ortada tekrar bakar
• yaklaşık Late zamanlamasında son bir MTD geçişini yine korur
• kaçırılan çözmeleri azaltmak için daha fazla zorlar
• ancak CPU yükünü de buna göre artırır

Dolayısıyla 3-Stage mevcut en iddialı ve en agresif aşamalı moddur.

CPU’da yeterli pay varsa çok çekici olabilir. CPU zaten zamanlama sınırlarına yakınsa, teorik avantaj temiz ve güvenilir biçimde bitirmekten daha az önem taşır.

Bu noktada modların anlamı çok daha netleşir:

Bir önemli nokta daha

Aşamalı modlar yalnızca “birden fazla çözme” değildir; farklı aşamalara farklı roller verirler

Biraz daha geniş bakıldığında 2-Stage ve 3-Stage’i ilginç yapan şey yalnızca çözmenin birden fazla kez tetiklenmesi değildir.

Daha derin nokta, her aşamanın farklı bir rol oynamasıdır.

• erken aşamalar daha hafif ve hızlıdır
• son aşama daha eksiksizdir
• CPU çabası bir anda harcanmak yerine çevrim boyunca dağıtılır

Bu FT8’e son derece iyi uyar.

Prensipte sona kadar bekleyip tek bir nihai karar verilebilir. Ancak daha erken kurtarılabilir adayları aramanın ve daha sonra daha fazla bilgi ve daha ciddi işlemle probleme yeniden dönmenin gerçek değeri vardır.

Bu nedenle aşamalı modları anlamak yalnızca bir ayarı anlamak değildir. Aslında FT8 optimizasyonunun ne anlama geldiğini anlamaktır.

Pratik yorum

Her mod gerçekte nasıl kullanılmalı?

Bunca teknik ayrıntıdan sonra tartışmayı işletim diline geri getirmek yararlıdır.

2-Stage

Son derece pratiktir. Tepki kabiliyetini korurken daha erken bir bakış yapar. Son aşama Late kadar geç değildir; bu yüzden gereksiz yere ağırlaşmaz.

3-Stage

İyi anlamda en iddialı mod.

Erken bakar, daha sonra tekrar bakar ve yine güçlü bir son geçiş için bekler. CPU payı varsa ve kaçırılan çözmeleri azaltmak öncelikliyse, tüm paneldeki en ilginç ayarlardan biridir.

Early

Bunu yalnızca zayıf CPU’lar için bir geri dönüş modu olarak görmemek gerekir. Aynı zamanda çok rasyonel bir kararlılık stratejisidir. Bir sonraki çevrime taşmayı önlemek her son sinyal kırıntısını almaktan daha önemliyse Early tam doğru seçim olabilir.

Normal

Referans noktasıdır. Çoğu kullanıcı için test burada başlamalıdır. Diğer modlarla karşılaştırmayı çok kolaylaştırır.

Late

Daha uzun bekle, daha geç çöz ve son kararı biraz daha fazla bilgiyle ver. Teoride yardımcı olabilir. Pratikte yalnızca sistem hâlâ güvenilir biçimde bitirebiliyorsa yararlıdır.

Birlikte ele alındığında Decode Start modları “kişisel zevk” olarak görülmemelidir. Farklı zamanlama stratejileri olarak düşünülmeleri daha doğrudur.

Peki aslında neyi optimize ediyoruz?

Ortalama performansı değil, 15 saniyelik çevrim içindeki CPU zamanının kullanımını

Bu noktada genel ilke açık olmalıdır.

FT8 optimizasyonu yalnızca her şeyi “daha güçlü” yapmak değildir.

Şunlara karar vermektir:

• ne kadar bekleneceği
• ne sıklıkla bakılacağı
• daha hafif geçişlerin nerede yapılacağı
• daha ağır son geçişin nerede yapılacağı
• ve tüm sürecin çevrimden çevrime kararlı kalıp kalmadığı

Başka bir deyişle bu, CPU performansının ne kadar olduğundan çok nasıl kullanıldığıyla ilgilidir.

Bu açıdan Decode Start tüm dekoder panelindeki en önemli ayarlardan biridir. Küçük bir UI seçeneği gibi görünen şey gerçekte zaman stratejisinin doğrudan ifadesidir.

Bu nedenle Decode Start’ı anlamak yalnızca bir ayarı açıklamak değildir. FT8’de hesaplama tahsisinin temel felsefesini anlamanın bir yoludur.

Daha kişisel bir not

Bunu neden yazıyorum?

Buraya kadar tartışmayı genel ve teknik tutmaya çalıştım. Ancak bağlam için kendi konumumu açıkça belirtmeliyim.

Bunun nedeni JTDX’in değersiz olması değil. Yazılım aynı zamanda pratikte mevcut olan, test edilecek kadar olgun ve şu anda yararlı olan şeylere göre değerlendirilmelidir.

Birisi gerçekten arayüzünü tercih ettiği için JTDX’te kalıyorsa bu tamamen anlaşılır. Ancak konu günümüzdeki dekoder yeteneği ve pratik işletim değeri ise WSJT-X 3.1 improved ciddi ilgiyi hak eder.

Kendi işletim felsefem

Buraya kadar genel ilkelere odaklandım. Ancak kendi düşüncemin pratikte nereye vardığını açıklamak yararlı olabilir.

Ana işletim bilgisayarım Core i9-9900K kullanıyor. Bu ayrıntı önemli — ama yalnızca nispeten güçlü bir CPU olduğu için değil.

Makinenin nasıl yapılandırıldığı da önemlidir.

Windows güç ayarlarında minimum işlemci durumunu %100’e ayarlıyorum. Yani çözme yükü ortaya çıktıktan sonra CPU’nun frekansı yükseltmesini beklemiyorum. Onun zaten yüksek saat hızında, hazır ve bekliyor olmasını tercih ediyorum. Benim sistemimde fiilen 4,7 GHz’de duruyor.

Nedeni basit.

FT8 çözme, uzun süre sabit yük altında çalışan video render gibi değildir. Öngörülebilir aralıklarla tekrarlanan kısa ve yoğun bir işlem patlamasına çok daha yakındır.

Bu tür bir iş yükünde ortalama benchmark performansı tüm hikâye değildir. İlk tepki önemlidir.

CPU düşük güç durumundaysa sistem şunları yapmak zorundadır:

• yükü algılamak
• performans durumunu değiştirmek
• saat hızlarını yükseltmek
• voltajı ayarlamak
• ve zamanlayıcının tepki vermesine izin vermek

Bu gecikmeler uzun süren iş yüklerinde önemsiz olabilir. Ancak kısa ve zamanlamaya duyarlı patlamalarda insanların beklediğinden daha önemli olabilir.

Bu yüzden şuna inanıyorum:

Elbette bu seçimin bedelleri vardır.

• daha yüksek güç tüketimi
• daha fazla ısı
• daha düşük verimlilik
• enerji tasarrufu açısından daha az zarafet

Ancak bir istasyon bilgisayarında çözme tepkisi ve kararlılığını elektriksel düzenlilikten daha önemli görüyorum.

Kendi ayarlarım neden bilinçli olarak agresif

Çünkü 50 MHz benim için önemli

Ayarlarım bu felsefeyi oldukça açık yansıtır.

• Decoder Sensitivity: Subpass
• QSO Rx Frequency Sensitivity: High
• CPU zaten yüksek saat hızında hazır bekliyor

Bu tutucu bir kurulum değildir ve öyleymiş gibi de davranmıyorum.

Fakat bunun bir nedeni var:

50 MHz benim için çok önemlidir.

6 metrede:

• koşullar hızla değişebilir
• aktivite aniden artabilir
• zayıf ve güçlü sinyaller sıkça aynı anda bulunur
• ve kısa bir açılım kaçırılan fırsatları özellikle sinir bozucu hale getirebilir

Bu nedenle kaçırılan çözmeleri azaltmak için CPU kaynaklarını harcamaya hazırım.

Bu yüzden şunları kullanıyorum:

• daha derin arama için Subpass
• aday kurtarmada daha agresif olmak için High sensitivity
• ve burst iş yükü gelmeden önce CPU’yu hazır tutan bir güç yapılandırması

Bu yalnızca “daha fazlası daha iyidir diye her şeyi sonuna kadar açmak” değildir.

Şunlar üzerine kurulmuş bilinçli bir işletim stratejisidir:

• 50 MHz’e vurgu
• yeterli CPU payı
• tepki hızının önemi
• ve fırsat uğruna verimlilikten fedakârlık etmeye isteklilik

Son düşünceler

Asıl soru “Hangi program doğru?” değil, “Hangi ayar felsefesi istasyonunuza uyuyor?”dur

Bu tartışmanın tamamını tek cümleye indirmem gerekse şöyle derdim:

Bu açıdan WSJT-X 3.1 improved çok ilginç bir yazılımdır. Yalnızca daha fazla seçenek sunduğu için değil, operatöre dekoder zamanlama stratejisi üzerinde anlamlı kontrol verdiği için.

Decode Start bunun en açık örneklerinden biridir.

2-Stage, 3-Stage, Early, Normal ve Late yalnızca kozmetik etiketler değildir. FT8 çevrimi boyunca çözme çabasını dağıtmanın farklı yollarını temsil ederler.

Aşamalı modlara daha yakından bakıldığında altlarında özellikle zarif bir fikir görülür:

Son olarak, JTDX’e gerçekten değer veren biri olarak şunu söyleyeyim:

JTDX’e bağlılığınız arayüzünden kaynaklanıyorsa bu bir şeydir. Ancak endişeniz gerçek işletim koşullarındaki güncel dekoder yeteneğiyse tereddüt etmek için pek neden yoktur.