Entendendo as configurações do decodificador FT8 no WSJT-X 3.1 improved

O JTDX há muito oferece explicações úteis sobre o funcionamento de suas configurações de decodificação. Esses guias sempre foram valiosos porque deixam um ponto importante muito claro:

Esse é o princípio fundamental.

Mas em 2026, se seu foco é desempenho em FT8/FT4, a conversa mudou.

O WSJT-X 3.1 improved já não é apenas «o WSJT-X padrão com alguns recursos extras». Uma quantidade substancial de experiência prática de decodificação — incluindo ideias muito familiares aos usuários de JTDX — foi incorporada de forma significativa. Neste ponto, compará-lo casualmente com o WSJT-X 2.7 ou versões anteriores já não é muito informativo.

Dizendo de forma mais direta: para o operador médio, o WSJT-X 3.1 improved merece hoje ser considerado seriamente como uma opção de primeira escolha.

Esperar pela próxima versão GA do JTDX é, naturalmente, uma possibilidade. Mas se suas prioridades são desempenho prático de decodificação, recursos disponíveis, atividade de desenvolvimento e aquilo que você pode realmente instalar e usar hoje, é mais racional utilizar o que já está disponível e já é forte.

Nada disso significa que o JTDX não tenha lugar. Se alguém é profundamente ligado à interface do JTDX, isso é uma razão perfeitamente válida para continuar com ele. Mas essa é uma questão diferente de capacidade de decodificação e otimização prática.

Este artigo não pretende ser apenas mais uma lista de configurações recomendadas. Quero examinar uma questão mais profunda:

O que significa realmente otimizar o decodificador FT8? E, mais especificamente, o que a configuração «Decode Start» do WSJT-X 3.1 improved realmente faz?

Primeiro, a conclusão prática

Comece com Normal. Experimente 3-Stage se houver margem de CPU. Use Early se a margem de tempo for mais importante.

Vamos começar pela conclusão prática.

A regra mais importante ao ajustar o decodificador FT8 não é:

«Use as configurações mais pesadas disponíveis.»

É:

«Use as configurações mais agressivas que seu sistema consiga concluir de forma confiável dentro do ciclo de 15 segundos.»

É uma forma de pensar bastante diferente.

Como ponto de partida, algo como o seguinte é sensato para muitas estações:

Isso não é necessariamente a configuração final, mas é um ponto de partida sólido. A partir daí, você pode avançar para ajustes mais agressivos se sua CPU tiver folga. Se começar a ver atraso, conclusão tardia ou instabilidade, recue.

Quanto ao Decode Start, um resumo prático:

Esse é o resumo prático. Mas a razão pela qual essa configuração importa é mais interessante do que o próprio resumo sugere.

Decode Start não é simplesmente uma preferência de «começar mais cedo ou mais tarde». Ele está diretamente ligado a quantos estágios o decodificador usa, onde esses estágios são colocados no tempo e como o esforço de decodificação é distribuído ao longo do ciclo FT8.

Esse é o verdadeiro núcleo da questão.

Por que o WSJT-X 3.1 improved merece atenção séria hoje

Para entender por que isso importa, é útil recuar um pouco e olhar o quadro geral.

Nos últimos anos, o WSJT-X improved tornou-se muito mais do que um ramo paralelo com opções extras. Evoluiu para uma plataforma prática de ideias de decodificação do mundo real, flexibilidade de interface e refinamentos orientados à operação.

Depois de passar algum tempo com as versões improved atuais, uma coisa fica evidente:

a antiga pergunta «Como isso se compara ao WSJT-X 2.7 padrão?» já não é a mais útil.

As perguntas mais relevantes agora são:

• Quão bom é o WSJT-X 3.1 improved hoje como ferramenta prática de operação FT8/FT4?
• Quanto conhecimento prático de decodificação foi incorporado a ele?
• E como um operador deve ajustá-lo para sua própria estação, CPU e prioridades operacionais?

É por isso que este artigo não é principalmente sobre tabelas comparativas. É sobre como usar o software de forma inteligente.

E quando a discussão passa de «quais configurações existem?» para «como devem ser usadas?», torna-se necessário perguntar o que elas realmente significam dentro de um ciclo FT8 de 15 segundos.

O papel de cada configuração

«Mais agressivo» não significa automaticamente «melhor»

Antes de focar no Decode Start, vale a pena esclarecer como as configurações do decodificador FT8 devem ser entendidas em geral.

Um mal-entendido muito comum é este:

configurações mais pesadas devem significar melhor desempenho.

Parece plausível, mas o FT8 não funciona assim.

Como o FT8 trabalha em ciclos de 15 segundos, o que realmente importa é o equilíbrio entre quatro coisas:

1. Quanto sinal você espera antes de decodificar
2. Quão profundamente você procura mensagens candidatas
3. Se todo o processamento termina a tempo
4. Quantos falsos decodes você está disposto a tolerar

Visto assim, otimizar FT8 não é buscar «potência máxima». É decidir como alocar um tempo de processamento limitado.

Essa perspectiva muda a maneira como cada configuração deve ser vista.

Número de threads

Para a maioria dos operadores, Auto continua sendo o melhor ponto de partida. Simplesmente forçar mais threads não garante resultado melhor. O escalonamento do sistema operacional, a carga em segundo plano, a topologia dos núcleos e o comportamento geral do sistema importam.

Número de passes de decodificação

Mais passes podem aumentar a chance de recuperar sinais mais fracos ou ambíguos, mas também consomem tempo de CPU. Se seu sistema for forte, 3 passes podem valer a pena. Para muitas estações, 2 é o padrão mais sensato. Em hardware limitado, 1 pode ser a escolha mais segura.

Decoder Sensitivity

A interpretação prática é simples:

• Minimum é mais leve
• Low thresholds é equilibrado
• Subpass é mais agressivo, porém mais pesado

Subpass não oferece desempenho de graça. É trabalho extra em troca da possibilidade de recuperar sinais mais fracos ou difíceis.

Uma observação sobre Fast / Normal / Deep versus Multithreaded FT8 Decoder

Essa é uma parte particularmente fácil de interpretar errado. Como Fast / Normal / Deep aparece na mesma tela que Multithreaded FT8 decoder, é natural supor que sejam apenas versões diferentes do mesmo controle. O código-fonte, porém, indica que não são o mesmo tipo de configuração.

Primeiro, Fast / Normal / Deep é a configuração tradicional de profundidade de decodificação: em outras palavras, uma forma de dizer ao decodificador quão profundamente pesquisar. No caminho FT8 convencional de thread único, essa profundidade está diretamente ligada ao peso do processamento e à agressividade da busca.

Multithreaded FT8 decoder, por outro lado, é um eixo completamente diferente. A questão fundamental é qual família de motor de decodificação está sendo usada. No código, profundidade de decodificação e FT8 multithread são tratados como parâmetros separados, não como dois nomes para a mesma coisa.

A nuance importante vem a seguir. Quando o FT8 realmente roda com o decodificador multithread ativado, o programa entra em um caminho MTD dedicado em vez do antigo caminho FT8 convencional. Nesse caminho, as configurações que realmente controlam o comportamento são as específicas do MTD — e não os antigos níveis Fast / Normal / Deep:

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

Portanto, a forma mais precisa de pensar é esta: Fast / Normal / Deep ainda existe e continua pertencendo à lógica geral de profundidade de decodificação do programa, mas em operação FT8 MTD não é o principal controle que define o quanto o decodificador é agressivo. Na prática, os controles que realmente importam são os orientados ao MTD — especialmente Decoder Sensitivity, Decode Start, Number of decode passes e QSO Rx Frequency Sensitivity.

Em outras palavras, se você está tentando ajustar seriamente o WSJT-X 3.1 improved para FT8 com o decodificador multithread ativado, é melhor pensar em termos dos controles específicos de comportamento MTD do que assumir que Fast / Normal / Deep continua sendo o principal determinante do caráter do decoder. A antiga configuração de profundidade ainda faz parte do projeto; ela simplesmente deixa de ser a alavanca prática mais importante dentro do caminho FT8 MTD.

QSO Rx Frequency Sensitivity

Não é apenas uma configuração de velocidade. Ela afeta o quanto o decodificador examina agressivamente a atividade ao redor da região de frequência do QSO e os candidatos próximos.

• Low é conservador
• Medium é equilibrado
• High é agressivo

E, como esperado, maior agressividade também pode trazer mais candidatos duvidosos e mais ruído de decodificação.

Reduce False Decodes

Isso merece mais atenção do que às vezes recebe. Encontrar mais não é automaticamente melhor se os resultados adicionais forem cada vez menos confiáveis. Em bandas congestionadas e condições ambíguas, o controle de falsos decodes é muito importante.

Em conjunto, essas configurações não competem isoladamente para ver qual é a «mais forte». Cada uma expressa uma resposta diferente para a mesma questão central:

dentro de uma janela muito limitada de 15 segundos, o que o decodificador deve priorizar?

E entre todas elas, Decode Start é um dos exemplos mais claros e reveladores.

A questão principal

O que o «Decode Start» realmente faz?

É aqui que o assunto fica realmente interessante.

Na interface, Decode Start oferece cinco opções:

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

À primeira vista, parece um simples controle de tempo:

começar a decodificar mais cedo ou mais tarde.

Mas isso não é toda a história.

Olhando a implementação real do WSJT-X 3.1 improved, esses modos são tratados internamente como:

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

Durante a operação FT8, o programa usa valores como m_hsymStop, m_earlyDecode e m_earlyDecode2 para determinar quando os estágios de decodificação são acionados.

Isso nos diz imediatamente:

Para facilitar o entendimento, comecemos pelos três modos mais simples — Early, Normal e Late — e depois passemos aos modos mais reveladores, 2-Stage e 3-Stage.

Early / Normal / Late

Primeiro, os três modos mais simples

Vamos começar pelas opções mais diretas.

Quando o decodificador FT8 multithread está ativado, os pontos internos de parada são aproximadamente:

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

Em termos aproximados de tempo, isso corresponde a:

• Early → cerca de 13,8 segundos
• Normal → cerca de 14,1 segundos
• Late → cerca de 14,4 segundos

O significado básico é intuitivo:

• Early abre mão de um pouco de coleta de sinal em troca de maior margem de CPU
• Late espera mais para coletar um pouco mais de informação antes de decodificar
• Normal fica no meio

Se Decode Start tivesse apenas esses três modos, ainda seria uma configuração útil — mas não especialmente incomum.

O que torna o recurso muito mais interessante é o que vem depois:

2-Stage e 3-Stage.

Nota técnica adicional

O que 2-Stage e 3-Stage realmente são

Não apenas «mais cedo» ou «mais tarde», mas uma estratégia de decodificação em estágios que combina STD e MTD

O changelog do WSJT-X improved descreve os modos 2-Stage e 3-Stage como modos que «combinam inteligentemente ambos os decodificadores», resultando no que chama de melhor desempenho de decodificação FT8 até hoje.

Em outras palavras, o software os apresenta explicitamente como uma maneira de combinar o decodificador tradicional STD (single-thread) com o novo MTD (multithread).

O que o changelog não explica é a ordem exata de execução nem a relação de tempo entre os dois. Isso só fica claro ao observar a implementação.

E quando isso é feito, fica óbvio que 2-Stage e 3-Stage não são apenas tempos de início diferentes. São estratégias de decodificação em múltiplos estágios, e os diferentes estágios não desempenham todos o mesmo papel.

A divisão de trabalho entre STD e MTD

Aqui, STD se refere ao decodificador FT8 tradicional de thread único. MTD se refere ao decodificador FT8 multithread introduzido na linha improved.

Olhando a implementação, os modos em estágios funcionam aproximadamente assim:

• os estágios iniciais usam STD
• o estágio final usa MTD

Essa é a ideia central do projeto.

Em outras palavras, é melhor entender isso como uma separação deliberada entre:

• uma análise anterior, mais leve e rápida
• e um passe de decodificação posterior e mais completo

Essa é uma distinção muito importante.

Um projeto mais simples poderia esperar até o final do intervalo de recepção e então executar um único passe pesado. O WSJT-X improved não faz isso. Em vez disso, realiza buscas intermediárias de candidatos antes do estágio final e completa uma decodificação mais séria depois.

Isso deixa claro que o projeto presta muita atenção a um problema central:

Perspectiva do desenvolvedor: para que serve realmente o pré-passe STD

Segundo Uwe Risse / DG2YCB, o pré-passe STD não é apenas uma decodificação preliminar extra. Seu papel importante é trazer para o fluxo MTD a vantagem de decodificação antecipada conhecida do decodificador STD tradicional.

Durante o desenvolvimento, várias combinações de STD e MTD foram testadas junto com diferentes parâmetros nzhsym. A abordagem atual — STD como pré-passe e MTD como passe final principal — produziu os melhores resultados práticos.

Este é um ponto-chave. 2-Stage e 3-Stage não são simples mecanismos para «executar o decodificador mais de uma vez». Eles foram projetados para combinar a decodificação antecipada e leve do STD com a maior capacidade do MTD no passe final, usando de forma mais eficiente o tempo limitado de CPU dentro do ciclo FT8 de 15 segundos.

Uwe também observa que o 2-Stage obtém cerca de 99,5% do rendimento do 3-Stage, exigindo muito menos poder computacional. Isso explica por que o 2-Stage é uma recomendação prática tão forte para a maioria dos usuários, enquanto o 3-Stage continua sendo a opção de desempenho máximo para computadores muito rápidos.

O que 2-Stage realmente significa

Na decodificação real no ar, o 2-Stage consiste em um pré-passe STD em nzhsym=41, seguido pelo passe MTD final em nzhsym=49.

Portanto, a sequência real é:

• pré-passe STD @ nzhsym=41 — cerca de 11,8 segundos
• MTD final @ nzhsym=49 — cerca de 14,1 segundos

O ponto principal é que o segundo pré-passe STD em nzhsym=46 não faz parte do 2-Stage em decodificação real. Esse pré-passe extra pertence somente ao 3-Stage.

Em outras palavras, o 2-Stage é bem equilibrado: faz uma análise inicial antecipada e termina com o passo principal MTD em nzhsym=49.

Como o equilíbrio entre rendimento de decodificação e custo de CPU é tão bom, 2-Stage é o modo que eu recomendaria primeiro para a maioria dos usuários. Segundo Uwe Risse / DG2YCB, ele alcança cerca de 99,5% do rendimento do 3-Stage com muito menos poder de processamento. É um compromisso prático muito forte.

O que 3-Stage realmente significa

3-Stage adiciona um segundo pré-passe STD em nzhsym=46 antes do passe MTD final.

Na decodificação real no ar, a sequência é:

• pré-passe STD @ nzhsym=41 — cerca de 11,8 segundos
• pré-passe STD @ nzhsym=46 — cerca de 13,2 segundos
• MTD final @ nzhsym=50 — cerca de 14,4 segundos

Assim, o 3-Stage primeiro faz uma análise antecipada em 41, depois outro pré-passe STD em 46 e, por fim, executa o passe MTD principal em 50.

Isso faz do 3-Stage o modo de decodificação FT8 de maior desempenho disponível no WSJT-X 3.1 improved.

No entanto, é preciso fazer um alerta prático importante. O ganho adicional de decodificação do 3-Stage não é proporcional ao uso adicional de CPU. Uwe Risse / DG2YCB observa que o 2-Stage já alcança cerca de 99,5% do rendimento do 3-Stage, portanto o ganho restante é pequeno em comparação com o poder computacional extra exigido.

Em computadores mais fracos, o pré-passe STD extra em nzhsym=46 pode consumir tempo demais e, no pior caso, interferir na etapa MTD final crucial em nzhsym=50. Por isso, o 3-Stage deve ser visto como um modo de alto desempenho: é a opção máxima para usuários com hardware poderoso, mas não é automaticamente a melhor recomendação para todos.

Deve ser entendido como «STD primeiro, MTD por último», e não «MTD primeiro, STD depois»

Esse é um dos pontos mais fáceis de interpretar errado.

Como o changelog diz que 2-Stage e 3-Stage combinam STD e MTD, alguns leitores podem imaginar um modelo assim:

• MTD executa primeiro
• depois STD preenche o que o MTD perdeu

Mas não é isso que o comportamento real de decodificação mostra.

A interpretação mais correta é o contrário:

• STD faz o passe ou os passes iniciais, mais leves, de reconhecimento
• MTD faz a decodificação final, mais completa

Em operação real, a distinção é:

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

Essa distinção importa. 3-Stage oferece o maior desempenho de decodificação possível, mas 2-Stage é a recomendação mais prática para a maioria dos usuários porque evita o custo adicional de CPU do segundo pré-passe STD em nzhsym=46.

Por que usar STD nos estágios iniciais?

Isso também é revelador.

Se o objetivo fosse simplesmente «executar o decodificador mais vezes», seria natural esperar que o software executasse MTD repetidamente em cada estágio. Mas não é isso que ele faz.

A razão provável é simples:

os estágios iniciais devem ser leves e rápidos.

Nesses pontos iniciais, a recepção ainda não está completa. A quantidade de informação disponível ainda é menor do que será no estágio final. Executar a lógica de decodificação mais pesada em potência total toda vez não seria necessariamente o uso mais eficiente do tempo limitado de CPU.

Por isso, o software usa STD para examinar rapidamente e com baixo custo os pontos iniciais, reservando MTD para o passe final e mais importante.

Isso não é apenas um detalhe de implementação. Reflete uma filosofia de decodificação extremamente adequada ao FT8 como carga curta, em rajadas e sensível ao tempo.

O código também sugere que os estágios iniciais usam processamento um pouco mais limitado do que o estágio final, reforçando a ideia de que esses modos não são simples passes repetidos, mas uma progressão em estágios na qual cada passe tem um papel diferente.

A essência de 2-Stage e 3-Stage é a alocação de tempo

No fundo, 2-Stage e 3-Stage tratam de uma única coisa:

como alocar esforço computacional dentro de um ciclo de 15 segundos.

• O decodificador deve olhar mais cedo?
• Deve fazer uma análise adicional no meio do ciclo?
• Deve esperar até o fim para a tentativa final mais completa?

É isso que os modos em estágios estão decidindo.

Portanto, 2-Stage e 3-Stage não devem ser vistos como simples ajustes de tempo. É melhor entendê-los como maneiras diferentes de distribuir o decodificador FT8 ao longo do tempo.

Como devem ser interpretados na operação real?

Quando traduzida para termos operacionais, a diferença se torna bastante prática.

2-Stage

• preserva razoavelmente bem a responsividade
• adiciona uma análise mais cedo
• mantém o estágio final próximo do timing Normal
• melhora a recuperação de candidatos sem levar a carga da CPU ao extremo

Em outras palavras, é uma estratégia equilibrada em estágios.

3-Stage

• olha cedo
• olha novamente no meio
• ainda mantém um passe MTD final próximo do timing Late
• pressiona mais para reduzir decodes perdidos
• mas aumenta a carga de CPU proporcionalmente

Assim, o 3-Stage é o modo em estágios mais ambicioso e agressivo disponível.

Se a CPU tiver folga suficiente, pode ser extremamente atraente. Se a CPU já estiver próxima de seus limites de tempo, a vantagem teórica importa menos do que simplesmente terminar o processamento de maneira limpa.

Nesse ponto, o significado desses modos fica muito mais claro:

Mais um ponto importante

Os modos em estágios não são apenas «múltiplas decodificações»; eles atribuem papéis diferentes a diferentes estágios

Visto de uma perspectiva um pouco mais ampla, o que torna 2-Stage e 3-Stage tão interessantes não é apenas o fato de acionarem a decodificação mais de uma vez.

O ponto mais profundo é que cada estágio desempenha um papel diferente.

• os estágios iniciais são mais leves e rápidos
• o estágio final é mais completo
• o esforço da CPU é distribuído ao longo do ciclo, em vez de ser gasto de uma só vez

Isso combina muito bem com o FT8.

Em princípio, seria possível esperar até o fim e tomar uma única decisão final. Mas há valor real em procurar candidatos recuperáveis mais cedo e depois revisitar o problema com mais informação e processamento mais intenso.

É por isso que entender os modos em estágios não é apenas entender uma configuração. É entender o que significa a própria otimização FT8.

Interpretação prática

Como cada modo deve ser usado na prática?

Depois de todos os detalhes técnicos, vale a pena voltar à linguagem de operação.

2-Stage

Altamente prático. Preserva a responsividade e ainda faz uma análise antecipada. O estágio final não é tão tardio quanto Late, evitando uma exigência desnecessariamente alta.

3-Stage

O modo mais ambicioso — no bom sentido.

Ele olha cedo, olha novamente mais tarde e ainda conserva um passe final forte. Se há folga de CPU e reduzir decodes perdidos é prioridade, esta é uma das configurações mais interessantes de todo o painel.

Early

Não deve ser descartado apenas como solução para CPU fraca. Também é uma estratégia de estabilidade bastante racional. Se evitar transbordamento para o próximo ciclo for mais importante do que extrair o último pedaço de sinal, Early pode ser exatamente a escolha certa.

Normal

O ponto de referência. Para a maioria dos usuários, os testes devem começar aqui. Isso torna muito mais fácil comparar os outros modos.

Late

Espere mais, decodifique mais tarde e tome a decisão final com um pouco mais de informação. Em teoria isso pode ajudar; na prática só é útil se o sistema ainda terminar com confiabilidade.

Em conjunto, os modos Decode Start não devem ser entendidos como «gosto pessoal». É melhor vê-los como diferentes estratégias de tempo.

Então, o que estamos realmente otimizando?

Não o desempenho médio, mas o uso do tempo de CPU dentro do ciclo de 15 segundos

Neste ponto, o princípio geral deve estar claro.

Otimização FT8 não significa simplesmente tornar tudo «mais poderoso».

Trata-se de decidir:

• quanto tempo esperar
• com que frequência olhar
• onde fazer passes mais leves
• onde fazer o passe final mais pesado
• e se todo o processo permanece estável de ciclo para ciclo

Em outras palavras, isso trata de como o desempenho da CPU é usado, e não apenas de quanto desempenho existe.

Dessa perspectiva, Decode Start é uma das configurações mais importantes de todo o painel do decodificador. O que parece uma pequena opção de interface é, na realidade, uma expressão direta da estratégia de tempo.

Por isso, entender Decode Start vai além de explicar uma configuração. É uma forma de compreender a filosofia subjacente da alocação computacional em FT8.

Uma nota mais pessoal

Por que estou escrevendo tudo isso

Até aqui tentei manter a discussão geral e técnica. Mas, para dar contexto, devo deixar clara minha própria posição.

Isso não acontece porque o JTDX não tenha valor. Acontece porque software também deve ser julgado pelo que está realmente disponível, maduro o suficiente para ser testado e útil agora.

Se alguém permanece com JTDX porque realmente prefere sua interface, isso é totalmente compreensível. Mas se a questão é capacidade atual de decodificação e valor prático de operação, o WSJT-X 3.1 improved merece séria atenção.

Minha própria filosofia de operação

Até aqui foquei em princípios gerais. Mas pode ser útil explicar aonde meu próprio raciocínio leva na prática.

Meu PC principal de operação usa um Core i9-9900K. Esse detalhe importa — mas não apenas porque é uma CPU relativamente forte.

Também importa como a máquina está configurada.

Nas configurações de energia do Windows, defino o estado mínimo do processador em 100%. Em outras palavras, não espero a CPU elevar o clock depois que a carga de decodificação aparece. Prefiro que ela já esteja em alta frequência, pronta e esperando. No meu caso, fica efetivamente em 4,7 GHz.

A razão é simples.

Decodificação FT8 não é como renderização de vídeo de longa duração, em que uma carga constante permanece por muito tempo. É muito mais parecida com uma curta rajada de trabalho concentrado, repetida em intervalos previsíveis.

Nesse tipo de carga, o desempenho médio em benchmarks não conta toda a história. A resposta inicial importa.

Se a CPU estiver em um estado de baixo consumo, o sistema precisa:

• detectar a carga
• mudar o estado de desempenho
• aumentar os clocks
• ajustar a tensão
• e deixar o escalonador reagir

Esses atrasos podem ser insignificantes em cargas longas. Mas em rajadas curtas e sensíveis ao tempo, podem importar mais do que se imagina.

É por isso que penso assim:

Naturalmente, essa escolha tem contrapartidas.

• maior consumo de energia
• mais calor
• menor eficiência
• menos elegância do ponto de vista de economia de energia

Mas em um PC de estação, considero responsividade e estabilidade de decodificação mais importantes do que eficiência elétrica.

Por que minhas configurações são deliberadamente agressivas

Porque 50 MHz é muito importante para mim

Minhas configurações refletem essa filosofia com bastante clareza.

• Decoder Sensitivity: Subpass
• QSO Rx Frequency Sensitivity: High
• CPU já pronta em clock alto

Não é uma configuração conservadora, e não finjo que seja.

Mas há uma razão:

50 MHz é muito importante para mim.

Em 6 metros:

• as condições podem mudar rapidamente
• a atividade pode subir de repente
• sinais fracos e fortes frequentemente coexistem
• e uma abertura breve pode tornar oportunidades perdidas especialmente frustrantes

Por isso, estou disposto a gastar recursos de CPU para reduzir decodes perdidos.

É por isso que uso:

• Subpass, para pesquisar mais profundamente
• sensibilidade High, para ser mais agressivo na recuperação de candidatos
• e uma configuração de energia que mantém a CPU pronta antes que a carga em rajada chegue

Isso não é simplesmente «colocar tudo no máximo porque mais deve ser melhor».

É uma estratégia operacional deliberada construída em torno de:

• ênfase em 50 MHz
• folga suficiente de CPU
• importância da velocidade de resposta
• e disposição para trocar eficiência por oportunidade

Considerações finais

A verdadeira pergunta não é «Qual programa está certo?», mas «Qual filosofia de ajuste combina com sua estação?»

Se eu tivesse de reduzir toda esta discussão a uma única frase, seria esta:

Visto dessa perspectiva, o WSJT-X 3.1 improved é um software muito interessante. Não apenas porque oferece mais opções, mas porque dá ao operador controle significativo sobre a estratégia de tempo do decodificador.

E Decode Start é um dos exemplos mais claros disso.

2-Stage, 3-Stage, Early, Normal e Late não são apenas rótulos cosméticos. Eles representam maneiras diferentes de distribuir o esforço de decodificação pelo ciclo FT8.

E, olhando mais de perto os modos em estágios, aparece uma ideia particularmente elegante:

E por fim, digo isto como alguém que realmente valoriza o JTDX:

Se seu apego ao JTDX vem da interface, isso é uma coisa. Mas se sua preocupação é a capacidade atual de decodificação em condições reais de operação, há pouca razão para hesitar.