Entendiendo la configuración del decodificador FT8
en WSJT-X 3.1 improved

JTDX ha ofrecido desde hace tiempo explicaciones útiles sobre el funcionamiento de su decodificador. Esas guías siempre han sido valiosas, porque dejan muy claro un punto importante:

Ese es el principio clave.

Pero en 2026, si tu enfoque es el rendimiento en la operación FT8/FT4, la conversación ha cambiado.

WSJT-X 3.1 improved ya no es simplemente "el WSJT-X estándar con algunas funciones extra". Se ha incorporado de forma significativa una cantidad considerable de pensamiento práctico sobre decodificadores, incluyendo ideas que resultarán muy familiares para los usuarios de JTDX. Llegados a este punto, compararlo casualmente con WSJT-X 2.7 o versiones anteriores ya no aporta, francamente, demasiada información.

Dicho de forma más directa: para el operador promedio, WSJT-X 3.1 improved merece ahora ser tomado muy en serio como primera opción.

Esperar la próxima versión GA de JTDX es, por supuesto, una postura posible. Pero si tu prioridad es el rendimiento práctico del decodificador, las funciones disponibles, la actividad de actualización y lo que realmente puedes instalar y usar hoy, entonces usar lo que ya está aquí y ya es sólido es el camino más racional.

Nada de esto significa que JTDX no tenga su lugar. Si alguien está profundamente apegado a la interfaz de JTDX, esa es una razón perfectamente válida para quedarse con él. Pero esa es una cuestión distinta de la capacidad del decodificador y la optimización práctica.

Este artículo no pretende ser simplemente otra lista de ajustes recomendados. Lo que quiero examinar en cambio es una pregunta más profunda:

¿Qué significa realmente la optimización del decodificador FT8?
Y más concretamente, ¿qué hace realmente el ajuste "Decode Start" en WSJT-X 3.1 improved?

La conclusión práctica primero

Empieza con Normal. Prueba 3-Stage si tienes margen de CPU. Usa Early si el margen de tiempo es más importante.

Permíteme empezar por la conclusión práctica.

La regla más importante en el ajuste del decodificador FT8 no es:

"Usa la configuración más pesada disponible."

Es:

"Usa la configuración más agresiva que tu sistema pueda completar de forma fiable dentro del ciclo de 15 segundos."

Esa es una mentalidad muy distinta.

Como referencia inicial, algo como lo siguiente resulta sensato para muchas estaciones:

Eso no es necesariamente la respuesta definitiva, pero es un buen punto de partida. A partir de ahí, puedes avanzar en una dirección más agresiva si tu CPU tiene margen. Si empiezas a ver retraso, finalización tardía o inestabilidad, das un paso atrás.

En cuanto a Decode Start, un resumen práctico:

Ese es el resumen práctico. Pero la razón por la que este ajuste importa es más interesante de lo que sugiere el resumen por sí solo.

Decode Start no es simplemente una preferencia de "empezar antes o después". Está estrechamente ligado a cuántas etapas usa el decodificador, dónde se sitúan esas etapas en el tiempo y cómo se distribuye el esfuerzo de decodificación a lo largo del ciclo FT8.

Ese es el verdadero núcleo del asunto.

Por qué WSJT-X 3.1 improved merece atención seria ahora

Para entender por qué esto importa, ayuda dar un paso atrás y mirar el panorama general.

En los últimos años, WSJT-X improved se ha convertido en mucho más que una rama secundaria con opciones extra. Ha evolucionado hasta ser una plataforma práctica para ideas reales de decodificación, flexibilidad de interfaz y mejoras orientadas a la operación.

En cuanto uno pasa tiempo con las versiones actuales de improved, algo resulta evidente:

la vieja pregunta "¿cómo se compara esto con el WSJT-X estándar 2.7?" ya no es la más útil.

Las preguntas más relevantes ahora son:

• ¿Qué tan bueno es WSJT-X 3.1 improved como herramienta práctica de operación FT8/FT4 hoy en día?
• ¿Cuánto pensamiento real sobre decodificación se ha incorporado en él?
• ¿Y cómo debería un operador ajustarlo para su propia estación, CPU y prioridades operativas?

Por eso este artículo no trata principalmente sobre tablas comparativas. Trata sobre cómo usar el software con inteligencia.

Y una vez que la discusión pasa de "¿qué ajustes existen?" a "¿cómo deberían usarse?", se vuelve necesario preguntar qué significan realmente esos ajustes dentro de un ciclo FT8 de 15 segundos.

El papel de cada ajuste

"Más agresivo" no significa automáticamente "mejor"

Antes de centrarnos en Decode Start, vale la pena aclarar cómo deben entenderse en general los ajustes del decodificador FT8.

Un malentendido muy común es este:

los ajustes más pesados deben significar mejor rendimiento.

Suena razonable, pero FT8 no funciona así.

Como FT8 funciona en ciclos de 15 segundos, lo que realmente importa es un equilibrio entre cuatro cosas:

1. Cuánta señal esperas antes de decodificar
2. Con qué profundidad buscas mensajes candidatos
3. Si todo eso termina a tiempo
4. Cuántas decodificaciones falsas estás dispuesto a tolerar

Visto así, la optimización de FT8 no se trata de "máxima potencia". Se trata de cómo asignar un tiempo de procesamiento limitado.

Esa perspectiva cambia cómo debe verse cada ajuste.

Número de hilos

Para la mayoría de los operadores, Auto sigue siendo el mejor punto de partida. Simplemente forzar más hilos no garantiza un mejor resultado. La planificación del sistema operativo, la carga en segundo plano, la topología de núcleos y el comportamiento general del sistema importan todos.

Número de pasadas de decodificación

Más pasadas pueden aumentar la probabilidad de recuperar señales más débiles o ambiguas. Pero también cuestan tiempo de CPU. Si tu sistema es potente, 3 pasadas pueden valer la pena. Para muchas estaciones, 2 es el valor predeterminado más sensato. En hardware limitado, 1 puede ser la opción más segura.

Decoder Sensitivity

Una lectura práctica es sencilla:

• Minimum es más ligero
• Low thresholds es equilibrado
• Subpass es más agresivo, pero más pesado

Subpass no es rendimiento gratuito. Es trabajo extra a cambio de la posibilidad de recuperar señales más débiles o difíciles.

Una nota sobre Fast / Normal / Deep frente al decodificador FT8 multihilo

Esta es una de las partes más fáciles de malinterpretar. Como Fast / Normal / Deep aparece en la misma pantalla que el decodificador FT8 multihilo, es natural suponer que son simplemente versiones distintas del mismo control. Pero el código fuente sugiere que no son el mismo tipo de ajuste.

Primero, Fast / Normal / Deep es el ajuste tradicional de profundidad de decodificación: en otras palabras, una forma de indicarle al decodificador con qué profundidad buscar. En la ruta de decodificación FT8 monohilo convencional, este ajuste de profundidad está directamente ligado a cuán pesada se vuelve la decodificación y con qué agresividad se realiza la búsqueda.

El decodificador FT8 multihilo, en cambio, es un eje completamente distinto. Es fundamentalmente una cuestión de qué familia de motor de decodificación se está usando. En el código, la profundidad de decodificación y el FT8 multihilo se gestionan como parámetros separados, no como dos nombres para lo mismo.

El matiz importante viene a continuación. Cuando FT8 se ejecuta realmente con el decodificador multihilo activado, el programa entra en una ruta MTD dedicada en lugar de la antigua ruta de decodificación FT8 convencional. En esa ruta, los ajustes que realmente controlan el comportamiento del decodificador son los específicos de MTD, y no los antiguos niveles Fast / Normal / Deep:

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

Así que la forma más precisa de pensarlo es esta: Fast / Normal / Deep sigue existiendo, y sigue perteneciendo a la lógica más amplia de profundidad de decodificación del programa, pero en la operación FT8 con MTD no es el control principal que define la agresividad del decodificador. En el ajuste práctico, los controles que realmente importan son los orientados a MTD, especialmente Decoder Sensitivity, Decode Start, Number of decode passes y QSO Rx Frequency Sensitivity.

En otras palabras, si intentas ajustar seriamente WSJT-X 3.1 improved para FT8 con el decodificador multihilo activado, es mejor pensar en términos de controles de comportamiento específicos de MTD que asumir que Fast / Normal / Deep sigue siendo el principal determinante del carácter del decodificador. El antiguo ajuste de profundidad sigue formando parte del diseño; simplemente ya no es la palanca práctica más importante una vez que estás dentro de la ruta FT8 MTD.

QSO Rx Frequency Sensitivity

Esto no es simplemente un ajuste de velocidad. Afecta con qué agresividad el decodificador examina la actividad alrededor de la región de frecuencia relacionada con el QSO y los candidatos cercanos.

• Low es conservador
• Medium es equilibrado
• High es agresivo

Y, como cabría esperar, una mayor agresividad también puede traer candidatos más dudosos y más ruido de decodificación.

Reduce False Decodes

Esto merece más atención de la que a veces recibe. Encontrar más no es automáticamente mejor si la salida adicional es cada vez menos fiable. En bandas concurridas y en condiciones ambiguas, el control de decodificaciones falsas importa muchísimo.

En conjunto, estos ajustes no compiten de forma aislada para ver cuál es "el más fuerte". Cada uno de ellos expresa una respuesta distinta a la misma pregunta subyacente:

dentro de una ventana muy limitada de 15 segundos, ¿qué debería priorizar el decodificador?

Y entre todos ellos, Decode Start es uno de los ejemplos más claros y reveladores.

La pregunta principal

¿Qué hace realmente "Decode Start"?

Aquí es donde el tema se vuelve genuinamente interesante.

En la interfaz de usuario, Decode Start ofrece cinco opciones:

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

A primera vista, esto parece un simple control de temporización:

empezar a decodificar antes, o empezar a decodificar después.

Pero esa no es toda la historia.

Al observar la implementación real de WSJT-X 3.1 improved, estos modos se gestionan internamente como:

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

Y durante la operación FT8, el programa usa valores como m_hsymStop, m_earlyDecode y m_earlyDecode2 para determinar cuándo se activan las etapas de decodificación.

Esto nos dice de inmediato:

Para facilitar la comprensión, empecemos por los tres modos más simples — Early, Normal y Late — y luego pasemos a los modos más reveladores, 2-Stage y 3-Stage.

Early / Normal / Late

Primero, los tres modos más simples

Empecemos por las opciones más directas.

Cuando el decodificador FT8 multihilo está activado, los puntos de parada internos son aproximadamente:

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

En términos de temporización aproximada, eso corresponde a:

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

El significado básico es intuitivo:

• Early sacrifica un poco de recolección de señal a cambio de más margen de CPU
• Late espera más tiempo para reunir algo más de información antes de decodificar
• Normal se sitúa en el medio

Si Decode Start constara solo de estos tres modos, seguiría siendo un ajuste útil, pero no especialmente inusual.

Lo que hace la función mucho más interesante es lo que viene a continuación:

2-Stage y 3-Stage.

Nota técnica adicional

Qué son realmente 2-Stage y 3-Stage

No simplemente "antes" o "después", sino una estrategia de decodificación por etapas que combina STD y MTD

El registro de cambios de WSJT-X improved describe los modos 2-stage y 3-stage como aquellos que "combinan inteligentemente ambos decodificadores", dando como resultado lo que llama el mejor rendimiento de decodificación FT8 hasta la fecha.

En otras palabras, el software los presenta explícitamente como una forma de combinar el decodificador tradicional STD (monohilo) con el más reciente decodificador MTD (multihilo).

Lo que el registro de cambios no explica es el orden de ejecución exacto ni la relación de temporización entre ambos. Eso solo se aclara al observar la implementación.

Y una vez que lo haces, resulta evidente que 2-Stage y 3-Stage no son simplemente distintos momentos de inicio. Son estrategias de decodificación de múltiples etapas, y las distintas etapas no cumplen todas el mismo papel.

La división de tareas entre STD y MTD

Aquí, STD se refiere al decodificador FT8 tradicional monohilo. MTD se refiere al decodificador FT8 multihilo introducido en la línea improved.

Observando la implementación, los modos por etapas funcionan aproximadamente así:

• las etapas anteriores usan STD
• la etapa final usa MTD

Esa es la idea de diseño clave.

En otras palabras, esto se entiende mejor como una separación deliberada entre:

• una mirada anterior, más ligera y rápida
• y una pasada de decodificación posterior, más completa

Esa es una distinción muy importante.

Un diseño más simple podría haber esperado hasta el final del intervalo de recepción y luego realizar una única pasada de decodificación pesada. WSJT-X improved no hace eso. En cambio, realiza búsquedas intermedias de candidatos antes de la etapa final, y luego completa una decodificación más seria más tarde.

Esto deja claro que el diseño presta mucha atención a un problema central:

Perspectiva del desarrollador: para qué sirve realmente la pasada previa STD

Según Uwe Risse / DG2YCB, la pasada previa STD no es simplemente una decodificación preliminar adicional. Su papel importante es que aporta al flujo de trabajo MTD la ventaja de decodificación temprana conocida del decodificador STD tradicional.

Durante el desarrollo, se probaron varias combinaciones de STD y MTD, junto con distintos parámetros nzhsym. El enfoque actual — usar STD como pasada previa y MTD como pasada final principal — produjo los mejores resultados prácticos.

Este es un punto clave. 2-Stage y 3-Stage no son simplemente mecanismos para "ejecutar el decodificador más de una vez". Están diseñados para combinar el comportamiento ligero de decodificación temprana de STD con el poder de decodificación final más completo de MTD, usando de forma más eficaz el tiempo de CPU limitado dentro del ciclo FT8 de 15 segundos.

Uwe también señala que 2-Stage logra alrededor del 99,5% del rendimiento de decodificación de 3-Stage, requiriendo mucha menos potencia de cómputo. Esto explica por qué 2-Stage es una recomendación práctica tan sólida para la mayoría de los usuarios, mientras que 3-Stage sigue siendo la opción de máximo rendimiento para equipos muy rápidos.

Qué significa realmente 2-Stage

En la decodificación en vivo en el aire, 2-Stage consiste en una pasada previa STD en nzhsym=41, seguida de la pasada final de decodificación MTD en nzhsym=49.

Así que la secuencia real es:

• pasada previa STD @ nzhsym=41 — unos 11,8 segundos
• MTD final @ nzhsym=49 — unos 14,1 segundos

El punto clave es que la segunda pasada previa STD en nzhsym=46 no forma parte de 2-Stage en la decodificación en vivo. Esa pasada previa adicional pertenece únicamente a 3-Stage.

En otras palabras, 2-Stage es un modo bien equilibrado: realiza una pasada exploratoria temprana y luego termina con el paso principal de decodificación MTD en nzhsym=49.

Como el equilibrio entre el rendimiento de decodificación y el coste de CPU es tan bueno, 2-Stage es el modo que recomendaría primero a la mayoría de los usuarios. Según Uwe Risse / DG2YCB, logra alrededor del 99,5% del rendimiento de decodificación de 3-Stage, requiriendo mucha menos potencia de cómputo. Eso lo convierte en un compromiso práctico muy sólido.

Qué significa realmente 3-Stage

3-Stage añade una segunda pasada previa STD en nzhsym=46 antes de la pasada final de decodificación MTD.

En la decodificación en vivo en el aire, la secuencia es:

• pasada previa STD @ nzhsym=41 — unos 11,8 segundos
• pasada previa STD @ nzhsym=46 — unos 13,2 segundos
• MTD final @ nzhsym=50 — unos 14,4 segundos

Así, 3-Stage primero realiza una pasada exploratoria temprana en 41, luego otra pasada previa STD adicional en 46, y finalmente ejecuta el paso principal de decodificación MTD en 50.

Esto convierte a 3-Stage en el modo de decodificación FT8 de mayor rendimiento disponible en WSJT-X 3.1 improved.

Sin embargo, aquí es necesaria una advertencia práctica importante. La ganancia de decodificación adicional de 3-Stage no es proporcional al uso adicional de CPU. Uwe Risse / DG2YCB señala que 2-Stage ya logra alrededor del 99,5% del rendimiento de decodificación de 3-Stage, de modo que la ganancia restante es pequeña en comparación con la potencia de cómputo adicional requerida.

En equipos más modestos, la pasada previa STD adicional en nzhsym=46 puede consumir demasiado tiempo, y en el peor de los casos puede interferir con el paso final de decodificación MTD en nzhsym=50, que es el más importante de todos. Por eso 3-Stage debe considerarse un modo de gama alta: es la opción definitiva para usuarios con hardware potente, pero no es automáticamente la mejor recomendación para todos.

Debe entenderse como "primero STD, MTD al final", no como "primero MTD, STD después"

Este es uno de los puntos más fáciles de malinterpretar.

Como el registro de cambios dice que 2-Stage y 3-Stage combinan STD y MTD, algunos lectores podrían imaginar un modelo como este:

• MTD se ejecuta primero
• luego STD completa lo que MTD no captó

Pero eso no es lo que indica el comportamiento real de decodificación en vivo.

La interpretación más precisa es la contraria:

• STD realiza la pasada o pasadas exploratorias anteriores, más ligeras
• MTD realiza la decodificación final, más seria

En la operación en vivo, la distinción es:

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

Esa distinción importa. 3-Stage ofrece el mayor rendimiento de decodificación posible, pero 2-Stage es la recomendación más práctica para la mayoría de los usuarios porque evita el coste de CPU adicional de la segunda pasada previa STD en nzhsym=46.

¿Por qué usar STD en las etapas anteriores?

Esto también es revelador.

Si el objetivo fuera simplemente "ejecutar el decodificador más veces", uno podría esperar que el software ejecutara MTD repetidamente en cada etapa. Pero eso no es lo que hace.

Una razón probable es sencilla:

las etapas anteriores están pensadas para ser ligeras y rápidas.

En esos puntos anteriores, la recepción aún no está completa. La cantidad de información disponible sigue siendo menor de la que habrá en la etapa final. Ejecutar la lógica de decodificación más pesada posible a plena potencia cada vez no sería necesariamente el uso más eficiente de un tiempo de CPU limitado.

Así que, en cambio, el software usa STD para mirar de forma rápida y económica en los puntos anteriores, y reserva MTD para la pasada final y más determinante.

Eso no es simplemente un detalle de implementación. Refleja una filosofía de decodificación extremadamente bien adaptada a FT8 como carga de trabajo corta, en ráfagas y sensible a la temporización.

El código también sugiere que las etapas anteriores usan un procesamiento algo más limitado que la etapa final, lo que respalda aún más la idea de que estos modos no son simplemente pasadas repetidas, sino una progresión por etapas en la que cada pasada tiene un papel distinto.

La esencia de 2-Stage y 3-Stage es la asignación de tiempo

En el fondo, 2-Stage y 3-Stage tratan realmente sobre una sola cosa:

cómo asignar el esfuerzo computacional dentro de un ciclo de 15 segundos.

• ¿Debería el decodificador echar un vistazo temprano?
• ¿Debería echar un vistazo adicional a mitad de camino?
• ¿Debería esperar hasta el final para el intento final más completo?

Eso es lo que deciden los modos por etapas.

Así que 2-Stage y 3-Stage no deben considerarse simples ajustes de temporización. Se entienden mejor como distintas formas de desplegar el decodificador FT8 a lo largo del tiempo.

¿Cómo deberían interpretarse en la operación real?

Una vez traducida a términos operativos, la distinción se vuelve bastante práctica.

2-Stage

• preserva bastante bien la capacidad de respuesta
• añade una mirada temprana
• mantiene la etapa final en torno a la temporización de Normal
• mejora la recuperación de candidatos sin llevar la carga de CPU a extremos

En otras palabras, es una estrategia por etapas equilibrada.

3-Stage

• mira temprano
• vuelve a mirar a mitad de camino
• aun así mantiene una pasada final MTD en una temporización aproximada a Late
• empuja con más fuerza la reducción de decodificaciones perdidas
• pero aumenta la carga de CPU en consecuencia

Así que 3-Stage es el modo por etapas más ambicioso y agresivo disponible.

Si la CPU tiene margen suficiente, puede resultar extremadamente atractivo. Si la CPU ya está cerca de sus límites de temporización, entonces la ventaja teórica importa menos que simplemente terminar de forma limpia.

Llegados a este punto, el significado de estos modos queda mucho más claro:

Un punto importante más

Los modos por etapas no son simplemente "múltiples decodificaciones"; asignan papeles distintos a etapas distintas

Vistos desde una perspectiva algo más amplia, lo que hace tan interesantes a 2-Stage y 3-Stage no es simplemente que activen la decodificación más de una vez.

El punto más profundo es que cada etapa cumple un papel distinto.

• las etapas anteriores son más ligeras y rápidas
• la etapa final es más completa
• el esfuerzo de CPU se distribuye a lo largo del ciclo en lugar de gastarse todo de una vez

Esto encaja notablemente bien con FT8.

En principio, se podría esperar hasta el final y tomar una única decisión final. Pero hay un valor real en buscar candidatos recuperables antes, y luego revisar el problema más tarde con más información y un procesamiento más serio.

Por eso entender los modos por etapas no consiste solo en entender un ajuste. Se trata en realidad de entender qué significa la optimización de FT8 en sí misma.

Interpretación práctica

¿Cómo debería usarse realmente cada modo?

Tras todo el detalle técnico, vale la pena devolver la discusión al lenguaje operativo.

2-Stage

Muy práctico. Preserva la capacidad de respuesta a la vez que echa una mirada temprana. La etapa final no es tan tardía como Late, por lo que evita volverse innecesariamente exigente.

3-Stage

El modo más ambicioso, en el buen sentido.

Mira temprano, vuelve a mirar más tarde y aun así aguanta para una pasada final sólida. Si hay margen de CPU disponible y reducir las decodificaciones perdidas es una prioridad, este es uno de los ajustes más interesantes de todo el panel.

Early

No debería descartarse como un simple recurso para CPU débiles. También es una estrategia de estabilidad muy racional. Si evitar que el proceso se extienda al siguiente ciclo importa más que extraer hasta el último bit de señal, Early puede ser exactamente la elección correcta.

Normal

El punto de referencia. Para la mayoría de los usuarios, aquí es donde debería empezar la prueba. Facilita mucho la comparación con los demás modos.

Late

Espera más, decodifica después y toma la decisión final con algo más de información. En teoría, eso puede ayudar. En la práctica, solo es útil si el sistema sigue terminando de forma fiable.

En conjunto, los modos de Decode Start no deben entenderse como "gusto personal". Se entienden mejor como distintas estrategias de temporización.

Entonces, ¿qué estamos optimizando en realidad?

No el rendimiento promedio, sino el uso del tiempo de CPU dentro del ciclo de 15 segundos

Llegados a este punto, el principio más amplio debería estar claro.

La optimización de FT8 no consiste simplemente en hacer las cosas "más potentes".

Se trata de decidir:

• cuánto esperar
• con qué frecuencia mirar
• dónde hacer pasadas más ligeras
• dónde hacer la pasada final más pesada
• y si todo el proceso se mantiene estable de un ciclo a otro

En otras palabras, esto trata realmente sobre cómo se usa el rendimiento de la CPU, no solo cuánto existe.

Desde esa perspectiva, Decode Start es uno de los ajustes más importantes de todo el panel del decodificador. Lo que parece una pequeña opción de interfaz es, en realidad, una expresión directa de estrategia de tiempo.

Y por esa razón, entender Decode Start es más que una cuestión de explicar un ajuste. Es una forma de entender la filosofía subyacente de la asignación computacional en FT8.

Una nota más personal

Por qué estoy escribiendo esto

Hasta este punto, he intentado mantener la discusión general y técnica. Pero, para dar contexto, debería dejar clara mi propia posición.

Esto no es porque JTDX carezca de valor. Es porque el software también debe juzgarse por lo que está disponible en la práctica, lo suficientemente maduro para probarse y útil en este momento.

Si alguien se queda con JTDX porque de verdad prefiere su interfaz, eso es totalmente comprensible. Pero si la pregunta es la capacidad actual del decodificador y el valor operativo práctico, WSJT-X 3.1 improved merece atención seria.

Mi propia filosofía operativa

Hasta aquí me he centrado en principios generales. Pero puede ser útil explicar adónde lleva mi propio razonamiento en la práctica.

Mi PC principal de operación usa un Core i9-9900K. Ese detalle importa, pero no simplemente porque sea una CPU relativamente potente.

También importa por cómo está configurada la máquina.

En la configuración de energía de Windows, ajusto el estado mínimo del procesador al 100%. En otras palabras, no espero a que la CPU eleve su frecuencia después de que aparece la carga de decodificación. Prefiero que ya esté funcionando a alta velocidad de reloj, lista y a la espera. En mi caso, se sitúa efectivamente en 4,7 GHz.

La razón es sencilla.

La decodificación FT8 no se parece a la renderización de vídeo de larga duración, donde una carga constante se mantiene durante periodos extensos. Se parece mucho más a una ráfaga corta de trabajo concentrado, repetida a intervalos predecibles.

En ese tipo de carga de trabajo, el rendimiento promedio en pruebas no es toda la historia. La respuesta inicial importa.

Si la CPU está en un estado de menor potencia, el sistema tiene que:

• detectar la carga
• cambiar de estado de rendimiento
• elevar la frecuencia de reloj
• ajustar el voltaje
• y dejar que el planificador reaccione

Esos retrasos pueden ser insignificantes en cargas de trabajo de larga duración. Pero en ráfagas cortas y sensibles a la temporización, pueden importar más de lo que la gente espera.

Por eso creo esto:

Por supuesto, esa elección conlleva compromisos.

• mayor consumo de energía
• más calor
• menor eficiencia
• menos elegancia desde el punto de vista del ahorro de energía

Pero en un PC de estación, considero que la capacidad de respuesta y la estabilidad de la decodificación son más importantes que la pulcritud eléctrica.

Por qué mi propia configuración es deliberadamente agresiva

Porque 50 MHz me importa

Mi configuración refleja esa filosofía con bastante claridad.

• Decoder Sensitivity: Subpass
• QSO Rx Frequency Sensitivity: High
• CPU ya esperando a alta velocidad de reloj

Esta no es una configuración conservadora, y no pretendo que lo sea.

Pero hay una razón para ello:

50 MHz me importa muchísimo.

En 6 metros:

• las condiciones pueden cambiar rápidamente
• la actividad puede aumentar de repente
• señales débiles y fuertes a menudo coexisten
• y una apertura breve puede hacer que las oportunidades perdidas sean especialmente frustrantes

Por eso, estoy dispuesto a gastar recursos de CPU con tal de reducir las decodificaciones perdidas.

Por eso uso:

• Subpass, para buscar más a fondo
• sensibilidad High, para ser más agresivo en la recuperación de candidatos
• y una configuración de energía que mantiene la CPU lista antes de que llegue la carga de trabajo en ráfaga

Esto no es simplemente "subir todo porque más debe ser mejor".

Es una estrategia operativa deliberada, construida en torno a:

• énfasis en 50 MHz
• margen de CPU suficiente
• importancia de la velocidad de respuesta
• y la disposición a sacrificar eficiencia por oportunidad

Reflexiones finales

La pregunta real no es "¿qué programa es el correcto?" sino "¿qué filosofía de ajuste se adapta a tu estación?"

Si tuviera que reducir toda esta discusión a una sola frase, sería esta:

Visto desde esa perspectiva, WSJT-X 3.1 improved es un software muy interesante. No porque simplemente ofrezca más opciones, sino porque le da al operador un control significativo sobre la estrategia de temporización del decodificador.

Y Decode Start es uno de los ejemplos más claros de ello.

2-Stage, 3-Stage, Early, Normal y Late no son simplemente etiquetas cosméticas. Representan distintas formas de distribuir el esfuerzo de decodificación a lo largo del ciclo FT8.

Y si se observan más de cerca los modos por etapas, se puede ver debajo de ellos una idea especialmente elegante:

Y, por último, permítanme decir esto como alguien que verdaderamente valora JTDX:

Si tu apego a JTDX tiene su raíz en su interfaz, eso es una cosa. Pero si tu preocupación es la capacidad actual del decodificador en condiciones reales de operación, hay pocas razones para dudar.