Bitaxe Hardware-Fehler erkennen: Power Fault, Selbsttest und Chip count 0 richtig deuten

Ein Bitaxe meldet Hardware-Probleme an drei Stellen: auf dem kleinen Display, als rote Zeile im Dashboard von AxeOS und im Log. Die Texte sind kurz, englisch und manchmal irreführend. „Power Fault Detected. Check your Power Supply.“ erscheint zum Beispiel auch dann, wenn das Netzteil völlig in Ordnung ist. Dieser Artikel ordnet jede Hardware-Meldung von AxeOS ein: was sie technisch bedeutet, in welchem Bauteil sie entsteht und was du prüfst, bevor du an einen Defekt denkst. Grundlage sind der Quellcode von AxeOS 2.15.4, der aktuellen Version vom 21. Oktober 2026 (in 2.15.3 ist dieser Teil identisch), das Datenblatt des Spannungsreglers TPS546D24A von Texas Instruments und die offenen Hardware-Dateien des Bitaxe Gamma. Eigene Messreihen stecken nicht darin. Wo wir aus dem Code Schlüsse ziehen, die niemand gemessen hat, steht das dabei.

• Welche Meldung bedeutet was?
• In fünf Schritten zur Ursache
• Wo die Fehler entstehen: der Strompfad im Gamma
• „Power Fault Detected“: was der Spannungsregler meldet
• Spannung unter Last prüfen: die Pausen-Methode
• Der Selbsttest: was er prüft und wie du ihn startest
• „ASIC 0 not found“ und Chip count 0
• Überhitzung: Chip, Regler und der Schutz von AxeOS
• Lüfter: „Fan Control Failed“ und FAN:WARN
• Neustarts: was Reset Reason verrät
• Wann es ein Fall für den Support ist
• Häufige Fragen

Welche Meldung bedeutet was?

Die Tabelle sammelt die Hardware-Meldungen, die AxeOS 2.15.4 auf Gamma, GT, Supra Hex und Gamma Hex zeigen kann, und sagt, wo du sie siehst. Die Texte stehen genau so im Quellcode, nur Zahlen und Chipnummern ändern sich je nach Gerät. Meldungen zu Pool und WLAN wie „Using fallback pool“ fehlen hier, die erklärt Bitaxe mined nicht. Wo welche Karte und Seite in AxeOS liegt, zeigt AxeOS erklärt. Nerdaxe, NerdQaxe und NerdOctaxe laufen mit NerdOS und melden Fehler mit eigenen Texten; für sie gelten die Grundlagen zum Strompfad, nicht die einzelnen Meldungen.

In fünf Schritten zur Ursache

Bei Hardware-Meldungen lohnt eine feste Reihenfolge. Jeder Schritt schließt eine ganze Gruppe von Ursachen aus oder bestätigt sie, und die ersten vier brauchen nur einen Browser im selben Netz wie der Miner.

1. Meldung festhalten. Fotografiere Display und Dashboard, bevor du neu startest. Ein Power Fault verschwindet mit dem Neustart, auch wenn seine Ursache bleibt.
2. Log sichern und lesen. Auf der Seite Logs lädst du das Protokoll mit „Download Logs“ herunter. Es liegt im Zusatzspeicher (PSRAM) des ESP32 und übersteht laut Code einen Neustart per Software, auch einen Absturz; nach dem Ziehen des Netzteils ist es leer. Such nach „TPS546“ für den Spannungsregler, nach „OVERHEAT“ für den Hitzeschutz, nach „chip(s) detected“ für die Chiperkennung und nach „Fan Control“ für den Lüfter.
3. Reset Reason ansehen. Die Seite System nennt den Grund des letzten Neustarts. Ein Brownout zeigt auf die Stromversorgung, ein Watchdog oder Absturz auf die Firmware.
4. Spannung unter Last prüfen. Mit der Pausen-Methode siehst du in zwei Minuten, wie viel Spannung Netzteil, Kabel und Stecker unter Last verlieren.
5. Selbsttest laufen lassen. Er prüft mit Werkswerten, ohne Pool und ohne WLAN, ob Chip, Regler, Sensor und Lüfter arbeiten.

Erst wenn der Selbsttest mit Werkseinstellungen und dem mitgelieferten Netzteil scheitert, spricht viel für einen Defekt der Platine. Was du dann dem Support schickst, steht am Ende. Wer lieber Schritt für Schritt gefragt werden möchte, nimmt die Miner-Diagnose; sie deckt auch Probleme mit WLAN und Pool ab.

Wo die Fehler entstehen: der Strompfad im Gamma

Für die Fehlersuche reicht ein grobes Bild der Platine. Wir nehmen den Bitaxe Gamma als Beispiel, weil seine Schaltpläne offen auf GitHub liegen und er das Einsteigermodell der Familie ist.

Strom kommt über einen runden Hohlstecker 5,5 × 2,1 mm mit 5 V, Plus innen. Die Hardware-Dokumentation des Projekts ist dabei deutlich: „5V DC Only! Anything else will damage the Bitaxe.“ Das Netzteil soll mehr als 4 A (20 W) liefern, ohne unter 5 V zu fallen; empfohlen werden 25 bis 30 W.

Von der Buchse gehen zwei getrennte Wege ab. Der erste führt zum Spannungsregler TPS546D24A. Er macht aus 5 V die Kernspannung des Rechenchips, ab Werk 1,15 V. Laut Datenblatt verträgt er 2,95 bis 16 V am Eingang und bis zu 40 A am Ausgang, mehrere lassen sich bis 160 A zusammenschalten. Über einen Zweidraht-Bus, den PMBus, meldet er dem ESP32 Eingangsspannung, Ausgangsspannung, Strom, seine eigene Temperatur und jeden Fehler. Fast alle Strom-Meldungen in AxeOS stammen von ihm.

Der Rechenchip BM1370 hat 2040 kleine Rechenkerne in vier Rechenbereichen, die AxeOS in der Karte „Hashrate Registers“ einzeln anzeigt; wie du sie liest, steht in Hashrate Error beim Bitaxe. Zwei kleine Linearregler erzeugen zusätzlich 1,2 V und 0,8 V für ihn. Mit dem ESP32 spricht er über eine serielle Leitung (UART); dazwischen sitzen Pegelwandler, weil beide Seiten mit unterschiedlichen Spannungen arbeiten. Den Takt gibt ein 25-MHz-Oszillator vor.

Der zweite Weg führt über einen eigenen 3,3-V-Regler zum ESP32-S3. Er führt AxeOS aus, hält das WLAN, steuert das Display und liest die Sensoren. Daraus folgt eine wichtige Regel für die Diagnose: Leuchtet das Display und ist AxeOS erreichbar, hat der ESP32 Strom. Über den Rechenchip sagt das nichts. Bei einem Power Fault läuft der ESP32 weiter und kann den Fehler melden. Bricht die Eingangsspannung dagegen so tief ein, dass auch der ESP32 ausgeht, startet er neu und meldet einen Brownout.

Der Baustein EMC2101 steuert den Lüfter und misst die Chiptemperatur über eine Diode im BM1370. Antwortet er nicht, meldet AxeOS ungültige Temperaturen oder „Fan Control Failed“. Der Lüfter ist ein 40-mm-Modell mit vier Pins und 5-V-PWM.

Die anderen Modelle folgen demselben Prinzip mit 12 V am Eingang. Der Bitaxe GT hat zwei Chips und einen zweiphasigen Regler, der Gamma Hex 1300 sechs Chips und einen vierphasigen. Beim Supra Hex 702 liegen drei Spannungsbereiche in Reihe, sein Regler liefert deshalb rund das Dreifache der Chipspannung. Die Meldungen sind dieselben, nur die Grenzwerte unterscheiden sich.

„Power Fault Detected“: was der Spannungsregler meldet

Hinter der Meldung steckt eine einzige Abfrage. AxeOS liest laufend das Statuswort des TPS546, ein 16-Bit-Register nach dem PMBus-Standard. Ist darin eins von fünf Bits gesetzt, gilt das als Power Fault: Regler aus (OFF), Überspannung am Ausgang (VOUT_OV), Überstrom am Ausgang (IOUT_OC), Unterspannung am Eingang (VIN_UV) oder ein Temperaturproblem (TEMP). Das Dashboard schreibt in allen fünf Fällen denselben Satz, denn der Text ist in der Firmware fest hinterlegt. Welcher Fall vorliegt, verrät nur das Log: Beim ersten Auftreten schreibt AxeOS einmal eine Momentaufnahme aller Statusregister und je gesetztem Bit eine Klartextzeile.

Ein sechstes Bit für Kommunikations-, Speicher- und Logikfehler (CML) landet zwar als „A communication, memory, logic fault has occurred“ im Log, löst aber keinen Power Fault aus.

Die fünf Abschaltgründe im Log

Filtere die Seite Logs nach „TPS546“. Die erste Zeile lautet „Status: 0x…“, danach folgen die Erklärungen:

Bei Unterspannung, Überstrom und Überspannung steht „The voltage regulator is turned off“ meist zusätzlich im Log, weil der Regler in diesen Fällen abschaltet. Entscheidend ist die Zeile, die daneben steht.

Grenzwerte des Reglers je Modell

Die Schwellen schreibt AxeOS beim Start in den Regler. So stehen sie in der Firmware 2.15.4:

Die Temperaturgrenzen sind bei allen gleich: Warnung ab 105 °C, Abschaltung ab 145 °C. Die Überspannungsgrenze am Eingang ist eine Schutzschwelle, keine Erlaubnis. Ein 12-V-Netzteil gehört nie an einen Gamma, auch wenn der Stecker passt. Welches Netzteil zu welchem Modell gehört und warum Gaia und Gamma denselben Stecker bei verschiedener Spannung haben, steht in Netzteil für Bitaxe.

Der Überstromwert wirkt hoch, weil er auf der Ausgangsseite gilt: Bei 1,15 V fließt dort ein Vielfaches des Netzteilstroms. Ein Rechenbeispiel mit den Werkswerten des Gamma: AxeOS zeigt 15 bis 19 W Leistung. Darin stecken pauschal 5 W für den Rest der Platine (mehr dazu im nächsten Abschnitt), am Chip kommen also 10 bis 14 W an. Geteilt durch 1,15 V sind das rund 9 bis 12 A. Bis zur Abschaltung bei 30 A ist damit mehr als das Doppelte Luft. Wer dort ankommt, hat Takt und Spannung weit über die Werkswerte gehoben.

Warum die Meldung bis zum Neustart bleibt

Die Fehlerbits des TPS546 sind gespeichert. Laut Datenblatt bleiben sie gesetzt, bis der Befehl CLEAR_FAULTS sie löscht; besteht die Ursache dann noch, setzt der Regler sie sofort wieder. AxeOS schickt diesen Befehl nur beim Start: Es schaltet den Regler aus, löscht die Fehler und schaltet ihn mit der eingestellten Spannung wieder ein. Daraus folgt:

• Ein Power Fault verschwindet erst mit einem Neustart, auch wenn die Ursache längst weg ist, etwa ein kurz wackelnder Stecker.
• Kommt er nach dem Neustart sofort wieder, ist die Ursache dauerhaft: eine ungültige Kernspannung, ein Netzteil, das schon beim Anlaufen einbricht, oder ein defekter Regler.
• Kommt er erst nach Minuten unter Last, spricht das für Unterspannung unter Last oder Wärme.
• Nach einem Überstrom bleibt der Regler aus. AxeOS stellt ihn so ein, dass er in diesem Fall ohne Wiederanlauf abschaltet. Bei Übertemperatur wartet er dagegen, bis er abgekühlt ist, und läuft von selbst wieder an.

Die Falle unter 1000 mV

Eine Ursache für einen Power Fault hat mit dem Netzteil gar nichts zu tun und lässt sich selbst beheben. Der Regler des Gamma nimmt nur Kernspannungen von 1,0 bis 2,0 V an. Fordert AxeOS weniger an, steht im Log „Voltage requested (0.980000 V) is out of range“, der Regler bleibt aus, und das Dashboard meldet „Check your Power Supply“. Weil der Chip ohne Kernspannung nicht antworten kann, zeigt das Display nach dem nächsten Start zusätzlich „ASIC 0 not found“; das folgt aus der Startreihenfolge im Code.

Dahin kommt ein Gamma auf zwei Wegen: Jemand stellt beim Undervolting weniger als 1000 mV ein, oder der Überhitzungsschutz zieht von einem knappen Wert pauschal 100 mV ab. Bis einschließlich AxeOS 2.15.4 wird so aus jedem Wert unter 1100 mV nach einer Überhitzung einer unter 1000 mV, und weil AxeOS den gesenkten Wert speichert, bleibt der Fehler auch nach jedem Neustart. Die Korrektur steckt seit September 2026 im Entwicklungszweig (Pull Request 1790), in einem Release noch nicht. Abhilfe: unter Settings die Core Voltage auf mindestens 1000 mV setzen, Save, Restart.

Spannung unter Last prüfen: die Pausen-Methode

Ob Netzteil, Kabel und Stecker genug Reserve haben, zeigt AxeOS selbst, wenn du zwei Werte vergleichst: die Eingangsspannung ohne Last und mit Last. Der Regler misst sie an seinem Eingang, also hinter Netzteil, Kabel und Buchse. Der Unterschied ist der Spannungsverlust auf genau diesem Weg.

1. Lies im Dashboard in der Karte Power die Input Voltage ab, während der Miner rechnet. Warte dafür einige Minuten nach dem Start.
2. Pausiere das Mining mit dem Symbol „Pause Mining“ oben rechts. AxeOS schaltet dabei die Kernspannung ab, der Chip zieht keinen Strom mehr. Lies die Input Voltage nach einigen Sekunden erneut ab.
3. Setz das Mining mit „Resume Mining“ fort und notiere beide Werte. Im Diagramm kannst du zusätzlich die Kurve „Voltage“ einblenden und den Verlauf über Stunden sehen.

Ändert sich der Wert während der Pause nicht, miss die Spannung des Netzteils ohne Last mit einem Multimeter am Hohlstecker, Plus innen, Minus außen. Das ersetzt den Wert aus Schritt 2.

Rechenbeispiel: Wie viel Reserve hat die Leitung?

Ein Beispiel mit angenommenen Werten, keine Messung: pausiert 5,15 V, beim Rechnen 4,90 V, Leistung laut AxeOS 17 W.

Den Strom aus dem Netzteil zeigt AxeOS nicht direkt. „Current“ in der Karte Power ist beim Gamma der Strom am Ausgang des Reglers, also auf der Seite des Chips, und „Power“ ist dessen Ausgangsleistung plus pauschal 5 W für den Rest der Platine. Beides steht so im Quellcode. Die Schätzung über Leistung geteilt durch Spannung ist deshalb grob, für eine Abschätzung reicht sie.

Auch das Modell ist vereinfacht: Es behandelt Netzteil und Leitung wie einen festen Widerstand. Echte Netzteile regeln nach, und sehr kurze Einbrüche erfasst die Anzeige nicht. Als Maßstab taugt die Vorgabe aus der Hardware-Dokumentation: unter Last nicht unter 5 V. Das Beispiel mit 4,90 V verfehlt sie knapp. Dann hilft zuerst ein kurzes, kräftiges Kabel und ein fest sitzender Stecker, danach ein stärkeres Netzteil. Wie Kabellänge und Querschnitt den Verlust bestimmen und was bei mehreren Minern an einem Netzteil gilt, rechnet Netzteil für Bitaxe vor.

Der Selbsttest: was er prüft und wie du ihn startest

Der Selbsttest ist das beste Werkzeug, um Hardware von Einstellungen zu trennen. Er läuft unabhängig von deinen Einstellungen mit den Werkswerten des Chips, braucht weder WLAN noch Pool, weil er sich selbst einen Rechenauftrag erzeugt, und prüft Chip, Regler, Temperatursensor und Lüfter nacheinander. Beim Gamma rechnet der Chip dabei mit 525 MHz und 1150 mV, auch wenn du sonst übertaktest.

Selbsttest starten

Es gibt zwei Wege. Automatisch nach einem Factory Reset: Spielst du die Firmware mit flasher.bitaxe.de und der Installationsart „Factory Reset“ auf, ist der Speicher frisch. Beim ersten Start findet AxeOS dann ein gesetztes Selbsttest-Merkmal und noch keinen einzigen Share und startet den Werkstest; danach richtest du den Miner neu ein wie in Bitaxe Gamma einrichten. Von Hand mit der Taste BOOT: AxeOS prüft genau einmal beim Start, ob BOOT gedrückt ist, und zwar kurz nachdem Speicher, Gerätekonfiguration und Sensorbus bereit sind. So triffst du den Moment:

1. Netzteil einstecken oder RESET drücken und loslassen.
2. Direkt danach BOOT drücken und gedrückt halten.
3. Loslassen, sobald „BITAXE SELF-TEST“ auf dem Display steht.

Zwei Fallen gibt es dabei. Hältst du BOOT schon beim Einstecken gedrückt, startet der ESP32 im Flash-Modus, denn die Taste hängt an GPIO0, und dieser Pin entscheidet beim Einschalten über die Startart. Das Display bleibt dann dunkel; Netzteil ziehen und mit etwas späterem Druck wiederholen. Drückst du zu spät, startet der Miner normal. Wer BOOT dann zwei Sekunden hält, schaltet das Einrichtungs-WLAN ein oder aus; ein weiterer langer Druck oder ein Neustart stellt das zurück.

Die zwölf Prüfungen der Reihe nach

Der Selbsttest bricht bei der ersten gescheiterten Prüfung ab und zeigt ihr Kürzel. Zwölf Prüfungen kennt AxeOS 2.15.4. Beim Gamma laufen zehn davon, weil seiner Platine die Bausteine für zwei Prüfungen älterer Boards fehlen.

Schon vor der ersten Prüfung muss die Chiperkennung beim Start geklappt haben. Antwortet der Chip nicht, zeigt der Selbsttest sofort deren Meldung, etwa „ASIC 0 not found“, und bricht ab. Dasselbe gilt für Bausteine, die beim Start nicht reagieren: Dann steht dort zum Beispiel „THERMAL:FAIL“ für den Temperatur- und Lüfterbaustein oder „DISPLAY:FAIL“.

Während der 30 Sekunden zeigt das Display eine Zeile im Format „1043 Gh/s 64.8°C 12s“: Hashrate, Temperatur und verbleibende Sekunden; die Zahlen hier sind nur ein Beispiel. Am Ende steht „SELF-TEST PASS!“ mit dem Countdown „Restarting in 10...“, danach startet der Miner normal. „VCORE:FAIL“ kann übrigens zwei Dinge heißen: beim Start, dass der Regler nicht antwortet, und in Prüfung 10, dass die gemessene Kernspannung außerhalb des Fensters liegt. Das Log unterscheidet die beiden („VCORE init failed“ gegen „Core voltage test failed“).

Grenzwerte je Modell

Die Grenzen rechnet AxeOS aus den Werkswerten: Takt mal Zahl der kleinen Rechenkerne mal Zahl der Chips ergibt die erwartete Hashrate, davon müssen beim BM1370 85 % und beim BM1368 80 % erreicht werden. Jeder Rechenbereich darf um ein Drittel vom Durchschnitt abweichen, die Kernspannung je Chip um 10 %. Die Leistungsgrenze ist ein fester Zielwert je Board plus 3 W Spielraum, beim Gamma Hex plus 21 W.

Zum Nachrechnen am Gamma: 525 MHz × 2040 Kerne ergibt 1071 GH/s, die Expected-Hashrate im Dashboard. 85 % davon sind 910 GH/s. Gamma 602 und 603 bekommen 3 W mehr Spielraum als der 601; laut Firmware ist das im Selbsttest der einzige Unterschied der Revisionen.

Ergebnis lesen und den Test beenden

Besteht der Miner, startet er nach zehn Sekunden von selbst neu, und ein Werkstest gilt danach als erledigt. Scheitert er, bleibt das Ergebnis stehen, und die Zeile darunter sagt, wie es weitergeht:

• Nach dem Start mit BOOT: „Press RESET button to restart.“ Ein Druck auf RESET startet den Miner normal.
• Beim Werkstest nach einem Factory Reset: „Hold BOOT button for 2 seconds to cancel self-test, or press RESET to run self-test again.“ Hier startet RESET den Test erneut, und das bei jedem Neustart, bis er bestanden ist. Hältst du BOOT zwei Sekunden, löscht AxeOS das Merkmal, und der Miner startet normal.

Das erklärt einen Miner, der nach jedem Neustart wieder „BITAXE SELF-TEST“ zeigt: Er hängt nicht, er wiederholt einen gescheiterten Werkstest. Das Kürzel auf dem Display nennt den Grund.

Was der Selbsttest nicht beweist

• Die Eingangsspannung misst er beim Gamma nicht. Prüfung 3 gibt es nur auf älteren Boards. Ein schwaches Netzteil fällt nur auf, wenn es in der halben Minute so weit einbricht, dass der Regler abschaltet. Für Netzteilfragen ist die Pausen-Methode besser.
• Er prüft nur die Werkswerte. Ob dein Chip deine Übertaktung schafft, sagt er nicht.
• Er dauert eine halbe Minute. Fehler, die erst nach Stunden unter Wärme auftreten, findet er nicht.
• Sehr starke Kühlung kann ihn stören. Die Aufwärmphase hat kein Zeitlimit: Erreicht der Chip bei 10 % Lüfter keine 55 °C, etwa in einem kalten Raum oder unter einem großen Kupferkühler, steht „ASIC Temp: …“ beliebig lange auf dem Display. Und weil der Lüfter danach auf 65 °C regelt und bis auf 10 % herunter darf, kann er bei sehr guter Kühlung die Drehzahlgrenze verfehlen und FAN:WARN melden. Beides folgt aus dem Code; ob es mit einem bestimmten Kühler eintritt, haben wir nicht gemessen. Dann den Test in einem wärmeren Raum wiederholen.

„ASIC 0 not found“ und Chip count 0

Die Meldung klingt nach einem toten Chip. Sie heißt aber zunächst nur, dass beim Start kein Chip auf die Abfrage seiner Kennung geantwortet hat.

So erkennt AxeOS den Chip

Beim Start setzt der ESP32 den Chip über seine Reset-Leitung zurück und schickt über die serielle Leitung eine Rundfrage. Jeder Chip antwortet mit seiner Kennung, der BM1370 mit 0x1370, und AxeOS zählt die gültigen Antworten. Bei mehreren Chips laufen Daten, Takt und Reset von Chip zu Chip weiter, die Platine bildet eine Kette. Stimmt die Zahl nicht, steht im Log:

0 chip(s) detected on the chain, expected 1
ASIC 0 not found
ASIC initialization failed - chip chain detection failed

Das Display zeigt „ASIC STATUS:“ und darunter die Meldung als Laufschrift. Das Mining startet nicht, der Rest von AxeOS läuft weiter, das Dashboard bleibt also erreichbar. Bei mehreren Chips nennt die Meldung die fehlenden Nummern, etwa „ASIC 2,3,4,5 not found“, wenn beim Supra Hex nur zwei von sechs antworten. Vorsicht bei der Deutung: AxeOS zählt nur Antworten und weiß nicht, welche Chips geantwortet haben. Weil die Signale durch die Kette laufen, liegt die Unterbrechung aber wahrscheinlich hinter dem letzten Chip, der noch antwortet.

Falsche Firmware oder falsches Board

Steht im Log „CHIP_ID response mismatch: expected 0x1368, got 0x1370“, antwortet ein BM1370, die Firmware erwartet aber einen BM1368. Dann läuft eine Firmware oder Board-Version für ein anderes Gerät, in diesem Beispiel für einen Supra auf einem Gamma. Der Chip ist in Ordnung. Dasselbe gilt für „Unexpected ASIC 1 detected“: Es antworten mehr Chips, als die Board-Version vorsieht. Prüf auf der Seite System die „Board Version“, beim Gamma 601, 602 oder 603, und spiel bei einer Abweichung die passende Firmware mit dem Flasher und „Factory Reset“ neu auf. Wie das geht, zeigt die Update-Anleitung für AxeOS.

Wenn die Board-Version stimmt

Dann fehlt dem Chip eine seiner Voraussetzungen: Kernspannung, die beiden Hilfsspannungen, der Takt, ein sauberes Reset-Signal oder die serielle Verbindung. Am einfachsten auszuschließen ist die fehlende Kernspannung. Sieh im Log nach, ob davor ein Power Fault oder „Voltage requested … is out of range“ steht. Ohne Kernspannung kann der Chip nicht antworten, und die Erkennung meldet ihn als fehlend, obwohl er heil ist.

1. Netzteil ganz ziehen, zehn Sekunden warten, wieder einstecken.
2. Unter Settings Core Voltage und Frequency auf die Einträge mit „(Default)“ stellen, Save, Restart.
3. Board Version prüfen, notfalls einen Factory Reset mit dem Flasher machen.
4. Den Selbsttest starten. Zeigt er wieder „ASIC 0 not found“, ist der Fehler reproduzierbar.
5. Die Platine ansehen: Brandspuren, abgerissene Bauteile oder Schäden an der Buchse sind ein klarer Fall für den Support.

Bleibt „ASIC 0 not found“ mit Werkswerten, richtiger Firmware und ohne Power Fault, liegt der Fehler auf der Platine. Mit Hausmitteln ist dann nichts mehr zu prüfen; der nächste Schritt ist der Support.

Überhitzung: Chip, Regler und der Schutz von AxeOS

AxeOS beobachtet zwei Temperaturen: die des Chips, beim Gamma über eine Diode im BM1370 gemessen, und die des Spannungsreglers, die der TPS546 selbst meldet (VR Temp). Ab 70 °C am Chip oder 105 °C am Regler warnt das Dashboard mit „Danger: High Temperature“. Über 75 °C am Chip oder über 105 °C am Regler greift der Schutz.

Was dann passiert und wie du danach aufräumst, beschreibt Bitaxe leiser machen Schritt für Schritt. Kurz: AxeOS stoppt das Mining, schaltet die automatische Lüftersteuerung aus und den Lüfter auf 100 %, wartet mindestens 30 Sekunden und bis der Regler unter 95 °C liegt, und rechnet dann mit 100 MHz weniger Takt und 100 mV weniger Spannung weiter. Beides speichert es. Für die Diagnose sind drei Punkte wichtig:

• Die Werte bleiben gesenkt. Jede weitere Auslösung senkt erneut. Eine Hashrate weit unter Expected nach einer Überhitzung ist deshalb kein Defekt, sondern der gesenkte Takt.
• Die 1000-mV-Falle. Aus Kernspannungen unter 1100 mV wird beim Gamma ein Power Fault, siehe oben.
• Falscher Alarm durch Sensorfehler. Ein offener Fehlerbericht beschreibt, dass der Schutz auch auf Fehlercodes der Sensoren reagiert (Issue 2000): Eine offene Messdiode liest der Lüfterbaustein als genau 127 °C, ein gestörter Sensorbus lieferte dort „OVERHEAT! VR: 16384.000000C ASIC: 64.250000C“. Auslöser war laut Bericht ein defektes Display, das am selben Bus hängt. Unplausible Werte in der OVERHEAT-Zeile sind also ein Hinweis auf Bus oder Sensor, nicht auf Hitze.

Zum Regler: Für den Dauerbetrieb nennt der Overclocking-Guide bis 85 °C als gut. Steigt VR Temp, während die Chiptemperatur normal bleibt, helfen weniger Takt und weniger Spannung am schnellsten, weil dann weniger Strom durch den Regler fließt und er weniger Verlustwärme erzeugt. NerdOS auf Nerdaxe und NerdQaxe hat eigene Grenzen und Meldungen wie „MINER OVERHEATED“ und „VREG OVERHEATED“; die stehen ebenfalls im Overclocking-Guide.

Lüfter: „Fan Control Failed“ und FAN:WARN

Der Lüfter fällt in AxeOS auf drei Arten auf:

• „Fan Control Failed (Auto)“ im Dashboard. Die Firmware wollte die Drehzahl setzen, und der Lüfterbaustein EMC2101 hat den Befehl nicht angenommen. Das ist ein Kommunikationsfehler auf der Platine, kein müder Lüfter. AxeOS wertet ihn als Hardwarefehler und stoppt das Mining, damit der Chip nicht ungekühlt rechnet. In Klammern steht die Betriebsart, in der es passiert ist, etwa Auto, Manual oder Startup. Im Log heißt es „FATAL: Fan Control Failed (Auto). Flagging hardware fault.“ Ein Neustart setzt den Fehler zurück; kommt er wieder, ist es ein Fall für den Support.
• 0 U/min bei laufendem Mining in der Karte Fan oder im Diagramm „Fan RPM“. Der Baustein arbeitet, aber der Lüfter dreht nicht oder sein Drehzahlsignal fehlt: Stecker, Kabel, ein blockierter oder verschlissener Lüfter. Bleibt der Chip dabei normal warm, fehlt eher nur das Drehzahlsignal; steigt die Temperatur, steht der Lüfter wirklich.
• FAN:WARN im Selbsttest. Die Drehzahl lag am Ende des Tests unter der Grenze, 1000 U/min, beim GT und Gamma Hex 500 U/min. Bei sehr guter Kühlung kann das ein Fehlalarm sein, siehe Selbsttest.

Ein Ersatz für den Gamma muss ein 40-mm-Lüfter mit vier Pins und 5-V-PWM sein. Den Tausch zeigt Bitaxe leiser machen, ein leiser Ersatz ist der Noctua NF-A4x20 5V PWM.

Neustarts: was Reset Reason verrät

Auf der Seite System steht unter Reset Reason, warum der ESP32 zuletzt neu gestartet ist. Die Gründe liefert das Entwicklungssystem ESP-IDF von Espressif, AxeOS zeigt sie als festen englischen Text. Die wichtigsten:

Auf die Hardware zeigen nur Brownout und Power Glitch, und auch dann zuerst auf die Versorgung, also Netzteil, Kabel und Stecker. Wie du Neustarts automatisch gemeldet bekommst, zeigt Bitaxe überwachen.

Wann es ein Fall für den Support ist

Nach den Schritten oben bleiben wenige Fälle, die auf einen echten Defekt deuten:

• Der Selbsttest scheitert mit Werkseinstellungen und dem mitgelieferten Netzteil, wiederholt an derselben Stelle.
• „ASIC 0 not found“ bleibt trotz richtiger Board-Version und Factory Reset, ohne Power Fault im Log.
• Ein Power Fault mit „An output overvoltage fault has occurred“ bei Werkswerten.
• „Fan Control Failed“ kommt nach jedem Neustart wieder.
• Ein Rechenbereich fällt im Selbsttest dauerhaft aus („ASIC 0 DOMAIN:FAIL“), auch bei kühlem Chip.

Damit wir schnell antworten können, schick uns:

• Modell, Board Version und Firmware-Version von der Seite System
• ein Foto des Displays mit dem Ergebnis des Selbsttests
• das heruntergeladene Log, möglichst mit dem ersten Auftreten des Fehlers
• den Reset Reason
• welches Netzteil und Kabel du nutzt, ob du übertaktet hast und welche Firmware lief
• Fotos der Platine, wenn etwas zu sehen ist

Erreichbar sind wir über Hilfe & Support und die Seite Kontakt. Ob ein Mangel vorliegt, prüfen wir im Einzelfall. Gegenüber Verbrauchern gelten die gesetzlichen Mängelrechte. Ausgeschlossen sind sie nach Abschnitt 9.3 unserer AGB, soweit ein Defekt zum Beispiel auf Overclocking, eine ungeeignete Stromversorgung oder eigenmächtige Änderungen an Hard- oder Firmware zurückgeht. Deshalb fragen wir nach Netzteil, Übertaktung und Firmware.

Häufige Fragen

Quellen

• bitaxeorg/ESP-Miner (AxeOS), Release v2.15.4 vom 21.10.2026: self_test.c (Prüfungen, Kürzel, Grenzen), TPS546.c (Statuswort, Logzeilen, Grenzwerte je Modell), power_management_task.c (Überhitzungsschutz), asic_common.c (Chiperkennung), device_config.h (Werkswerte je Board), fan_controller_task.c (Lüfterfehler), flashing.md (Selbsttest nach dem Flashen)
• ESP-Miner Pull Request 1790 (Mindestspannung nach Überhitzung, im Entwicklungszweig seit 14.09.2026) und Issue 2000 (Überhitzungsschutz reagiert auf Sensorfehler, offen)
• Texas Instruments: TPS546D24A, Datenblatt SLUSDN0A, Abschnitte STATUS_BYTE, STATUS_WORD, STATUS_VOUT, STATUS_INPUT und CLEAR_FAULTS
• bitaxeorg/bitaxeGamma: README und Schaltplan der Revision 601 (Netzteil, Stecker, Bauteile)
• Espressif: ESP-IDF, Reset Reason und esptool, Boot Mode Selection (GPIO0 und Flash-Modus)