Minerador não hasheia? Bíblia do troubleshooting 2026

Pesquise em qualquer comunidade de mineração caseira em qualquer dia e encontrará os mesmos posts: um Bitaxe que inicializa mas fica em 0 GH/s, um NerdQaxe que reinicia a cada dois minutos, um Gamma que perdeu metade do hashrate após uma atualização de firmware, uma máquina que diz estar hasheando enquanto a pool não vê nada. Esses dispositivos são hardware de código aberto executando firmware de código aberto em silício industrial recuperado, e essa combinação é poderosa, barata e genuinamente frágil de formas que um eletrodoméstico não é.

Este guia é a referência que gostaríamos que existisse toda vez que ajudamos alguém a fazer debug. Ele cobre os seis domínios de falha que explicam quase toda unidade morta ou com problemas, ensina a ler os logs como um banco de reparo faz, e termina com uma tabela mestre de sintomas e um dicionário das linhas de erro reais que você verá. Aplica-se a toda a família AxeOS: cada Bitaxe (Max, Ultra, Supra, Gamma, Gamma 601/602, GT, Hex), as linhas NerdAxe e NerdQaxe incluindo as variantes ++ e Hydro, o NerdOctaxe, e por extensão qualquer derivado do ESP-Miner, incluindo as novas máquinas BM1373 cobertas em nossa referência da era BM1373.

Um princípio antes de tudo: diagnostique antes de tocar. A ordem de operações neste guia existe porque cada etapa elimina uma classe inteira de causas. Pular direto para o reflash do firmware quando o problema real é uma fonte que cede desperdiça uma noite e pode te deixar com dois problemas em vez de um.

Com pressa? As cinco correções que resolvem a maioria dos casos

Antes de ler qualquer outra coisa, tente estas na ordem. Juntas, resolvem a maioria dos relatos de “meu minerador está morto” sem ferramentas, sem logs e sem abrir o gabinete.

1. CICLO A FRIO, FEITO CORRETAMENTE.
   Desconecte o CONECTOR de alimentação (não o interruptor
   da tomada). Conte 60 segundos completos. Reconecte.
   Por quê: falhas do regulador SE TRAVAM e sobrevivem a
   qualquer reinício por software; apenas um corte real de
   energia as apaga.

2. VERIFIQUE O QUE REALMENTE O ALIMENTA.
   O USB-C faz o painel funcionar mas NAO pode alimentar o
   ASIC. Um minerador só no USB-C marca 0 GH/s e ~2 W para
   sempre. Verifique que a fonte real (jack/XT30) está
   conectada e bem encaixada, e que está na TENSAO CERTA
   (5 V contra 12 V: a errada destrói a placa).

3. DIGITE http:// EXPLICITAMENTE.
   Navegadores trocam silenciosamente para https:// e falham.
   http://IP-DO-MINERADOR, com o prefixo, sempre.

4. DÊ 2,4 GHz A ELE.
   Esses rádios nunca falam 5 GHz. Em roteadores mesh, crie
   um SSID só de 2,4 GHz ou uma rede IoT, WPA2-AES, e
   desative o isolamento de AP.

5. PERGUNTE À POOL, NAO AO MINERADOR.
   O tempo desde o último share aceito no painel da POOL é
   o único teste honesto de presença online. Mais de 10
   minutos = morto agora, não importa o que a interface diga.

Resolvido? Ótimo, feche a aba. Não resolvido? O triagem
abaixo encontra sua seção em 60 segundos.

Encontre seu problema rapidamente

Vinte seções são muitas. Três formas de pular para a sua:

Pela busca: cada string de erro neste guia está escrita literalmente, exatamente como o firmware a imprime. Pressione Ctrl+F (Cmd+F no Mac), cole sua mensagem de erro e você cairá em cima dela: essa é uma decisão de design, não sorte.

Por sintoma:

Por estilo de leitura: a próxima seção divide o guia em um caminho para iniciantes e um profissional.

Escolha seu caminho

Este guia serve dois leitores muito diferentes, e você não deveria lê-lo da mesma forma.

Primeiro minerador, primeiro problema? Siga o caminho numerado e não pule nada: as duas regras de segurança, o autoteste integrado, a triagem de 60 segundos e então apenas a seção para a qual a triagem te enviar. Cada bloco de código está pronto para copiar e colar, cada termo que você talvez não conheça está no mini-glossário logo abaixo, e nada no caminho iniciante exige abrir o gabinete ou possuir um multímetro.

Confortável com terminal e multímetro? Sua faixa rápida: a seção de API para baixar logs remotamente e verificar a frota, o dicionário de linhas vermelhas para pular direto de uma string de erro para sua causa, a tabela de peculiaridades por modelo e a seção profissional de bancada no final, onde vivem os esquemas, o método de pontos de teste e os recursos em nível de placa. Seções marcadas como PRO assumem que você sabe ler um esquema e medir uma placa energizada com segurança.

Mini-glossário para iniciantes

Dez termos, dez segundos cada, e o restante do guia se lê duas vezes mais rápido.

ASIC        o chip de mineração em si, a única peça que
            realmente calcula hashes
ESP32       o pequeno controlador que faz todo o resto:
            WiFi, painel, comunicação com o ASIC
AxeOS       o firmware + painel web no ESP32
VCORE       a alimentação de ~1,0-1,3 V do núcleo do ASIC,
            gerada na placa a partir dos seus 5 V ou 12 V
            de entrada
VRM / TPS546  o circuito regulador que cria VCORE e protege
            o chip desligando-se em falhas
stratum     o protocolo pelo qual seu minerador fala com a
            pool
share       uma prova de trabalho que você envia; a pool as
            conta para saber que você está vivo e honesto
% erro HW   resultados que o chip calculou ERRADO: o número
            honesto de saúde (manter abaixo de 2%)
OTA         atualização "pelo ar" pelo painel, em oposição
            a flashar via USB
NVS         a memória de configurações que sobrevive a
            reflashes: por isso existe o reset de fábrica

Antes de tudo: duas regras de segurança e uma ferramenta integrada

As duas regras que evitam placas mortas

Regra um: nunca adivinhe a tensão. Bitaxes padrão de chip único usam 5 V; GT, Hex, NerdQaxe++ e NerdOctaxe usam 12 V. As tomadas jack de ambas as famílias são fisicamente intercambiáveis, e conectar uma fonte de 12 V a uma placa de 5 V a destrói permanentemente em menos de um segundo. Antes de cada conexão, leia o rótulo da fonte, não a forma do conector. Esse é o erro mais caro desse hobby.

Regra dois: um conector quente significa parar. Morno é um aviso; quente, descolorido ou cheirando a plástico significa desligar agora e substituir o cabo antes da próxima energização. Todo o resto neste guia pode esperar até amanhã. Isso não.

Execute o autoteste integrado

O AxeOS inclui um autoteste de inicialização cuja existência a maioria dos proprietários desconhece. Ele testa cinco subsistemas em sequência e reporta a primeira falha na tela, tornando-o um diagnóstico de hardware gratuito de trinta segundos que nomeia o domínio com falha:

O QUE TESTA (em ordem)       SE FALHAR, A TELA MOSTRA
  rail de entrada               POWER FAIL
  regulador de tensão do núcleo VCORE FAIL
  barramento de sensores I2C    (trava durante o teste)
  feedback do tacômetro do vent FAN FAIL
  detecção do ASIC              ASIC FAIL
  curta rajada de hashing       HASHRATE FAIL

COMO LER O RESULTADO
  POWER / VCORE FAIL   -> seção Alimentação. O teste rejeita
                          uma entrada com mais de 10% de
                          desvio do nominal: meça a fonte.
  ASIC FAIL            -> seção Problemas de ASIC.
  FAN FAIL             -> ventoinha desconectada, travada ou
                          fio de tacômetro morto.
  HASHRATE FAIL        -> chip detectado mas sem calcular:
                          geralmente alimentação no limite ou
                          problema de configurações; volte
                          aos valores de fábrica.

SE O PRÓPRIO TESTE TRAVAR
  Tela presa em SELF TEST por mais de 30 segundos, ou loop
  infinito SELF TEST -> reinício: no AxeOS v2.12+ segure o
  botão BOOT por 2 segundos durante a tela SELF TEST para
  pular e chegar ao painel, depois diagnostique a partir
  daí. Um loop de autoteste após flash geralmente significa
  imagem errada para a placa.

O autoteste roda automaticamente na primeira inicialização e pode ser acionado nas configurações. Execute-o após qualquer evento de hardware: transporte, remontagem do dissipador, troca de fonte. Ele transforma “algo está errado” em um subsistema nomeado antes mesmo de você abrir um único log.

O que a tela está te dizendo

Nos modelos com display, o OLED é um instrumento de status, não decoração. Ele alterna entre telas de informação a cada poucos segundos; o botão BOOT avança manualmente e acorda um display apagado pelo temporizador. Os estados importantes: a tela de boot (firmware vivo), a tela do hotspot de configuração (não configurado ou credenciais WiFi perdidas), a tela de endereço IP (sua porta para o painel), o autoteste e os códigos FAIL acima, um aviso de superaquecimento e a animação de bloco encontrado que esperamos que você veja algum dia. Uma tela apagada não prova que a placa está morta: verifique se simplesmente o temporizador de desligamento do display acionou e se a pool ainda está recebendo shares.

A triagem de 60 segundos

Antes de abrir um único log, responda a cinco perguntas. Elas particionam todo o espaço do problema.

P1  Algo liga? (LED, tela, ventoinha)
      NAO -> DOMÍNIO ALIMENTAÇÃO. Vá para: Alimentação.
      SIM -> P2

P2  O dispositivo chega ao painel AxeOS ou mostra um IP?
      NAO -> P2a: ele transmite seu hotspot de configuração?
             SIM -> DOMÍNIO WIFI. Vá para: Rede.
             NAO -> DOMÍNIO BOOT. Vá para: Firmware.
      SIM -> P3

P3  O painel mostra hashrate acima de zero?
      NAO -> P3a: mostra falha de alimentação, banner de
             superaquecimento ou 0 chips ASIC?
             falha alim.    -> Alimentação
             superaquec.    -> Problemas térmicos
             0 chips        -> ASIC
      SIM -> P4

P4  A POOL mostra shares aceitos nos últimos 10 minutos?
      NAO -> DOMÍNIO STRATUM. Vá para: Pool.
      SIM -> P5

P5  O hashrate, taxa de erro e temperatura estão corretos?
      NAO -> Problemas térmicos ou overclock mal feito.
      SIM -> Nada está quebrado. Feche a aba do navegador.

Note que P4 pergunta à pool, não ao dispositivo. A perseguição ao fantasma mais comum na mineração caseira é fazer debug de um minerador cuja interface parece perfeita enquanto a pool parou de ouvi-lo há uma hora. O dispositivo e a pool veem cada um metade do quadro, e este guia retorna a essa assimetria repetidamente.

Como ler os logs

Todo o resto neste guia é mais rápido se você souber ler os logs, portanto esta seção vem primeiro. Há duas superfícies de log, e elas respondem a perguntas diferentes.

O log web do AxeOS

Abra o painel no endereço IP do minerador e encontre a visualização de log. Ela mostra o registro de execução em tempo real: tráfego stratum, envios de shares, mudanças de dificuldade, eventos de temperatura. É a ferramenta certa quando o dispositivo inicializa bem e a pergunta é o que ele está fazendo agora. Sua limitação: começa depois que a rede está no ar, então não pode mostrar uma falha de boot, e morre com o servidor web, então não pode mostrar um crash.

O console serial: a verdade

Para qualquer coisa envolvendo boot, crashes, detecção de ASIC ou associação WiFi, você precisa do console serial. É a mesma saída que os desenvolvedores leem, e começa a partir da primeira instrução.

1. Conecte um cabo USB-C de DADOS (não um cabo só de carga)
   do minerador ao computador. Em algumas placas Bitaxe uma
   conexão nativa USB-C para USB-C falha na negociação; use
   um cabo ou adaptador USB-A para USB-C, que força 5V clássico.

2. Abra um terminal serial a 115200 bauds, 8N1:

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

3. Pressione o botão RST na placa (ou reconecte a
   alimentação). O log de boot completo rola desde o início.

Linhas de log do ESP-IDF carregam uma letra de severidade: I para informação, W para aviso, E para erro. A maioria dos terminais renderiza linhas E em vermelho. Um boot saudável tem zero linhas E. Essa é toda a habilidade de leitura de logs em uma frase: percorra o boot, encontre o primeiro E e procure-o no dicionário ao final deste guia. O primeiro erro é o que mais importa, pois os posteriores geralmente são danos em cascata do primeiro.

Como é um boot saudável

Anotado e resumido. O seu diferirá nos detalhes mas deve atingir os mesmos marcos na mesma ordem.

rst:0x1 (POWERON_RESET), boot:0x8 (SPI_FAST_FLASH_BOOT)
        <- motivo do reset. POWERON é normal. Resets repetidos
           RTC_WDT ou BROWNOUT aqui são seu primeiro sinal de
           alerta.

I (xx) main: Found device config: <modelo da sua placa>
        <- firmware identificou a placa. Nome de modelo errado
           aqui significa imagem de firmware errada.

I (xx) TPS546: Found TPS546D24A          (placas com TPS)
I (xx) Power: VCORE set to 1150 mV
        <- o regulador de núcleo respondeu no I2C e o rail do
           ASIC está ativo. Se esse bloco estiver ausente ou
           com erros, nada a seguir pode funcionar.

I (xx) bm13xx: Found 1 chip(s)
        <- A linha. O número deve igualar a contagem de chips
           da sua placa: 1 para chip único, 2 para o GT, 4
           para o NerdQaxe, 6 para o Hex, 8 para o NerdOctaxe.

I (xx) wifi: connected, IP: 192.168.x.x
        <- rede ativa. Falhas de associação imprimem códigos de
           motivo aqui (dicionário abaixo).

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: ...
        <- a pool aceitou o login e enviou trabalho.

I (xx) asic_result: Nonce found, diff xxx of yyy
        <- o ASIC está retornando resultados. Em um ou dois
           minutos você deve ver shares acima da dificuldade
           da pool sendo enviados e aceitos.

Memorize a ordem dos marcos: motivo do reset → configuração da placa → regulador → contagem de chips → WiFi → stratum → nonces. O primeiro marco que falhar nomeia a seção deste guia que você precisa.

Problemas de alimentação: a causa número um de tudo

Se as falhas de mineradores caseiros tivessem um ranking, a alimentação ocuparia os três primeiros lugares. Essas placas rodam silício de 3 nm e 5 nm em alta corrente a partir de fontes de consumo por conectores de consumo, e as margens são estreitas.

Conheça sua arquitetura de alimentação

Bitaxe de chip único (Max/Ultra/Supra/Gamma)
  Entrada:   5 V via jack (5,5x2,1mm) ou USB-C
  Corrente:  até ~5 A no Gamma de fábrica, mais com OC
  Regulador: TPS546D24A buck digital (placas antigas: DAC
             DS4432U + monitor INA260) abaixa os 5V para
             ~1,1-1,3V de núcleo ASIC em corrente muito alta
  Janela:    regulador liga ~4,8 V, desliga abaixo de ~4,5 V

Família 12 V (GT, Hex, NerdQaxe++, NerdOctaxe)
  Entrada:   12 V via conector XT30 ou jack
  Corrente:  NerdQaxe++ ~8+ A em carga plena; Octaxe mais
  Risco:     aquecimento do conector; queda sob carga

FATO CRÍTICO: o USB-C nas placas Bitaxe atuais é SOMENTE
para o ESP32 e para flash. Não pode alimentar o ASIC. Uma
placa rodando somente em USB-C inicializa, mostra o painel
e hasha a exatamente 0 GH/s consumindo ~2 W. Isso imita com
precisão um regulador morto e desperdiça horas toda semana
na comunidade.

Power Fault Detected: o que realmente aconteceu

O regulador TPS546 monitora quatro proteções: sobrecorrente, sobretensão, subtensão, sobretemperatura. Quando uma dispara, o regulador trava no desligamento e o AxeOS mostra o banner de falha de alimentação. O ASIC perde seu rail; o ESP32, alimentado separadamente, mantém a interface ativa. Dois fatos governam a solução:

• O travamento sobrevive a reinícios por software. O estado de falha é mantido no registro de status do próprio regulador até que a tensão de entrada seja fisicamente removida. Reiniciar pela interface web, chamar a API de restart ou pressionar o botão reset do ESP32 não o apaga. Esse é um comportamento documentado, não um bug, e também é por isso que existe uma classe inteira de issues no GitHub: placas BM1370 presas em 0 GH/s consumindo 5 W onde o endpoint de restart não resolve nada mas um ciclo de energia resolve tudo.
• O disparo é um sintoma; a causa está a montante. O regulador está protegendo um chip que vale mais do que a placa ao redor. A esmagadora maioria dos disparos recorrentes remonta à alimentação de entrada, não ao regulador.

A sequência de solução, em ordem:

1. CICLO A FRIO. Desconecte o próprio conector de alimentação
   (não o interruptor da parede). Conte 10 segundos completos.
   Algumas placas precisam de 60 segundos para os capacitores
   de bulk descarregarem e um estado de retenção brownout do
   ESP32 ser apagado. Reconecte. Isso sozinho resolve a maioria
   das falhas pontuais.

2. REMOVA O USB-C. Se algo está conectado ao USB-C, desconecte
   e verifique que a fonte real (jack/XT30) está no lugar.
   Descarte a armadilha USB-C descrita acima.

3. MEÇA SOB CARGA. Multímetro em DC no conector de entrada
   ENQUANTO O MINERADOR HASHA:
     placas 5 V:  espere 4,9-5,3 V sustentados.
                  Abaixo de 4,8 V = a fonte é o problema.
     placas 12 V: espere 11,8-12,2 V sustentados.
                  Abaixo de 11,4 V = a fonte é o problema.
   Uma medição sem carga não prova nada: fontes baratas mostram
   5,0 V perfeitos em repouso e afundam para 4,4 V sob carga.

4. ELIMINE O CAMINHO. Conecte a fonte diretamente na tomada:
   sem filtros de linha, sem extensões, sem correntes. Filtros
   de linha de baixa qualidade adicionam queda mensurável.
   Mova o jack: se a tela piscar, o conector ou cabo está gasto.

5. MELHORE A FONTE. Especificação mínima honesta:
     placas de chip único 5 V:  5 V / 5 A de qualidade, dedicada
     classe NerdQaxe++ 12 V:    12 V / 10 A (120 W) mínimo
   Carregadores de celular e adaptadores universais são de longe
   a causa raiz mais comum em todo este guia.

O aviso do XT30

A família de 12 V empurra 8 ou mais amperes por um XT30. O conector é dimensionado para isso; os rabichos soldados à mão atrás dele muitas vezes não são. Inspecione: pinos descoloridos, conector morno ao toque, soldas frias ou crimpagens frouxas. Uma junção de alta resistência a 8 A aquece, oxida, resiste mais e aquece mais: esse é o único modo de falha na mineração caseira que termina em plástico derretido. Se o conector já esteve quente o suficiente para descolorir, substitua o cabo, não o reutilize. Unidades NerdQaxe que travam com um erro de fonte e um código Guru Meditation remetem exatamente a esse rail cedendo sob carga.

Brownout: o crash que não é um crash

O ESP32 tem um detector de brownout por hardware. Quando o rail de 3,3 V cai, ele imprime Brownout detector was triggered e reinicia. Um minerador que reinicia a cada poucos minutos, especialmente quando o ASIC sobe para carga plena, quase nunca tem problema de firmware: é a alimentação cedendo no momento de máximo consumo. A solução são os passos 3 a 5 acima. Não persiga o firmware por um loop de brownout.

Problemas de ASIC: o chip não está respondendo

A linha do log de boot a observar é a contagem de chips. O firmware enumera a cadeia de ASIC via UART e imprime quantos chips responderam. Qualquer coisa diferente da contagem completa da sua placa pertence a esta seção.

Zero chips detectados

O painel mostra contagem ASIC 0 ou o log mostra uma falha de inicialização. Causas, por frequência observada:

1. Regulador travado ou estado de brownout retido. Um chip sem tensão de núcleo não pode se enumerar. Faça a descarga a frio completa de 60 segundos antes de qualquer coisa: desconecte a fonte principal, o USB-C e todos os acessórios, espere um minuto inteiro, realimente. Isso sozinho resolve uma fração significativa dos casos.
2. Imagem de firmware errada. Flashar a imagem de outra placa, mesmo que uma única vez, pode deixar uma configuração de dispositivo incorreta na memória não volátil que persiste entre reflashes. Se a linha de modelo no log de boot não corresponde à placa física, faça um reset de fábrica completo e então flashe a imagem correta. Uma imagem BM1366 em uma placa BM1370 nunca encontrará o chip.
3. Evento mecânico. A sequência clássica: a unidade foi movida, caiu, foi enviada ou o dissipador foi reapertado, e nunca mais hasheou. Sob o ASIC há uma matriz BGA de soldas; a flexão as racha. Pressão de montagem desigual do dissipador faz o mesmo. Se a cronologia bater, é um reparo de bancada (reflow), não problema de configuração.
4. Fuga de fábrica. Uma unidade nova que nunca hasheou nem uma vez tem probabilidade desproporcional de ter uma solda fria de fabricação. Não gaste um fim de semana no software: faça a descarga a frio e a verificação de firmware, depois acione a garantia.

Contagem parcial de chips: a assinatura multichip

Um Hex reportando 3 de 6, um NerdQaxe reportando 2 de 4, um GT reportando 1 de 2. Placas multichip enumeram os ASICs como uma cadeia, então um único chip morto ou desconectado quebra a detecção naquele ponto da cadeia: o número te diz aproximadamente onde está a quebra. Uma placa de quatro chips mostrando 2 tem um problema no chip 3. As causas são as mesmas de cima (margem de alimentação, solda rachada) mais uma específica do multichip: um chip fraco na cadeia que cai apenas em frequência alta. Se a contagem completa volta nas frequências de fábrica mas chips desaparecem com overclock, você encontrou o die mais fraco da sua loteria de silício, e seu teto é o teto de toda a placa.

Erros I2C: o barramento de sensores, não o minerador

Uma classe confusa: o minerador hasha normalmente enquanto Power, ASIC Temp e Input Voltage aparecem como traços, nulos ou zeros, e o log mostra erros de transmissão/recepção I2C ou timeouts. O caminho de hashing (UART para o ASIC) e o caminho de telemetria (I2C para o PMBus do regulador, o sensor de temperatura, o monitor de corrente) são barramentos separados. Um pode falhar enquanto o outro funciona. Gatilho conhecido: uma faixa de regressão de firmware em torno do AxeOS v2.13/v2.14 onde o caminho de leitura de sensores falha silenciosamente em um subconjunto de unidades. Também causado por qualquer acessório compartilhando o conector I2C: um OLED adicionado ou sensor externo com contato instável pode bloquear o barramento para os sensores embutidos. Retorne ao estado original, faça um ciclo a frio, e se for a faixa de firmware, atualize para frente ou volte uma versão.

O efeito colateral perigoso: sem realimentação de temperatura a curva da ventoinha não pode funcionar, então a ventoinha trava em uma velocidade. Se a telemetria está morta, trate a proteção térmica como morta também e não deixe a unidade sem supervisão até que seja corrigida.

Problemas térmicos: o calor é um orçamento, não um evento

Os números que importam

Temp. núcleo ASIC  alvo:        55-62 C sustentados
                   preocupante: acima de 65 C constante
                   corte:       ~75 C -> modo Overheat

Temp. VREG         roda 10-15 C mais quente que o núcleo sob
                   carga; em placas BM1370/BM1373 geralmente
                   é o sensor limitante, não o núcleo

Modo Overheat      hashing para, ventoinha vai a 100%, interface
                   permanece ativa; sai com histerese quando
                   temperatura cai de volta para ~65 C

Diagnóstico por padrão

Superaquece imediatamente partindo do frio — problema de montagem. O dissipador não está fazendo contato: pad térmico ausente ou rasgado, pasta seca ou ausente, torque de aperto desigual, ou dissipador solto no transporte. Um chip sem contato vai de temperatura ambiente ao corte em segundos. Remonte, aplique um grão de arroz de pasta de qualidade, aperte os parafusos em cruz de forma uniforme.

Superaquece após 10 a 30 minutos — problema de capacidade. O contato está bom mas o sistema não consegue dissipar calor tão rápido quanto o produz. As causas se acumulam: ambiente acima de 27 C aproximadamente, unidade em armário, gaveta ou gabinete fechado, entrada ou saída de ar bloqueada, tapete de poeira nas aletas, ou um overclock para o qual o resfriamento nunca foi dimensionado. Dê a ela 10 cm de ar livre em ambos os lados, limpe as aletas, e se começou após uma mudança de frequência, essa mudança foi longe demais.

Deriva lenta ao longo de semanas — problema de manutenção. Mesmas configurações, temperatura subindo um grau por vez: acúmulo de poeira ou pasta térmica secando. Pasta nessas placas é um consumível; substituí-la a cada 6 a 12 meses é normal.

Superaquecimento após atualização de firmware — problema de curva. Curvas de ventoinha e calor mudam entre versões; um exemplo documentado em torno da v2.11 deslocou o comportamento padrão o suficiente para que unidades rodassem vários graus mais quentes e ligeiramente mais lentas nas configurações de fábrica. Leia as notas da versão, aumente a velocidade da ventoinha manualmente um patamar, ou ajuste a temperatura alvo se seu firmware expõe controle PID.

A ventoinha em si

Uma ventoinha reportando 0 RPM em qualquer temperatura está desconectada, bloqueada por um cabo ou morta. Uma ventoinha gritando a 100% constantemente significa ou um chip realmente quente (veja acima) ou telemetria de temperatura morta guiando a curva às cegas (veja a seção I2C). Ventoinhas de reposição de 40 mm e 60 mm são baratas; as silenciosas premium (a escolha habitual da comunidade é uma Noctua) baixam o ruído abaixo de 40 dB e são a melhoria de hardware com melhor custo-benefício em qualquer dessas unidades.

Problemas de rede: a visão de mundo WiFi do ESP32

O rádio em cada uma dessas máquinas fala apenas 2,4 GHz. Não 5 GHz, não 6 GHz, sem exceções, sem correção por firmware. Uma enorme parte das falhas de configuração se resume a essa frase colidindo com o comportamento dos roteadores modernos.

O problema dos roteadores mesh

Sistemas mesh modernos transmitem um SSID combinado único e direcionam clientes entre faixas. O ESP32 não consegue entrar no lado de 5 GHz, e o band steering pode impedi-lo de se fixar em 2,4 GHz. As correções confiáveis; a maioria dos roteadores suporta pelo menos uma:

Opção A  Criar um SSID exclusivo de 2,4 GHz (melhor)
Opção B  Usar o recurso de "rede IoT" do roteador: vários
         fabricantes adicionaram isso exatamente para
         dispositivos como estes
Opção C  Desativar o band steering / "smart connect" para
         que as faixas apareçam como SSIDs separados

Depois verifique no SSID de 2,4 GHz:
  Segurança      WPA2-Personal, apenas AES (não TKIP, e redes
                 somente WPA3 vão falhar)
  Canal          fixo 1, 6 ou 11 em áreas congestionadas,
                 não Auto
  Largura canal  20 MHz
  Isolamento AP  DESATIVADO <- com ele ativo, o WiFi conecta
                 mas o painel é inacessível da sua LAN, o
                 que parece exatamente um dispositivo morto
  Filtro MAC     desativado, ou adicione o MAC do minerador

Lendo falhas de WiFi no log serial

O console serial imprime um motivo de desconexão em cada associação com falha, e o motivo nomeia a solução:

AUTH_EXPIRE / auth failed      senha (PSK) incorreta. Redigite;
                               atenção a aspas tipográficas se
                               colou de um celular.
NO_AP_FOUND                    SSID não visível em 2,4 GHz:
                               band steering, SSID oculto,
                               fora de alcance, ou só 5 GHz.
beacon timeout                 sinal muito fraco ou canal
                               congestionado; mova a unidade
                               ou fixe o canal.
ASSOC_TOOMANY                  limite de clientes do roteador
                               atingido.
Brownout detector triggered    não é WiFi de forma alguma: o
                               pico de consumo do rádio na
                               associação derruba uma fonte
                               fraca. Corrija a alimentação,
                               não a rede.

Esse último merece ênfase: a transmissão WiFi é o maior pico instantâneo de carga que o ESP32 produz. Uma fonte no limite que sobrevive ao repouso morre na associação, então uma unidade que “trava ao conectar ao WiFi” geralmente é um problema de alimentação disfarçado de problema de rede.

Acessibilidade sem falha de WiFi

Dois recursos de segurança de roteadores merecem menção especial porque bloqueiam mineradores por design. O ASUS AiProtection e o equivalente em alguns modelos TP-Link classificam o tráfego stratum como suspeito e o descartam silenciosamente: o minerador entra no WiFi perfeitamente e então não consegue alcançar nenhuma pool. Se uma unidade se conecta ao WiFi mas toda conexão com pool falha, e a mesma pool funciona em um hotspot de celular, desative o recurso de proteção do roteador ou coloque o minerador na lista branca antes de tocar em qualquer outra coisa.

E uma peculiaridade do navegador que gera falsos alarmes sem fim: o AxeOS serve HTTP simples na porta 80. Navegadores modernos convertem silenciosamente endereços sem prefixo para HTTPS, o que falha, e o minerador parece morto. Digite o prefixo explicitamente: http:// antes do IP, sempre. Se ainda falhar, tente outro navegador e desative extensões de bloqueio para endereços locais.

Se o minerador tem um IP mas você não consegue abrir o painel: isolamento AP (acima), uma peculiaridade da lista de clientes do roteador, ou mDNS. O dispositivo se anuncia com um nome .local; quando várias unidades usam o mesmo nome, o firmware moderno adiciona automaticamente um sufixo derivado do MAC, mas caches mDNS obsoletos no seu computador podem ainda apontar para a unidade errada. Na dúvida, use o IP bruto da tabela DHCP do roteador e dê a cada unidade um nome distinto.

Problemas de stratum e pool: o último quilômetro

O dispositivo inicializa, hasha, e a pool é onde a verdade é decidida. Nesta seção a visão do lado do minerador e a visão do lado da pool precisam ser lidas juntas.

Conexão recusada ou inacessível

Verifique nesta ordem:
1. URL exata:   stratum+tcp://host:porta - sem https://,
                sem barra final, porta presente e correta
2. DNS:         outro dispositivo na mesma LAN resolve o host?
                Alguns roteadores de operadora e filtros DNS
                (ou bloqueadores tipo Pi-hole) engolem domínios
                de mineração silenciosamente.
3. Porta:       algumas redes bloqueiam portas de saída
                incomuns. Teste de um hotspot de celular: se
                conectar lá, a rede doméstica está filtrando.
4. Região:      tente o outro endpoint regional da pool; você
                pode estar vendo uma interrupção de uma única
                região.

Authorize falha

A pool recusou o login. Em uma pool solo, o nome de usuário é seu endereço de carteira mais o nome do worker, e o endereço é toda a identidade: não há conta para errar de digitar. Causas: um endereço com erro de digitação (um caractere é suficiente), um endereço da chain errada (veja abaixo), um nome de worker com espaços ou caracteres especiais, ou um campo de senha que a pool espera não vazio (use x).

O endereço da chain errada: o assassino silencioso

O erro de configuração mais prejudicial na mineração SHA-256 multi-chain, e pode falhar de duas formas diferentes:

• Falha ruidosa: a pool valida o formato do endereço por chain e rejeita o authorize ou cada share. Irritante mas seguro: você percebe em minutos.
• Falha silenciosa: um endereço que é formalmente válido em mais de uma chain, ou uma pool que não valida em profundidade, aceita seus shares o dia todo, e então o pagamento não consegue chegar até você. Em uma pool solo não custodial, as recompensas de bloco são pagas coinbase-diretamente para a string de endereço que você configurou. Não existe ticket de suporte que reverta um coinbase pago para um endereço do qual você não pode gastar.

A regra: o endereço deve ser nativo da chain para a qual você está apontando, gerado por uma carteira dessa chain e verificado. Se você rotaciona um único minerador físico entre chains, mantenha uma tabela escrita de chain para endereço e reverifique o campo de nome de usuário toda vez que mudar a URL stratum. Isso vale mais do que todos os outros conselhos desta seção combinados.

Shares rejeitados: lendo os motivos de rejeição

Rejeições não são um problema único; a string de motivo no log te diz qual dos quatro problemas você tem.

"job not found" / stale       Você enviou trabalho para um job
  em pequenas rajadas logo    que a pool já havia substituído:
  após novos blocos           normal em mudanças de bloco. Abaixo
                              de ~1-2% total: ignore. Sustentado
                              mais alto: latência de rede ou
                              perda de pacotes WiFi; verifique o
                              RSSI, tente a região de pool mais
                              próxima.

"above target" /              O share não atinge a dificuldade
"low difficulty share"        atribuída pela pool. Casos
                              persistentes: um descompasso após
                              mudança de dificuldade, ou erros
                              de hardware corrompendo o resultado.
                              Verifique o % de erro HW.

"duplicate"                   Mesmo nonce enviado duas vezes.
                              Ocasional: artefato inofensivo de
                              retransmissão. Um fluxo contínuo:
                              estado de falha conhecido onde o
                              ASIC entra em loop em um nonce; o
                              chip travou. Ciclo de energia; se
                              recorrer nas frequências atuais,
                              reduza o overclock.

tudo rejeitado                Configuração, não má sorte:
                              endereço da chain errada, nome de
                              worker malformado, ou porta errada
                              (ex. uma porta de alta dificuldade
                              destinada a ASICs grandes).

Percentual de erro de hardware: o número honesto

O hashrate do painel é uma afirmação; a taxa de erros de hardware é uma confissão. Ela conta resultados que o ASIC retornou e que falham na verificação. Abaixo de 2 por cento é saudável. Taxa de erro crescendo com temperatura crescendo significa térmico; taxa crescendo com temperatura constante após uma mudança de configuração significa que o ponto de frequência/tensão está além do silício deste chip. Um chip a 5 por cento de erros pode mostrar um hashrate orgulhoso enquanto seu hashrate efetivo cai silenciosamente abaixo do que uma frequência menor entregaria. Ao sintonizar, otimize para shares aceitos por hora, nunca para o número do painel. O método completo está na seção de tuning da referência BM1373, e o contexto sobre o que significa a dificuldade de share no explicador de best share.

«O minerador diz que hasha mas a pool não mostra nada»

O sintoma mais postado em toda comunidade, então aqui está o caminho completo de resolução:

1. LADO POOL, tempo desde o último share aceito:
   mais de 10 minutos = a conexão está morta AGORA, não
   importa o que a interface do minerador diga. Médias do
   painel decaem ao longo de ~uma hora e ocultam desconexões
   recentes. "Hashrate acima de zero" NAO é um teste de
   presença; "último share recente" é.

2. LADO MINERADOR, log em tempo real:
   Shares estão sendo ENVIADOS? Se o ASIC encontra nonces
   mas nada é enviado, o socket stratum está travado: reinicie
   o minerador.
   Os envios estão dando ERRO? Leia a tabela de motivos de
   rejeição.

3. IDENTIDADE: o painel da pool que você está olhando está
   filtrado no mesmo endereço de carteira E na mesma moeda
   que o minerador está configurado? Um número surpreendente
   desses casos é um painel BTC aberto enquanto o minerador
   aponta para BCH, ou a página de um endereço de teste de
   ontem.

4. FALLBACK: há uma pool de backup configurada, e o minerador
   mudou para ela silenciosamente? Seu hashrate pode estar
   chegando na OUTRA pool. Verifique as estatísticas dela.

Configure sempre o fallback

Todos os dispositivos da família AxeOS suportam uma pool de backup. Um minerador sem fallback que perde seu socket stratum às 2 da manhã não faz nada até que você perceba, e a média decrescente do painel garante que você perceba tarde. Defina o fallback para uma segunda região da sua pool para que um problema regional nunca paralise a máquina. Hosts e portas por região para cada chain estão na página de conexão.

Problemas de firmware: flashar, brickear, recuperar

O OTA de dois arquivos e o meio-brick

Atualizações do AxeOS chegam como dois artefatos: o binário do firmware e a imagem da interface web (www.bin). Um modo de falha documentado é o OTA travando durante a fase www.bin, deixando firmware e interface fora de sincronia: o dispositivo inicializa e minera mas o painel está em branco ou quebrado. Isso não é um brick. Vá diretamente para a URL de recuperação:

http://<ip-do-minerador>/recovery

e faça upload novamente da imagem web. Se o dispositivo não inicializar mais depois de uma atualização com falha, o web flasher USB (Chrome ou Edge, cabo de dados USB-C) reescreve a imagem de fábrica completa e recupera praticamente qualquer soft-brick. Três regras tornam o flash chato em vez de assustador:

• Faça a imagem corresponder à placa exatamente, até a revisão. O número de revisão está impresso na própria PCB e mostrado na seção Sistema do AxeOS: um Supra 401 precisa da imagem 401, não da 402. Conheça os dois tipos de arquivo na página de releases: o completo esp-miner-factory-REV-vX.X.X.bin (bootloader + partições + interface + firmware, para flash USB e recuperação total) e o menor esp-miner.bin (apenas firmware, para OTA pelo painel). Usar um onde o outro pertence é a receita clássica de meio-brick. Imagem Gamma em um Gamma, Ultra em um Ultra. Uma imagem errada pode deixar uma configuração incorreta na NVS que sobrevive a reflashes normais; a cura é reset de fábrica mais imagem correta.
• Nunca flashe por WiFi com conexão no limite ou alimentação no limite. O travamento durante www.bin está correlacionado exatamente com essas duas condições.
• Conheça seu alvo de rollback. Regressões acontecem: uma faixa de perda de telemetria em torno da v2.13/v2.14, uma mudança de curva de ventoinha em torno da v2.11 que deixou unidades mais quentes, um caminho de atualização em torno da v2.4.3 que congelava em algumas revisões de hardware até que os usuários fizessem downgrade. Antes de atualizar, anote sua versão atual; se a nova se comportar mal, a anterior está a um web-flash de distância na página de releases do projeto.

Loops de crash: lendo um Guru Meditation

Um Guru Meditation Error é o kernel panic do ESP32. A palavra entre parênteses é a pista:

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

LoadProhibited /       bug de firmware tocando memória inválida:
StoreProhibited        anote sua versão, verifique o issue
                       tracker, volte uma versão
IllegalInstruction     flash corrompida ou stack sobrescrita:
                       reflash completo via USB
Cache error /          geralmente segue problemas de PSRAM
DoubleException        (abaixo)
Interrupt wdt timeout  uma task travou, frequentemente relacionada
                       à rede; verifique issue conhecida na sua
                       versão

Um panic isolado: ignore. Um loop: identifique se é o mesmo motivo a cada vez (falha de firmware ou hardware: aja conforme a tabela) ou se está intercalado com mensagens de brownout (então é a alimentação: pare de ler panics e vá consertar a fonte).

Falhas de PSRAM: a especialidade da família Nerd

NerdQaxe, NerdOctaxe e outras placas construídas no módulo ESP32-S3-WROOM-1 usam PSRAM externa. Um banner de boot mostrando erro de leitura de ID PSRAM ou falha de inicialização, seguido de panic StoreProhibited assim que o firmware toca a RAM externa, tem cinco raízes conhecidas: módulos falsificados sem die PSRAM, firmware compilado com o modo PSRAM errado (octal vs quad), solda fria sob o módulo, brownout durante a janela de inicialização, ou um die envelhecido. A triagem prática: descarte primeiro a alimentação (como sempre), flashe a imagem exata do fabricante para sua placa (que codifica o modo PSRAM correto), e se o erro persistir com alimentação limpa e firmware correto, o próprio módulo é o culpado, o que é um caso de garantia ou bancada.

Overclock mal feito: recuperação e prevenção

A assinatura da falha: frequência ou tensão elevadas, e agora a unidade trava, achata após minutos ou horas, throttla, ou um chip em uma placa multichip desaparece. A física é implacável em um aspecto específico: a instabilidade por clock muito alto frequentemente leva tempo para aparecer. Uma configuração que sobrevive a um teste de 10 minutos pode falhar no minuto 40 quando a placa atinge saturação térmica completa, e é por isso que qualquer afirmação de estabilidade por menos de 24 horas é provisória.

RECUPERAÇÃO (se a unidade ainda inicializa):
  Interface web -> voltar frequência e tensão ao padrão de
  fábrica -> salvar -> ciclo de energia a frio (apaga qualquer
  falha travada).

RECUPERAÇÃO (se entra em loop antes de alcançar a interface):
  Flash da imagem de fábrica via USB: isso restaura os pontos
  de operação de série. Depois reset de fábrica para limpar
  a NVS.

PREVENÇÃO (todo o método em cinco linhas):
  - um patamar de 25 MHz por vez, tensão intocada
  - mínimo 30 minutos por patamar, observando o % de erro HW
  - erro acima de 2% = volte um patamar; esse é o limite
  - só então eleve a tensão em passos de 25 mV se aceitar o
    calor extra; fique dentro da janela 1100-1300 mV
  - 24 horas na configuração final antes de chamá-la de estável

E uma nota honesta: undervoltar para eficiência falha exatamente igual a overclockar para velocidade, só na direção oposta: pouca tensão para o clock produz os mesmos erros e travamentos. A loteria do silício se aplica em ambas as extremidades.

Diagnosticando pela API: o atalho do usuário avançado

Todo minerador da família AxeOS expõe uma API REST na porta 80, e isso muda a aparência do troubleshooting: sem necessidade de tela, sem clicar por painéis, e escala de uma unidade para uma frota. A especificação completa vive no arquivo openapi.yaml no repositório ESP-Miner; estas são as chamadas que importam para diagnóstico.

As cinco chamadas de diagnóstico

# Tudo de uma vez: médias de hashrate, temperaturas, tensão,
# potência, RPM da ventoinha, shares, melhor dificuldade,
# RSSI WiFi, uptime, versão do firmware, heap livre
curl http://IP-DO-MINERADOR/api/system/info

# Estado do ASIC: modelo, contagem, frequência, tensão
curl http://IP-DO-MINERADOR/api/system/asic

# Série temporal com que os gráficos do painel são desenhados
curl "http://IP-DO-MINERADOR/api/system/statistics?columns=hashrate,asicTemp,vrTemp,power"

# A SUBESTIMADA: baixar os logs do dispositivo remotamente.
# Sem cabo serial, sem PuTTY: traga o log pela rede e filtre
# pelas linhas vermelhas do dicionário abaixo.
curl http://IP-DO-MINERADOR/api/system/logs

# Qual é qual? Faz o dispositivo se identificar (tela/LED):
# inestimável em uma prateleira de caixas idênticas
curl -X POST http://IP-DO-MINERADOR/api/system/identify

Esse endpoint de logs merece uma frase própria: a maior parte da seção de console serial deste guia pode ser feita do seu sofá com essa única chamada, desde que o dispositivo inicialize o suficiente para servir HTTP. O cabo serial permanece necessário apenas para falhas em tempo de boot e loops de crash.

Lendo /api/system/info como um mecânico

Seis campos naquele JSON respondem à maioria dos tickets antes de serem abertos:

CAMPO (nome típico)       O QUE TE DIZ
hashRate / hashrate_10m   a afirmação: compare com a pool
temp / asicTemp           o orçamento de 55-62 C da seção
                          térmica
vrTemp                    o lado do regulador: frequentemente
                          o limitador real em BM1370/BM1373
voltage                   o rail de entrada COMO A PLACA VÊ:
                          um multímetro de software. Caindo
                          abaixo de 4,9 V sob carga = fonte,
                          provado sem abrir o gabinete
power                     watts consumidos: 2 W em uma
                          unidade "hasheando" = armadilha
                          USB-C
sharesAccepted /          o par da verdade; rejeitados
sharesRejected            subindo = tabela de motivos
wifiRSSI                  mais forte que -70 dBm é saudável;
                          mais fraco explica shares expirados
freeHeap                  encolhendo lentamente ao longo de
                          dias = a classe de bug de vazamento
                          de memória; anote a versão, verifique
                          o tracker

Saúde da frota em um loop

Com mais de uma unidade, pare de verificar painéis. Este loop imprime um resumo de saúde de uma linha por minerador e sinaliza os mortos:

#!/bin/bash
# fleet-check.sh - ajuste os IPs ao seu enxame
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  INACESSÍVEL"
    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

Execute-o do cron a cada cinco minutos, canalize para uma notificação de sua escolha, e uma falha às 2 da manhã se torna um alerta às 2:05 em vez de uma surpresa de manhã. Os nomes de campos variam levemente entre versões de firmware; faça dump do JSON bruto uma vez e ajuste.

A API também conserta coisas

# Reiniciar sem tocar no hardware
curl -X POST http://IP-DO-MINERADOR/api/system/restart
#   (lembre: isso NAO apaga uma falha TPS546 travada,
#    para isso ainda é necessário o desconectar físico)

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

# Corrigir uma configuração de pool digitada errada sem a UI
curl -X PATCH http://IP-DO-MINERADOR/api/system \
  -H "Content-Type: application/json" \
  -d '{"stratumUser": "SUA_CARTEIRA.worker1"}'

Um aviso honesto: a API não tem autenticação. Qualquer um na sua LAN pode ler e reconfigurar seus mineradores. Em uma rede doméstica isso geralmente é aceitável; em uma rede compartilhada ou acessível a convidados, coloque os mineradores em sua própria VLAN ou segmento IoT: que convenientemente é a mesma correção que a seção WiFi já recomendou.

Peculiaridades por modelo: conheça a personalidade da sua placa

Além dos modos de falha universais, cada família de placas tem comportamentos característicos que vale a pena conhecer antes de depurar uma.

A tabela mestre de sintomas

O dicionário de linhas vermelhas

As strings de erro que você realmente verá, em um só lugar, escritas literalmente para que o Ctrl+F as encontre. Encontre sua linha, obtenha sua direção.

LINHA NO LOG                       SIGNIFICADO -> PARA ONDE IR
---------------------------------------------------------------
Brownout detector was triggered    tensão caiu -> Alimentação
rst:0x.. (BROWNOUT_RESET)          o mesmo, no banner de reset
Power Fault Detected               TPS546 travado -> Alimentação
TPS546 status / regulator fault    mesma família -> Alimentação
VCORE init failed /                firmware não consegue programar
  device ID mismatch               o regulador: imagem errada ou
                                   I2C -> ASIC + Firmware
i2c_master_transmit_receive err /  barramento de sensores caído ->
  ESP_ERR_TIMEOUT near boot        ASIC, subseção I2C
Found 0 chip(s) / ASIC init fail   chip não responde -> ASIC
Chip count N of M                  quebra de cadeia em N+1 -> ASIC
Device has overheated /            corte a 75 C -> Térmico
  Overheat Mode
VREG temp over limit               regulador quente -> Térmico
wifi: NO_AP_FOUND                  visibilidade 2,4 GHz -> Rede
wifi: AUTH_EXPIRE / auth fail      senha errada -> Rede
wifi: beacon timeout               sinal ou canal fraco -> Rede
wifi_disconnect reason: N          pesquise N; corrija por motivo
Stratum connection failed /        pool inacessível -> Stratum
  connect errno
authorize failed                   login rejeitado -> Stratum,
                                   verificar endereço e worker
job not found (ao enviar)          share expirado -> Stratum
above target / low diff share      incompatibilidade diff ou HW
duplicate share                    nonce travado -> ciclo de
                                   energia, depois reduzir clock
Guru Meditation Error: (MOTIVO)    panic -> Firmware, leia a
                                   palavra do motivo
esp_psram: PSRAM ID read error /   init PSRAM -> Firmware,
  Failed to init external RAM      subseção família Nerd
E (xx) esp_image: checksum failed  flash corrompida -> reflash USB
[www.bin / UI em branco após OTA]  URL de recovery -> Firmware

Manutenção preventiva: o ritual mensal de 15 minutos

Quase tudo acima é mais barato de prevenir do que de debugar.

MENSAL
  [ ] Poeira: aletas e pás da ventoinha (ar comprimido,
      segurando a ventoinha)
  [ ] Verificação pelo lado da pool: tendência aceitos contra
      rejeitados, e % de erro HW ainda abaixo de 2
  [ ] Olhada nas temperaturas: alguma deriva desde o mês
      passado?
  [ ] Tocar fisicamente o conector de alimentação: morno é
      um aviso, quente é uma parada

A CADA 6-12 MESES
  [ ] Substituir a pasta térmica (é um consumível)
  [ ] Inspecionar pinos XT30 ou jack por descoloração
  [ ] Reverificar fonte sob carga com multímetro

A CADA ATUALIZAÇÃO DE FIRMWARE
  [ ] Ler as notas da versão ANTES de flashar
  [ ] Anotar a versão atual (seu alvo de rollback)
  [ ] Flashar com alimentação estável, preferencialmente
      próximo ao roteador
  [ ] Reverificar configuração da pool depois: atualizações
      podem resetar campos

SEMPRE
  [ ] Pool de fallback configurada (segunda região)
  [ ] Nomes de worker distintos em toda a frota
  [ ] Tabela escrita: chain -> endereço de carteira
  [ ] Configurações de fábrica anotadas antes de qualquer
      ajuste

Quando é realmente hardware: o que é reparável

Você fez ciclo a frio, reset de fábrica, reflash da imagem correta com alimentação verificada, e a falha persiste. Essa é a definição de um problema de hardware. O mapa realista de reparos:

• Reparável na bancada (ar quente, microscópio, mãos firmes ou um profissional): TPS546 ou componentes do estágio buck defeituosos, capacitores cerâmicos rachados, soldas frias sob o ASIC ou o módulo ESP32 (reflow), conectores de alimentação gastos, ventoinhas mortas. Isso é rotina para qualquer bancada de reparo de ASIC.
• Às vezes recuperável: uma placa com um curto-circuito franco no rail de 5 V (quase zero ohms para terra, com energia desligada) — não continue aplicando energia; o curto deve ser encontrado e removido primeiro.
• Geralmente terminal: um ASIC que funcionou sem contato com o dissipador por mais do que alguns segundos, sequelas de fuga térmica, ou um chip que recebeu a tensão de núcleo errada durante um reparo improvisado do VRM. Em uma placa de chip único o chip é a maior parte do valor: além de certo ponto, substituir vence consertar.

A ajuda da comunidade vive no Discord do OSMU e no issue tracker do ESP-Miner no GitHub: antes de abrir um ticket, pesquise no tracker primeiro, pois uma parcela surpreendente dos relatos de “minha unidade está quebrada” são issues conhecidos com uma correção já mesclada na próxima versão. Ao reportar, um relatório completo recebe resposta em horas enquanto um vago morre no silêncio. Copie este modelo:

PLACA:      (modelo exato + revisão, ex. Gamma 602)
FIRMWARE:   (versão AxeOS, do painel ou de /api/system/info)
FONTE:      (tensão, amperes, marca - e: medida sob carga?)
POOL:       (URL + porta + moeda)
SINTOMA:    (uma frase: o que acontece, desde quando)
GATILHO:    (o que mudou logo antes: atualização? transporte?
             OC? remontagem do dissipador? nada?)
TENTOU:     (ciclo a frio 60s? reset de fábrica? reflash?
             frequências de fábrica? resultado do autoteste?)
LOG:        (cole o log de boot do serial 115200 ou de
             curl http://IP/api/system/logs - no mínimo
             a primeira linha E e dez linhas ao redor)

Esse modelo não é burocracia: é exatamente a informação que uma bancada de reparo coleta primeiro, na ordem em que a coleta.

PRO: a seção de bancada — esquemas, pontos de teste e o multímetro

Esta seção assume que você sabe ler um esquema e sondar uma placa energizada sem curto-circuitar pinos adjacentes. Se essa frase te fez hesitar, pare aqui: tudo acima desta linha é solucionável sem abrir o gabinete, e uma ponta de prova que escorrega em uma placa viva de 3 nm transforma um problema em dois. Para todos os outros, é aqui que o hardware aberto compensa.

Por que essas placas são diferentes de qualquer outro minerador

O hardware Bitaxe é licenciado sob CERN-OHL-S e projetado no KiCad, e cada esquema, layout de PCB e lista de materiais é público. Isso significa que você nunca adivinha o que um componente é ou onde um rail passa: você pode abrir o esquema exato da sua revisão exata, encontrar a net e medi-la. Nenhum dono de Antminer jamais teve esse privilégio. Cada repositório de hardware também carrega uma seção que quase ninguém abre: a página de HW issues com bugs conhecidos, reworks e errata por revisão. Antes de diagnosticar qualquer falha em nível de placa, verifique se sua revisão tem uma errata documentada: uma parcela surpreendente de falhas de hardware “misteriosas” já está escrita lá com o rework que as corrige.

O método do multímetro: três rails contam toda a história

Falhas no caminho de alimentação se localizam com três medições em DC, tomadas em ordem. Referência ao terra primeiro, respeite a sequência, e meça sob carga onde indicado.

RAIL 1 - ENTRADA (5 V ou 12 V dependendo da família)
  Onde:     conector ou pads de entrada (veja esquema)
  Esperado: família 5 V:  4,9 - 5,3 V  ENQUANTO HASHA
            família 12 V: 11,8 - 12,2 V ENQUANTO HASHA
  Baixo só sob carga -> fonte ou cabo (maioria dos casos)
  Lê 0 com boa fonte -> proteção de entrada queimada ou
                        curto a jusante: meça resistência
                        ao terra COM ENERGIA DESLIGADA;
                        quase zero ohms = curto, pare de
                        aplicar energia, encontre-o

RAIL 2 - 3,3 V (a alimentação do ESP32)
  Onde:     net de 3,3 V conforme esquema (módulo ESP32)
  Esperado: 3,2 - 3,4 V estáveis
  Ausente com entrada ok -> o pequeno regulador de 3,3 V
  ou seus passivos: explica "completamente morto, sem
  enumeração USB" com fonte comprovadamente boa

RAIL 3 - VCORE (a alimentação do ASIC)
  Onde:     saída do estágio buck TPS546 / net de núcleo
  Esperado: aproximadamente 1,0 - 1,3 V, correspondendo
            ao valor definido no AxeOS
  Ausente com entrada e 3,3 V ok -> o estágio buck:
  falha travada (sempre ciclo a frio primeiro), ou
  TPS546 / indutor / passivos circundantes defeituosos
  Presente mas com valor errado -> programação do
  regulador ou comunicação PMBus: contraste com o que
  o AxeOS acredita ter definido

MEDIÇÕES DE CONFIRMAÇÃO
  Continuidade conector de entrada -> entrada do regulador:
  encontra trilhas rompidas e soldas rachadas do jack
  Temperatura do die do TPS546 pelo painel vs mão
  aproximada: um regulador quente demais para se aproximar
  em repouso está falhando

Esses três rails particionam qualquer falha de alimentação: entrada ruim = antes da placa; entrada boa e 3,3 V ruim = o pequeno regulador; ambos bons e VCORE ruim = o estágio buck; todos três bons = a falha não é de alimentação, volte à seção ASIC. Dez minutos com um multímetro de vinte dólares substituem horas de especulação.

O que uma bancada de reparo pode e não pode fazer

ROTINA (ar quente + microscópio + mãos firmes)
  - substituição do TPS546 ou componentes do estágio buck
  - capacitores cerâmicos rachados (visual: fissura fina
    atravessando o corpo; elétrico: curto ou circuito aberto)
  - reflow de BGA sob o ASIC ou módulo ESP32 (a classe de
    falha após queda e após remontagem)
  - substituição de conectores (jack gasto, XT30 cozido)

POSSÍVEL COM PACIÊNCIA
  - caçar um curto no rail de 5 V (câmera térmica ou o
    truque da evaporação de isopropanol sobre áreas suspeitas)
  - troca do módulo ESP32-S3 (requer reflash depois)

NÃO VALE A PENA / TERMINAL
  - substituir o ASIC em placas de chip único: o chip é a
    maior parte do valor da placa e chips doadores são
    recuperados de qualquer forma; uma placa nova vence em
    custo e certeza
  - qualquer coisa após fuga térmica ou entrada com
    polaridade invertida em todo o rail

Lendo o esquema como um técnico de reparo

Três hábitos que tornam os esquemas abertos realmente úteis. Primeiro, encontre a página da árvore de alimentação e trace de entrada até VCORE uma vez no papel antes de sondar qualquer coisa: você agora conhece cada componente capaz de matar o rail. Segundo, anote os designadores de referência (R12, C34, U3) do estágio buck: posts de fórum e errata se referem a peças por designador, e mapeá-los para sua placa leva segundos com o arquivo de layout aberto. Terceiro, compare revisões quando uma falha é específica de revisão: o changelog entre, digamos, um Gamma 600 e um 601 te diz exatamente o que os projetistas corrigiram, que frequentemente é exatamente o que falha no mais antigo.

A biblioteca de recursos de código aberto

Todas as fontes primárias em uma tabela. Salve esta seção nos favoritos: metade do valor do hardware aberto é saber onde os originais vivem, e cada link abaixo é a fonte oficial, não um espelho.

Pontos principais

• Seis domínios cobrem quase toda falha: alimentação, ASIC, térmico, rede, stratum, firmware. A triagem de 60 segundos te diz em qual você está antes de tocar em qualquer coisa.
• A alimentação é a causa número um e o impostor número um: se disfarça como crashes de WiFi, panics de firmware, chips travados e placas mortas. Meça a entrada sob carga antes de acreditar em qualquer outra teoria.
• Uma falha travada do regulador sobrevive a qualquer reinício por software. Desconectar fisicamente por 10 a 60 segundos é um passo de diagnóstico real, não superstição.
• O USB-C alimenta o ESP32, nunca o ASIC. Uma placa só em USB-C imita perfeitamente um minerador morto a 0 GH/s.
• Aprenda o console serial a 115200 bauds. A primeira linha E em um log de boot nomeia seu problema mais rápido do que qualquer thread de fórum.
• O autoteste integrado nomeia o subsistema com falha em 30 segundos, e a API REST traz os logs, a telemetria e até a correção pela rede: use ambos antes de buscar um cabo serial.
• Nunca conecte uma fonte de 12 V a uma placa de 5 V. Os conectores são intercambiáveis; as placas não são.
• O ESP32 fala apenas 2,4 GHz; band steering e isolamento AP são os dois recursos de roteador que quebram a maioria das configurações.
• A verdade do lado da pool vence o otimismo do lado do minerador: o tempo desde o último share aceito é o único teste honesto de presença, e 10 minutos é o limiar.
• O endereço da carteira deve ser nativo da chain sendo minerada. Em uma pool não custodial, esse é o único erro sem caminho de volta.
• O percentual de erro de hardware é o número honesto de desempenho; o hashrate do painel é uma afirmação. Ajuste para shares aceitos e exija 24 horas antes de chamar qualquer configuração de estável.
• Um conector de alimentação quente é o único sintoma que significa parar agora, não debugar depois.

Compilado do issue tracker e das notas de release do ESP-Miner, da documentação de erros fatais do ESP-IDF, da documentação de bancadas de reparo da comunidade e dos padrões de falha recorrentes reportados nas comunidades Bitaxe, NerdAxe e NerdQaxe, em 20 de julho de 2026. O comportamento de firmware descrito aqui (travamento de falhas, limiares de superaquecimento, URLs de recuperação, faixas de regressão conhecidas) reflete as versões do AxeOS e do ESP-Miner vigentes na publicação; verifique as notas da sua versão. Este guia é mantido como referência viva: se você encontrar um modo de falha não coberto aqui, nos conte pela página de contato e nós o adicionaremos.