S17/S17 Pro Firmware Options

The supposed “dog” of the crypto miners still has a lot of fight left in them. When I first looked at getting the S17 I read a lot of negative reviews, and there were/are issues with them, however there’s also a lot of greatness (and profitability) in these miners. The first point I looked at was cost per TH. The S17 Pro 59TH units I got were roughly $45 per TH. If I compared that to other SHA256 miners it sits near the bottom cost wise (S9 is ~$40-45 and S19 is ~$90-100), that’s good enough for me!

S17 Pro 59TH

  • Cost – $45 per TH
  • Profit – $0.20 per TH per day
  • Time to Payoff – 225 Days!!!

OK, great, I bought a few and got them running. All came up fine but I knew I could squeeze out more. I started looking at available firmware options, which surprisingly there were many. I ultimately decided on several to try; Hiveon, Braiins, Awesome miner, and Asic.to (don’t hate me for missing one of the many others…)

Each had their own unique challenges, whether is was the basic install, having the system properly recognize the hash boards, or the ease of tuning the hash boards to maximize my efficiency.

At the end of the day I went with Braiins. The reason for this was many fold, a great interface, awesome tuning, and easy to use. All things being equal each was easily enough installed, and all cost about the same in dev fees, but the features and performance from Braiins won the day.

I put the process I went through in a quick video, including the quirks that each firmware presents.

Don’t skimp on the solder when reflowing an ASIC…

What is that I see above? That’s ASIC 28 on an L3+ hash board. You probably can’t tell what’s going on here, but I’ll attempt to explain why the image above is bad and I promise I have a better one below.

I was working on a hash board that showed the infamous “0 asics found” and eventually, through blood, sweat, anger, hunger, and tears found that ASIC 28 was actually bad and wound up affecting the entire hash board. Sometimes the ASIC tester points to the exact cause, but most of the time it’s just you, a multimeter, and a worthless $200+ hash board test jig.

Let’s fast forward to me soldering on my first DFN (dual-flat no-leads) package. At first they look intimidating, but once you get the hang of it they’re actually quite simple to put on. The only thing you have to worry about (which bit me in the end, hence why I’m writing this) is that if you don’t have enough solder on the power and ground pads, you won’t get a good enough connection for the ASIC to function.

I followed a few videos online (from Antminer Repair) to learn the basics, but since I didn’t have the fancy solder stencil, I was forced to do my favorite thing, improvise.

I started the painstaking process of removing the old ASIC, which can be a problem itself. Bitmain doesn’t use a low temp solder so you really have to heat things up for a while before the ASIC will give up its death grip. Unfortunately I did a little damage to the PCB (printed circuit board) when removing it, fortunately it was a NC (no connect) pin. You’ll also want to remove the heat sinks from the ASICs around the one you’re replacing so you can get some room to work. About 30 seconds from a heat gun is enough to pop these off easily.

Luckily Pin 15 (torn pad) is a NC (no connect) and on the side you see some copper showing from me prying the old ASIC off.
Luckily Pin 15 (torn pad) is a NC (no connect) and on the side you see some copper showing from me prying the old ASIC off.

After following the advice from Antminer Repair on Youtube I tinned both the pads on the PCB and on the ASIC itself. I then placed the part on and heated it until it self aligned and slowly held it in place until the solder hardened. Sounds way too simple, but easy day, right?

After cooling and cleaning I went and plugged the hash board in, nothing, “0 asics found”, I was defeated. I broke out my multimeter and started measuring all the signals (RI, RST, CLK, BO, and CO.) I even measured out the resistance between pins and pads to make sure I hadn’t damaged anything. I was at a loss. Finally it dawned on me, maybe there’s poor connections from the ASIC to the PCB. I don’t have x-ray vision, so I got the next best thing, an actual x-ray.

ASIC 28 (center) with poor connection to power and ground due to me being skimpy with the solder.
ASIC 28 (center) with poor connection to power and ground due to me being skimpy with the solder.

As you can see, or maybe not, look at the ASIC above and below, there is a large solid mass where the power and ground planes are. Now look at the one in the middle, not so much. My aha moment was here, without proper power and ground this puppy wasn’t going anywhere. 

I reflowed the ASIC and removed it, added a bit more solder, and viola, 72 ASICS found, my dream come true.

Don’t skimp, don’t be cheap, and practice practice practice (or do what I’m going to do in the future and pay a professional.)

A Walkthrough of the L3+ Hash Board (2nd Edition)

Like many of you I’ve had some frustrations with my L3+ units, mostly surrounding the hash boards and various failures. Bitmain previously released an L3+ Maintenance Guide  in 2018 that did a great job summarizing some basic failures, how to identify, and then the Internet took over with the various fixes. I’ve reviewed Bitmain’s manual many times and have boiled down most of the pertinent info below, as well I’ve added my two cents. Make that more than two cents, I hopefully dive into some of their topics a little deeper and attempt to explain it in more detail and make it easier to understand. Their manual can be cryptic and it’s missing a lot of the middle pieces tying some things together so I attempted to fill in the blanks as well. Some of the graphics and schematics I pulled from their document so I’d like to acknowledge them here.

This is meant to be a living document so I’ll update it as I find new solutions to problems. Furthermore there are several areas where I couldn’t find enough information or wasn’t able to reverse engineer how something functions so I denoted those with an assumption note.

If you need to order any of these parts you can find a link to vendors here.

I’m all about sharing so I’m putting this all out there to help everyone out, but please, if you re-use some of this give me a shout-out. I’ve had things plagiarized in the past and while it’s not anything earth shattering, it’s also a work in progress so I don’t want someone putting info out there that’s not complete nor something they can explain as to how they came to a specific conclusion. It not only makes them look bad, but it can cause distrust in the data being put out there. Long story short, share it and shout outs.

A general note regarding testing voltages at the various test points. You must have the hash board power and I/O cable plugged in and a working L3 control board or test fixture. The PIC (which provides the signal to turn on the 10V) won’t initialize the 10V buck controller until it receives the programming information from the control board, therefore not only the 10V but the 14.2V and the individual power regulators won’t have power to function.

Another quick note, if you don’t have one, getting a hot air rework station will make some of these fixes easier. You can pick up a station complete with a hot air gun and soldering iron for about $50, I use the FEITA 8586 SMD Hot Air Rework Station from Amazon.

PIC (programmable interface controller)

U3 (U74 on V1.6) is a 16LF1704/5 8-bit microcontroller PIC (programmable interface controller.) This is what makes the hash board, well, hash. If this is not programmed properly the hash board may exhibit all sorts of strange errors, anything from missing chips to bad temperature readings, to no or partial hashing, or the board not being recognized at all. 

The PIC takes the frequency and voltage information from the L3 Control Board (what you set them at through the software interface) and adjusts the voltage output and frequency for the BM1485 chain. The PIC communicates with the other ASICs and ICs through I2C (SDA, SCL, and GND) which basically is an IC to IC communication protocol.

It is possible to reprogram this from code from your other hash boards which I will cover in another post at a later date (it’s quite an in-depth process and involves using a Pickit3 programmer and a little luck.)

Common Failures related to U3/U74 (PIC)

No 10V found (measured at both sides of C948 or between either pin of L2 and ground.)

Improper voltage (less than 10V) measured at C948.

  • Your buck converter may have failed or may have cold solder joints. First try reflowing the joints and if that doesn’t work, replace the part. Depending on the voltage it puts out you may still be able to run at a lower frequency and have it work. I have one board with a failing buck converter (it only puts out around 8V but it varies) and I’ve tested out various frequencies and actually have it working up to 300MHz. That’s more of an FYI and something my curiosity had me research. You should always conduct the repair before operating them in abnormal conditions, I’m just waiting for a replacement part at the moment.

Temperature Sensor

U87 (U88 on V1.6) is a T451/TMP451 temperature sensor. This is powered by the 1.8V voltage regulator in the first chain. You can get failures if the voltage regulator (U86 on V1.6 hash board) is damaged by a voltage spike/surge.

In reviewing the schematic of the temperature sensor, we can see that the T451 uses I2C to communicate on the hash board as well as having its own built in temperature sensor that is attached externally (pin 2(D+) and pin 3(D-)) to ASIC 1 I believe.

TEMP_P and TEMP_N are the PNP or NPN transistor in the ASIC (BM1485) itself that read the temperature. This is most likely a thermal substrate transistor that outputs to the TMP451 for processing then reports this information out via the I2C bus. I also see there are pads across the board for numerous T451’s, probably an enhanced feature they never implemented?

Common Failures related to U88 (Temperature Sensor)

“Failure to get temp data” error in L3+ Kernel log.

  • Check voltage levels between pin 1 (1.8V) and pin 5 (GND), improper voltage from the first LDO chain can lead to a failure of the temperature sensor working properly.
  • Your temperature sensor may have failed or may have cold solder joints. First try reflowing the joints and if that doesn’t work, replace the part.


There are a total of 72 BM1485 ASIC’s on-board the L3+ hash board. There is no data sheet readily available for this but what I have gleaned from info they’ve put out there aren’t too many failures that are easily tied to these (at least nothing that’s easy for a DIY fix.) These are powered by 12 individual 1.8V power domains.

(*Note: assumption) The clock signal comes from Y1, a 25 MHz crystal, and each board communicates with each other through the CI/CO signals for synchronization.

If one BM1485 in the chain goes bad, it may break the communication to BM1485’s down the line. I’ve found that it can either be fairly simple, or really hard, to diagnose these. One key here is that if you get an error that shows only a lower number of ASICs, like 27 ASICs found, then ASIC 28 may be your problem. You can verify this by checking the test points as I have listed under below under the 1.8V Power Domain.

Furthermore errors such as CRC5 (as found in the kernel log) often point to a bad ASIC. I recently diagnosed this in my article on What to do with 0 asics found and CRC5 errors.

Without a data sheet there is quite a bit of mystery behind how this actually works, but a little reverse engineering and research has led me to assume some of the following (key word is assume):

(*Note: big time assumptions here)

The frequency on each BM1485 (as set in your “Miner Configurations” pages) is set through programming received on CI/CO (command input/output) and RI/RO (respond input/output.) A command string is sent to the BM1485 to set the PLL divide for the various frequency levels on the BM1485. 

U1 (ASIC 1) is actually the BM1485 ASIC that the temperature is read from. The TMP451 reads the temperature data from pins 6 and 7 of the BM1485, processes this and returns the information on the I2C bus to pins 15 and 16 of the BM1485.

One question I’m still waiting on Bitmain to answer (not sure if they will ever get to it) is whether or not RF and TF are wired up to each ASIC for the I2C bus. 

Common Failures related to the BM1485 ASIC

ASICs showing as “x” or no ASICs found.

  • Check voltage levels at the following test points on each voltage domain (set your ground lead on the negative size of the tantalum capacitor or ground plane closest to each set of the test points.) Make sure you have the boards plugged into power and I/O cables to the control board. Without this the hash board won’t initialize the voltage domains (if using a text fixture go ahead and press start button or IP_Sig on control board.)
  • RST – 1.8V
  • BO – 0V
  • RI – 1.6V – 1.8V
  • CO – 1.6V – 1.8V
  • CLKO – 0.9V

Note: The signals for RST, BO, CO, and CLKO run from from U1 to U72. RI actually runs in reverse from this, going from U72 to U1.

1.8V Power Domains for BM1485

The L3+ has a total of 72 ASIC chips spread across 12 voltage domains (with 6 BM1485’s each.) Each voltage domain is controlled by a 1.8V voltage regulator that has changed over various version of the hash board.

* Version 1.5 and earlier hash boards – One SPX5205M5-L-1-8 1.8V voltage regulator (pkg SOT23-5) for each of the 12 voltage domains (6 – BM1485 ASICs per domain.) These are generally labeled as R18 on the top along with the date code.

* Some versions of the hash board have also used the SGM2202-1.8 (pkg SOT23-5.) These are generally labeled as G49xx on the top (xx is date code.)

* Version 1.6 hash board – U75, U76, U77, U78, U79, U80, U81, U82, U83, U84, U85, and U86 are LN1134A182MR 1.8V voltage regulators (pkg SOT23-5L) for each of the 12 voltage domains (6 – BM1485 ASICs per domain.) The first 10 domains are generally labeled 4VK4. Make sure to use higher input voltage LN1134’s for the last 2 domains as their input voltage from the boost circuit is greater than the other domains. The last two may be labeled as 4AK4.

These are extremely susceptible to damage from a voltage spike out of the boost circuit. To measure the output of each one you need to measure between pin 2 and pin 5. You can measure the input voltage between pins 1 or 3 and pin 5.

Common Failures related to 1.8V Voltage Domains

ASICs showing as “x” or no ASICs found.

  • Check voltage levels at the following test points on each voltage domain (set your ground lead on the negative size of the capacitor closest to each set of the test points.) Make sure you have the boards plugged into power and I/O cables to the control board. Without this the hash board won’t initialize the voltage domains.
  • RST – 1.8V
  • BO – 0V
  • RI – 1.6V – 1.8V
  • CO – 1.6V – 1.8V
  • CLKO – 0.9V

Note: The signals for RST, BO, CO, and CLKO run from from U1 to U72. RI actually runs in reverse from this, going from U72 to U1.

If you encounter a voltage domain that does not output 1.8V on pin 5 of the voltage regulator then it most likely should be replaced. It’s common for these to go out, especially during voltage spikes. The boost circuit has been known to knock the later domains (ASICs 49-54, 55-60, 61-66, and 67-72) when they fail.

10V Circuit

U1 is a LM27402 synchronous buck controller. On the V1.5 it is called U74, and on the V1.6 it is called U200. On versions 1.5 and later it is a uP9305W synchronous buck controller and has other components not originally on the earlier versions.

This output value is set by the PIC and is derived from the value that the user selects in the firmware (i.e. if you change the chain voltage from the “Miner Configuration -> Advanced Settings” page this is where that voltage changes.)

Q1, Q3 (not installed), Q4, and Q5 are THPR9003NL MOSFET N-Channel Switching Regulators. These rarely fail and they are fairly difficult to isolate.

On version 1.6 there are additional components for the 10V circuit, Q30 and Q32 are 8040 NPN Silicon Epitaxial Planar Transistors, Q31 and Q33 are a 6040 PNP Silicon Epitaxial Planar Transistors.

Common Failures related to the 10V circuit

Improper voltage (less than 10V) measured at C948.

  • Your buck converter may have failed or may have cold solder joints. First try reflowing the joints and if that doesn’t work, replace the part. Depending on the voltage it puts out you may still be able to run at a lower frequency and have it work. I have one board with a failing buck converter (it only puts out around 8V but it varies) and I’ve tested out various frequencies and actually have it working up to 300MHz. That’s more of an FYI and something my curiosity had me research. You should always conduct the repair before operating them in abnormal conditions, I’m just waiting for a replacement part at the moment.

14.2V Boost Circuit

U111 is an RT8537 switching power supply. This is used to boost the 10V supply (coming through the inductor L2) to 14.2V. It’s generally considered the most finicky part of the hash board itself and seems to fail quite often. Early on Bitmain discovered that components were oxidizing and therefore leading to failure so they started covering the circuit in epoxy. Why you may ask? I have no idea why this oxidizes any more or less than other parts of the circuit, but they seemed convinced this would fix the problem. In the end of the day, nope, they still fail and we still add in external booster circuits

Basically this circuit boosts 10V from the buck controller to 14.2V. L1 is used to store the energy for the boost and D1 isolates the 14.2V BOOST_OUT through reverse protection. When you install an external boost circuit you have to remove D1 to eliminate the possibility of interference from the old boost circuit.

Failure of the boost circuit can also cause damage to the 1.8V voltage domains.

Common Failures related to the 14.2V boost circuit

Improper voltage at D1 (less than 14V, generally much less.)

  • Your on-board boost circuit may have failed. Install an external boost circuit  and remove D1 to isolate the on-board boost from the external boost.
  • Your 10V may also be off from the buck controller, this should be researched and solved before assuming the boost circuit is bad.
  • If your boost circuit is failing it may still show 14V, however the last two power domains may appear to have bad LDO’s (good input voltage however the output is less than 1.8V.) The LDO’s are most likely fine, try installing a boost circuit as this should fix the problem.

Other Components (data later on)

Q10 is a 1AMP SOT-23 package which I believe is a MMBT3904 NPN general purpose amplifier. More on this later once I figure out what’s going on here.

Y1 is a 25.000 MHz crystal that’s used as the clock signal for all ASICs. If this goes out, nothing works, you’ll need an oscilloscope to verify this.

What to do with 0 asics found and CRC5 errors?

Has anyone else ever been frustrated with an error that simply says, “bitmain_scanreg,crc5 error, should be 00, but check as 01…..” I have, and lacking available source code to trace this down, I’m only guessing to the culprit. The fact that it seems to be looking for something blank makes me think it’s an ASIC check, or possibly something with the PIC.

Disclaimer – This may be hard to follow, it’s sometimes hard to put thoughts as you work a problem down, but it’s a great reference for me in the future and hopefully y’all as well.

Problem – I have a board that doesn’t find any ASICs and obviously won’t hash. The only real clue I had was a long series of:

 bitmain_scanreg,crc5 error,should be 00, but check as 01…..

Looking at all the usual places, Reddit, Discord, and google searches only pointed me to people saying the obvious, your board’s bad, send it to Bitmain or a repair shop. Well, regardless of this, I’m determined to figure this out for all of us that want DIY fixes.


I’ll start by saying the test fixtures you can buy on Ebay and other sites are basically garbage, at least if you spend $200 on one. I did a quick article on turning your control board into a DIY test fixture and that’s all I ever use anymore. I always test with the data cable and power cable hooked up, once I press the test button (IP_sig on the control board itself) the PIC initializes the board and I should get ~10V out of the buck converter, 14.2V from the boost, and 1.8V from the LDO’s. A quick check of these voltages show that all are reading perfect, so on to the ASIC by ASIC search. So knowing the proper voltages are present, I moved onto the LDO’s.

All LDO’s tested out perfect, we’ve got ~2.5V in and 1.8V out from each. So much for an easy fix, so now it’s time to get down and dirty, 72 individual checks of the basics, RI and CLK (all the ASICs have test points available on the bottom of the board.) As I moved through each ASIC, starting at 72, I found an anomaly at ASIC 28. I verified proper voltages to RI (1.8V) and CLK (0.8V) at all ASICS until I got to ASIC 28, which has CLK at 0.95V but 0V at RI. ASIC’s from 1-27 also have 0V at RI. Aha! I’m thinking short at this point, so where is the short? I moved to pulling off the heatsinks in that entire row, inspected, reflowed the joints, but still having the “found 0 asics” error in the kernel log.

We now go back to the schematics to see how the chains are organized and if there’s any reason this particular ASIC could take out the chain before it, or is there another one in the chain doing the damage.

I’ve also verified that CO (pin 4) and BO (pin 2) read 1.8V on ASIC28, so if there’s a short to ground causing the 0V at RI (pin 3), it’s not there. If we go back one ASIC in the chain, ASIC 27, we also measure RI as 0V. ASIC 27 outputs RO (pin 26) into RI (pin 3) of ASIC 28. Of note, the two pins on either side of RO are CI (pin 25) and BI (pin 27.) When we go to the schematics we see that CI (pin 25) is the transmit signal that goes to CO (pin 4) of ASIC 28. We also see that BI (pin 27) is shown as tied to ground and is tied to BO (pin 2) of ASIC 28.

OK, that’s a lot of data, but one thing that stands out, if on ASIC 27 BI (pin 27) is tied to ground, can there be a short from BI (pin 27) to RO (pin 26) and would that cause us to see 0V on RI at ASIC 28? 

I measured resistance between each of the pins on each ASIC, and verified that each ASIC had continuity from input to output of the next, no issues. Now I’m getting frustrated, I think it’s something with ASIC 28, but that’s a PITA to remove. I’ve tried reflowing to no avail, guess my next step is to attempt to remove it with a heat gun and then replace, this could get interesting.

One hot air reflow knife, 1 pair of tweezers, a lot of flux, and even more patience pays off. It took me a good 2-3 minutes before I was able to pop ASIC 28 off, but I ultimately won. I’ve heard folks say it takes 30 seconds, well, they must have better gear than me. Anyway, after popping ASIC 28 off, cleaning the pads, and cleaning the board I was ready to throw it back into a system and see what we have.

Chain 0, 27 asics found

This was music to my ears, I flipped the board over and measured RI at ASIC 27 and several between that and ASIC 1, 1.8V! As my son would say, “We did it!!!” We found the issue, I looked at the kernel log and all CRC5 errors were gone, and on the miner status page we could clearly see 27 asics found. I felt the biggest sense of relief and victory.

But now the hard part, I’ve never soldered on a new ASIC on one of these. That’s a different story for a different time, but for now we’ve slayed the dragon (the dragon being CRC5 errors.)


CRC5 errors seem to point to a bad ASIC. If you’re receiving these I would move immediately to testing the voltages (RST, BO, RI, CO, CLK) with power and a data cable installed. You may need to press the test (or IP_Sig) button to start the buck controller so the LDOs are operating so keep that in mind. The board won’t output ~10V from the buck controller without this, and you’ll need to do this every minute or two when the board is in test mode.

If you get an anomaly on one of these output voltages it could be that particular ASIC, or the ASIC up the chain. Shooters choice as to which it can be, but you are much closer to solving this problem.

Programming the PIC on an L3+ Hash Board

I recently came across an L3+ hash board that wasn’t producing 10V from the buck controller and therefore no 14.2V from the boost circuit. I know the boost circuit often goes bad, but it’s rare to not see 10V from the buck controller. I was getting 12V power to the hash board, and it was connected with a good I/O cable. I went into the kernel log and it wasn’t being recognized by the control board. I started scratching my head, what would cause a hash board not to be recognized?

Well, it wasn’t long before logic kicked in. If the kernel log doesn’t see it, that means the hash board isn’t (most likely) initializing the PIC, and subsequently not firing up the buck controller to product the 10V needed. I’d never programmed a PIC onboard before, so I got my Pickit3 Programmerdownloaded the Microchip MPLab IDE, and got to work!

In order not to bore you with a lot of writing, I made the following video. I know others have made one too, I just cut to the chase in a lot of it and instead of 30 minutes as I’ve seen from others, you get 5 out of me. I got a lot of great info from customminerservice.com so I wanted to give them a shout out too!

Reviving a $300 “for parts only” L3+ I bought off Ebay

I’m always looking for a project, and a good deal, so I’ll often browse Ebay and see if there’s any cheap “for parts only” complete miners to buy. Most the times these get bid up near complete working unit prices, but from time to time they are either overlooked or scary enough from the pictures that people pass on them. My most recent find I picked up for around $300, complete with all hash boards and power supply.

When I received the unit it was packed well, but dirty, I’m talking that black dust that you can only seem to find in the darkest corner of some mining warehouse. Also a couple boards seemed to have been unplugged for sometime (like they stopped working before the rest) and the control board was broken out of the rails that hold it in place. OK, we’ve got our work cut out for us.

First thing I always check when I buy a miner is the control board. I disconnected this, blew it off with compressed air, cleaned it in an alcohol bath, blew it off again, then hooked it up to my network with a custom power connector I made from an old 12V/600mA DC adapter. It powered up fine and I got lights on the ethernet connector but it never connected to my network and even running a network scan I couldn’t see anything new attaching. Holding down the reset for 10 seconds didn’t clear it, so either we have a corrupt control board or a bad one. I decided let’s go worst case and assume it’s corrupt with a virus so we’ll use the guide that CustomMinerService.com developed to recover the control board. Without stealing his thunder (click on the link to his website for full details), you basically have to complete the following steps:

  • Solder a jumper wire and 1-10k resistor between two pins on the backside of the control board
  • Flash Bitmain recovery firmware to an SD card and install this on your control board
  • Wait a few minutes and pray you get two flashing lights (red/green) on the front
  • Turn off
  • Remove the SD card, jumper wire, and resistor
  • Turn on
  • It should now boot to Bitmain stock firmware

I’ve obviously skipped and gleaned over some details above, but u/BornShook has it all explained extremely well on his website. I will say I’ve followed this set of instructions several times and it’s worked perfect, and for this latest project that 100% did the trick, so now I’ve got a working control board again! Next step, flashing HiveOS to the control board, which can be tricky with the Bitmain signature checks, however I’ve got an article that takes you through the process step-by-step and I’ve done it dozens of times with success. 

Once the HiveOS is loaded it was time to turn to the hash boards and case. One thing I noticed right away was that the fans were installed backwards and were fairly new. I’m not sure if they had some custom venting that had them do that, or just a simple mistake, but we’ll fix that up. Just like the control board, my first steps for testing a hash board include:

  1. Brush off thick dust deposits first (always wear glasses when blowing compressed air)
  2. Blow through board, connectors, and under heatsinks (be careful around heat sinks as you don’t want to get too close) with compressed air
  3. Brush off any remaining dust deposits
  4. Blow one more time
  5. Put in alcohol bath and slosh around, brushing off any remaining thick deposits
  6. Pull out and let drip dry for 30 mins
  7. Blow one more time, making sure to blow out connectors well
  8. Wipe off any residue and inspect board for any obvious defects.

Once I do this for all hash boards, I will install them into the system one at a time and bring the system up. Once I see the board is hashing I will move onto the next. In this case all four came right up so I installed them back into the system, fixed the reversed fans, and brought the whole system up. Slowly I cranked up the speed and ran an autotune 

All in all I was into this project for $325, a couple hours of labor, and to my amazement the system is cranking away 14 hours later at 615MH/s with a nonce around 0.01%. That’s a true diamond in the rough.

How many miners, how big of a miner, can I fit on a circuit?

More and more I’ve seen questions from folks about how many, or how big, of a miner can I fit on a circuit. This is a question that has many unknown variables that I plan on diving into below. Disclaimer – Please keep in mind this is my opinion and not an actual consultation for your mining business, so before you do any wiring or make any changes to your electrical system please consult a licensed electrician.

Now on to the good stuff. In order to answer the question how how many/how much we need to know a little more information; the basics of your panel, the basics of your circuits, the basics of the miner, and anything else you plan to operate. 


For starters, each location in question needs to have a load calculation done to insure that you aren’t going to draw more than 80% of the maximum panel rating. As an example, if you have a dedicated 100A panel you can’t draw more than 80A continuous at any time. Since the mining world is in watts, let’s use Ohms law to break that down.

100A Panel @ 80% rule = 80A

Ohms Law tells us that Power = Current x Voltage

80A x 240V = 19,200W

So the key thing to keep in mind before planning out circuits is that you can’t have a continuous load more than 19,200W on this panel.


Now that we know the maximum wattage of our panel, we can use a little math to plan out what our circuits need to be. I’ll make the assumption that whatever miner we are using operates on 240V since that’s the industry standard at the power level they operate on.

There are 2 main amperage ratings for 240V breakers that are used in the mining world (yes I know there are more but these are the most common), 20A and 30A. There are several reasons for choosing one over the other, ranging from length of wire run, number of units per circuit, cost of wiring, and available breaker space. The most important thing to remember about each circuit is that they also have a maximum wattage rating:

20A Circuit @ 80% rule = 16A

16A x 240V = 3840W

30A Circuit @ 80% rule = 24A

24A x 240V = 5760W


So we know the maximum wattage our panel will hold, and we know the maximum wattage different types of circuits hold, only thing we are missing is what type of miner we’re running and what its power requirements are. 

Since this is February 2022 I’ll choose two scenarios, the first is using a newly released miner, the second is using a couple generations old miner. I’m partial to Bitmain products so I’ll look at the S19 or L7 for one scenario (~3250W) and the L3++ for the other (~900W, don’t hate on my S9 people!)

We know that our maximum panel wattage is 19,200W, so how many of each miner could we theoretically operate (I say theoretical since we have to split this up in to several circuits and the math may not work out perfect.)

S19/L7 = 3250W

19,200W / 3250W = 5.9

5 S19/L7 = 16,250W

So that leaves us with 2950W available in the panel for other electronics, fans, network equipment, etc.

L3++ = 900W

19,200W / 900W = 21.33

21 L3++ = 18,900W

So this leaves us with only 300W available in the panel for other electronics, fans, network equipment, etc. Of course this is only relevant if you plan on running everything for your operation off this one panel. 


Now that we know what our options are it’s more simple at this point, with a little math for the L3++ scenario.

For the S19/L7 scenario it’s clear that we need 5 – 20A circuits, one circuit for each unit. This allows us to dedicate one circuit per unit and keeps us under the 80% rule for the full panel load (we are only using 16,250W which is only 68%.) Unfortunately you can’t fit two of them per 30A circuit like some other units (you’d need to be closer to 2800W to do this) but we have plenty of space in the 100A panel for 5 20A breakers. Keep in mind that 20A breakers will use 12ga wiring whereas stepping up to a 30A breaker requires 10ga wiring.

For the L3++ scenario we use a little math. We can put 4 units per 20A circuit (3600W) or 6 units per 30A circuit (5400W). To maximize the number of units, and keep it simple, we can also go with 5 – 20A breakers, 4 units for each circuit. This keeps us under the 80% rule for the full panel load (we are only using 18,000W which is only 75%.) Once again we will use 12ga wiring for this.

This was a quick down and dirty calculation and please know that there is more in depth planning that would go into an actual circuit design (like run lengths, ventilation, other equipment draw, main panel draw, etc.)

Is the S17 Pro a good idea?

A lot of folks talk bad about the S17, but why I wondered? Before I bought my first unit I did the research and came to the conclusion that it got a really bad reputation based off some poor engineering decisions and poor manufacturing early on. There are 3 versions of this, the S17, S17 Pro, and S17+, each with its own set of issues, but is there a diamond in the rough?


Bitmain first released the S17 in April 2019. There was a 50TH/s and 53TH/s version that ran around 2300W. This first run had a tremendous failure rate in the field, reported from 20-30%. Bitmain at first denied there were problems but early on in 2020 they admitted to having design issues and high failure rates. Two of the biggest issues stemmed from their power supply design and heat sink design. The power supply seems to not be able to pump out the required current to keep the hash boards running properly and the heat sink, well, they were just plain falling off and shorting out the unit (ouch.) Another couple issues that seems to be a common issue across all the 17 series is the units dropping a hash board randomly and bad I/O cables. The dropping hash board may point to power supply issues, but it has gone unresolved. This is fixed by a simple reboot most of the times. Same with the I/O cables. Doesn’t seem hard to get that right, but alas they didn’t.

Bitmain followed this up with the S17 Pro, also released in April 2019. This had a 50TH/s, 53TH/s, and 59TH/s version. The big difference between this and the S17 is that the S17 Pro has a Turbo mode in the settings, allowing it higher hashing power. This model was produced longer than the S17 and the later S17 Pro 59TH didn’t have as many heatsink and power supply failures. This does however have the “dropping hash board” issue that is generally fixed upon rebooting the unit.

Bitmain’s last release was the disastrous S17+, introduced in December, 2019. I’m still not sure what the root of the issues were, manufacturing, firmware, cables, but these were plagued with issues from the start. It was also a power hog at 3000W for roughly 72TH/. Why does that number matter? Well the S17 and S17 Pro all ran under 2600W max, which luckily allowed circuits to be designed such that two units could fit on one 30A circuit. Take that same setup and you can’t cram two S17+ units on the same circuit without overloading it (beyond 80%.) IMHO I wouldn’t have released a version that just went over that number, I would have kept it under 70TH/s so it could have been a plug in replacement (electrically speaking) for the previous generation. There, off my soap box. If you’re going over that, go big, which the next generation S19’s did.


So there’s our quick history lesson, so let’s bring it in to the main question. Which one is the best of the “average” and what does that look like. After doing my research I settled on the S17 Pro 59TH. I have had a lot of success with this model, albeit I have seen the missing hash board problem here and there. Knowing these were some of the last units manufactured I had more confidence that their processes had been worked out. Additionally I looked at the return based off cost and hashing power. 

I started by looking at a more recent SHA-256 miner, the S19 Pro 110TH. If we look at the price per TH we get (based off today’s used prices) $11,000 / 110TH = $100/TH (I love clean math.) Keeping apples to apples we get the following for these other SHA-256 miners:

S17 Pro 59TH – $3000 / 59TH = $50.84 

S17 50TH – $2500 / 50TH = $50.00

S9 SE 16TH – $550 / 16TH = $34.38

S9 13.5TH – $450 / 13.5TH = $33.33

As far as I understand it, a TH is a TH when it comes to SHA 256. That’s why so many people still use the S9, the same rate applies whether you are at 13.5TH or 110TH.  So basically when it comes to straight hashing power (not profitability), 8 S9’s at $450 apiece ($3600 total) equals one S19 110TH at $11,000 I believe. I know, factor in power, but I’m just speaking straight hashing power at this point.


Now that we have our cost per TH, I looked at what would maximize my profits based off available panel space. I have 60A available, split into three 20A circuits. Keeping that configuration, and picking the most robust of the flavors, I could get the following:

Per 20A Circuit (max 3840W)

  • 3 x S9 13.5TH (1200W) = 3600W (40.5TH total @ $1350 total cost = $33.33 per/TH)
  • S17 Pro 59TH (2400W) + S9 13.5TH (1200W) = 3600W  (72.5TH total @ $3450 total cost = $47.59 per/TH)
  • S19 Pro 110TH (3250W) + nada = 3250W (110TH total @ $11,000 total cost = $100 per/TH)

If I change my wiring and turn the three 20A into two 30A circuits I get the following:

Per 30A Circuit (max 5760W):

  • 4 x S9 13.5TH (1200W) = 4800W (54TH total @ $1800 total = $33.33 per/TH)
  • 2 x S17 Pro 59TH (2400W) = 4800W (118TH total @ $6000 total = $50.85 per/TH)
  • S17 Pro 59TH (2400W) + 2 x S9 13.5TH (1200W) = 4800W (86TH total @ $3900 total = $45.35 per/TH)
  • S19 Pro 110TH (3250W) + 2 x S9 13.5TH (1200W) = 5650W (137TH total @ $11,900 total = $86.86 per/TH)


All were viable options, clearly the most hashing I could get involved getting an S19 into the mix and the cheapest was keeping with the S9. So many numbers, so much to consider. I decided that my best, and cheapest route, was to stick with my 20A circuits (didn’t feel like rewiring the basement) and go with the S17 Pro 59TH. Why? The big reason was cost per TH balanced with getting my fair share of hashing power. The S17 Pro fit nicely in the middle and puts my ROI on the unit at more than half of what it would be for an S19 Pro 110TH.

I’ve since installed HiveOS onto some of the S17 Pro’s with mixed results. It’s great to have more control over the frequency and voltage, but some of the core issues that weren’t firmware related still rear their head (I’m looking at you ghost hash board.) That aside, I’ve had some of these running around a year and still hashing great.