¿Tu minero casero no hashea? Biblia del troubleshooting 2026

Busca en cualquier comunidad de minería casera un día cualquiera y encontrarás los mismos mensajes: un Bitaxe que arranca pero se queda en 0 GH/s, un NerdQaxe que se reinicia cada dos minutos, un Gamma que perdió la mitad del hashrate tras una actualización de firmware, una máquina que dice estar hasheando mientras el pool no ve nada. Estos dispositivos son hardware de código abierto ejecutando firmware de código abierto sobre silicio industrial rescatado, y esa combinación es potente, barata y genuinamente frágil de formas en que un electrodoméstico no lo es.

Esta guía es la referencia que deseábamos que existiera cada vez que ayudábamos a alguien a depurar uno. Cubre los seis dominios de fallo que explican casi cualquier unidad muerta o defectuosa, te enseña a leer los logs como lo hace un banco de reparación y termina con una tabla maestra de síntomas y un diccionario de las líneas de error reales que verás. Se aplica a toda la familia AxeOS: cualquier Bitaxe (Max, Ultra, Supra, Gamma, Gamma 601/602, GT, Hex), las líneas NerdAxe y NerdQaxe incluidas las variantes ++ e Hydro, el NerdOctaxe y, por extensión, cualquier derivado de ESP-Miner, incluidas las nuevas máquinas BM1373 que cubrimos en nuestra referencia de la era BM1373.

Un principio antes que nada: diagnostica antes de tocar. El orden de operaciones de esta guía existe porque cada paso descarta toda una clase de causas. Saltar directamente a reflashear el firmware cuando el problema real es una fuente que cae te cuesta una tarde y puede dejarte con dos problemas en lugar de uno.

¿Con prisa? Las cinco soluciones que resuelven la mayoría de casos

Antes de leer nada más, prueba estas en orden. Juntas resuelven la mayoría de los avisos de «mi minero está muerto» sin herramientas, sin logs y sin abrir la carcasa.

1. CICLO EN FRÍO, BIEN HECHO.
   Desconecta el CONECTOR de alimentación (no el interruptor
   del enchufe). Cuenta 60 segundos completos. Reconecta.
   Por qué: los fallos del regulador SE ENCLAVAN y sobreviven
   a cualquier reinicio por software; solo un corte real de
   energía los borra.

2. COMPRUEBA QUÉ LO ALIMENTA DE VERDAD.
   USB-C mueve el panel pero NO puede alimentar el ASIC.
   Un minero solo con USB-C marca 0 GH/s y ~2 W para siempre.
   Verifica que la fuente real (jack/XT30) esté enchufada y
   bien asentada, y que sea el VOLTAJE CORRECTO (5 V frente
   a 12 V: el equivocado destruye la placa).

3. ESCRIBE http:// EXPLÍCITAMENTE.
   Los navegadores cambian en silencio a https:// y fallan.
   http://IP-DEL-MINERO, con el prefijo, siempre.

4. DALE 2,4 GHz.
   Estas radios nunca hablan 5 GHz. En routers mesh, crea un
   SSID solo de 2,4 GHz o una red IoT, WPA2-AES, y desactiva
   el aislamiento de AP.

5. PREGUNTA AL POOL, NO AL MINERO.
   El tiempo desde el último share aceptado en el panel del
   POOL es la única prueba honesta de que está en línea. Más
   de 10 minutos = muerto ahora, diga lo que diga la interfaz.

¿Resuelto? Bien, cierra la pestaña. ¿No? El triaje de abajo
encuentra tu sección en 60 segundos.

Encuentra tu problema rápido

Veinte secciones son muchas. Tres formas de saltar a la tuya:

Por búsqueda: cada cadena de error de esta guía está escrita literalmente, tal como la imprime el firmware. Pulsa Ctrl+F (Cmd+F en Mac), pega tu mensaje de error y caerás justo encima: es una decisión de diseño, no suerte.

Por síntoma:

Por estilo de lectura: la siguiente sección divide la guía en un camino para principiantes y otro profesional.

Elige tu camino

Esta guía atiende a dos lectores muy distintos, y no deberías leerla igual.

¿Primer minero, primer problema? Sigue el camino numerado y no te saltes nada: las dos reglas de seguridad, el autotest integrado, el triaje de 60 segundos y después solo la sección a la que el triaje te envíe. Cada bloque de código está listo para copiar y pegar, cada término que quizá no conozcas está en el miniglosario de justo debajo, y nada del camino para principiantes exige abrir la carcasa ni tener un multímetro.

¿Cómodo con una terminal y un polímetro? Tu carril rápido: la sección de la API para descargar logs en remoto y revisar la flota, el diccionario de líneas rojas para saltar directo de una cadena de error a su causa, la tabla de peculiaridades por modelo y la sección profesional de banco al final, donde viven los esquemáticos, el método de puntos de medida y los recursos a nivel de placa. Las secciones marcadas como PRO asumen que sabes leer un esquemático y medir una placa energizada sin riesgo.

Miniglosario para el que empieza

Diez términos, diez segundos cada uno, y el resto de la guía se lee al doble de velocidad.

ASIC        el chip minero en sí, la única pieza que
            realmente calcula hashes
ESP32       el pequeño controlador que hace todo lo demás:
            WiFi, panel, hablar con el ASIC
AxeOS       el firmware + el panel web sobre el ESP32
VCORE       la alimentación de ~1,0-1,3 V del núcleo del
            ASIC, generada en la placa a partir de tus
            5 V o 12 V de entrada
VRM / TPS546  el circuito regulador que crea VCORE y
            protege el chip apagándose ante fallos
stratum     el protocolo con el que tu minero habla al pool
share       una prueba de trabajo que envías; el pool las
            cuenta para saber que estás vivo y eres honesto
% error HW  resultados que el chip calculó MAL: la cifra
            honesta de salud (mantener por debajo del 2%)
OTA         actualización «por el aire» desde el panel, en
            contraposición a flashear por USB
NVS         la memoria de ajustes que sobrevive a los
            reflasheos; por eso existe el reset de fábrica

Antes que nada: dos reglas de seguridad y una herramienta integrada

Las dos reglas que evitan placas muertas

Regla uno: nunca adivines el voltaje. Los Bitaxe estándar de un solo chip usan 5 V; el GT, el Hex, el NerdQaxe++ y el NerdOctaxe usan 12 V. Los conectores jack de ambas familias son físicamente intercambiables, y conectar una fuente de 12 V a una placa de 5 V la destruye permanentemente en menos de un segundo. Antes de cada conexión, lee la etiqueta de la fuente, no la forma del conector. Es el error más caro de esta afición.

Regla dos: un conector caliente significa parar. Templado es un aviso; caliente, descolorido u oliendo a plástico significa apagar ya y sustituir el cable antes del siguiente encendido. Todo lo demás en esta guía puede esperar a mañana. Esto no.

Ejecuta el autotest integrado

AxeOS incluye un autotest de encendido cuya existencia la mayoría de propietarios desconoce. Comprueba cinco subsistemas en secuencia e informa del primer fallo en la pantalla, lo que lo convierte en un diagnóstico de hardware gratuito de treinta segundos que te nombra el dominio averiado:

QUÉ COMPRUEBA (en orden)      SI FALLA, LA PANTALLA MUESTRA
  raíl de entrada               POWER FAIL
  regulador de voltaje núcleo   VCORE FAIL
  bus de sensores I2C           (se queda colgado en el test)
  realimentación del ventilador FAN FAIL
  detección del ASIC            ASIC FAIL
  ráfaga corta de hashing       HASHRATE FAIL

CÓMO LEER EL RESULTADO
  POWER / VCORE FAIL   -> sección Problemas de energía. El
                          test rechaza una entrada que se
                          desvíe más de un 10% del nominal;
                          mide la fuente.
  ASIC FAIL            -> sección Problemas del ASIC.
  FAN FAIL             -> ventilador desconectado, atascado
                          o cable de tacómetro muerto.
  HASHRATE FAIL        -> chip detectado pero sin calcular:
                          normalmente energía justa o un
                          problema de ajustes; vuelve a los
                          valores de fábrica.

SI EL PROPIO TEST SE ATASCA
  Pantalla clavada en SELF TEST más de 30 segundos, o un
  bucle infinito SELF TEST -> reinicio: en AxeOS v2.12+
  mantén pulsado el botón BOOT 2 segundos durante la
  pantalla SELF TEST para saltarlo y llegar al panel, y
  diagnostica desde ahí. Un bucle de autotest tras flashear
  suele significar una imagen equivocada para la placa.

El autotest se ejecuta automáticamente en el primer arranque y puede lanzarse desde los ajustes. Hazlo después de cualquier evento de hardware: un transporte, un remontaje del disipador, un cambio de fuente. Convierte «algo va mal» en un subsistema con nombre antes de que hayas abierto un solo log.

Qué te está diciendo la pantalla

En los modelos con display, el OLED es un instrumento de estado, no decoración. Va rotando pantallas de información cada pocos segundos; el botón BOOT avanza manualmente y despierta una pantalla apagada por tiempo. Los estados que conviene reconocer: la pantalla de arranque (el firmware vive), la del hotspot de configuración (sin configurar o credenciales WiFi perdidas), la de la dirección IP (tu puerta al panel), el autotest y los códigos FAIL de arriba, un aviso de sobrecalentamiento y la animación de bloque encontrado que esperamos que veas algún día. Una pantalla apagada no prueba que la placa esté muerta: comprueba si simplemente saltó el temporizador de apagado del display y si el pool sigue mostrando shares entrantes.

El triaje de 60 segundos

Antes de abrir un solo log, responde cinco preguntas. Particionan todo el espacio del problema.

P1  ¿Se enciende algo? (LED, pantalla, ventilador)
      NO  -> DOMINIO ENERGÍA. Ve a: Problemas de energía.
      SÍ  -> P2

P2  ¿Llega al panel de AxeOS o muestra una IP?
      NO  -> P2a: ¿Emite su hotspot de configuración?
             SÍ -> DOMINIO WIFI. Ve a: Problemas de red.
             NO -> DOMINIO ARRANQUE. Ve a: Firmware.
      SÍ  -> P3

P3  ¿El panel muestra un hashrate por encima de cero?
      NO  -> P3a: ¿Muestra un fallo de energía, un aviso de
             sobrecalentamiento o 0 chips ASIC?
             fallo energía -> Problemas de energía
             sobrecalent.  -> Problemas térmicos
             0 chips       -> Problemas del ASIC
      SÍ  -> P4

P4  ¿El POOL muestra shares aceptados en los últimos 10 min?
      NO  -> DOMINIO STRATUM. Ve a: Problemas de pool.
      SÍ  -> P5

P5  ¿Hashrate, tasa de error y temperatura son los correctos?
      NO  -> Problemas térmicos u overclock mal hecho.
      SÍ  -> No hay nada roto. Cierra la pestaña.

Fíjate en que P4 pregunta al pool, no al dispositivo. La persecución más habitual en falso del minado casero es depurar un minero cuya interfaz parece perfecta mientras el pool dejó de oírlo hace una hora. El dispositivo y el pool ven cada uno la mitad del cuadro, y esta guía vuelve a esa asimetría una y otra vez.

Cómo leer los logs

Todo lo demás en esta guía va más rápido si sabes leer los logs, así que esta sección va primero. Hay dos superficies de log, y responden a preguntas distintas.

El log web de AxeOS

Abre el panel en la IP del minero y busca la vista de log. Muestra el registro de ejecución en vivo: tráfico stratum, envíos de shares, cambios de dificultad, eventos de temperatura. Es la herramienta correcta cuando el dispositivo arranca bien y la pregunta es qué está haciendo ahora. Su límite: empieza cuando la red ya está levantada, así que no puede mostrarte un fallo de arranque, y muere con el servidor web, así que no puede mostrarte un cuelgue.

La consola serie: la verdad

Para cualquier cosa relacionada con el arranque, los cuelgues, la detección del ASIC o la asociación WiFi necesitas la consola serie. Es la misma salida que leen los desarrolladores y empieza desde la primera instrucción.

1. Conecta un cable de DATOS USB-C (no uno solo de carga)
   del minero al ordenador. En algunas placas Bitaxe una
   conexión nativa USB-C a USB-C no llega a negociar; usa
   un cable o adaptador USB-A a USB-C, que fuerza 5V clásico.

2. Abre un terminal serie a 115200 baudios, 8N1:

   Windows:  PuTTY -> Serial -> COMx -> 115200
   Linux:    sudo minicom -D /dev/ttyACM0 -b 115200
             (o: screen /dev/ttyACM0 115200)
   macOS:    screen /dev/tty.usbmodem* 115200

3. Pulsa el botón RST de la placa (o reconecta la energía).
   El log de arranque completo se desplaza desde el inicio.

Las líneas de log de ESP-IDF llevan una letra de severidad: I de información, W de aviso, E de error. La mayoría de terminales pintan las líneas E en rojo. Un arranque sano tiene cero líneas E. Esa es toda la habilidad de leer logs en una frase: recorre el arranque, encuentra la primera E y búscala en el diccionario del final de esta guía. El primer error es el que importa, porque los posteriores suelen ser daño en cascada del primero.

Cómo se ve un arranque sano

Anotado y resumido. El tuyo diferirá en detalles pero debe alcanzar los mismos hitos en el mismo orden.

rst:0x1 (POWERON_RESET), boot:0x8 (SPI_FAST_FLASH_BOOT)
        <- motivo del reset. POWERON es normal. Resets
           repetidos RTC_WDT o BROWNOUT aquí son tu primera
           señal de alarma.

I (xx) main: Found device config: <modelo de tu placa>
        <- el firmware identificó la placa. Un nombre de
           modelo equivocado aquí significa imagen de
           firmware equivocada.

I (xx) TPS546: Found TPS546D24A          (placas con TPS)
I (xx) Power: VCORE set to 1150 mV
        <- el regulador de núcleo respondió por I2C y el
           raíl del ASIC está arriba. Si falta este bloque
           o da errores, nada posterior puede funcionar.

I (xx) bm13xx: Found 1 chip(s)
        <- LA línea. La cifra debe igualar el número de
           chips de tu placa: 1 en monochip, 2 en el GT,
           4 en el NerdQaxe, 6 en el Hex, 8 en el Octaxe.

I (xx) wifi: connected, IP: 192.168.x.x
        <- red levantada. Los fallos de asociación imprimen
           aquí códigos de motivo (diccionario más abajo).

I (xx) stratum_task: Connected to pool ...
I (xx) stratum_task: mining.subscribe / authorize OK
I (xx) stratum_task: Set difficulty to ...
I (xx) create_jobs_task: New Work: ...
        <- el pool aceptó el login y envió trabajo.

I (xx) asic_result: Nonce found, diff xxx of yyy
        <- el ASIC devuelve resultados. En uno o dos minutos
           deberías ver shares por encima de la dificultad
           del pool siendo enviados y aceptados.

Memoriza el orden de los hitos: motivo del reset → configuración de placa → regulador → recuento de chips → WiFi → stratum → nonces. El hito que falle primero nombra la sección de esta guía que necesitas.

Problemas de energía: la causa número uno de todo

Si los fallos de mineros caseros tuvieran una clasificación, la alimentación ocuparía los tres primeros puestos. Estas placas mueven silicio de 3 nm y 5 nm a alta corriente desde fuentes de consumo y por conectores de consumo, y los márgenes son estrechos.

Conoce tu arquitectura de energía

Bitaxe monochip (Max/Ultra/Supra/Gamma)
  Entrada:   5 V por jack (5,5x2,1mm) o USB-C
  Corriente: hasta ~5 A en el Gamma de fábrica, más con OC
  Regulador: TPS546D24A buck digital (placas antiguas:
             DAC DS4432U + monitor INA260) baja los 5V a
             ~1,1-1,3V de núcleo ASIC a corriente muy alta
  Ventana:   el regulador arranca a ~4,8 V y corta bajo ~4,5 V

Familia 12 V (GT, Hex, NerdQaxe++, NerdOctaxe)
  Entrada:   12 V por conector XT30 o jack
  Corriente: NerdQaxe++ ~8+ A a plena carga; Octaxe más
  Riesgo:    calentamiento del conector; caída de la fuente

HECHO CRÍTICO: el USB-C de las placas Bitaxe actuales es
SOLO para el ESP32 y para flashear. No puede alimentar el
ASIC. Una placa funcionando solo con USB-C arranca, muestra
el panel y hashea a exactamente 0 GH/s consumiendo ~2 W.
Esto imita con precisión un regulador muerto y hace perder
horas cada semana en toda la comunidad.

Power Fault Detected: qué ha pasado en realidad

El regulador TPS546 vigila cuatro protecciones: sobrecorriente, sobretensión, subtensión y sobretemperatura. Cuando una salta, el regulador se enclava apagado y AxeOS muestra el aviso de fallo de energía. El ASIC pierde su raíl; el ESP32, alimentado aparte, mantiene viva la interfaz. Dos hechos gobiernan la solución:

• El enclavamiento sobrevive a los reinicios por software. El estado de fallo se guarda en el registro de estado del propio regulador hasta que se retira físicamente la tensión de entrada. Reiniciar desde la interfaz web, llamar a la API de reinicio o pulsar el botón de reset del ESP32 no lo borra. Es comportamiento documentado, no un bug, y también es la razón de que exista toda una clase de issues en GitHub: placas BM1370 atascadas a 0 GH/s consumiendo 5 W donde el endpoint de reinicio no arregla nada pero un ciclo de energía lo arregla todo.
• El disparo es un síntoma; la causa está aguas arriba. El regulador protege un chip que vale más que la placa que lo rodea. La abrumadora mayoría de disparos recurrentes se remonta a la energía de entrada, no al regulador.

La secuencia de solución, en orden:

1. CICLO EN FRÍO. Desconecta el conector de alimentación en
   sí (no el interruptor de la pared). Cuenta 10 segundos
   completos. Algunas placas necesitan 60 segundos para que
   los condensadores de filtro se descarguen y se borre un
   estado de retención por brownout del ESP32. Reconecta.
   Esto solo ya resuelve la mayoría de fallos puntuales.

2. QUITA EL USB-C. Si hay algo enchufado al USB-C, quítalo y
   verifica que la fuente real (jack/XT30) esté bien puesta.
   Descarta la trampa del USB-C descrita arriba.

3. MIDE BAJO CARGA. Multímetro en DC en el conector de
   entrada MIENTRAS EL MINERO HASHEA:
     placas 5 V:  espera 4,9-5,3 V sostenidos.
                  Por debajo de 4,8 V = la fuente es el
                  problema.
     placas 12 V: espera 11,8-12,2 V sostenidos.
                  Por debajo de 11,4 V = la fuente es el
                  problema.
   Una medida sin carga no prueba nada: las fuentes baratas
   muestran 5,0 V perfectos en reposo y se hunden a 4,4 V
   bajo carga.

4. ELIMINA LA RUTA. Enchufa la fuente directamente a la
   pared: sin regletas, sin alargadores, sin encadenados.
   Las regletas de baja calidad añaden caída medible.
   Mueve el jack: si la pantalla parpadea, el conector o el
   cable están gastados.

5. MEJORA LA FUENTE. Especificación mínima honesta:
     placas monochip 5 V:      5 V / 5 A de calidad, dedicada
     clase NerdQaxe++ 12 V:    12 V / 10 A (120 W) mínimo
   Los cargadores de móvil y los adaptadores universales son
   con diferencia la causa raíz más común de toda esta guía.

La advertencia del XT30

La familia de 12 V empuja 8 o más amperios por un XT30. El conector está dimensionado para ello; las coletas soldadas a mano que hay detrás muchas veces no. Inspecciona en busca de pines descoloridos, un conector templado al tacto, soldaduras frías o crimpados flojos. Una unión de alta resistencia a 8 A se calienta, se oxida, resiste más y se calienta más: es el único modo de fallo del minado casero que acaba en plástico fundido. Si el conector alguna vez estuvo lo bastante caliente como para descolorirse, cambia el cable, no lo reutilices. Las unidades NerdQaxe que se cuelgan con un error de fuente y un código Guru Meditation se remontan exactamente a este raíl cayendo bajo carga.

Brownout: el cuelgue que no es un cuelgue

El ESP32 tiene un detector de brownout por hardware. Cuando el raíl de 3,3 V cae, imprime Brownout detector was triggered y se reinicia. Un minero que se reinicia cada pocos minutos, sobre todo cuando el ASIC sube a plena carga, casi nunca tiene un problema de firmware: es la alimentación cayendo en el momento de máximo consumo. La solución son los pasos 3 a 5 de arriba. No persigas al firmware por un bucle de brownout.

Problemas del ASIC: el chip no responde

La línea del log de arranque que hay que vigilar es el recuento de chips. El firmware enumera la cadena de ASIC por UART e imprime cuántos chips respondieron. Cualquier cosa que no sea el número completo de tu placa pertenece a esta sección.

Cero chips detectados

El panel muestra recuento ASIC 0 o el log muestra un fallo de inicialización. Causas, por frecuencia observada:

1. Regulador enclavado o estado de brownout retenido. Un chip sin voltaje de núcleo no puede enumerarse. Haz la descarga en frío completa de 60 segundos antes que nada: desconecta la fuente principal, el USB-C y todos los accesorios, espera un minuto entero y vuelve a alimentar. Esto solo cierra una fracción notable de los casos.
2. Imagen de firmware equivocada. Flashear la imagen de otra placa, aunque sea una sola vez, puede dejar una configuración de dispositivo errónea en la memoria no volátil que persiste entre reflasheos. Si la línea de modelo del log de arranque no coincide con la placa física, haz un reset de fábrica completo y luego flashea la imagen correcta. Una imagen de BM1366 en una placa BM1370 nunca encontrará el chip.
3. Evento mecánico. La secuencia clásica: la unidad se movió, se cayó, se envió, o se reapretó el disipador, y nunca volvió a hashear. Bajo el ASIC hay una matriz BGA de soldaduras; la flexión las agrieta. Una presión de montaje desigual del disipador hace lo mismo. Si la cronología encaja, es una reparación de banco (reflow), no un problema de ajustes.
4. Escape de fábrica. Una unidad nueva que nunca ha hasheado ni una vez tiene una probabilidad desproporcionada de ser una soldadura fría de fabricación. No dediques un fin de semana al software: haz la descarga en frío y la comprobación de firmware, y luego reclama la garantía.

Recuento parcial de chips: la firma multichip

Un Hex que reporta 3 de 6, un NerdQaxe que reporta 2 de 4, un GT que reporta 1 de 2. Las placas multichip enumeran los ASIC como una cadena, así que un solo chip muerto o desconectado rompe la detección en ese punto de la cadena: el número te dice aproximadamente dónde está la rotura. Una placa de cuatro chips que muestra 2 tiene un problema en el chip 3. Las causas son las mismas de arriba (margen de energía, soldadura agrietada) más una específica del multichip: un chip débil en la cadena que se cae solo a frecuencia alta. Si el recuento completo vuelve a frecuencias de fábrica pero desaparecen chips al hacer overclock, has encontrado el die más débil de tu lotería del silicio, y su techo es el techo de toda la placa.

Errores I2C: el bus de sensores, no el minero

Una clase confusa: el minero hashea con normalidad mientras Power, ASIC Temp e Input Voltage aparecen como guiones, nulos o ceros, y el log muestra errores de transmisión/recepción I2C o timeouts. La ruta de hashing (UART hacia el ASIC) y la ruta de telemetría (I2C hacia el PMBus del regulador, el sensor de temperatura, el monitor de corriente) son buses separados. Uno puede fallar mientras el otro funciona. Detonante conocido: una banda de regresión de firmware en torno a AxeOS v2.13/v2.14 donde la ruta de lectura de sensores falla en silencio en un subconjunto de unidades. También lo causa cualquier accesorio que comparta el conector I2C: un OLED añadido o un sensor externo con conexión inestable puede bloquear el bus para los sensores integrados. Deja la unidad de serie, haz un ciclo en frío, y si es la banda de firmware, actualiza hacia delante o retrocede una versión.

El efecto secundario peligroso: sin realimentación de temperatura la curva del ventilador no puede funcionar, así que el ventilador se queda fijo a una velocidad. Si la telemetría está muerta, considera la protección térmica igualmente muerta y no dejes la unidad desatendida hasta arreglarlo.

Problemas térmicos: el calor es un presupuesto, no un evento

Las cifras que importan

Temp. núcleo ASIC  objetivo:  55-62 C sostenidos
                   preocupa:  por encima de 65 C constantes
                   corte:     ~75 C -> modo Overheat

Temp. VREG         va 10-15 C más caliente que el núcleo
                   bajo carga; en placas BM1370/BM1373 es a
                   menudo el sensor limitante, no el núcleo

Modo Overheat      el hashing se detiene, el ventilador va
                   al 100%, la interfaz sigue viva; se sale
                   con histéresis cuando la temperatura
                   vuelve a unos 65 C

Diagnóstico por patrón

Se sobrecalienta al instante en frío — problema de montaje. El disipador no hace contacto: almohadilla térmica ausente o rota, pasta seca o inexistente, par de apriete desigual, o un disipador que se soltó en el transporte. Un chip sin contacto pasa de temperatura ambiente al corte en segundos. Vuelve a montarlo, aplica un grano de arroz de pasta de calidad y aprieta los tornillos en cruz de forma uniforme.

Se sobrecalienta a los 10-30 minutos — problema de capacidad. El contacto es bueno pero el sistema no evacúa el calor tan rápido como lo genera. Las causas se acumulan: ambiente por encima de unos 27 C, unidad en un armario, cajón o caja cerrada, entrada o salida de aire bloqueada, capa de polvo en las aletas, o un overclock para el que la refrigeración nunca se dimensionó. Dale 10 cm de aire libre a ambos lados, limpia las aletas, y si empezó tras un cambio de frecuencia, ese cambio fue demasiado.

Deriva lenta durante semanas — problema de mantenimiento. Los mismos ajustes y la temperatura subiendo grado a grado: acumulación de polvo o pasta térmica secándose. La pasta en estas placas es un consumible; renovarla cada 6 a 12 meses es normal.

Sobrecalentamiento tras una actualización de firmware — problema de curva. Las curvas de ventilador y calor cambian entre versiones; un ejemplo documentado en torno a la v2.11 desplazó el comportamiento por defecto lo bastante como para que las unidades funcionaran varios grados más calientes y algo más lentas con ajustes de fábrica. Lee las notas de la versión, sube la velocidad del ventilador un escalón a mano, o ajusta la temperatura objetivo si tu firmware expone control PID.

El ventilador en sí

Un ventilador que reporta 0 RPM a cualquier temperatura está desconectado, atascado por un cable o muerto. Un ventilador chillando al 100% de forma constante significa o bien un chip realmente caliente (ver arriba) o telemetría de temperatura muerta guiando la curva a ciegas (ver la sección I2C). Los ventiladores de recambio de 40 mm y 60 mm son baratos; los silenciosos de gama alta (la elección habitual de la comunidad es un Noctua) bajan el ruido por debajo de 40 dB y son la mejora de hardware con mejor relación calidad-precio en cualquiera de estas unidades.

Problemas de red: la visión del mundo WiFi del ESP32

La radio de todas estas máquinas habla solo 2,4 GHz. Ni 5 GHz, ni 6 GHz, sin excepciones, sin arreglo por firmware. Una enorme proporción de fallos de instalación se reduce a esa frase chocando con el comportamiento de los routers modernos.

El problema del router mesh

Los sistemas mesh modernos emiten un SSID combinado y dirigen a los clientes entre bandas. El ESP32 no puede unirse al lado de 5 GHz, y el band steering puede impedirle asentarse en 2,4 GHz. Las soluciones fiables; la mayoría de routers admite al menos una:

Opción A  Crear un SSID exclusivo de 2,4 GHz (lo mejor)
Opción B  Usar la función «red IoT» del router: varios
          fabricantes la añadieron justo para dispositivos
          como estos
Opción C  Desactivar el band steering / «smart connect»
          para que las bandas aparezcan como SSID separados

Después verifica en el SSID de 2,4 GHz:
  Seguridad      WPA2-Personal, solo AES (no TKIP, y las
                 redes solo WPA3 fallarán)
  Canal          fijo 1, 6 u 11 en zonas congestionadas,
                 no Auto
  Ancho de canal 20 MHz
  Aislam. de AP  DESACTIVADO <- activado, el WiFi conecta
                 pero el panel es inalcanzable desde tu LAN,
                 lo que parece exactamente un aparato muerto
  Filtrado MAC   apagado, o añade la MAC del minero

Leer fallos de WiFi en el log serie

La consola serie imprime un motivo de desconexión en cada asociación fallida, y el motivo nombra la solución:

AUTH_EXPIRE / auth failed      contraseña (PSK) incorrecta.
                               Reescríbela; ojo con las
                               comillas tipográficas si la
                               pegaste desde el móvil.
NO_AP_FOUND                    SSID no visible en 2,4 GHz:
                               band steering, SSID oculto,
                               fuera de alcance o solo 5 GHz.
beacon timeout                 señal demasiado débil o canal
                               congestionado; mueve la unidad
                               o fija el canal.
ASSOC_TOOMANY                  límite de clientes del router
                               alcanzado.
Brownout detector triggered    no es WiFi en absoluto: el
                               pico de consumo de la radio al
                               asociarse hunde una fuente
                               débil. Arregla la energía, no
                               la red.

Ese último merece énfasis: transmitir por WiFi es el mayor pico instantáneo de carga que produce el ESP32. Una fuente justa que sobrevive al reposo muere en la asociación, así que una unidad que «se cuelga al conectarse al WiFi» suele ser un problema de energía disfrazado de red.

Accesible pero sin fallo de WiFi

Dos funciones de seguridad de routers merecen mención especial porque bloquean mineros por diseño. ASUS AiProtection y el equivalente de algunos modelos TP-Link clasifican el tráfico stratum como sospechoso y lo descartan en silencio: el minero se une al WiFi perfectamente y luego no alcanza ningún pool. Si una unidad conecta al WiFi pero toda conexión a pool falla, y ese mismo pool funciona desde un hotspot del móvil, desactiva la función de protección del router o pon el minero en la lista blanca antes de tocar nada más.

Y una peculiaridad de navegador que genera falsas alarmas sin fin: AxeOS sirve HTTP plano en el puerto 80. Los navegadores modernos convierten en silencio las direcciones desnudas a HTTPS, lo que falla, y el minero parece muerto. Escribe el prefijo explícitamente: http:// delante de la IP, siempre. Si sigue fallando, prueba otro navegador y desactiva los bloqueadores de anuncios para direcciones locales.

Si el minero tiene IP pero no puedes abrir el panel: aislamiento de AP (arriba), una peculiaridad de la lista de clientes del router, o mDNS. El dispositivo se anuncia con un nombre .local; cuando varias unidades usan el mismo nombre, el firmware moderno añade automáticamente un sufijo derivado de la MAC, pero las cachés mDNS obsoletas de tu ordenador pueden seguir apuntando a la unidad equivocada. En caso de duda, usa la IP en crudo de la tabla DHCP del router y dale a cada unidad un nombre distinto.

Problemas de stratum y pool: la última milla

El dispositivo arranca, hashea, y el pool es donde se decide la verdad. En esta sección la vista del minero y la vista del pool tienen que leerse juntas.

Conexión rechazada o inalcanzable

Comprueba en este orden:
1. URL exacta: stratum+tcp://host:puerto - sin https://,
               sin barra final, con el puerto presente y
               correcto
2. DNS:        ¿otro dispositivo de la misma LAN resuelve
               el host? Algunos routers de operadora y
               filtros DNS (o bloqueadores tipo Pi-hole)
               se comen los dominios de minería en silencio.
3. Puerto:     algunas redes bloquean puertos de salida
               poco comunes. Prueba desde un hotspot del
               móvil: si allí conecta, la red de casa filtra.
4. Región:     prueba el otro endpoint regional del pool;
               puedes estar viendo una caída de una región.

Authorize falla

El pool rechazó el login. En un pool solo el nombre de usuario es tu dirección de wallet más el nombre del worker, y la dirección es toda la identidad: no hay cuenta que puedas escribir mal. Causas: una dirección con una errata (basta un carácter), una dirección de la cadena equivocada (ver abajo), un nombre de worker con espacios o caracteres especiales, o un campo de contraseña que el pool espera no vacío (usa x).

La dirección de la cadena equivocada: el asesino silencioso

El error de configuración más dañino del minado SHA-256 multicadena, y puede fallar de dos formas distintas:

• Fallo ruidoso: el pool valida el formato de dirección por cadena y rechaza el authorize o todos los shares. Molesto pero seguro: te enteras en minutos.
• Fallo silencioso: una dirección válida en formato para más de una cadena, o un pool que no valida en profundidad, acepta tus shares todo el día, y luego el pago no puede llegarte. En un pool solo no custodial, las recompensas de bloque se pagan coinbase-directo a la cadena de texto de dirección que configuraste. No existe ticket de soporte que revierta una coinbase pagada a una dirección de la que no puedes gastar.

La regla: la dirección debe ser nativa de la cadena a la que apuntas, generada por un monedero de esa cadena y verificada. Si rotas un mismo minero físico entre cadenas, mantén una tabla escrita de cadena a dirección y revisa el campo de usuario cada única vez que cambies la URL stratum. Esto vale más que todos los demás consejos de esta sección juntos.

Shares rechazados: leer los motivos de rechazo

Los rechazos no son un problema único; la cadena de motivo en el log te dice cuál de los cuatro problemas tienes.

"job not found" / stale       Enviaste trabajo de un job
  en ráfagas pequeñas justo   que el pool ya había
  tras bloques nuevos         reemplazado: normal en los
                              cambios de bloque. Por debajo
                              del ~1-2% total: ignóralo.
                              Sostenido más alto: latencia
                              de red o pérdida de paquetes
                              WiFi; revisa el RSSI, prueba
                              la región de pool más cercana.

"above target" /              El share no alcanza la
"low difficulty share"        dificultad que asignó el pool.
                              Casos persistentes: un desfase
                              tras un cambio de dificultad,
                              o errores de hardware que
                              corrompen el resultado. Revisa
                              el % de error HW.

"duplicate"                   El mismo nonce enviado dos
                              veces. Ocasional: artefacto
                              inofensivo de reintento. Un
                              chorro de ellos: estado de
                              fallo conocido en que el ASIC
                              se queda en bucle sobre un
                              nonce; el chip se atascó.
                              Ciclo de energía; si se repite
                              con tus frecuencias actuales,
                              reduce el overclock.

todo rechazado                Configuración, no mala suerte:
                              dirección de cadena errónea,
                              nombre de worker mal formado,
                              o puerto equivocado (p. ej. un
                              puerto de dificultad alta
                              pensado para ASIC grandes).

Porcentaje de error de hardware: la cifra honesta

El hashrate del panel es una afirmación; la tasa de error de hardware es una confesión. Cuenta los resultados que el ASIC devolvió y no pasan la verificación. Por debajo del 2 por ciento es sano. Tasa de error creciente con temperatura creciente significa térmica; tasa creciente a temperatura constante tras un cambio de ajustes significa que el punto de frecuencia y voltaje está más allá del silicio de este chip. Un chip al 5 por ciento de errores puede mostrar un hashrate orgulloso mientras tu hashrate efectivo cae en silencio por debajo de lo que daría una frecuencia menor. Al afinar, optimiza los shares aceptados por hora, nunca la cifra del panel. El método completo está en la sección de ajuste de la referencia BM1373, y el trasfondo de qué significa la dificultad de share en la explicación del best share.

«El minero dice que hashea pero el pool no muestra nada»

El síntoma más publicado en todas las comunidades, así que aquí está la ruta de resolución completa:

1. LADO POOL, tiempo desde el último share aceptado:
   más de 10 minutos = la conexión está muerta AHORA, diga
   lo que diga la interfaz del minero. Las medias del panel
   decaen a lo largo de ~una hora y ocultan desconexiones
   recientes. «Hashrate por encima de cero» NO es una prueba
   de estar en línea; «último share reciente» sí.

2. LADO MINERO, log en vivo:
   ¿Se están ENVIANDO shares? Si el ASIC encuentra nonces
   pero no se envía nada, el socket stratum está atascado:
   reinicia el minero.
   ¿Los envíos dan ERROR? Lee la tabla de motivos de rechazo.

3. IDENTIDAD: ¿el panel del pool que estás mirando está
   filtrado por la misma dirección de wallet Y la misma
   moneda para la que está configurado el minero? Un número
   sorprendente de casos son un panel de BTC abierto
   mientras el minero apunta a BCH, o la página de una
   dirección de prueba de ayer.

4. FALLBACK: ¿hay un pool de respaldo configurado y el
   minero cambió a él en silencio? Tu hashrate puede estar
   llegando al OTRO pool. Revisa sus estadísticas.

Configura siempre el respaldo

Todos los dispositivos de la familia AxeOS admiten un pool de respaldo. Un minero sin respaldo que pierde su socket stratum a las 2 de la madrugada no hace nada hasta que te das cuenta, y la media decreciente del panel se asegura de que te des cuenta tarde. Pon el respaldo en una segunda región de tu pool para que un problema regional nunca deje la máquina parada. Los hosts y puertos por región para cada cadena están en la página de conexión.

Problemas de firmware: flashear, brickear, recuperar

El OTA de dos archivos y el medio brick

Las actualizaciones de AxeOS vienen en dos artefactos: el binario del firmware y la imagen de la interfaz web (www.bin). Un modo de fallo documentado es que el OTA se atasque en la fase de www.bin, dejando firmware e interfaz desincronizados: el dispositivo arranca y mina pero el panel está en blanco o roto. Esto no es un brick. Ve directamente a la URL de recuperación:

http://<ip-del-minero>/recovery

y vuelve a subir la imagen web. Si el dispositivo no arranca en absoluto tras una actualización fallida, el flasher web por USB (Chrome o Edge, cable de datos USB-C) reescribe la imagen de fábrica completa y recupera prácticamente cualquier soft-brick. Tres reglas hacen que flashear sea aburrido en vez de aterrador:

• La imagen debe corresponder exactamente a la placa, hasta la revisión. El número de revisión está impreso en la propia PCB y se muestra en la sección Sistema de AxeOS: un Supra 401 necesita la imagen 401, no la 402. Conoce los dos tipos de archivo de la página de releases: el completo esp-miner-factory-REV-vX.X.X.bin (bootloader + particiones + interfaz + firmware, para flasheo USB y recuperación total) y el más pequeño esp-miner.bin (solo firmware, para OTA desde el panel). Usar uno donde va el otro es una receta clásica de medio brick. Imagen de Gamma en un Gamma, de Ultra en un Ultra. Una imagen equivocada puede dejar una configuración errónea en la NVS que sobrevive a reflasheos normales; la cura es reset de fábrica más imagen correcta.
• Nunca flashees por WiFi con conexión justa o energía justa. El atasco durante www.bin se correlaciona exactamente con esas dos cosas.
• Conoce tu objetivo de rollback. Las regresiones ocurren: una banda de pérdida de telemetría en torno a v2.13/v2.14, un cambio de curva de ventilador en torno a v2.11 que dejó las unidades más calientes, una ruta de actualización en torno a v2.4.3 que se congeló en algunas revisiones hasta que los usuarios bajaron de versión. Antes de actualizar, anota tu versión actual; si la nueva se porta mal, la anterior está a un flasheo web de distancia en la página de releases del proyecto.

Bucles de cuelgue: leer un Guru Meditation

Un Guru Meditation Error es el kernel panic del ESP32. La palabra entre paréntesis es la pista:

Guru Meditation Error: Core X panic'ed (MOTIVO)

LoadProhibited /       bug de firmware tocando memoria
StoreProhibited        inválida: anota tu versión, revisa el
                       issue tracker, retrocede una versión
IllegalInstruction     flash corrupta o pila sobrescrita:
                       reflasheo completo por USB
Cache error /          suele seguir a problemas de PSRAM
DoubleException        (más abajo)
Interrupt wdt timeout  una tarea colgada; a menudo por red;
                       busca un issue conocido en tu versión

Un panic aislado: ignóralo. Un bucle: identifica si es el mismo motivo cada vez (fallo de firmware o hardware: actúa según la tabla) o si se intercala con mensajes de brownout (entonces es la energía: deja de leer panics y ve a arreglar la fuente).

Fallos de PSRAM: la especialidad de la familia Nerd

NerdQaxe, NerdOctaxe y otras placas construidas sobre el módulo ESP32-S3-WROOM-1 usan PSRAM externa. Un banner de arranque con un error de lectura del ID de PSRAM o un fallo de inicialización, seguido de un panic StoreProhibited en cuanto el firmware toca la RAM externa, tiene cinco raíces conocidas: módulos falsificados sin die de PSRAM, un firmware compilado con el modo de PSRAM equivocado (octal frente a quad), soldadura fría bajo el módulo, brownout durante la ventana de inicialización, o un die envejecido. El triaje práctico: descarta primero la energía (como siempre), flashea la imagen exacta del fabricante para tu placa (que codifica el modo de PSRAM correcto), y si el error persiste con energía limpia y firmware correcto, el módulo en sí es el culpable, lo que es un caso de garantía o de banco.

Overclock mal hecho: recuperación y prevención

La firma del fallo: frecuencia o voltaje subidos, y ahora la unidad se cuelga, se aplana tras minutos u horas, hace throttling, o desaparece un chip de una placa multichip. La física es implacable en un aspecto concreto: la inestabilidad por un reloj demasiado alto a menudo tarda en aparecer. Un ajuste que sobrevive a una prueba de 10 minutos puede fallar en el minuto 40, cuando la placa alcanza su saturación térmica, y por eso toda afirmación de estabilidad por debajo de 24 horas es provisional.

RECUPERACIÓN (si la unidad todavía arranca):
  Interfaz web -> devolver frecuencia y voltaje a fábrica ->
  guardar -> ciclo de energía en frío (borra cualquier fallo
  enclavado).

RECUPERACIÓN (si entra en bucle antes de llegar a la UI):
  Flashea la imagen de fábrica por USB: eso restaura los
  puntos de operación de serie. Luego reset de fábrica para
  vaciar la NVS.

PREVENCIÓN (todo el método en cinco líneas):
  - un escalón de 25 MHz cada vez, sin tocar el voltaje
  - 30 minutos mínimo por escalón, vigilando el % error HW
  - error por encima del 2% = baja un escalón; ese es el muro
  - solo entonces sube voltaje en pasos de 25 mV si aceptas
    el calor extra; quédate en la ventana 1100-1300 mV
  - 24 horas en el ajuste final antes de llamarlo estable

Y una nota honesta: bajar voltaje para ganar eficiencia falla igual que subir frecuencia para ganar velocidad, solo que en la otra dirección: voltaje insuficiente para el reloj produce los mismos errores y cuelgues. La lotería del silicio se aplica en ambos extremos.

Diagnosticar por la API: el atajo del usuario avanzado

Todos los mineros de la familia AxeOS exponen una API REST en el puerto 80, y eso cambia el aspecto de la resolución de problemas: no hace falta pantalla, no hay que hacer clic por paneles, y escala de una unidad a una flota. La especificación completa vive en el archivo openapi.yaml del repositorio ESP-Miner; estas son las llamadas que importan para diagnosticar.

Las cinco llamadas de diagnóstico

# Todo de golpe: medias de hashrate, temperaturas, voltaje,
# potencia, RPM del ventilador, shares, mejor dificultad,
# RSSI WiFi, uptime, versión de firmware, heap libre
curl http://IP-DEL-MINERO/api/system/info

# Estado del ASIC: modelo, cantidad, frecuencia, voltaje
curl http://IP-DEL-MINERO/api/system/asic

# La serie temporal con la que se dibujan las gráficas
curl "http://IP-DEL-MINERO/api/system/statistics?columns=hashrate,asicTemp,vrTemp,power"

# LA INFRAVALORADA: descargar los logs del aparato en remoto.
# Sin cable serie, sin PuTTY: trae el log por la red y filtra
# las líneas rojas del diccionario de abajo.
curl http://IP-DEL-MINERO/api/system/logs

# ¿Cuál es cuál? Hace que el aparato se identifique solo
# (pantalla/LED): valiosísimo en una estantería de cajas
# idénticas
curl -X POST http://IP-DEL-MINERO/api/system/identify

Ese endpoint de logs merece una frase propia: la mayor parte de la sección de consola serie de esta guía se puede hacer desde el sofá con esa única llamada, siempre que el aparato arranque lo bastante como para servir HTTP. El cable serie solo sigue siendo necesario para fallos de arranque y bucles de cuelgue.

Leer /api/system/info como un mecánico

Seis campos de ese JSON responden a la mayoría de consultas antes de que se formulen:

CAMPO (nombre habitual)   QUÉ TE DICE
hashRate / hashrate_10m   la afirmación: compárala con el pool
temp / asicTemp           el presupuesto de 55-62 C de la
                          sección térmica
vrTemp                    el lado del regulador: a menudo el
                          limitador real en BM1370/BM1373
voltage                   el raíl de entrada TAL COMO LO VE
                          LA PLACA: un multímetro por
                          software. Si cae por debajo de
                          4,9 V con carga = la fuente,
                          demostrado sin abrir la carcasa
power                     vatios consumidos: 2 W en una
                          unidad «hasheando» = trampa USB-C
sharesAccepted /          el par de la verdad; rechazados
sharesRejected            subiendo = tabla de motivos
wifiRSSI                  más fuerte que -70 dBm es sano;
                          más débil explica shares caducados
freeHeap                  encogiendo poco a poco durante
                          días = la clase de bug de fuga de
                          memoria; anota versión y revisa
                          el tracker

Salud de la flota en un bucle

Con más de una unidad, deja de mirar paneles. Este bucle imprime un resumen de salud de una línea por minero y marca los muertos:

#!/bin/bash
# fleet-check.sh - ajusta las IP a tu enjambre
for IP in 192.168.1.101 192.168.1.102 192.168.1.103; do
  J=$(curl -s -m 5 "http://$IP/api/system/info")
  if [ -z "$J" ]; then
    echo "$IP  INALCANZABLE"
    continue
  fi
  echo "$J" | python3 -c "
import sys, json
d = json.load(sys.stdin)
print('$IP  %-10s %6.1f GH/s  %4.1fC  %4.1fW  acc:%s rej:%s' % (
  d.get('hostname','?'),
  d.get('hashRate',0),
  d.get('temp',0),
  d.get('power',0),
  d.get('sharesAccepted','?'),
  d.get('sharesRejected','?')))"
done

Ejecútalo desde cron cada cinco minutos, canalízalo a la notificación que prefieras, y un fallo a las 2 de la madrugada pasa a ser una alerta a las 2:05 en lugar de una sorpresa por la mañana. Los nombres de campo varían ligeramente entre versiones de firmware; vuelca el JSON en crudo una vez y ajusta.

La API también arregla cosas

# Reiniciar sin tocar el hardware
curl -X POST http://IP-DEL-MINERO/api/system/restart
#   (recuerda: esto NO borra un fallo TPS546 enclavado;
#    para eso sigue haciendo falta desenchufar físicamente)

# Devolver un experimento de overclock a valores sensatos
curl -X PATCH http://IP-DEL-MINERO/api/system \
  -H "Content-Type: application/json" \
  -d '{"frequency": 525, "coreVoltage": 1150}'

# Arreglar una configuración de pool mal tecleada sin la UI
curl -X PATCH http://IP-DEL-MINERO/api/system \
  -H "Content-Type: application/json" \
  -d '{"stratumUser": "TU_WALLET.worker1"}'

Una advertencia honesta: la API no tiene autenticación. Cualquiera en tu LAN puede leer y reconfigurar tus mineros. En una red doméstica eso suele ser aceptable; en una red compartida o accesible a invitados, pon los mineros en su propia VLAN o segmento IoT: que, convenientemente, es la misma solución que ya recomendaba la sección de WiFi.

Peculiaridades por modelo: conoce la personalidad de tu placa

Más allá de los modos de fallo universales, cada familia de placas tiene comportamientos característicos que conviene conocer antes de depurar una.

La tabla maestra de síntomas

El diccionario de líneas rojas

Las cadenas de error que verás de verdad, en un solo sitio, escritas literalmente para que Ctrl+F las encuentre. Encuentra tu línea, consigue tu dirección.

LÍNEA EN EL LOG                    SIGNIFICADO -> ADÓNDE IR
---------------------------------------------------------------
Brownout detector was triggered    caída de tensión -> Energía
rst:0x.. (BROWNOUT_RESET)          lo mismo, en el banner de reset
Power Fault Detected               TPS546 enclavado -> Energía
TPS546 status / regulator fault    misma familia -> Energía
VCORE init failed /                el firmware no puede programar
  device ID mismatch               el regulador: imagen mala o
                                   I2C -> ASIC + Firmware
i2c_master_transmit_receive err /  bus de sensores caído -> ASIC,
  ESP_ERR_TIMEOUT near boot          subsección I2C
Found 0 chip(s) / ASIC init fail   el chip no responde -> ASIC
Chip count N of M                  rotura de cadena en N+1 -> ASIC
Device has overheated /            corte a 75 C -> Térmico
  Overheat Mode
VREG temp over limit               regulador caliente -> Térmico
wifi: NO_AP_FOUND                  visibilidad 2,4 GHz -> Red
wifi: AUTH_EXPIRE / auth fail      contraseña mala -> Red
wifi: beacon timeout               señal o canal débil -> Red
wifi_disconnect reason: N          busca N; soluciona por motivo
Stratum connection failed /        pool inalcanzable -> Stratum
  connect errno
authorize failed                   login rechazado -> Stratum,
                                   revisar dirección y worker
job not found (al enviar)          share caducado -> Stratum
above target / low diff share      desfase de dificultad o error HW
duplicate share                    nonce atascado -> ciclo de
                                   energía, luego bajar reloj
Guru Meditation Error: (MOTIVO)    panic -> Firmware, lee la
                                   palabra del motivo
esp_psram: PSRAM ID read error /   init de PSRAM -> Firmware,
  Failed to init external RAM        subsección familia Nerd
E (xx) esp_image: checksum failed  flash corrupta -> reflash USB
[www.bin / UI en blanco tras OTA]  URL de recovery -> Firmware

Mantenimiento preventivo: el ritual mensual de 15 minutos

Casi todo lo anterior es más barato de prevenir que de depurar.

MENSUAL
  [ ] Polvo: aletas y aspas del ventilador (aire comprimido,
      sujetando el ventilador)
  [ ] Revisión desde el pool: tendencia aceptados frente a
      rechazados, y % de error HW todavía por debajo de 2
  [ ] Vistazo a las temperaturas: ¿deriva respecto al mes
      pasado?
  [ ] Tocar físicamente el conector de energía: templado es
      un aviso, caliente es un alto

CADA 6-12 MESES
  [ ] Renovar la pasta térmica (es un consumible)
  [ ] Inspeccionar pines XT30 o jack por decoloración
  [ ] Reverificar la fuente bajo carga con un multímetro

EN CADA ACTUALIZACIÓN DE FIRMWARE
  [ ] Leer las notas de versión ANTES de flashear
  [ ] Anotar la versión actual (tu objetivo de rollback)
  [ ] Flashear con energía estable, a ser posible cerca del
      router
  [ ] Revisar la configuración de pool después: las
      actualizaciones pueden resetear campos

SIEMPRE
  [ ] Pool de respaldo configurado (segunda región)
  [ ] Nombres de worker distintos en toda la flota
  [ ] Tabla escrita: cadena -> dirección de wallet
  [ ] Ajustes de fábrica anotados antes de tocar nada

Cuando de verdad es hardware: qué se puede reparar

Has hecho ciclo en frío, reset de fábrica, reflasheado la imagen correcta con energía verificada, y el fallo persiste. Esa es la definición de un problema de hardware. El mapa realista de reparación:

• Reparable en banco (aire caliente, microscopio, buen pulso o un profesional): TPS546 o componentes de la etapa buck averiados, condensadores cerámicos agrietados, soldaduras frías bajo el ASIC o el módulo ESP32 (reflow), conectores de energía gastados, ventiladores muertos. Es rutina para cualquier banco de reparación de ASIC.
• A veces recuperable: una placa con un cortocircuito franco en el raíl de 5 V (casi cero ohmios a masa, sin alimentar) — no sigas aplicando energía; primero hay que encontrar y eliminar el corto.
• Normalmente terminal: un ASIC que funcionó sin contacto con el disipador más de unos segundos, las secuelas de una fuga térmica, o un chip al que se le dio el voltaje de núcleo equivocado durante una reparación improvisada del VRM. En una placa monochip el chip es casi todo el valor: pasado cierto punto, sustituir gana a reparar.

La ayuda comunitaria vive en el Discord de OSMU y en el issue tracker de ESP-Miner en GitHub: antes de abrir uno, busca primero en el tracker, porque una proporción llamativa de los avisos de «mi unidad está rota» son issues conocidos con un arreglo ya fusionado para la siguiente versión. Al reportar, un informe completo se responde en horas mientras uno vago muere en silencio. Copia esta plantilla:

PLACA:      (modelo exacto + revisión, p. ej. Gamma 602)
FIRMWARE:   (versión AxeOS, del panel o de /api/system/info)
FUENTE:     (voltaje, amperios, marca, y: ¿medida bajo carga?)
POOL:       (URL + puerto + moneda)
SÍNTOMA:    (una frase: qué pasa, desde cuándo)
DETONANTE:  (qué cambió justo antes: ¿update? ¿transporte?
             ¿OC? ¿remontaje del disipador? ¿nada?)
PROBADO:    (¿ciclo en frío 60s? ¿reset de fábrica? ¿reflash?
             ¿frecuencias de fábrica? ¿resultado del autotest?)
LOG:        (pega el log de arranque desde serie 115200 o desde
             curl http://IP/api/system/logs; como mínimo la
             primera línea E y diez líneas alrededor)

Esa plantilla no es burocracia: es exactamente la información que un banco de reparación recoge primero, en el orden en que la recoge.

PRO: la sección de banco — esquemáticos, puntos de medida y el polímetro

Esta sección asume que sabes leer un esquemático y medir una placa energizada sin puentear pines adyacentes. Si esa frase te hizo dudar, para aquí: todo lo que hay por encima de esta línea se resuelve sin abrir la carcasa, y una punta de prueba que resbala sobre una placa viva de 3 nm convierte un problema en dos. Para los demás, aquí es donde el hardware abierto rinde.

Por qué estas placas son distintas de cualquier otro minero

El hardware Bitaxe está licenciado bajo CERN-OHL-S y diseñado en KiCad, y todos los esquemáticos, layouts de PCB y listas de materiales son públicos. Eso significa que nunca adivinas qué es un componente ni por dónde va un raíl: puedes abrir el esquemático exacto de tu revisión exacta, encontrar la red y medirla. Ningún propietario de Antminer ha tenido nunca ese privilegio. Cada repositorio de hardware lleva además una sección que casi nadie abre: la página de HW issues con bugs conocidos, reworks y erratas por revisión. Antes de diagnosticar cualquier fallo a nivel de placa, comprueba si tu revisión tiene una errata documentada: una proporción llamativa de fallos de hardware «misteriosos» ya está escrita allí junto con la modificación que los soluciona.

El método del multímetro: tres raíles cuentan toda la historia

Los fallos de la ruta de energía se localizan con tres medidas en continua, tomadas en orden. Referencia a masa primero, respeta la secuencia y mide bajo carga donde se indica.

RAÍL 1 - ENTRADA (5 V o 12 V según la familia)
  Dónde:     conector o pads de entrada (ver esquemático)
  Esperado:  familia 5 V:  4,9 - 5,3 V  MIENTRAS HASHEA
             familia 12 V: 11,8 - 12,2 V MIENTRAS HASHEA
  Bajo solo con carga -> fuente o cable (la mayoría)
  Marca 0 con buena fuente -> protección de entrada quemada
                              o corto aguas abajo: mide
                              resistencia a masa SIN
                              ALIMENTAR; casi cero ohmios =
                              corto, deja de dar tensión y
                              búscalo

RAÍL 2 - 3,3 V (la alimentación del ESP32)
  Dónde:     red de 3,3 V según esquemático (módulo ESP32)
  Esperado:  3,2 - 3,4 V estables
  Ausente con entrada correcta -> el pequeño regulador de
  3,3 V o sus pasivos: explica «completamente muerto, sin
  enumeración USB» con una fuente demostradamente buena

RAÍL 3 - VCORE (la alimentación del ASIC)
  Dónde:     salida de la etapa buck TPS546 / red de núcleo
  Esperado:  aproximadamente 1,0 - 1,3 V, coincidiendo con
             el valor fijado en AxeOS
  Ausente con entrada y 3,3 V correctos -> la etapa buck:
  fallo enclavado (siempre ciclo en frío primero), o
  TPS546 / bobina / pasivos del entorno averiados
  Presente pero con valor equivocado -> programación del
  regulador o comunicación PMBus: contrasta con lo que
  AxeOS cree haber fijado

MEDIDAS DE CONFIRMACIÓN
  Continuidad conector de entrada -> entrada del regulador:
  encuentra pistas rotas y soldaduras agrietadas del jack
  Temperatura del die del TPS546 en el panel frente a la
  mano cerca: un regulador al que no puedes acercarte en
  reposo está fallando

Esos tres raíles particionan cualquier fallo de energía: entrada mala = antes de la placa; entrada buena y 3,3 V malos = el regulador pequeño; ambos buenos y VCORE malo = la etapa buck; los tres buenos = el fallo no es de energía, vuelve a la sección del ASIC. Diez minutos con un polímetro de veinte dólares sustituyen horas de especulación.

Qué puede y qué no puede hacer un banco de reparación

RUTINA (aire caliente + microscopio + buen pulso)
  - sustitución del TPS546 o de componentes de la etapa buck
  - condensadores cerámicos agrietados (visual: fisura fina
    cruzando el cuerpo; eléctrico: corto o circuito abierto)
  - reflow de BGA bajo el ASIC o el módulo ESP32 (la clase
    de fallo posterior a caída y a remontaje)
  - sustitución de conectores (jack gastado, XT30 cocido)

POSIBLE CON PACIENCIA
  - cazar un corto en el raíl de 5 V (cámara térmica o el
    truco de la evaporación de isopropílico sobre las zonas
    sospechosas)
  - cambio del módulo ESP32-S3 (requiere reflasheo después)

NO MERECE LA PENA / TERMINAL
  - sustituir el ASIC en placas monochip: el chip es casi
    todo el valor de la placa y los chips donantes vienen
    igualmente de rescate; una placa nueva gana en coste y
    en certeza
  - cualquier cosa tras una fuga térmica o una entrada con
    polaridad invertida a lo largo de todo el raíl

Leer el esquemático como un técnico

Tres hábitos que hacen que los esquemáticos abiertos sean realmente útiles. Primero: busca la página del árbol de alimentación y traza una vez sobre papel el camino de la entrada a VCORE antes de medir nada; a partir de ahí conoces cada componente capaz de matar el raíl. Segundo: anota los designadores (R12, C34, U3) de la etapa buck; los mensajes de foro y las erratas se refieren a las piezas por designador, y localizarlas en tu placa lleva segundos con el archivo de layout abierto. Tercero: compara revisiones cuando un fallo sea específico de una revisión; el registro de cambios entre, digamos, un Gamma 600 y un 601 te dice exactamente qué arreglaron los diseñadores, que suele ser exactamente lo que falla en el más antiguo.

La biblioteca de recursos de código abierto

Todas las fuentes primarias en una tabla. Guarda esta sección en marcadores: la mitad del valor del hardware abierto está en saber dónde viven los originales, y cada enlace de abajo es la fuente oficial, no un espejo.

Puntos clave

• Seis dominios cubren casi cualquier fallo: energía, ASIC, térmica, red, stratum, firmware. El triaje de 60 segundos te dice en cuál estás antes de tocar nada.
• La energía es la causa número uno y el impostor número uno: se disfraza de cuelgues de WiFi, panics de firmware, chips atascados y placas muertas. Mide la entrada bajo carga antes de creerte ninguna otra teoría.
• Un fallo enclavado del regulador sobrevive a cualquier reinicio por software. Desenchufar físicamente de 10 a 60 segundos es un paso de diagnóstico real, no superstición.
• El USB-C alimenta el ESP32, nunca el ASIC. Una placa solo con USB-C imita a la perfección a un minero muerto a 0 GH/s.
• Aprende la consola serie a 115200 baudios. La primera línea E de un log de arranque nombra tu problema más rápido que cualquier hilo de foro.
• El autotest integrado nombra el subsistema averiado en 30 segundos, y la API REST trae los logs, la telemetría e incluso la solución por la red: usa ambos antes de buscar un cable serie.
• Nunca conectes una fuente de 12 V a una placa de 5 V. Los conectores son intercambiables; las placas no.
• El ESP32 solo habla 2,4 GHz; el band steering y el aislamiento de AP son las dos funciones de router que rompen más instalaciones.
• La verdad del lado del pool gana al optimismo del lado del minero: el tiempo desde el último share aceptado es la única prueba honesta de estar en línea, y 10 minutos es el umbral.
• La dirección de wallet debe ser nativa de la cadena que se mina. En un pool no custodial ese es el único error sin camino de vuelta.
• El porcentaje de error de hardware es la cifra honesta de rendimiento; el hashrate del panel es una afirmación. Afina hacia shares aceptados y exige 24 horas antes de llamar estable a cualquier ajuste.
• Un conector de alimentación caliente es el único síntoma que significa parar ahora, no depurar luego.

Recopilado del issue tracker y las notas de versión de ESP-Miner, la documentación de errores fatales de ESP-IDF, la documentación de bancos de reparación de la comunidad y los patrones de fallo recurrentes reportados en las comunidades de Bitaxe, NerdAxe y NerdQaxe, a 20 de julio de 2026. El comportamiento de firmware descrito aquí (enclavamiento de fallos, umbrales de sobrecalentamiento, URL de recuperación, bandas de regresión conocidas) refleja las versiones de AxeOS y ESP-Miner vigentes en el momento de publicar; consulta las notas de versión de la tuya. Esta guía se mantiene como referencia viva: si te topas con un modo de fallo no cubierto aquí, cuéntanoslo por la página de contacto y lo añadiremos.