Miner casalingo non hasha? Bibbia del troubleshooting 2026

Cerca in una qualsiasi community di mining casalingo in un giorno qualunque e troverai sempre gli stessi post: un Bitaxe che si avvia ma resta a 0 GH/s, un NerdQaxe che si riavvia ogni due minuti, un Gamma che ha perso metà hashrate dopo un aggiornamento del firmware, una macchina che dice di stare hashando mentre la pool non vede nulla. Questi dispositivi sono hardware open source che esegue firmware open source su silicio industriale recuperato, e quella combinazione è potente, economica e davvero delicata in modi in cui un elettrodomestico non lo è.

Questa guida è il riferimento che avremmo voluto avere ogni volta che abbiamo aiutato qualcuno a fare debug. Copre i sei domini di guasto che spiegano quasi ogni unità morta o capricciosa, insegna a leggere i log come fa un banco di riparazione, e si chiude con una tabella maestra dei sintomi e un dizionario delle righe di errore reali che vedrai. Vale per tutta la famiglia AxeOS: ogni Bitaxe (Max, Ultra, Supra, Gamma, Gamma 601/602, GT, Hex), le linee NerdAxe e NerdQaxe comprese le varianti ++ e Hydro, il NerdOctaxe e per estensione qualsiasi derivato di ESP-Miner, incluse le nuove macchine BM1373 trattate nel nostro riferimento sull’era BM1373.

Un principio prima di tutto il resto: diagnostica prima di toccare. L’ordine delle operazioni di questa guida esiste perché ogni passo esclude un’intera classe di cause. Saltare direttamente al riflash del firmware quando il problema vero è un alimentatore che cede ti costa una serata e può lasciarti con due problemi invece di uno.

Hai fretta? Le cinque soluzioni che risolvono la maggior parte dei casi

Prima di leggere qualsiasi altra cosa, prova queste nell’ordine. Insieme risolvono la maggioranza delle segnalazioni «il mio miner è morto» senza attrezzi, senza log e senza aprire il case.

1. CICLO A FREDDO, FATTO BENE.
   Stacca il CONNETTORE di alimentazione (non l'interruttore
   della presa). Conta 60 secondi pieni. Ricollega.
   Perché: i fault del regolatore SI AGGANCIANO e sopravvivono
   a qualsiasi riavvio software; solo un distacco vero li
   azzera.

2. CONTROLLA COSA LO ALIMENTA DAVVERO.
   L'USB-C fa girare la dashboard ma NON può alimentare
   l'ASIC. Un miner solo su USB-C segna 0 GH/s e ~2 W per
   sempre. Verifica che l'alimentatore vero (jack/XT30) sia
   collegato e ben inserito, e che sia della TENSIONE GIUSTA
   (5 V contro 12 V: quella sbagliata distrugge la scheda).

3. SCRIVI http:// ESPLICITAMENTE.
   I browser passano in silenzio a https:// e falliscono.
   http://IP-DEL-MINER, con il prefisso, ogni volta.

4. DAGLI I 2,4 GHz.
   Queste radio non parlano mai i 5 GHz. Sui router mesh crea
   un SSID solo 2,4 GHz o una rete IoT, WPA2-AES, e disattiva
   l'isolamento AP.

5. CHIEDI ALLA POOL, NON AL MINER.
   Il tempo dall'ultimo share accettato sulla dashboard della
   POOL è l'unico test onesto di presenza online. Oltre 10
   minuti = morto adesso, qualunque cosa dica l'interfaccia.

Risolto? Bene, chiudi la scheda. Non risolto? Il triage qui
sotto trova la tua sezione in 60 secondi.

Trova il tuo problema in fretta

Venti sezioni sono tante. Tre modi per saltare alla tua:

Con la ricerca: ogni stringa di errore in questa guida è scritta alla lettera, esattamente come la stampa il firmware. Premi Ctrl+F (Cmd+F su Mac), incolla il tuo messaggio di errore e ci atterri sopra: è una scelta di progetto, non fortuna.

Per sintomo:

Per stile di lettura: la sezione successiva divide la guida in un percorso per principianti e uno professionale.

Scegli il tuo percorso

Questa guida serve due lettori molto diversi, e non dovresti leggerla allo stesso modo.

Primo miner, primo problema? Segui il percorso numerato senza saltare nulla: le due regole di sicurezza, l’autotest integrato, il triage da 60 secondi e poi solo la sezione a cui il triage ti manda. Ogni blocco di codice è pronto da copiare, ogni termine che potresti non conoscere è nel mini-glossario qui sotto, e niente del percorso base richiede di aprire il case o di possedere un multimetro.

A tuo agio con un terminale e un tester? La tua corsia veloce: la sezione API per scaricare i log da remoto e controllare la flotta, il dizionario delle righe rosse per saltare dritto da una stringa di errore alla sua causa, la tabella delle particolarità per modello e la sezione professionale da banco in fondo, dove vivono gli schemi, il metodo dei punti di misura e le risorse a livello scheda. Le sezioni marcate PRO danno per scontato che tu sappia leggere uno schema e sondare una scheda sotto tensione in sicurezza.

Mini-glossario per chi inizia

Dieci termini, dieci secondi ciascuno, e il resto della guida si legge al doppio della velocità.

ASIC        il chip di mining vero e proprio, l'unico pezzo
            che calcola davvero gli hash
ESP32       il piccolo controller che fa tutto il resto:
            WiFi, dashboard, dialogo con l'ASIC
AxeOS       il firmware + la dashboard web sull'ESP32
VCORE       l'alimentazione a ~1,0-1,3 V del core dell'ASIC,
            generata sulla scheda dai tuoi 5 V o 12 V in
            ingresso
VRM / TPS546  il circuito regolatore che crea VCORE e
            protegge il chip spegnendosi in caso di fault
stratum     il protocollo con cui il miner parla alla pool
share       una prova di lavoro che invii; la pool le conta
            per sapere che sei vivo e onesto
% errore HW risultati che il chip ha calcolato SBAGLIATI:
            il numero onesto sulla salute (stare sotto il 2%)
OTA         aggiornamento «over the air» dalla dashboard, in
            contrapposizione al flash via USB
NVS         la memoria delle impostazioni che sopravvive ai
            riflash: per questo esiste il reset di fabbrica

Prima di tutto: due regole di sicurezza e uno strumento integrato

Le due regole che evitano schede morte

Regola uno: non tirare mai a indovinare sulla tensione. I Bitaxe standard a chip singolo vogliono 5 V; GT, Hex, NerdQaxe++ e NerdOctaxe vogliono 12 V. I jack delle due famiglie sono fisicamente intercambiabili, e collegare un alimentatore da 12 V a una scheda da 5 V la distrugge in modo permanente in meno di un secondo. Prima di ogni collegamento leggi l’etichetta dell’alimentatore, non la forma dello spinotto. È l’errore più costoso di questo hobby.

Regola due: un connettore caldo significa stop. Tiepido è un avviso; caldo, scolorito o che sa di plastica significa spegnere subito e sostituire il cavo prima della prossima accensione. Tutto il resto in questa guida può aspettare domani. Questo no.

Lancia l’autotest integrato

AxeOS include un autotest all’accensione della cui esistenza la maggior parte dei proprietari non sa nulla. Mette alla prova cinque sottosistemi in sequenza e segnala il primo guasto sul display, il che ne fa una diagnosi hardware gratuita da trenta secondi che ti dà il nome del dominio guasto:

COSA VERIFICA (in ordine)     SE FALLISCE, IL DISPLAY MOSTRA
  rail di ingresso              POWER FAIL
  regolatore tensione di core   VCORE FAIL
  bus sensori I2C               (si blocca durante il test)
  segnale tachimetrico ventola  FAN FAIL
  rilevamento dell'ASIC         ASIC FAIL
  breve raffica di hashing      HASHRATE FAIL

COME LEGGERE IL RISULTATO
  POWER / VCORE FAIL   -> sezione Alimentazione. Il test
                          rifiuta un ingresso che si discosta
                          più del 10% dal nominale: misura
                          l'alimentatore.
  ASIC FAIL            -> sezione Problemi dell'ASIC.
  FAN FAIL             -> ventola scollegata, bloccata o filo
                          tachimetrico morto.
  HASHRATE FAIL        -> chip rilevato ma che non calcola:
                          di solito alimentazione al limite o
                          un problema di impostazioni; torna
                          ai valori di fabbrica.

SE È IL TEST STESSO A BLOCCARSI
  Display fermo su SELF TEST per più di 30 secondi, oppure un
  loop infinito SELF TEST -> riavvio: su AxeOS v2.12+ tieni
  premuto il tasto BOOT per 2 secondi durante la schermata
  SELF TEST per saltarlo e arrivare alla dashboard, poi
  diagnostica da lì. Un loop di autotest dopo un flash di
  solito significa immagine sbagliata per quella scheda.

L’autotest parte automaticamente al primo avvio e si può lanciare dalle impostazioni. Fallo dopo qualsiasi evento hardware: un trasporto, un rimontaggio del dissipatore, un cambio di alimentatore. Trasforma «qualcosa non va» in un sottosistema con un nome prima ancora che tu abbia aperto un solo log.

Cosa ti sta dicendo il display

Sui modelli con schermo, l’OLED è uno strumento di stato, non un ornamento. Ruota schermate informative ogni pochi secondi; il tasto BOOT avanza manualmente e risveglia un display spento dal timer. Gli stati da riconoscere: la schermata di avvio (il firmware è vivo), quella dell’hotspot di configurazione (non configurato o credenziali WiFi perse), quella dell’indirizzo IP (la tua porta verso la dashboard), l’autotest e i codici FAIL visti sopra, un avviso di surriscaldamento, e l’animazione del blocco trovato che speriamo tu incontri prima o poi. Un display spento non è la prova di una scheda morta: controlla se è semplicemente scattato il timeout di spegnimento e se la pool continua a vedere arrivare share.

Il triage da 60 secondi

Prima di aprire un solo log, rispondi a cinque domande. Partizionano l’intero spazio del problema.

D1  Si accende qualcosa? (LED, display, ventola)
      NO -> DOMINIO ALIMENTAZIONE. Vai a: Alimentazione.
      SÌ -> D2

D2  Il dispositivo arriva alla dashboard AxeOS o mostra un IP?
      NO -> D2a: trasmette il suo hotspot di configurazione?
            SÌ -> DOMINIO WIFI. Vai a: Problemi di rete.
            NO -> DOMINIO AVVIO. Vai a: Firmware.
      SÌ -> D3

D3  La dashboard mostra un hashrate sopra lo zero?
      NO -> D3a: mostra un fault di alimentazione, un banner
            di surriscaldamento o 0 chip ASIC?
            fault alim.  -> Alimentazione
            surriscald.  -> Problemi termici
            0 chip       -> Problemi dell'ASIC
      SÌ -> D4

D4  La POOL mostra share accettati negli ultimi 10 minuti?
      NO -> DOMINIO STRATUM. Vai a: Problemi di pool.
      SÌ -> D5

D5  Hashrate, tasso di errore e temperatura sono quelli giusti?
      NO -> Problemi termici oppure overclock sbagliato.
      SÌ -> Non è rotto niente. Chiudi la scheda del browser.

Nota che D4 interroga la pool, non il dispositivo. La caccia al fantasma più comune nel mining casalingo è fare debug di un miner la cui interfaccia sembra perfetta mentre la pool non lo sente più da un’ora. Il dispositivo e la pool vedono ciascuno metà del quadro, e questa guida torna su questa asimmetria più volte.

Come si leggono i log

Tutto il resto di questa guida è più veloce se sai leggere i log, quindi questa sezione viene per prima. Ci sono due superfici di log, e rispondono a domande diverse.

Il log web di AxeOS

Apri la dashboard all’indirizzo IP del miner e cerca la vista log. Mostra il registro di esecuzione in tempo reale: traffico stratum, invii di share, cambi di difficoltà, eventi di temperatura. È lo strumento giusto quando il dispositivo si avvia bene e la domanda è cosa sta facendo adesso. Il suo limite: parte quando la rete è già su, quindi non può mostrarti un fallimento di avvio, e muore con il server web, quindi non può mostrarti un crash.

La console seriale: la verità

Per qualsiasi cosa riguardi avvio, crash, rilevamento dell’ASIC o associazione WiFi serve la console seriale. È lo stesso output che leggono gli sviluppatori, e parte dalla primissima istruzione.

1. Collega un cavo USB-C DATI (non uno solo di ricarica) dal
   miner al computer. Su alcune schede Bitaxe una connessione
   nativa USB-C verso USB-C non riesce a negoziare; usa un
   cavo o adattatore USB-A verso USB-C, che forza i 5V
   classici.

2. Apri un terminale seriale a 115200 baud, 8N1:

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

3. Premi il tasto RST sulla scheda (o ricollega l'alimenta-
   zione). L'intero log di boot scorre dall'inizio.

Le righe di log di ESP-IDF portano una lettera di gravità: I per informazione, W per avviso, E per errore. La maggior parte dei terminali colora di rosso le righe E. Un avvio sano ha zero righe E. Ecco tutta l’arte della lettura dei log in una frase: scorri il boot, trova la prima E e cercala nel dizionario in fondo a questa guida. Conta soprattutto il primo errore, perché quelli successivi di solito sono danni a cascata del primo.

Com’è fatto un avvio sano

Commentato e abbreviato. Il tuo differirà nei dettagli ma deve toccare le stesse tappe nello stesso ordine.

rst:0x1 (POWERON_RESET), boot:0x8 (SPI_FAST_FLASH_BOOT)
        <- motivo del reset. POWERON è normale. Reset ripetuti
           RTC_WDT o BROWNOUT qui sono il primo campanello
           d'allarme.

I (xx) main: Found device config: <modello della tua scheda>
        <- il firmware ha identificato la scheda. Un nome di
           modello sbagliato qui significa immagine firmware
           sbagliata.

I (xx) TPS546: Found TPS546D24A          (schede con TPS)
I (xx) Power: VCORE set to 1150 mV
        <- il regolatore di core ha risposto su I2C e il rail
           dell'ASIC è su. Se questo blocco manca o dà errori,
           niente a valle può funzionare.

I (xx) bm13xx: Found 1 chip(s)
        <- LA riga. Il numero deve corrispondere ai chip della
           tua scheda: 1 per chip singolo, 2 per il GT, 4 per
           il NerdQaxe, 6 per l'Hex, 8 per il NerdOctaxe.

I (xx) wifi: connected, IP: 192.168.x.x
        <- rete su. I fallimenti di associazione stampano qui
           i codici di motivo (dizionario più sotto).

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: ...
        <- la pool ha accettato il login e inviato lavoro.

I (xx) asic_result: Nonce found, diff xxx of yyy
        <- l'ASIC restituisce risultati. Entro un paio di
           minuti dovresti vedere share sopra la difficoltà
           della pool inviati e accettati.

Impara a memoria l’ordine delle tappe: motivo del reset → configurazione scheda → regolatore → conteggio chip → WiFi → stratum → nonce. La prima tappa che fallisce dà il nome alla sezione della guida che ti serve.

Problemi di alimentazione: la causa numero uno di tutto

Se i guasti dei miner casalinghi avessero una classifica, l’alimentazione occuperebbe i primi tre posti. Queste schede fanno girare silicio a 3 nm e 5 nm ad alta corrente partendo da alimentatori di consumo e attraverso connettori di consumo, e i margini sono stretti.

Conosci la tua architettura di alimentazione

Bitaxe a chip singolo (Max/Ultra/Supra/Gamma)
  Ingresso:  5 V via jack (5,5x2,1mm) o USB-C
  Corrente:  fino a ~5 A sul Gamma di serie, di più in OC
  Regolatore: TPS546D24A buck digitale (schede vecchie: DAC
             DS4432U + monitor INA260) abbassa i 5V a
             ~1,1-1,3V di core ASIC a corrente altissima
  Finestra:  il regolatore parte a ~4,8 V e stacca sotto
             ~4,5 V

Famiglia 12 V (GT, Hex, NerdQaxe++, NerdOctaxe)
  Ingresso:  12 V via connettore XT30 o jack
  Corrente:  NerdQaxe++ ~8+ A a pieno carico; Octaxe di più
  Rischio:   riscaldamento del connettore; caduta sotto carico

FATTO CRITICO: l'USB-C sulle schede Bitaxe attuali serve SOLO
all'ESP32 e al flash. Non può alimentare l'ASIC. Una scheda
alimentata solo via USB-C si avvia, mostra la dashboard e
hasha a esattamente 0 GH/s assorbendo ~2 W. Questo imita in
modo preciso un regolatore morto e fa perdere ore ogni
settimana a tutta la community.

Power Fault Detected: cosa è successo davvero

Il regolatore TPS546 sorveglia quattro protezioni: sovracorrente, sovratensione, sottotensione, sovratemperatura. Quando una scatta, il regolatore si aggancia in spegnimento e AxeOS mostra il banner di fault. L’ASIC perde il suo rail; l’ESP32, alimentato a parte, tiene viva l’interfaccia. Due fatti governano la soluzione:

• L’aggancio sopravvive ai riavvii software. Lo stato di fault resta nel registro di stato del regolatore stesso finché la tensione di ingresso non viene rimossa fisicamente. Riavviare dall’interfaccia web, chiamare l’API di restart o premere il tasto reset dell’ESP32 non lo azzera. È un comportamento documentato, non un bug, ed è anche il motivo per cui esiste un’intera classe di issue su GitHub: schede BM1370 bloccate a 0 GH/s che assorbono 5 W, dove l’endpoint di restart non risolve nulla ma un ciclo di alimentazione risolve tutto.
• Lo scatto è un sintomo; la causa è a monte. Il regolatore sta proteggendo un chip che vale più della scheda che gli sta intorno. La stragrande maggioranza degli scatti ricorrenti risale all’alimentazione in ingresso, non al regolatore.

La sequenza di intervento, in ordine:

1. CICLO A FREDDO. Stacca il connettore di alimentazione vero
   e proprio (non l'interruttore a muro). Conta 10 secondi
   pieni. Alcune schede richiedono 60 secondi perché i
   condensatori di bulk si scarichino e si azzeri uno stato di
   ritenuta brownout dell'ESP32. Ricollega. Questo da solo
   risolve la maggior parte dei fault occasionali.

2. TOGLI L'USB-C. Se c'è qualcosa collegato all'USB-C,
   staccalo e verifica che l'alimentatore vero (jack/XT30) sia
   inserito. Escludi la trappola USB-C descritta sopra.

3. MISURA SOTTO CARICO. Multimetro in DC sul connettore di
   ingresso MENTRE IL MINER STA HASHANDO:
     schede 5 V:  attesi 4,9-5,3 V sostenuti.
                  Sotto 4,8 V = il problema è l'alimentatore.
     schede 12 V: attesi 11,8-12,2 V sostenuti.
                  Sotto 11,4 V = il problema è l'alimentatore.
   Una misura a vuoto non dimostra niente: gli alimentatori
   scadenti mostrano 5,0 V perfetti a riposo e crollano a
   4,4 V sotto carico.

4. ELIMINA IL PERCORSO. Collega l'alimentatore direttamente
   alla presa a muro: niente ciabatte, niente prolunghe,
   niente concatenamenti. Le ciabatte scadenti aggiungono una
   caduta misurabile. Muovi il jack: se il display sfarfalla,
   la presa o il cavo sono consumati.

5. MIGLIORA L'ALIMENTATORE. Specifica minima onesta:
     schede 5 V a chip singolo: 5 V / 5 A di qualità, dedicato
     classe NerdQaxe++ 12 V:    12 V / 10 A (120 W) minimo
   I caricabatterie da telefono e gli adattatori universali
   sono di gran lunga la causa radice più comune di tutta
   questa guida.

L’avvertimento sull’XT30

La famiglia a 12 V spinge 8 o più ampere attraverso un XT30. Il connettore è dimensionato per farlo; i codini saldati a mano dietro di esso spesso no. Ispeziona: pin scoloriti, connettore tiepido al tatto, saldature fredde, crimpature lasche. Una giunzione ad alta resistenza a 8 A si scalda, si ossida, resiste di più e si scalda ancora: è l’unico modo di guasto del mining casalingo che finisce in plastica fusa. Se il connettore è mai stato abbastanza caldo da scolorire, sostituisci il cavo, non riutilizzarlo. Le unità NerdQaxe che crashano con un errore di alimentatore e un codice Guru Meditation risalgono esattamente a questo rail che cede sotto carico.

Brownout: il crash che non è un crash

L’ESP32 ha un rilevatore di brownout hardware. Quando il rail a 3,3 V si abbassa, stampa Brownout detector was triggered e si riavvia. Un miner che si riavvia ogni pochi minuti, soprattutto quando l’ASIC sale a pieno carico, non ha quasi mai un problema di firmware: è l’alimentazione che cede nel momento di massimo assorbimento. La soluzione sono i passi da 3 a 5 qui sopra. Non inseguire il firmware per un loop di brownout.

Problemi dell’ASIC: il chip non risponde

La riga del log di boot da guardare è il conteggio dei chip. Il firmware enumera la catena di ASIC via UART e stampa quanti chip hanno risposto. Qualsiasi cosa diversa dal conteggio pieno della tua scheda appartiene a questa sezione.

Zero chip rilevati

La dashboard mostra conteggio ASIC 0 oppure il log mostra un fallimento di inizializzazione. Cause, in ordine di frequenza osservata:

1. Regolatore agganciato o stato di brownout trattenuto. Un chip senza tensione di core non può enumerarsi. Fai la scarica a freddo completa da 60 secondi prima di ogni altra cosa: stacca alimentatore principale, USB-C e ogni accessorio, aspetta un minuto intero, rialimenta. Questo da solo chiude una quota significativa dei casi.
2. Immagine firmware sbagliata. Flashare l’immagine di un’altra scheda, anche una sola volta, può lasciare una configurazione di dispositivo errata nella memoria non volatile che sopravvive ai riflash. Se la riga del modello nel log di boot non corrisponde alla scheda fisica, fai un reset di fabbrica completo e poi flasha l’immagine corretta. Un’immagine BM1366 su una scheda BM1370 non troverà mai il chip.
3. Evento meccanico. La sequenza classica: l’unità è stata spostata, è caduta, è stata spedita, oppure il dissipatore è stato ristretto, e non ha più hashato. Sotto l’ASIC c’è una matrice BGA di saldature; la flessione le crepa. Una pressione di montaggio disomogenea del dissipatore fa lo stesso. Se la cronologia torna, è una riparazione da banco (rifusione), non un problema di impostazioni.
4. Fuga di fabbrica. Un’unità nuova che non ha mai hashato nemmeno una volta ha una probabilità sproporzionata di avere una saldatura fredda di produzione. Non passare un fine settimana sul software: fai la scarica a freddo e il controllo del firmware, poi attiva la garanzia.

Conteggio parziale dei chip: la firma multichip

Un Hex che riporta 3 su 6, un NerdQaxe 2 su 4, un GT 1 su 2. Le schede multichip enumerano gli ASIC come una catena, quindi un solo chip morto o scollegato interrompe il rilevamento in quel punto della catena: il numero ti dice all’incirca dove sta la rottura. Una scheda a quattro chip che mostra 2 ha un problema al chip 3. Le cause sono le stesse di sopra (margine di alimentazione, saldatura crepata) più una specifica del multichip: un chip debole nella catena che cade solo alle frequenze alte. Se il conteggio pieno torna alle frequenze di fabbrica ma i chip spariscono in overclock, hai trovato il die più debole della tua lotteria del silicio, e il suo tetto è il tetto dell’intera scheda.

Errori I2C: il bus dei sensori, non il miner

Una classe che confonde: il miner hasha normalmente mentre Power, ASIC Temp e Input Voltage compaiono come trattini, null o zeri, e il log mostra errori di trasmissione/ricezione I2C o timeout. Il percorso di hashing (UART verso l’ASIC) e quello di telemetria (I2C verso il PMBus del regolatore, il sensore di temperatura, il monitor di corrente) sono bus separati. Uno può cadere mentre l’altro gira. Innesco noto: una fascia di regressione firmware attorno ad AxeOS v2.13/v2.14 in cui il percorso di lettura dei sensori fallisce in silenzio su una parte delle unità. Causato anche da qualsiasi accessorio che condivide il connettore I2C: un OLED aggiunto o un sensore esterno con contatto ballerino può bloccare il bus per i sensori integrati. Riporta l’unità allo stato di serie, fai un ciclo a freddo, e se è la fascia firmware aggiorna in avanti o torna indietro di una versione.

L’effetto collaterale pericoloso: senza retroazione di temperatura la curva delle ventole non può funzionare, quindi la ventola si inchioda a una velocità. Se la telemetria è morta, considera morta anche la protezione termica e non lasciare l’unità incustodita finché non è sistemata.

Problemi termici: il calore è un budget, non un evento

I numeri che contano

Temp. core ASIC   obiettivo: 55-62 C sostenuti
                  preoccupa: sopra 65 C costanti
                  intervento: ~75 C -> modalità Overheat

Temp. VREG        va 10-15 C più calda del core sotto carico;
                  sulle schede BM1370/BM1373 spesso è il
                  sensore limitante, non il core

Modalità Overheat l'hashing si ferma, la ventola va al 100%,
                  l'interfaccia resta viva; si sblocca con
                  isteresi quando la temperatura torna
                  intorno ai 65 C

Diagnosi per schema temporale

Surriscalda subito da freddo — problema di montaggio. Il dissipatore non fa contatto: pad termico assente o strappato, pasta secca o mancante, coppia di serraggio irregolare, o dissipatore allentato durante il trasporto. Un chip senza contatto passa dalla temperatura ambiente all’intervento in pochi secondi. Rimonta, applica un chicco di riso di pasta di qualità, stringi le viti a croce in modo uniforme.

Surriscalda dopo 10-30 minuti — problema di capacità. Il contatto è buono ma il sistema non smaltisce il calore alla velocità con cui lo produce. Le cause si sommano: ambiente sopra i 27 C circa, unità in un mobile, in un cassetto o in un contenitore chiuso, presa o scarico dell’aria ostruiti, feltro di polvere sulle alette, oppure un overclock per cui il raffreddamento non è mai stato dimensionato. Dagli 10 cm di aria libera su entrambi i lati, pulisci le alette, e se è iniziato dopo un cambio di frequenza, quel cambio era di troppo.

Deriva lenta nell’arco di settimane — problema di manutenzione. Stesse impostazioni e temperatura che sale un grado alla volta: accumulo di polvere o pasta termica che si secca. La pasta su queste schede è un consumabile; sostituirla ogni 6-12 mesi è normale.

Surriscaldamento dopo un aggiornamento del firmware — problema di curva. Le curve di ventole e calore cambiano tra le versioni; un esempio documentato attorno alla v2.11 ha spostato il comportamento di default al punto che le unità giravano di diversi gradi più calde e un po’ più lente con le impostazioni di fabbrica. Leggi le note di rilascio, alza a mano la velocità della ventola di uno scalino, oppure regola la temperatura obiettivo se il tuo firmware espone il controllo PID.

La ventola in sé

Una ventola che riporta 0 RPM a qualsiasi temperatura è scollegata, bloccata da un cavo o morta. Una ventola che urla al 100% in modo costante significa o un chip davvero caldo (vedi sopra) o telemetria di temperatura morta che guida la curva alla cieca (vedi la sezione I2C). Le ventole di ricambio da 40 e 60 mm costano poco; quelle silenziose di fascia alta (la scelta abituale della community è una Noctua) abbassano il rumore sotto i 40 dB e sono l’upgrade hardware col miglior rapporto qualità-prezzo su una qualsiasi di queste unità.

Problemi di rete: la visione del WiFi secondo l’ESP32

La radio di ognuna di queste macchine parla solo 2,4 GHz. Non 5 GHz, non 6 GHz, nessuna eccezione, nessuna soluzione via firmware. Un’enorme fetta dei fallimenti di installazione si riduce a quella frase che collide con il comportamento dei router moderni.

Il problema dei router mesh

I sistemi mesh moderni trasmettono un unico SSID combinato e spostano i client tra le bande. L’ESP32 non può agganciarsi al lato 5 GHz, e il band steering può impedirgli di stabilizzarsi sui 2,4 GHz. Le soluzioni affidabili; la maggior parte dei router ne supporta almeno una:

Opzione A  Creare un SSID dedicato solo 2,4 GHz (la migliore)
Opzione B  Usare la funzione «rete IoT» del router: diversi
           produttori l'hanno aggiunta proprio per dispositivi
           come questi
Opzione C  Disattivare il band steering / «smart connect» così
           le bande compaiono come SSID separati

Poi verifica sull'SSID a 2,4 GHz:
  Sicurezza      WPA2-Personal, solo AES (non TKIP, e le reti
                 solo WPA3 falliranno)
  Canale         fisso 1, 6 o 11 nelle zone affollate, non Auto
  Larghezza      20 MHz
  Isolamento AP  DISATTIVATO <- attivo, il WiFi si connette ma
                 la dashboard è irraggiungibile dalla tua LAN,
                 il che sembra esattamente un dispositivo morto
  Filtro MAC     spento, oppure aggiungi il MAC del miner

Leggere i fallimenti WiFi nel log seriale

La console seriale stampa un motivo di disconnessione a ogni associazione fallita, e il motivo dà il nome alla soluzione:

AUTH_EXPIRE / auth failed      password (PSK) sbagliata.
                               Riscrivila; attenzione alle
                               virgolette tipografiche se
                               l'hai incollata dal telefono.
NO_AP_FOUND                    SSID non visibile sui 2,4 GHz:
                               band steering, SSID nascosto,
                               fuori portata o solo 5 GHz.
beacon timeout                 segnale troppo debole o canale
                               congestionato; sposta l'unità o
                               fissa il canale.
ASSOC_TOOMANY                  raggiunto il limite di client
                               del router.
Brownout detector triggered    non è affatto WiFi: il picco di
                               assorbimento della radio in
                               fase di associazione fa cedere
                               un'alimentazione debole. Sistema
                               l'alimentazione, non la rete.

Quest’ultimo merita enfasi: la trasmissione WiFi è il più grande picco istantaneo di carico che produce l’ESP32. Un’alimentazione al limite che sopravvive a riposo muore in fase di associazione, quindi un’unità che «crasha quando si connette al WiFi» di solito è un problema di alimentazione travestito da problema di rete.

Raggiungibilità senza fallimenti WiFi

Due funzioni di sicurezza dei router meritano una menzione speciale perché bloccano i miner per progetto. ASUS AiProtection e l’equivalente su alcuni modelli TP-Link classificano il traffico stratum come sospetto e lo scartano in silenzio: il miner si aggancia perfettamente al WiFi e poi non raggiunge nessuna pool. Se un’unità si connette al WiFi ma ogni connessione alla pool fallisce, e la stessa pool funziona da un hotspot del telefono, disattiva la funzione di protezione del router o metti il miner in whitelist prima di toccare qualsiasi altra cosa.

E una stranezza dei browser che genera infiniti falsi allarmi: AxeOS serve HTTP semplice sulla porta 80. I browser moderni convertono in silenzio gli indirizzi nudi in HTTPS, cosa che fallisce, e il miner sembra morto. Scrivi il prefisso esplicitamente: http:// davanti all’IP, ogni volta. Se continua a fallire, prova un altro browser e disattiva i blocchi pubblicitari per gli indirizzi locali.

Se il miner ha un IP ma non riesci ad aprire la dashboard: isolamento AP (vedi sopra), una stranezza della lista client del router, oppure mDNS. Il dispositivo si annuncia con un nome .local; quando più unità usano lo stesso nome, il firmware moderno aggiunge automaticamente un suffisso derivato dal MAC, ma cache mDNS obsolete sul tuo computer possono comunque puntare all’unità sbagliata. Nel dubbio usa l’IP grezzo dalla tabella DHCP del router e dai a ogni unità un nome diverso.

Problemi di stratum e pool: l’ultimo miglio

Il dispositivo si avvia, hasha, e la pool è il posto dove si decide la verità. In questa sezione la vista lato miner e quella lato pool vanno lette insieme.

Connessione rifiutata o irraggiungibile

Controlla in questo ordine:
1. URL esatta:  stratum+tcp://host:porta - niente https://,
                niente barra finale, porta presente e corretta
2. DNS:         un altro dispositivo sulla stessa LAN risolve
                l'host? Alcuni router degli operatori e i
                filtri DNS (o blocker tipo Pi-hole) mangiano i
                domini di mining in silenzio.
3. Porta:       alcune reti bloccano porte in uscita insolite.
                Prova da un hotspot del telefono: se lì
                connette, è la rete di casa che filtra.
4. Regione:     prova l'altro endpoint regionale della pool;
                potresti trovarti davanti a un disservizio di
                una singola regione.

L’authorize fallisce

La pool ha rifiutato il login. Su una pool solo lo username è il tuo indirizzo wallet più il nome del worker, e l’indirizzo è l’intera identità: non c’è nessun account da sbagliare. Cause: un indirizzo con un refuso (basta un carattere), un indirizzo della chain sbagliata (vedi sotto), un nome worker con spazi o caratteri speciali, oppure un campo password che la pool si aspetta non vuoto (usa x).

L’indirizzo della chain sbagliata: il killer silenzioso

L’errore di configurazione più dannoso del mining SHA-256 multi-chain, e può fallire in due modi diversi:

• Fallimento rumoroso: la pool valida il formato dell’indirizzo per chain e rifiuta l’authorize o ogni share. Fastidioso ma sicuro: te ne accorgi in pochi minuti.
• Fallimento silenzioso: un indirizzo formalmente valido su più di una chain, o una pool che non valida in profondità, accetta i tuoi share tutto il giorno, e poi il pagamento non può raggiungerti. Su una pool solo non custodial, le ricompense di blocco sono pagate coinbase-diretto alla stringa di indirizzo che hai configurato. Non esiste ticket di supporto che annulli una coinbase pagata a un indirizzo da cui non puoi spendere.

La regola: l’indirizzo deve essere nativo della chain a cui punti, generato da un wallet di quella chain e verificato. Se ruoti uno stesso miner fisico tra chain diverse, tieni una tabella scritta chain-indirizzo e ricontrolla il campo username ogni singola volta che cambi la URL stratum. Vale più di tutti gli altri consigli di questa sezione messi insieme.

Share rifiutati: leggere i motivi di rifiuto

I rifiuti non sono un problema solo; la stringa di motivo nel log ti dice quale dei quattro problemi hai.

"job not found" / stale       Hai inviato lavoro per un job
  a piccole raffiche subito   che la pool aveva già
  dopo i blocchi nuovi        sostituito: normale ai cambi di
                              blocco. Sotto il ~1-2% totale:
                              ignora. Costantemente più alto:
                              latenza di rete o perdita di
                              pacchetti WiFi; controlla l'RSSI,
                              prova la regione di pool più
                              vicina.

"above target" /              Lo share non raggiunge la
"low difficulty share"        difficoltà assegnata dalla pool.
                              Casi persistenti: uno sfasamento
                              dopo un cambio di difficoltà,
                              oppure errori hardware che
                              corrompono il risultato.
                              Controlla la % di errore HW.

"duplicate"                   Stesso nonce inviato due volte.
                              Occasionale: artefatto innocuo
                              di ritrasmissione. Un flusso
                              continuo: stato di guasto noto
                              in cui l'ASIC va in loop su un
                              nonce; il chip si è impuntato.
                              Ciclo di alimentazione; se si
                              ripete alle frequenze attuali,
                              riduci l'overclock.

tutto rifiutato               Configurazione, non sfortuna:
                              indirizzo della chain sbagliata,
                              nome worker malformato, oppure
                              porta sbagliata (es. una porta
                              ad alta difficoltà pensata per
                              ASIC grandi).

Percentuale di errore hardware: il numero onesto

L’hashrate della dashboard è un’affermazione; il tasso di errore hardware è una confessione. Conta i risultati restituiti dall’ASIC che non superano la verifica. Sotto il 2 per cento è sano. Tasso di errore che sale insieme alla temperatura significa termica; tasso che sale a temperatura costante dopo un cambio di impostazioni significa che il punto di frequenza e tensione è oltre il silicio di quel chip. Un chip al 5 per cento di errori può mostrare un hashrate orgoglioso mentre il tuo hashrate effettivo scende in silenzio sotto quello che darebbe una frequenza più bassa. Quando ottimizzi, punta agli share accettati all’ora, mai al numero della dashboard. Il metodo completo è nella sezione di tuning del riferimento BM1373, e il contesto su cosa significa la difficoltà di share nella spiegazione del best share.

«Il miner dice che hasha ma la pool non mostra nulla»

Il sintomo più postato in tutte le community, quindi ecco il percorso di risoluzione completo:

1. LATO POOL, tempo dall'ultimo share accettato:
   oltre 10 minuti = la connessione è morta ADESSO, qualunque
   cosa dica l'interfaccia del miner. Le medie della dashboard
   decadono nell'arco di ~un'ora e nascondono le disconnessioni
   recenti. «Hashrate sopra zero» NON è un test di presenza;
   «ultimo share recente» sì.

2. LATO MINER, log in tempo reale:
   Gli share vengono INVIATI? Se l'ASIC trova nonce ma non
   viene inviato niente, il socket stratum è impuntato:
   riavvia il miner.
   Gli invii danno ERRORE? Leggi la tabella dei motivi di
   rifiuto.

3. IDENTITÀ: la dashboard della pool che stai guardando è
   filtrata sullo stesso indirizzo wallet E sulla stessa
   moneta per cui è configurato il miner? Un numero
   sorprendente di questi casi è una dashboard BTC aperta
   mentre il miner punta a BCH, o la pagina di un indirizzo
   di test di ieri.

4. FALLBACK: c'è una pool di riserva configurata, e il miner
   ci è passato in silenzio? Il tuo hashrate potrebbe stare
   arrivando all'ALTRA pool. Controlla le sue statistiche.

Configura sempre il fallback

Ogni dispositivo della famiglia AxeOS supporta una pool di riserva. Un miner senza fallback che perde il socket stratum alle 2 di notte non fa nulla finché non te ne accorgi, e la media decrescente della dashboard fa in modo che te ne accorga tardi. Imposta il fallback su una seconda regione della tua pool, così un problema regionale non fermerà mai la macchina. Host e porte per regione di ogni chain sono sulla pagina di connessione.

Problemi di firmware: flashare, brickare, recuperare

L’OTA a due file e il mezzo brick

Gli aggiornamenti AxeOS arrivano in due artefatti: il binario del firmware e l’immagine dell’interfaccia web (www.bin). Un modo di guasto documentato è l’OTA che si blocca durante la fase www.bin, lasciando firmware e interfaccia disallineati: il dispositivo si avvia e mina ma la dashboard è vuota o rotta. Questo non è un brick. Vai direttamente alla URL di recupero:

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

e ricarica l’immagine web. Se il dispositivo non si avvia più affatto dopo un aggiornamento fallito, il web flasher USB (Chrome o Edge, cavo dati USB-C) riscrive l’immagine di fabbrica completa e recupera praticamente ogni soft-brick. Tre regole rendono il flash noioso invece che terrificante:

• Fai corrispondere l’immagine alla scheda esattamente, fino alla revisione. Il numero di revisione è stampato sul PCB stesso ed è mostrato nella sezione Sistema di AxeOS: un Supra 401 vuole l’immagine 401, non la 402. Conosci i due tipi di file della pagina delle release: quello completo esp-miner-factory-REV-vX.X.X.bin (bootloader + partizioni + interfaccia + firmware, per flash USB e recupero totale) e quello più piccolo esp-miner.bin (solo firmware, per OTA dalla dashboard). Usare uno al posto dell’altro è la ricetta classica del mezzo brick. Immagine Gamma su un Gamma, Ultra su un Ultra. Un’immagine sbagliata può lasciare una configurazione errata in NVS che sopravvive ai riflash normali; la cura è reset di fabbrica più immagine corretta.
• Non flashare mai via WiFi con connessione al limite o alimentazione al limite. Il blocco durante www.bin è correlato esattamente a queste due condizioni.
• Conosci il tuo bersaglio di rollback. Le regressioni capitano: una fascia di perdita telemetria attorno alla v2.13/v2.14, un cambio di curva ventole attorno alla v2.11 che faceva girare le unità più calde, un percorso di aggiornamento attorno alla v2.4.3 che si congelava su alcune revisioni hardware finché gli utenti non tornavano indietro. Prima di aggiornare annota la tua versione attuale; se la nuova si comporta male, la precedente è a un web-flash di distanza sulla pagina delle release del progetto.

Loop di crash: leggere un Guru Meditation

Un Guru Meditation Error è il kernel panic dell’ESP32. La parola tra parentesi è l’indizio:

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

LoadProhibited /       bug del firmware che tocca memoria non
StoreProhibited        valida: annota la versione, controlla
                       l'issue tracker, torna indietro di una
                       release
IllegalInstruction     flash corrotta o stack sovrascritto:
                       riflash completo via USB
Cache error /          di solito segue problemi di PSRAM
DoubleException        (più sotto)
Interrupt wdt timeout  un task è bloccato, spesso legato alla
                       rete; cerca una issue nota per la tua
                       versione

Un panic isolato: ignoralo. Un loop: capisci se è lo stesso motivo ogni volta (guasto firmware o hardware: agisci secondo la tabella) o se si alterna a messaggi di brownout (allora è l’alimentazione: smetti di leggere panic e vai a sistemare l’alimentatore).

Guasti PSRAM: la specialità della famiglia Nerd

NerdQaxe, NerdOctaxe e altre schede costruite sul modulo ESP32-S3-WROOM-1 usano PSRAM esterna. Un banner di avvio con un errore di lettura dell’ID PSRAM o un fallimento di inizializzazione, seguito da un panic StoreProhibited non appena il firmware tocca la RAM esterna, ha cinque radici note: moduli contraffatti senza die PSRAM, un firmware compilato con la modalità PSRAM sbagliata (octal invece di quad), saldatura fredda sotto il modulo, brownout durante la finestra di inizializzazione, oppure un die invecchiato. Il triage pratico: escludi prima l’alimentazione (come sempre), flasha l’immagine esatta del produttore per la tua scheda (che codifica la modalità PSRAM giusta), e se l’errore persiste con alimentazione pulita e firmware corretto, è il modulo stesso il colpevole, il che è un caso da garanzia o da banco.

Overclock andato male: recupero e prevenzione

La firma del guasto: frequenza o tensione alzate, e adesso l’unità crasha, si appiattisce dopo minuti o ore, va in throttling, oppure sparisce un chip da una scheda multichip. La fisica è impietosa su un punto preciso: l’instabilità da clock troppo alto spesso ci mette del tempo a manifestarsi. Un’impostazione che sopravvive a un test di 10 minuti può fallire al minuto 40, quando la scheda raggiunge la saturazione termica, ed è per questo che ogni affermazione di stabilità sotto le 24 ore è provvisoria.

RECUPERO (se l'unità si avvia ancora):
  Interfaccia web -> riporta frequenza e tensione ai valori di
  fabbrica -> salva -> ciclo di alimentazione a freddo (azzera
  eventuali fault agganciati).

RECUPERO (se va in loop prima che tu raggiunga l'interfaccia):
  Flasha l'immagine di fabbrica via USB: ripristina i punti di
  funzionamento di serie. Poi reset di fabbrica per svuotare
  la NVS.

PREVENZIONE (tutto il metodo in cinque righe):
  - uno scalino da 25 MHz alla volta, tensione intoccata
  - almeno 30 minuti per scalino, con l'occhio alla % errore HW
  - errore sopra il 2% = scendi di uno scalino; quello è il muro
  - solo allora alza la tensione a passi di 25 mV se accetti il
    calore in più; resta nella finestra 1100-1300 mV
  - 24 ore all'impostazione finale prima di dirla stabile

E una nota onesta: fare undervolt per efficienza fallisce esattamente come fare overclock per velocità, solo nella direzione opposta: troppa poca tensione per il clock produce gli stessi errori e gli stessi blocchi. La lotteria del silicio vale su entrambi i bordi.

Diagnosticare via API: la scorciatoia dell’utente esperto

Ogni miner della famiglia AxeOS espone una API REST sulla porta 80, e questo cambia l’aspetto del troubleshooting: nessun display necessario, nessun clic tra dashboard, e scala da una unità a una flotta. La specifica completa vive nel file openapi.yaml del repository ESP-Miner; queste sono le chiamate che contano per la diagnosi.

Le cinque chiamate diagnostiche

# Tutto insieme: medie di hashrate, temperature, tensione,
# potenza, RPM ventola, share, best difficulty, RSSI WiFi,
# uptime, versione firmware, heap libero
curl http://IP-DEL-MINER/api/system/info

# Stato dell'ASIC: modello, numero, frequenza, tensione
curl http://IP-DEL-MINER/api/system/asic

# La serie storica con cui sono disegnati i grafici
curl "http://IP-DEL-MINER/api/system/statistics?columns=hashrate,asicTemp,vrTemp,power"

# QUELLA SOTTOVALUTATA: scaricare i log da remoto.
# Niente cavo seriale, niente PuTTY: porta il log via rete e
# filtra le righe rosse del dizionario qui sotto.
curl http://IP-DEL-MINER/api/system/logs

# Quale è quale? Fa identificare il dispositivo da solo
# (display/LED): impagabile in uno scaffale di scatole
# identiche
curl -X POST http://IP-DEL-MINER/api/system/identify

Quell’endpoint dei log merita una frase a sé: la maggior parte della sezione sulla console seriale di questa guida si può fare dal divano con quella singola chiamata, purché il dispositivo si avvii abbastanza da servire HTTP. Il cavo seriale resta necessario solo per i guasti in fase di avvio e per i loop di crash.

Leggere /api/system/info come un meccanico

Sei campi di quel JSON rispondono alla maggior parte delle richieste prima ancora che vengano formulate:

CAMPO (nome tipico)       COSA TI DICE
hashRate / hashrate_10m   l'affermazione: confrontala con la pool
temp / asicTemp           il budget 55-62 C della sezione termica
vrTemp                    il lato regolatore: spesso il vero
                          limitatore su BM1370/BM1373
voltage                   il rail di ingresso COME LO VEDE LA
                          SCHEDA: un multimetro software. Se
                          scende sotto 4,9 V sotto carico =
                          alimentatore, dimostrato senza aprire
                          il case
power                     watt assorbiti: 2 W su un'unità «che
                          hasha» = la trappola USB-C
sharesAccepted /          la coppia della verità; rifiutati in
sharesRejected            crescita = tabella dei motivi
wifiRSSI                  più forte di -70 dBm è sano; più debole
                          spiega gli share scaduti
freeHeap                  che si restringe lentamente nei giorni
                          = la classe di bug da memory leak;
                          annota la versione, controlla il tracker

Salute della flotta in un ciclo

Con più di un’unità, smetti di controllare dashboard. Questo ciclo stampa un riassunto di salute su una riga per ogni miner e segnala quelli morti:

#!/bin/bash
# fleet-check.sh - adatta gli IP al tuo sciame
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  IRRAGGIUNGIBILE"
    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

Lancialo da cron ogni cinque minuti, mandalo alla notifica che preferisci, e un guasto alle 2 di notte diventa un allarme alle 2:05 invece di una sorpresa al mattino. I nomi dei campi variano leggermente tra le versioni di firmware; stampa il JSON grezzo una volta e adatta.

L’API sa anche riparare

# Riavviare senza toccare l'hardware
curl -X POST http://IP-DEL-MINER/api/system/restart
#   (ricorda: questo NON azzera un fault TPS546 agganciato,
#    per quello serve ancora lo scollegamento fisico)

# Riportare un esperimento di overclock a valori sensati
curl -X PATCH http://IP-DEL-MINER/api/system \
  -H "Content-Type: application/json" \
  -d '{"frequency": 525, "coreVoltage": 1150}'

# Sistemare una configurazione pool sbagliata senza interfaccia
curl -X PATCH http://IP-DEL-MINER/api/system \
  -H "Content-Type: application/json" \
  -d '{"stratumUser": "IL_TUO_WALLET.worker1"}'

Una precisazione onesta: l’API non ha autenticazione. Chiunque sulla tua LAN può leggere e riconfigurare i tuoi miner. Su una rete domestica di solito è accettabile; su una rete condivisa o accessibile agli ospiti, metti i miner su una VLAN o un segmento IoT dedicato: che è comodamente la stessa soluzione già consigliata nella sezione WiFi.

Particolarità per modello: conosci il carattere della tua scheda

Al di là dei modi di guasto universali, ogni famiglia di schede ha comportamenti caratteristici che conviene conoscere prima di metterci mano.

La tabella maestra dei sintomi

Il dizionario delle righe rosse

Le stringhe di errore che vedrai davvero, tutte in un posto, scritte alla lettera perché Ctrl+F le trovi. Trova la tua riga, ottieni la tua direzione.

RIGA NEL LOG                       SIGNIFICATO -> DOVE ANDARE
---------------------------------------------------------------
Brownout detector was triggered    tensione ceduta -> Alimentazione
rst:0x.. (BROWNOUT_RESET)          idem, nel banner di reset
Power Fault Detected               TPS546 agganciato -> Alimentaz.
TPS546 status / regulator fault    stessa famiglia -> Alimentazione
VCORE init failed /                il firmware non riesce a
  device ID mismatch               programmare il regolatore:
                                   immagine errata o I2C ->
                                   ASIC + Firmware
i2c_master_transmit_receive err /  bus sensori giù -> ASIC,
  ESP_ERR_TIMEOUT near boot          sottosezione I2C
Found 0 chip(s) / ASIC init fail   il chip non risponde -> ASIC
Chip count N of M                  rottura catena a N+1 -> ASIC
Device has overheated /            intervento a 75 C -> Termica
  Overheat Mode
VREG temp over limit               regolatore caldo -> Termica
wifi: NO_AP_FOUND                  visibilità 2,4 GHz -> Rete
wifi: AUTH_EXPIRE / auth fail      password sbagliata -> Rete
wifi: beacon timeout               segnale o canale debole -> Rete
wifi_disconnect reason: N          cerca N; risolvi per motivo
Stratum connection failed /        pool irraggiungibile -> Stratum
  connect errno
authorize failed                   login rifiutato -> Stratum,
                                   controlla indirizzo e worker
job not found (all'invio)          share scaduto -> Stratum
above target / low diff share      sfasamento difficoltà o err. HW
duplicate share                    nonce impuntato -> ciclo di
                                   alimentazione, poi ridurre clock
Guru Meditation Error: (MOTIVO)    panic -> Firmware, leggi la
                                   parola del motivo
esp_psram: PSRAM ID read error /   init PSRAM -> Firmware,
  Failed to init external RAM        sottosezione famiglia Nerd
E (xx) esp_image: checksum failed  flash corrotta -> riflash USB
[www.bin / UI vuota dopo update]   URL di recovery -> Firmware

Manutenzione preventiva: il rituale mensile da 15 minuti

Quasi tutto quello che precede costa meno prevenirlo che debuggarlo.

OGNI MESE
  [ ] Polvere: alette e pale della ventola (aria compressa,
      tenendo ferma la ventola)
  [ ] Controllo lato pool: andamento accettati contro rifiutati,
      e % errore HW ancora sotto il 2
  [ ] Occhiata alle temperature: deriva rispetto al mese scorso?
  [ ] Toccare fisicamente il connettore di alimentazione:
      tiepido è un avviso, caldo è uno stop

OGNI 6-12 MESI
  [ ] Sostituire la pasta termica (è un consumabile)
  [ ] Ispezionare i pin XT30 o jack per scolorimento
  [ ] Riverificare l'alimentatore sotto carico con il multimetro

A OGNI AGGIORNAMENTO FIRMWARE
  [ ] Leggere le note di rilascio PRIMA di flashare
  [ ] Annotare la versione attuale (il tuo bersaglio di rollback)
  [ ] Flashare con alimentazione stabile, se possibile vicino
      al router
  [ ] Ricontrollare la configurazione pool dopo: gli
      aggiornamenti possono azzerare dei campi

SEMPRE
  [ ] Pool di riserva configurata (seconda regione)
  [ ] Nomi worker distinti su tutta la flotta
  [ ] Tabella scritta: chain -> indirizzo wallet
  [ ] Impostazioni di fabbrica annotate prima di ogni tuning

Quando è davvero hardware: cosa si può riparare

Hai fatto il ciclo a freddo, il reset di fabbrica, il riflash dell’immagine corretta su alimentazione verificata, e il guasto resta. Questa è la definizione di problema hardware. La mappa realistica delle riparazioni:

• Riparabile al banco (aria calda, microscopio, mano ferma o un professionista): TPS546 o componenti dello stadio buck guasti, condensatori ceramici crepati, saldature fredde sotto l’ASIC o il modulo ESP32 (rifusione), connettori di alimentazione consumati, ventole morte. Sono routine per qualunque banco di riparazione ASIC.
• A volte recuperabile: una scheda con un corto franco sul rail a 5 V (quasi zero ohm verso massa, a spegnimento) — non continuare a dare tensione; il corto va prima trovato ed eliminato.
• Di solito irrecuperabile: un ASIC che ha girato senza contatto col dissipatore per più di qualche secondo, le conseguenze di una fuga termica, o un chip a cui è stata data la tensione di core sbagliata durante una riparazione improvvisata del VRM. Su una scheda a chip singolo il chip è quasi tutto il valore: oltre un certo punto, sostituire batte riparare.

L’aiuto della community vive sul Discord OSMU e sull’issue tracker GitHub di ESP-Miner: prima di aprire una segnalazione cerca nel tracker, perché una quota impressionante dei messaggi «la mia unità è rotta» sono issue note con una correzione già inclusa nella versione successiva. Quando segnali, una relazione completa ottiene risposta in poche ore mentre una vaga muore nel silenzio. Copia questo modello:

SCHEDA:     (modello esatto + revisione, es. Gamma 602)
FIRMWARE:   (versione AxeOS, da dashboard o /api/system/info)
ALIMENTAT.: (tensione, ampere, marca - e: misurato sotto carico?)
POOL:       (URL + porta + moneta)
SINTOMO:    (una frase: cosa succede, da quando)
INNESCO:    (cosa è cambiato subito prima: aggiornamento?
             trasporto? OC? rimontaggio dissipatore? niente?)
PROVATO:    (ciclo a freddo 60s? reset di fabbrica? riflash?
             frequenze di fabbrica? risultato dell'autotest?)
LOG:        (incolla il log di boot da seriale 115200 o da
             curl http://IP/api/system/logs - come minimo la
             prima riga E e dieci righe attorno)

Quel modello non è burocrazia: sono esattamente le informazioni che un banco di riparazione raccoglie per prime, nell’ordine in cui le raccoglie.

PRO: la sezione da banco — schemi, punti di misura e multimetro

Questa sezione dà per scontato che tu sappia leggere uno schema e sondare una scheda alimentata senza cortocircuitare pin adiacenti. Se quella frase ti ha fatto esitare, fermati qui: tutto quello che sta sopra questa riga si risolve senza aprire il case, e un puntale che scivola su una scheda viva a 3 nm trasforma un problema in due. Per tutti gli altri, è qui che l’hardware aperto ripaga.

Perché queste schede sono diverse da ogni altro miner

L’hardware Bitaxe è sotto licenza CERN-OHL-S e progettato in KiCad, e ogni schema, ogni layout di PCB e ogni distinta base è pubblico. Significa che non devi mai indovinare cos’è un componente o dove passa un rail: puoi aprire lo schema esatto della tua revisione esatta, trovare il net e misurarlo. Nessun proprietario di Antminer ha mai avuto questo privilegio. Ogni repository hardware porta inoltre una sezione che quasi nessuno apre: la pagina HW issues con bug noti, rework ed errata per revisione. Prima di diagnosticare qualsiasi guasto a livello scheda, controlla se la tua revisione ha un erratum documentato: una quota impressionante dei guasti hardware «misteriosi» è già scritta lì insieme alla modifica che li risolve.

Il metodo del multimetro: tre rail raccontano tutta la storia

I guasti del percorso di alimentazione si localizzano con tre misure in continua, prese in ordine. Riferimento a massa per primo, rispetta la sequenza, e misura sotto carico dove indicato.

RAIL 1 - INGRESSO (5 V o 12 V a seconda della famiglia)
  Dove:     connettore o piazzole di ingresso (vedi schema)
  Atteso:   famiglia 5 V:  4,9 - 5,3 V  MENTRE HASHA
            famiglia 12 V: 11,8 - 12,2 V MENTRE HASHA
  Basso solo sotto carico -> alimentatore o cavo (quasi sempre)
  Segna 0 con alimentatore buono -> protezione di ingresso
                                    bruciata o corto a valle:
                                    misura la resistenza verso
                                    massa A TENSIONE SPENTA;
                                    quasi zero ohm = corto,
                                    smetti di alimentare e
                                    cercalo

RAIL 2 - 3,3 V (l'alimentazione dell'ESP32)
  Dove:     net 3,3 V secondo lo schema (modulo ESP32)
  Atteso:   3,2 - 3,4 V stabili
  Assente con ingresso a posto -> il piccolo regolatore da
  3,3 V o i suoi passivi: spiega il «completamente morto,
  nessuna enumerazione USB» con un alimentatore dimostrato buono

RAIL 3 - VCORE (l'alimentazione dell'ASIC)
  Dove:     uscita dello stadio buck TPS546 / net di core
  Atteso:   circa 1,0 - 1,3 V, coerente col valore impostato
            in AxeOS
  Assente con ingresso e 3,3 V a posto -> lo stadio buck:
  fault agganciato (sempre ciclo a freddo per primo), oppure
  TPS546 / induttore / passivi circostanti guasti
  Presente ma con valore sbagliato -> programmazione del
  regolatore o comunicazione PMBus: confronta con quello che
  AxeOS crede di aver impostato

MISURE DI CONFERMA
  Continuità connettore di ingresso -> ingresso del regolatore:
  trova piste interrotte e saldature del jack crepate
  Temperatura del die del TPS546 dalla dashboard contro la mano
  avvicinata: un regolatore a cui non ti puoi avvicinare a
  riposo sta cedendo

Quei tre rail partizionano ogni guasto di alimentazione: ingresso cattivo = a monte della scheda; ingresso buono e 3,3 V cattivo = il regolatore piccolo; entrambi buoni e VCORE cattivo = lo stadio buck; tutti e tre buoni = il guasto non è di alimentazione, torna alla sezione ASIC. Dieci minuti con un multimetro da venti dollari sostituiscono ore di speculazione.

Cosa può e cosa non può fare un banco di riparazione

ROUTINE (aria calda + microscopio + mano ferma)
  - sostituzione del TPS546 o di componenti dello stadio buck
  - condensatori ceramici crepati (visivo: crepa sottile che
    attraversa il corpo; elettrico: corto o circuito aperto)
  - rifusione BGA sotto l'ASIC o il modulo ESP32 (la classe di
    guasto dopo caduta e dopo rimontaggio)
  - sostituzione di connettori (jack consumato, XT30 cotto)

POSSIBILE CON PAZIENZA
  - dare la caccia a un corto sul rail 5 V (termocamera o il
    trucco dell'evaporazione di alcol isopropilico sulle zone
    sospette)
  - sostituzione del modulo ESP32-S3 (richiede riflash dopo)

NON CONVIENE / IRRECUPERABILE
  - sostituire l'ASIC su schede a chip singolo: il chip è quasi
    tutto il valore della scheda e i chip donatori sono
    comunque di recupero; una scheda nuova vince su costo e
    su certezza
  - qualsiasi cosa dopo una fuga termica o un ingresso a
    polarità invertita su tutto il rail

Leggere lo schema come un tecnico riparatore

Tre abitudini che rendono gli schemi aperti davvero utili. Primo: trova la pagina dell’albero di alimentazione e traccia una volta su carta il percorso dall’ingresso a VCORE prima di sondare qualsiasi cosa; da quel momento conosci ogni componente in grado di uccidere il rail. Secondo: annota le sigle (R12, C34, U3) dello stadio buck; i post nei forum e gli errata si riferiscono ai componenti per sigla, e ritrovarli sulla tua scheda richiede secondi con il file di layout aperto. Terzo: confronta le revisioni quando un guasto è specifico di una revisione; il changelog tra, poniamo, un Gamma 600 e un 601 ti dice esattamente cosa hanno corretto i progettisti, che spesso è esattamente ciò che cede sul più vecchio.

La biblioteca di risorse open source

Tutte le fonti primarie in una tabella. Metti questa sezione nei preferiti: metà del valore dell’hardware aperto sta nel sapere dove vivono gli originali, e ogni link qui sotto è la fonte ufficiale, non un mirror.

Punti chiave

• Sei domini coprono quasi ogni guasto: alimentazione, ASIC, termica, rete, stratum, firmware. Il triage da 60 secondi ti dice in quale sei prima che tu tocchi qualsiasi cosa.
• L’alimentazione è la causa numero uno e l’impostore numero uno: si traveste da crash WiFi, panic del firmware, chip impuntati e schede morte. Misura l’ingresso sotto carico prima di credere a qualsiasi altra teoria.
• Un fault agganciato del regolatore sopravvive a ogni riavvio software. Staccare fisicamente per 10-60 secondi è un vero passo diagnostico, non superstizione.
• L’USB-C alimenta l’ESP32, mai l’ASIC. Una scheda solo su USB-C imita alla perfezione un miner morto a 0 GH/s.
• Impara la console seriale a 115200 baud. La prima riga E in un log di boot dà un nome al tuo problema più in fretta di qualsiasi thread di forum.
• L’autotest integrato dà un nome al sottosistema guasto in 30 secondi, e l’API REST porta log, telemetria e persino la soluzione via rete: usali entrambi prima di cercare un cavo seriale.
• Non collegare mai un alimentatore da 12 V a una scheda da 5 V. Gli spinotti sono intercambiabili; le schede no.
• L’ESP32 parla solo 2,4 GHz; band steering e isolamento AP sono le due funzioni dei router che rompono più installazioni.
• La verità lato pool batte l’ottimismo lato miner: il tempo dall’ultimo share accettato è l’unico test onesto di presenza, e 10 minuti è la soglia.
• L’indirizzo wallet deve essere nativo della chain che stai minando. Su una pool non custodial questo è l’unico errore senza via di ritorno.
• La percentuale di errore hardware è il numero onesto sulle prestazioni; l’hashrate della dashboard è un’affermazione. Ottimizza verso gli share accettati e pretendi 24 ore prima di definire stabile una qualsiasi impostazione.
• Un connettore di alimentazione caldo è l’unico sintomo che significa fermarsi adesso, non fare debug dopo.

Compilato dall’issue tracker e dalle note di rilascio di ESP-Miner, dalla documentazione ESP-IDF sugli errori fatali, dalla documentazione dei banchi di riparazione della community e dagli schemi di guasto ricorrenti segnalati nelle community Bitaxe, NerdAxe e NerdQaxe, al 20 luglio 2026. Il comportamento del firmware descritto qui (aggancio dei fault, soglie di surriscaldamento, URL di recupero, fasce di regressione note) riflette le versioni di AxeOS ed ESP-Miner correnti alla pubblicazione; controlla le note di rilascio della tua. Questa guida è mantenuta come riferimento vivo: se incontri un modo di guasto non coperto qui, segnalacelo dalla pagina dei contatti e lo aggiungeremo.