Понимание настроек декодера FT8 в WSJT-X 3.1 improved

JTDX уже давно предлагает полезные объяснения того, как работают его настройки декодера. Эти материалы всегда были ценны, потому что очень ясно показывают один важный принцип:

Это и есть ключевой принцип.

Но в 2026 году, если вас интересует производительность при работе FT8/FT4, характер обсуждения изменился.

WSJT-X 3.1 improved больше не является просто «обычным WSJT-X с несколькими дополнительными функциями». В него содержательно вошёл большой объём практических идей по декодированию — в том числе подходы, которые будут очень знакомы пользователям JTDX. На этом этапе поверхностное сравнение с WSJT-X 2.7 или более ранними версиями, откровенно говоря, уже мало что даёт.

Если сказать прямее: для среднего оператора WSJT-X 3.1 improved сейчас вполне заслуживает серьёзного рассмотрения как вариант первого выбора.

Конечно, можно ждать следующего GA-релиза JTDX. Но если для вас важны практическая производительность декодера, доступные функции, активность обновлений и то, что реально можно установить и использовать уже сегодня, рациональнее использовать то, что уже доступно и уже работает хорошо.

Это вовсе не означает, что JTDX больше не нужен. Если кому-то действительно нравится интерфейс JTDX, это совершенно нормальная причина продолжать им пользоваться. Но это уже другой вопрос, не равный вопросу возможностей декодера и практической оптимизации.

Эта статья не задумана как ещё один список рекомендуемых настроек. Вместо этого я хочу рассмотреть более глубокий вопрос:

Что вообще означает оптимизация декодера FT8? И, более конкретно, что на самом деле делает настройка «Decode Start» в WSJT-X 3.1 improved?

Сначала практический вывод

Начните с Normal. Попробуйте 3-Stage, если у CPU есть достаточный запас. Используйте Early, если важнее временной запас.

Начну с практического вывода.

Самое важное правило настройки декодера FT8 — вовсе не:

«Используйте самые тяжёлые из доступных настроек».

Правильнее так:

«Используйте наиболее агрессивные настройки, которые ваша система способна надёжно завершать в пределах 15-секундного цикла».

Это совсем иной подход к задаче.

В качестве исходной точки для многих станций разумен примерно такой набор:

Это не обязательно окончательный вариант, но хорошая исходная точка. Если у CPU есть запас, от неё можно двигаться в более агрессивную сторону. Если появляются задержки, слишком позднее завершение или нестабильность, следует сделать шаг назад.

Практически режимы Decode Start можно суммировать так:

Это практическое резюме. Но причина, по которой эта настройка важна, интереснее самого резюме.

Decode Start — не просто предпочтение «начать раньше или позже». Он тесно связан с тем, сколько этапов использует декодер, где эти этапы располагаются во времени и как вычислительная работа распределяется по циклу FT8.

Именно в этом суть вопроса.

Почему WSJT-X 3.1 improved сегодня заслуживает серьёзного внимания

Чтобы понять, почему это важно, полезно немного отступить назад и посмотреть на общую картину.

За последние годы WSJT-X improved стал гораздо больше, чем боковая ветка с дополнительными опциями. Он превратился в практическую платформу для реальных идей по декодированию, гибкого интерфейса и улучшений, ориентированных на работу в эфире.

После некоторого времени работы с современными сборками improved становится очевидна одна вещь:

старый вопрос «Как это сравнивается со стандартным WSJT-X 2.7?» уже не самый полезный.

Теперь гораздо важнее другие вопросы:

• Насколько хорош WSJT-X 3.1 improved как практический инструмент для работы FT8/FT4 сегодня?
• Какой объём реального практического опыта в области декодирования в него заложен?
• И как оператору настроить его под свою станцию, CPU и собственные приоритеты?

Именно поэтому эта статья прежде всего не о сравнительных таблицах. Она о том, как использовать программу осмысленно.

Когда разговор переходит от «какие настройки есть?» к «как их следует использовать?», необходимо понять, что эти настройки на самом деле означают внутри 15-секундного цикла FT8.

Роль каждой настройки

«Более агрессивно» не означает автоматически «лучше»

Прежде чем подробно разбирать Decode Start, полезно уточнить, как вообще следует понимать настройки декодера FT8.

Очень распространённое заблуждение выглядит так:

чем тяжелее настройки, тем выше должна быть производительность.

Это звучит логично, но FT8 работает не так.

Поскольку FT8 работает 15-секундными циклами, в действительности важен баланс четырёх факторов:

1. сколько сигнала вы ждёте перед началом декодирования
2. насколько глубоко выполняется поиск кандидатов сообщений
3. успевает ли весь этот процесс закончиться вовремя
4. какое количество ложных декодирований вы готовы допустить

С этой точки зрения оптимизация FT8 — это не «максимальная мощность». Это распределение ограниченного времени обработки.

Такой взгляд меняет то, как следует оценивать каждую настройку.

Количество потоков

Для большинства операторов Auto по-прежнему остаётся лучшей исходной точкой. Простое принудительное увеличение числа потоков не гарантирует лучший результат. Имеют значение планировщик ОС, фоновая нагрузка, топология ядер и общее поведение системы.

Количество проходов декодирования

Большее число проходов может повысить вероятность восстановления более слабых или неоднозначных сигналов. Но это требует дополнительного времени CPU. На мощной системе 3 прохода могут быть полезны. Для многих станций 2 — наиболее разумное значение по умолчанию. На ограниченном оборудовании безопаснее может оказаться 1.

Decoder Sensitivity

Практическое толкование довольно простое:

• Minimum — более лёгкий режим
• Low thresholds — сбалансированный режим
• Subpass — более агрессивный, но и более тяжёлый режим

Subpass не даёт производительность бесплатно. Это дополнительная работа в обмен на шанс восстановить более слабые или сложные сигналы.

О Fast / Normal / Deep и Multithreaded FT8 Decoder

Это один из моментов, который особенно легко понять неправильно. Поскольку Fast / Normal / Deep находится на том же экране, что и Multithreaded FT8 decoder, естественно предположить, что это просто разные варианты одной и той же настройки. Но исходный код показывает, что это разные типы параметров.

Во-первых, Fast / Normal / Deep — это традиционная настройка глубины декодирования: способ указать декодеру, насколько глубоко выполнять поиск. В обычном однопоточном пути FT8 эта глубина напрямую связана с вычислительной тяжестью декодирования и агрессивностью поиска.

Multithreaded FT8 decoder, напротив, относится к другой оси. По сути, это вопрос того, какое семейство движка декодирования используется. В коде глубина декодирования и многопоточный FT8 обрабатываются как отдельные параметры, а не как два названия одной функции.

Далее следует важный нюанс. Когда FT8 действительно работает с включённым многопоточным декодером, программа переходит в специальный путь MTD вместо старого обычного FT8-декодирования. В этом пути поведение в первую очередь определяется MTD-специфичными настройками, а не прежними уровнями Fast / Normal / Deep:

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

Наиболее точный способ понимать ситуацию таков: Fast / Normal / Deep всё ещё существует и остаётся частью общей логики глубины декодирования программы, но при работе FT8 через MTD это уже не главный регулятор агрессивности декодера. На практике важнее MTD-ориентированные параметры — прежде всего Decoder Sensitivity, Decode Start, Number of decode passes и QSO Rx Frequency Sensitivity.

Иными словами, если вы хотите серьёзно настроить WSJT-X 3.1 improved для FT8 с включённым многопоточным декодером, лучше мыслить в терминах MTD-специфичных параметров поведения, а не считать, что Fast / Normal / Deep остаётся главным фактором характера декодера. Старая настройка глубины всё ещё является частью конструкции; просто после перехода в путь FT8 MTD она уже не самый важный практический рычаг.

QSO Rx Frequency Sensitivity

Это не просто настройка скорости. Она влияет на то, насколько агрессивно декодер исследует активность в области частоты текущего QSO и близлежащих кандидатов.

• Low — консервативно
• Medium — сбалансированно
• High — агрессивно

И, как и следовало ожидать, большая агрессивность может привести к большему числу сомнительных кандидатов и большему шуму декодирования.

Reduce False Decodes

Эта настройка заслуживает большего внимания, чем ей иногда уделяют. «Найти больше» не обязательно означает «работать лучше», если дополнительные результаты становятся всё менее надёжными. На загруженных диапазонах и в неоднозначных условиях контроль ложных декодирований очень важен.

В совокупности эти настройки не соревнуются друг с другом за звание «самой сильной». Каждая из них по-своему отвечает на один и тот же фундаментальный вопрос:

что декодер должен считать приоритетом внутри очень ограниченного 15-секундного окна?

И среди всех параметров Decode Start — один из самых наглядных и показательных примеров.

Главный вопрос

Что на самом деле делает «Decode Start»?

Вот здесь тема становится по-настоящему интересной.

В пользовательском интерфейсе Decode Start предлагает пять вариантов:

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

На первый взгляд это выглядит как простой контроль времени:

начать декодирование раньше или начать его позже.

Но этим дело не ограничивается.

Если посмотреть на реальную реализацию WSJT-X 3.1 improved, внутри эти режимы представлены так:

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

Во время работы FT8 программа использует такие значения, как m_hsymStop, m_earlyDecode и m_earlyDecode2, чтобы определить моменты запуска различных этапов декодирования.

Это сразу говорит нам следующее:

Чтобы разобраться было проще, сначала рассмотрим более простые три режима — Early, Normal и Late — а затем перейдём к более показательным 2-Stage и 3-Stage.

Early / Normal / Late

Сначала три более простых режима

Начнём с наиболее прямолинейных вариантов.

При включённом многопоточном FT8-декодере внутренние точки остановки приблизительно таковы:

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

В приблизительном пересчёте на время это соответствует:

• Early → около 13,8 секунды
• Normal → около 14,1 секунды
• Late → около 14,4 секунды

Базовый смысл интуитивно понятен:

• Early жертвует небольшим объёмом накопленного сигнала ради большего временного запаса CPU
• Late ждёт дольше, чтобы перед декодированием собрать немного больше информации
• Normal находится посередине

Если бы Decode Start состоял только из этих трёх режимов, это всё равно была бы полезная настройка — но не особенно необычная.

Гораздо интереснее то, что идёт дальше:

2-Stage и 3-Stage.

Дополнительное техническое замечание

Что в действительности представляют собой 2-Stage и 3-Stage

Не просто «раньше» или «позже», а поэтапная стратегия декодирования, объединяющая STD и MTD

В журнале изменений WSJT-X improved режимы 2-stage и 3-stage описаны как режимы, которые «интеллектуально объединяют оба декодера», что, по формулировке разработчика, даёт лучшую на сегодняшний день производительность FT8-декодирования.

Иными словами, программа прямо представляет их как способ объединить традиционный декодер STD (однопоточный) и более новый декодер MTD (многопоточный).

Журнал изменений не объясняет точный порядок выполнения и временное соотношение между ними. Это становится ясно только при изучении реализации.

И тогда становится очевидно, что 2-Stage и 3-Stage — не просто разные моменты старта. Это многоэтапные стратегии декодирования, причём разные этапы играют разные роли.

Разделение труда между STD и MTD

Здесь STD означает традиционный однопоточный декодер FT8. MTD — многопоточный FT8-декодер, появившийся в линии improved.

Судя по реализации, поэтапные режимы работают примерно так:

• ранние этапы используют STD
• финальный этап использует MTD

Это и есть ключевая идея конструкции.

Иными словами, лучше всего понимать это как намеренное разделение на:

• ранний, более лёгкий и быстрый просмотр
• и более поздний, более полный проход декодирования

Это очень важное различие.

Более простая конструкция могла бы дождаться конца интервала приёма и затем выполнить один тяжёлый проход декодирования. WSJT-X improved делает иначе. Он выполняет промежуточные поиски кандидатов до финального этапа, а затем завершает более серьёзное декодирование позже.

Это ясно показывает, что конструкция уделяет особое внимание одной центральной проблеме:

Взгляд разработчика: для чего на самом деле нужен предварительный проход STD

По словам Uwe Risse / DG2YCB, предварительный проход STD — не просто дополнительное предварительное декодирование. Его важная роль в том, что он переносит преимущество раннего декодирования, известное по традиционному STD-декодеру, в рабочий процесс MTD.

В ходе разработки тестировались несколько сочетаний STD и MTD, а также разные параметры nzhsym. Текущая схема — STD как предварительный проход и MTD как основной финальный проход — показала лучшие практические результаты.

Это ключевой момент. 2-Stage и 3-Stage — не просто механизмы «запустить декодер несколько раз». Они предназначены для сочетания лёгкого раннего декодирования STD с более полной финальной мощностью MTD, чтобы эффективнее использовать ограниченное CPU-время внутри 15-секундного цикла FT8.

Uwe также отмечает, что 2-Stage достигает примерно 99,5% результата декодирования 3-Stage при существенно меньшей потребности в вычислительной мощности. Это объясняет, почему 2-Stage — столь сильная практическая рекомендация для большинства пользователей, тогда как 3-Stage остаётся режимом максимальной производительности для очень быстрых компьютеров.

Что на самом деле означает 2-Stage

При реальном эфирном декодировании 2-Stage состоит из одного предварительного прохода STD при nzhsym=41, после которого выполняется финальный проход MTD при nzhsym=49.

Фактическая последовательность такова:

• предварительный проход STD @ nzhsym=41 — примерно 11,8 секунды
• финальный MTD @ nzhsym=49 — примерно 14,1 секунды

Ключевой момент: второй предварительный проход STD при nzhsym=46 не является частью 2-Stage при реальном декодировании. Этот дополнительный проход относится только к 3-Stage.

Иными словами, 2-Stage — хорошо сбалансированный режим: он выполняет один ранний разведочный проход, а затем завершает работу основным MTD-декодированием при nzhsym=49.

Благодаря очень удачному балансу между результатом декодирования и нагрузкой CPU именно 2-Stage я бы в первую очередь рекомендовал большинству пользователей. По словам Uwe Risse / DG2YCB, он обеспечивает около 99,5% результата 3-Stage при значительно меньших вычислительных затратах. Это очень сильный практический компромисс.

Что на самом деле означает 3-Stage

3-Stage добавляет второй предварительный проход STD при nzhsym=46 перед финальным проходом MTD.

При реальном эфирном декодировании последовательность такова:

• предварительный проход STD @ nzhsym=41 — примерно 11,8 секунды
• предварительный проход STD @ nzhsym=46 — примерно 13,2 секунды
• финальный MTD @ nzhsym=50 — примерно 14,4 секунды

Таким образом, 3-Stage сначала выполняет ранний разведочный проход при 41, затем дополнительный предварительный проход STD при 46 и, наконец, основной MTD-проход при 50.

Это делает 3-Stage самым производительным режимом FT8-декодирования, доступным в WSJT-X 3.1 improved.

Однако здесь нужна важная практическая оговорка. Дополнительный выигрыш 3-Stage не пропорционален дополнительной нагрузке CPU. Uwe Risse / DG2YCB отмечает, что 2-Stage уже даёт примерно 99,5% результата 3-Stage, поэтому оставшийся выигрыш невелик по сравнению с требуемыми дополнительными вычислительными ресурсами.

На менее мощных компьютерах дополнительный предварительный проход STD при nzhsym=46 может занять слишком много времени и в худшем случае помешать критически важному финальному MTD-декодированию при nzhsym=50. Поэтому 3-Stage следует считать режимом для высокопроизводительных систем: это предельный вариант для пользователей с мощным оборудованием, но он не автоматически является лучшей рекомендацией для всех.

Следует понимать как «сначала STD, в конце MTD», а не «сначала MTD, потом STD»

Это один из моментов, которые особенно легко понять неправильно.

Поскольку в журнале изменений сказано, что 2-Stage и 3-Stage объединяют STD и MTD, некоторые читатели могут представить себе такую схему:

• сначала запускается MTD
• затем STD дополняет то, что MTD пропустил

Но реальное поведение при эфирном декодировании показывает не это.

Более точная интерпретация — противоположная:

• STD выполняет более ранний и лёгкий разведочный проход или проходы
• MTD выполняет финальное, более серьёзное декодирование

В реальной работе различие выглядит так:

• 2-Stage: STD @41 → финальный MTD @49
• 3-Stage: STD @41 → STD @46 → финальный MTD @50

Это различие важно. 3-Stage обеспечивает максимально возможную производительность декодирования, но 2-Stage является более практичной рекомендацией для большинства пользователей, поскольку избегает дополнительной нагрузки CPU от второго предварительного прохода STD при nzhsym=46.

Зачем вообще использовать STD на ранних этапах?

И это тоже многое объясняет.

Если бы целью было просто «запустить декодер большее число раз», логично было бы ожидать повторных запусков MTD на каждом этапе. Но программа устроена не так.

Вероятная причина проста:

ранние этапы должны быть лёгкими и быстрыми.

В эти ранние моменты приём ещё не завершён. Доступной информации меньше, чем будет на финальном этапе. Каждый раз запускать максимально тяжёлую логику декодирования на полной мощности не обязательно было бы самым эффективным использованием ограниченного CPU-времени.

Поэтому программа использует STD для быстрого и экономичного анализа на ранних точках, а MTD оставляет для финального и более значимого прохода.

Это не просто деталь реализации. Такой подход отражает философию декодирования, очень хорошо подходящую FT8 как короткой, импульсной и чувствительной ко времени вычислительной нагрузке.

Код также показывает, что ранние этапы используют несколько более ограниченную обработку по сравнению с финальным этапом. Это дополнительно подтверждает, что речь идёт не просто о повторяющихся проходах, а о поэтапном процессе, где каждый проход имеет собственную роль.

Суть 2-Stage и 3-Stage — распределение времени

В основе 2-Stage и 3-Stage лежит один вопрос:

как распределить вычислительные усилия внутри 15-секундного цикла.

• Нужно ли декодеру посмотреть на сигнал раньше?
• Нужно ли выполнить дополнительный просмотр в середине?
• Или лучше дождаться конца и сделать максимально полный финальный проход?

Именно это решают поэтапные режимы.

Поэтому 2-Stage и 3-Stage не следует считать простыми поправками времени. Их правильнее понимать как разные способы развернуть работу FT8-декодера во времени.

Как интерпретировать их в реальной работе?

Если перевести различия на язык практической эксплуатации, всё становится довольно наглядно.

2-Stage

• довольно хорошо сохраняет отзывчивость
• добавляет ранний просмотр
• оставляет финальный этап примерно в зоне времени Normal
• улучшает восстановление кандидатов, не загоняя нагрузку CPU в крайние значения

Иными словами, это сбалансированная поэтапная стратегия.

3-Stage

• смотрит рано
• смотрит ещё раз в середине
• при этом сохраняет финальный MTD-проход примерно на времени Late
• агрессивнее борется с пропущенными декодированиями
• но соответственно увеличивает нагрузку CPU

Таким образом, 3-Stage — самый амбициозный и агрессивный из доступных поэтапных режимов.

Если у CPU достаточный запас, такой режим может быть очень привлекателен. Если CPU уже близок к пределу по времени, теоретическое преимущество становится менее важным, чем способность просто стабильно завершить цикл без задержки.

После этого смысл режимов становится гораздо яснее:

Ещё один важный момент

Поэтапные режимы — не просто «несколько декодирований»; разные этапы получают разные роли

Если посмотреть шире, 2-Stage и 3-Stage интересны не только тем, что декодирование запускается более одного раза.

Более глубокий смысл в том, что каждый этап выполняет свою роль.

• ранние этапы легче и быстрее
• финальный этап более полный
• вычислительные усилия CPU распределяются по циклу, а не тратятся все сразу

Это удивительно хорошо соответствует природе FT8.

Теоретически можно было бы дождаться конца и принять единственное финальное решение. Но ранний поиск восстанавливаемых кандидатов действительно полезен, после чего к задаче можно вернуться позже уже с большим объёмом информации и более серьёзной обработкой.

Поэтому понимание поэтапных режимов — это не только понимание одной настройки. По сути, это понимание того, что вообще означает оптимизация FT8.

Практическая интерпретация

Как на практике следует использовать каждый режим?

После всей технической детализации полезно снова перевести разговор на язык реальной эксплуатации.

2-Stage

Очень практичный режим. Он сохраняет хорошую отзывчивость и при этом выполняет более ранний просмотр. Финальная стадия не столь поздняя, как Late, поэтому режим не становится без необходимости слишком требовательным.

3-Stage

Самый амбициозный режим — в хорошем смысле слова.

Он смотрит рано, затем смотрит ещё раз позже и всё же сохраняет мощный финальный проход. Если у CPU есть запас и уменьшение числа пропущенных декодирований является приоритетом, это одна из самых интересных настроек всей панели.

Early

Не стоит считать его только запасным вариантом для слабого CPU. Это также вполне рациональная стратегия стабильности. Если важнее не допустить перехода обработки в следующий цикл, чем извлечь последнюю долю сигнала, Early может оказаться именно тем режимом, который нужен.

Normal

Точка отсчёта. Для большинства пользователей тестирование лучше начинать именно здесь. Так намного проще сравнивать остальные режимы.

Late

Ждать дольше, декодировать позже и принимать финальное решение с немного большим объёмом информации. Теоретически это может помочь. Практически это полезно только в том случае, если система всё равно успевает надёжно завершить обработку.

В совокупности режимы Decode Start не следует понимать как вопрос «личного вкуса». Гораздо точнее считать их разными временными стратегиями.

Так что же мы на самом деле оптимизируем?

Не среднюю производительность, а использование CPU-времени внутри 15-секундного цикла

К этому моменту общий принцип уже должен быть понятен.

Оптимизация FT8 — не просто попытка сделать всё «мощнее».

Она заключается в принятии решений:

• как долго ждать
• как часто выполнять просмотр
• где делать более лёгкие проходы
• где выполнять более тяжёлый финальный проход
• и остаётся ли весь процесс стабильным от цикла к циклу

Иными словами, вопрос не только в том, сколько производительности CPU есть, но и в том, как она используется.

С этой точки зрения Decode Start — одна из самых важных настроек всей панели декодера. То, что выглядит как небольшая опция интерфейса, в действительности напрямую выражает временную стратегию.

Поэтому понимание Decode Start — не просто объяснение одной настройки. Это способ понять лежащую в основе FT8 философию распределения вычислительных ресурсов.

Немного более личный взгляд

Почему я вообще это пишу

До этого момента я старался вести разговор в общем и техническом ключе. Но для контекста стоит ясно обозначить мою собственную позицию.

Не потому, что JTDX не имеет ценности. Просто программное обеспечение следует оценивать и по тому, что практически доступно, достаточно зрелое для испытаний и полезно прямо сейчас.

Если кто-то остаётся с JTDX потому, что действительно предпочитает его интерфейс, это вполне понятно. Но если вопрос касается сегодняшних возможностей декодера и практической ценности в эфире, WSJT-X 3.1 improved заслуживает серьёзного внимания.

Моя собственная философия работы

До этого момента я в основном говорил об общих принципах. Но, возможно, полезно объяснить, к каким практическим решениям приводит мой собственный подход.

Мой основной рабочий компьютер использует Core i9-9900K. Эта деталь важна — но не просто потому, что это сравнительно мощный процессор.

Важно и то, как настроена сама система.

В параметрах питания Windows я устанавливаю минимальное состояние процессора на 100%. Иными словами, я не жду, пока CPU поднимет частоты после появления нагрузки декодирования. Я предпочитаю, чтобы он уже работал на высокой частоте и был готов к работе. В моём случае он фактически держится около 4,7 ГГц.

Причина проста.

Декодирование FT8 не похоже на длительный видеорендеринг, где стабильная нагрузка идёт продолжительное время. Оно гораздо ближе к короткому всплеску концентрированной работы, который повторяется через предсказуемые интервалы.

При таком типе нагрузки средний результат бенчмарка — далеко не вся картина. Важна первоначальная реакция системы.

Если CPU находится в пониженном энергосберегающем состоянии, системе приходится:

• обнаружить нагрузку
• переключить состояние производительности
• поднять тактовую частоту
• скорректировать напряжение
• и дать планировщику отреагировать

При длительной нагрузке такие задержки могут быть несущественны. Но при коротких, чувствительных ко времени всплесках они могут значить больше, чем кажется.

Поэтому я считаю следующее:

Разумеется, у такого выбора есть и обратная сторона.

• более высокое энергопотребление
• больше тепла
• ниже энергоэффективность
• меньшая элегантность с точки зрения энергосбережения

Но на станционном компьютере отзывчивость и стабильность декодирования для меня важнее идеальной экономичности.

Почему мои настройки намеренно агрессивны

Потому что для меня важен диапазон 50 МГц

Мои настройки довольно ясно отражают эту философию.

• Decoder Sensitivity: Subpass
• QSO Rx Frequency Sensitivity: High
• CPU заранее работает на высокой тактовой частоте

Это не консервативная конфигурация, и я не пытаюсь представить её таковой.

Но для неё есть причина:

50 МГц для меня имеет очень большое значение.

На 6 метрах:

• условия могут меняться очень быстро
• активность может резко возрасти
• слабые и сильные сигналы часто существуют одновременно
• а короткое открытие диапазона делает пропущенные возможности особенно досадными

Поэтому я готов расходовать ресурсы CPU, чтобы уменьшить число пропущенных декодирований.

Именно поэтому я использую:

• Subpass — для более глубокого поиска
• High — для более агрессивного восстановления кандидатов
• и конфигурацию питания, при которой CPU готов ещё до появления кратковременной нагрузки

Это не подход «выкрутить всё на максимум, потому что больше обязательно лучше».

Это осознанная эксплуатационная стратегия, основанная на:

• приоритете диапазона 50 МГц
• достаточном запасе CPU
• важности скорости реакции
• и готовности обменять энергоэффективность на дополнительную возможность принять сигнал

Заключительные мысли

Главный вопрос не «Какая программа правильная?», а «Какая философия настройки подходит вашей станции?»

Если свести весь этот разговор к одной фразе, она будет такой:

С этой точки зрения WSJT-X 3.1 improved — очень интересная программа. Не просто потому, что она предлагает больше настроек, а потому, что даёт оператору содержательный контроль над временной стратегией декодера.

И Decode Start — один из самых наглядных примеров этого.

2-Stage, 3-Stage, Early, Normal и Late — не просто косметические названия. Они представляют разные способы распределения вычислительной работы декодера по циклу FT8.

Если внимательно посмотреть на поэтапные режимы, под ними обнаруживается особенно изящная идея:

И в завершение скажу это как человек, который действительно ценит JTDX:

Если ваша привязанность к JTDX основана на его интерфейсе — это одно. Но если вас интересуют сегодняшние возможности декодера в реальных условиях работы, причин колебаться почти нет.