When all 3 boards die at the same time I'd suspect either the PSU or control board. Do you have other miners you can swap parts from, or a spare control board or PSU?

No firmware will work if all chips are not found.

Yeah, the Bitmain style testers like the Zeus tester are painfully slow for troubleshooting. I started using the Asic.Repair tester (https://tester.asic.repair/en), which will run the count test in a loop indefinitely, giving you all the time you want to probe the test points.

I posted about this last year, https://bitcointalk.org/index.php?topic=5125803.msg55424159#msg55424159
The docs on github didn't work on the miners I had, when I contacted Canaan direct they eventually sent me a different doc that I linked in the post above.

I was able to get a bit better efficiency after hours of tinkering, don't remember the exact #s though.

The "only find asic" just does the count, no hashing. The "pattern test" runs all the chips at the frequency & voltage specified in the Config.ini file, and checks the results. If a chip is able to communicate but performs poorly or not at all at the frequency & voltage being run, this test finds it.

You can run the board on the test fixture with some heatsinks off if you either shut it down before the pattern-test begins or set the option in the Config.ini file on the sdcard to only run the "find asic" test. It only uses a lot of power when doing the pattern test, so the chips won't overheat without a heatsink if only doing the asic count.


All of the temp sensor issues I have seen so far have been due to low 1.8V at the temp sensor. Typically you can find the 1.8V issues by tracing the resistance through the chips, like you described. Unfortunately, bad solder joints can break contact or make contact based on temperature, so many times you need to power the board up in order to find the issue. I check these by running the board and measuring the voltage drop across each chip. Anything above a couple mV drop is a potential issue. If you have access to a good benchtop multimeter, it can help a lot.

This is a lot easier with the Asic.repair test fixture, with the standard Bitmain style fixture it tries to find the chips 3 times and then stops, so you get only 15 seconds or so to measure before you have to wait for another run.

Sorry, didn't notice the large moq
 This will work.

https://www.digikey.com/short/f02vj377

Yup, those resistors are 33ohm 0201s, and the caps are 1uf 6.3V 0402s.

No way to remove or reflow the ASIC chip and not reflow the caps and resistors surrounding it. The large pads on the bottom of the chip sink heat to the board too well to be able to heat it up to the melting point and not melt the solder on the surrounding components.

Could you share some more details? What did they say was wrong, and how much did it cost?

Those are most likely 33ohm resistors. If not, they are 0 ohm. What leads on the asic do they connect to?



I'm pretty sure the ones I circled are 0201 resistors, ridiculously small ... like grain of sand small. It is defiantly a pain in the ass to get these on, you need some good tweezers.

https://www.digikey.com/en/products/detail/panasonic-electronic-components/ERJ-1GNJ330C/8343545

https://www.digikey.com/en/products/detail/panasonic-electronic-components/ERJ-1GN0R00C/3982319

The caps are either 1uf or 0.1uf. I think they are 0402 size. These should work.

https://www.digikey.com/en/products/detail/kemet/C0402C104K4RACTU/789653

https://www.digikey.com/en/products/detail/cal-chip-electronics-inc/GMC04X7R105M6R3NT/13908742

The board won't do anything unless the correct commands are sent from a control board. It needs to command the pic microcontroller to turn on power to the chips on the board, and then it needs to send a command to the chips in order to see any signals at the test points.

It is possible to just use the control board from the miner, and make up some cables (need to be 4awg to 6awg cables) to run from the psu to the hashboard so you can run it on a bench so you can access the test points. It is very slow though because it takes so long to boot up and then you only get 3 chances to measure anything when it is checking the ASIC count, after the 3rd try it just shuts down the board and you need to start again. The normal Bitmain style test jig (that is just a S17+ control board with special firmware), does the same thing except it boots a bit faster and then runs a test pattern to verify the operation and performance of each chip if all chips are found. For troubleshooting a board that isn't finding all the chips, it is still very slow, maybe a couple of minutes per round of 3 ASIC counts.

The tester from Asic.Repair (https://tester.asic.repair/en), far superior to the standard test jig for troubleshooting boards that aren't finding all chips. It allows you to run the ASIC count test continuously about once a second with no boot-up time. I have both and rarely use the standard test fixutre any more.

From the log you posted, it looks like none of the boards are working when they are all connected. For the hashboard to work, all 30 asics need to be found.


The "get_average_voltage" messages shows the measurement from each hashboard of the PSU voltage. There is only one main supply voltage, so the three boards are measuring the same supply voltage. It could be the PSU is just shutting down and the 3 measurements are showing the voltage drop after the supply shut down, notice from the timestamps that there are a few seconds between each reading.


From the little info you've given, I'd guess the most probable problem would be a bad PSU or input voltage as mikeywith said. Although I'm not sure how one board would work when the log you posted shows the PSU turning off before the boards start hashing. Before they start hashing, all 3 boards together are using much less power than a single board would use while actually hashing.

We might be able to get a better idea of what the issue is if you post some more logs and screenshots of the status screen.

• Log of 1 board working when all 3 boards are connected
• Logs of each board working when connected indiviudally

Also, what is the AC voltage you are powering these with? You should verify with a voltmeter.

Guess I didn't word that very clear... Didn't mean "even more than the PCB design", just additional. Might not be very difficult, but you think you can find someone to do it for under a few thousand $? I'm used to paying $150 an hour for good experienced software developer contractors.

If you filed a lawsuit against Bitmain, I wonder how much $ you'd need to be a big enough pain in their ass to motivate them to actually do anything. Probably not possible with the current USA administration, but cutting off all imports to the USA of miners violating the cgminer license would be a pretty powerful motivator. Do you know for sure that they are violating it? If they were smart, bmminer would have been developed as a completely different app not derived from cgminer at all.

I think bricking a few boards would be the least of your worries .... that's only several thousand $... that's nothing compared to how much it would cost to design and layout a new PCB, and then even more for doing some firmware.

Not possible, pinouts of the chips have changed.  Don't have the pinout for the S19 chip, but since the S17 is different from the S9, I seriously doubt they went back to an old pinout. Also, they run at different voltages. So PSU won't work, control board won't work, and hashboards won't work.

I guess it would be technically possible to reverse-engineer a S19 hashboard, design a new PCB layout that would fit into a S9 case, buy new PSUs and control boards, hack the firmware to support a different # of chips since I'm sure you're not going to fit 114 chips on a S9 format .... all to be able to re-use a couple fans and a case ...lol. Good luck with that...

I'm not sure solder melting point is the issue with the original assembly. I'd guess either poor temperature profile or just faulty/expired solder paste. Many of the chips I remove show signs on the large pads that the solder never flowed enough.

Yeah ... pretty sure the chances of working with half the leads disconnected is pretty low... lol.

I use the same chipquick for the chips as well. Don't know what they use in the factory, but I think in some of the Bitmain repair manuals it mentions low temp (138DegC) for everything. I like using it because you can keep the temperatures lower so less chance of destroying a board. Although it does make putting heat sinks on a bit tricky, would be easier if the chips were attached with higher melting point solder.

From what I can tell from the log, the miner starts mining and it takes about 3 minutes for the chip to overheat.



I'm assuming that was captured during the 3 minutes, and one chip temp is already up to 80 dec, significantly higher than the others. So it looks like it runs for a little bit, and that chip just keeps getting hotter until it hits the 90Deg limit and shuts down. You could confirm this by just looking at the status page and refreshing constantly during bootup, monitoring the temperature. If it just gradually rises to failure, then I don't think it looks like a faulty sensor, but just a bad ASIC or a bad connection to its heatsink.

These miners have a lot of issues with heat sinks, many times the copper plating that interfaces the chip to the solder that holds the heatsinks on delaminates, which can cause a little gap that will kill the efficiency of the heatsink. It is very possible that if you shake that miner a bit, or if you push on that heatsink, it will just fall right off. I assume you've already checked that there isn't a loose or missing heatsink? And that the heatsinks are clogged up with anything?

You may be able to limp along if you block the 2 empty slots somehow. With them blocked, a lot more air will be forced through the heatsinks and it might be enough to keep it below 90.

Specifically looking for control board enclosures... I need about 30 or so of them.

So you are running with only one hashboard in the miner? If so, the cooling will not be ideal. The air will take the path of least resistance which is right down the empty slots instead of being forced thought the heatsinks.

Please post the full log. Just copy the whole text and paste it into a code block ... this: , produces this:

Have you tried different pools? Pools like Nicehash can sometimes be difficult to set up and can cause issues like you describe, so to get a baseline try a standard well known pool, like Viabtc, Slush, Kano (if you are using factory firmware), F2pool, etc..