Las notas de NMAxe v3.1.03 agregan soporte para la placa Nexus y salvaguardas de recuperación
Publicación de la fuente: 2026-09-22 · Análisis editorial publicado: 2026-09-23
El repositorio de NMAxe enumera la versión 3.1.03 con compatibilidad con NMQAxe++ Nexus, detección automática de placa y recuperación de HCN. Los operadores deben verificar los activos de lanzamiento específicos del modelo antes de flashear.
Análisis e implicaciones prácticas
Esta sección contiene nuestro análisis y cálculos ilustrativos, separados del informe original.
Lo que publicó el repositorio
El repositorio ESP-Miner-NMAxe agregó una entrada el 22 de septiembre para la versión 3.1.03. Sus notas de la versión describen la compatibilidad con la placa NMQAxe++ Nexus utilizando un ASIC BM1373, detección automática de revisión de la placa, lógica de recuperación y cambios en la interfaz de usuario. Este es un firmware de código abierto para una familia de mineros compactos de Bitcoin construidos alrededor del hardware de control ESP32. Las notas son información del proyecto ascendente, no una prueba realizada por ASIC.tools. En el momento de nuestra verificación, la página de Versiones separada del repositorio todavía mostraba la versión 3.1.02 como la última versión empaquetada, por lo que los usuarios deben confirmar que los activos de la versión 3.1.03 coincidentes están realmente disponibles antes de intentar una actualización.
Soporte Nexus e identificación de placa.
La versión 3.1.03 agrega una nueva variante de placa NMQAxe++ Nexus basada en BM1373. Las notas también dicen que QAxe++ y QAxe++ Rev6.1 se pueden distinguir durante el arranque a través del pasador de sujeción GPIO46. Si el firmware no coincide con la placa detectada, la interfaz debería mostrar una superposición de firmware incorrecto en pantalla completa con el nombre de la placa en lugar de fallar silenciosamente. Esta salvaguardia reduce la ambigüedad pero no hace que cada binario sea universal. La guía anterior del proyecto dice que los usuarios deben seleccionar el firmware para el modelo exacto del dispositivo. Los operadores deben registrar la revisión de la PCB, el tipo de controlador y la imagen actual antes de descargar cualquier cosa.
Recuperación automática de HCN
La nueva reinicialización automática de HCN está destinada a reaccionar cuando el software detecta un desequilibrio de canales, canales faltantes o falta de progreso. El minero puede realizar una recuperación rápida del ciclo de encendido de Vcore, con al menos quince minutos entre intentos. Un intervalo acotado es útil porque los ciclos de encendido repetidos pueden ocultar una falla persistente de hardware, energía o térmica. Después de una actualización, supervise el recuento de recuperación, el hashrate de canal individual, la temperatura, el voltaje de suministro y los recursos compartidos del grupo. Si el mismo canal se cae repetidamente, conserve los registros e inspeccione los conectores, la refrigeración y la calidad de la energía en lugar de tratar la recuperación automática como prueba de que el problema subyacente está resuelto.
Presets, resultados de referencia y límites
Las notas de la versión enumeran ajustes preestablecidos de funcionamiento ECO, Normal y Turbo y gráficos de referencia que pueden almacenar aproximadamente de 28 a 80 resultados históricos. También mencionan la limitación de la frecuencia y Vcore a los límites del hardware. Los ajustes preestablecidos son puntos de partida convenientes, no se garantizan configuraciones estables para cada muestra de ASIC, fuente de alimentación o temperatura ambiente. Una configuración que produce un pico de referencia corto puede ofrecer una peor eficiencia de participación aceptada con el paso de las horas si aumentan los errores, el calor o la aceleración. Compare el hashrate aceptado y la potencia de la pared después del equilibrio térmico y mantenga la línea base de fábrica para que se pueda revertir un cambio de ajuste problemático.
Protecciones de refrigeración y tensión.
Según las notas, la versión 3.1.03 agrega un límite de seguridad de velocidad del ventilador y corrige la compensación de calibración de Nexus Vcore. Esos cambios afectan directamente el control térmico y eléctrico, por lo que la coincidencia de modelos es esencial. No copie un valor de voltaje de otra revisión de placa simplemente porque la interfaz web lo acepta. Verifique el funcionamiento del ventilador antes de minar, observe las temperaturas del ASIC y del regulador, y evite realizar pruebas desatendidas después de un cambio importante de firmware. Un techo de software no puede compensar un disipador de calor bloqueado, un conector suelto, una fuente de alimentación de tamaño insuficiente o una lectura incorrecta del sensor. Detenga el dispositivo si la temperatura o el comportamiento eléctrico difieren materialmente de la línea base conocida.
Cambios de arranque, interfaz y API
El proyecto dice que se mejoró la estabilidad del inicio y la interfaz de actualización ahora muestra una línea de tiempo de la versión con notas de la versión sincronizadas desde el repositorio de GitHub. Las respuestas de API obtienen un campo maxTarget y un registro del resultado de la última actualización inalámbrica. Estos campos pueden ayudar a los paneles de la flota a distinguir un límite disponible de una configuración elegida e identificar actualizaciones fallidas. La automatización debe tratar los campos nuevos o faltantes de manera defensiva: primero consulte una unidad de prueba, almacene el esquema de respuesta anterior y actualice los analizadores antes de implementarla de manera generalizada. Una respuesta HTTP que dice que una OTA se completó aún no reemplaza la verificación de la versión en ejecución, la conexión del grupo y los recursos compartidos aceptados después del reinicio.
Un procedimiento de actualización cauteloso
Primero exporte o fotografíe los ajustes de piscina, red, frecuencia, voltaje y temperatura. Identifique el modelo exacto y la revisión de PCB, luego obtenga la imagen correspondiente del repositorio oficial o del flash web oficial y verifique el nombre del archivo y la suma de verificación cuando se publique. Actualizar una unidad no crítica con energía estable; no interrumpa el borrado, el flasheo o el primer arranque. Confirme la versión en ejecución, la configuración, el comportamiento del ventilador, la detección de chips y la aceptación del grupo. Obsérvelo durante un período de calentamiento completo antes de expandirse a la flota. Mantenga disponible el método de recuperación por cable documentado porque una falla de OTA puede requerir una flash ESP32 directa.
Un arranque exitoso es solo el primer paso de validación. Confirme que se detecten todos los canales ASIC y que las acciones enviadas sean aceptadas por el grupo previsto. Conserve los registros seriales de la unidad de prueba, ya que pueden revelar reinicios o errores de calibración que oculta el promedio del tablero. Retroceda si la estabilidad, la temperatura o la eficiencia se deterioran.
Lo que queda por verificar
La entrada README es documentación valiosa, pero los operadores aún necesitan una versión etiquetada, recursos descargables y sumas de verificación que coincidan con sus placas. Revise los problemas abiertos para detectar problemas específicos del dispositivo y no asuma que una fecha README demuestra que una imagen ha completado su paquete de lanzamiento. ASIC.tools se vinculará únicamente a una descarga ascendente verificable y no reflejará un binario no confirmado como firmware oficial. La evidencia actual respalda una conclusión limitada: el proyecto upstream documenta las características v3.1.03 para Nexus y placas relacionadas, incluido un comportamiento de detección y recuperación más seguro, mientras que cada usuario aún debe verificar la compatibilidad exacta del hardware y la disponibilidad de los activos antes de flashear.
Antes del lanzamiento de una flota, guarde la URL ascendente exacta, la etiqueta, el hash de confirmación, la suma de verificación del archivo y el tiempo de instalación para el dispositivo de prueba. Ese registro permite a un operador reproducir la imagen y determinar si dos mineros realmente ejecutan código idéntico. Utilice una ventana de mantenimiento, acceso local y una copia de seguridad de la configuración en buen estado. Después de reiniciar, compare la frecuencia, el voltaje, la temperatura, la velocidad del ventilador, las partes aceptadas y rechazadas y la alimentación de la pared con la línea base previa a la actualización. Mire el tiempo suficiente para captar el intervalo de recuperación de quince minutos descrito en las notas. Si un tablero no aparece explícitamente como compatible, deténgase y pregunte al proyecto anterior en lugar de seleccionar una imagen con un nombre similar. El firmware puede mejorar las salvaguardas, pero una identificación cuidadosa y una implementación por etapas siguen siendo la protección más sólida contra una interrupción evitable.
Fuente: NMminer1024 / GitHub ↗
Calculadora de minería ↗
