ANTMINER U3 Discussion and Support Thread

[Jake36]

How often did they get stuck before you cut the wire?

Well, it's not the USB power causing the zombie, had 2 zombie after about 35 hours with the 5V wire cut (about 5 min apart) and had to do the power cycle to get them to come back.

So back to the drawing board.

Ok, but this time around, I suppose you didn't have to unplug the USB cable, right?

That was the first thing I tried, it didn't work, so just shut everything down, switched back to the good cables, and powered back on.

Wait so, you had the USB red wire cut, the device went zombie, you unplugged the power cord, plugged it back in, and the device still remained zombie until you did the same with the USB cable???

No, tried resetting by just pulling USB first (thats all I ever did before cutting the wire), that didn't work. To get them back up, I had to remove the power (while power was down, switched back to the good cables).

[1715157701]

1715157701

[1715157701]

1715157701

[1715157701]

1715157701

[1715157701]

1715157701

[1715157701]

1715157701

[sico2819]

Hello there; first post to let you know I have managed to run 3 antminer U3 at the same time on a raspberry 1, using a usb 3.0 hub.

Here is a small link, you can ask me details if you need !

(Credits goes to Sven Goessling for the original tuto : http://sven-goessling.de/13/04/2015/raspberry-pi-1-und-2-antminer-u3-installieren/ )

To make it short :

- install the required libraries
- clone 4.9.2 from https://github.com/ckolivas/cgminer and not from the bitmaintech
- compile it using sudo autogen.sh --enable-icarus and sudo make

-after that, the command line usage is  :

sudo ./cgminer -o POOL -u USER -p PASS --au3-volt 800 --au3-freq 237.5

NOTICE THE CHANGE IN FREQ/VOLT PARAMETERS IN PLAIN !

You can try to increase the volt/freq, but these are my parameters, working fine.

FOR THE HARDWARE :

Use a PC PSU, wire yellow and black for the 12V lines on the PSU to the U3 (I cut the wires of the crappy PSU they included to scavage the plug) and the red/black 5V lines of the PSU to power your USB Hub.


PS : I should receive 2 more this week, I will let you know if they work too.

[-ck]

- clone 4.9.2 from https://github.com/ckolivas/cgminer and not from the bitmaintech
- compile it using sudo autogen.sh  --enable-bmsc --enable-bitmain --enable-icarus and sudo make

You're giving confused advice there. Neither the --enable-bmsc option nor the --enable-bitmain option is in the master cgminer you're cloning so it won't do anything. Only --enable-icarus does anything on master cgminer and is the only thing required for this device.

[sico2819]

Ok, I wasn't sure of the options for the configure, so I copy/pasted them blindly.

Thank for the corrections, I will edit the previous message !

[sico2819]

By the way, they are pointed at solo.ckpool 

[efodix]

How often did they get stuck before you cut the wire?

Well, it's not the USB power causing the zombie, had 2 zombie after about 35 hours with the 5V wire cut (about 5 min apart) and had to do the power cycle to get them to come back.

So back to the drawing board.

Ok, but this time around, I suppose you didn't have to unplug the USB cable, right?

That was the first thing I tried, it didn't work, so just shut everything down, switched back to the good cables, and powered back on.

Wait so, you had the USB red wire cut, the device went zombie, you unplugged the power cord, plugged it back in, and the device still remained zombie until you did the same with the USB cable???

No, tried resetting by just pulling USB first (thats all I ever did before cutting the wire), that didn't work. To get them back up, I had to remove the power (while power was down, switched back to the good cables).

So before the device could be reset just by unplugging the USB while leaving the power supply on, and now that the wire is cut, it's reset by unplugging power? That's...odd.

Maybe some current is flowing through the black wire too? Though if you cut it, you might end up messing up the potential difference. Maybe it would work if you'd connect the black USB wire with the black PSU wire.

Also, I can't help but notice the devices zombied out almost simultaneously. Is that often the case?

[Jake36]

So before the device could be reset just by unplugging the USB while leaving the power supply on, and now that the wire is cut, it's reset by unplugging power? That's...odd.

Maybe some current is flowing through the black wire too? Though if you cut it, you might end up messing up the potential difference. Maybe it would work if you'd connect the black USB wire with the black PSU wire.

Also, I can't help but notice the devices zombied out almost simultaneously. Is that often the case?

It was the first time I actually seen them do it 1 right after the other. Most times (during the night or when I'm not home) it might be 2 - 3 hours (or days) in-between.

And yes, before I cut the wire, I just unplugged USB and they reset (don't know if I was just lucky or what). With the wire cut, it was the first time I had to unplug the power to get it back.

Another observation, if when checking on them, if you see any hashing around 25 - 30GH or lower, you might as well pull the USB and reset it. If not, it might take 10 minutes, 2 hours, or longer for it to zombie and it'll probably wait until your not around.

[bmoscato]

I don't understand why I had one unit hashing for literally months and once I add 2 units they all zombie out within a few hours of each other. I have yet to have all three units last more than 30 hours without them going ZOMBIE. It seems like it's a driver issue.

[efodix]

Hm..that's quite odd. What *may* be happening is that unplugging the USB creates a temporary voltage drop which resets the USB chip even though it is still powered from the other side. It takes time (a few milliseconds, but seemingly enough) for power supply to compensate for the power drop. When the red wire is cut, the chip is working, but unplugging the wire makes no effect on the current flow, and therefore there is no voltage spike.

Can the device be reset programatically from within cgminer?

[-ck]

Can the device be reset programatically from within cgminer?

Cgminer tries to reset it every way possible - watch for the reset messages which occasionally work. This cannot be fixed on the software end.

[Mikestang]

Can the device be reset programatically from within cgminer?

Cgminer tries to reset it every way possible - watch for the reset messages which occasionally work. This cannot be fixed on the software end.

Cgminer will succeed, too.  You'll notice this as the AU3 # changes.  It starts at AU3 0, then AU3 1, AU3 2, etc.  But eventually only a hard reset will cure the ZOMBIE.

[efodix]

Can the device be reset programatically from within cgminer?

Cgminer tries to reset it every way possible - watch for the reset messages which occasionally work. This cannot be fixed on the software end.

How about disabling/enabling USB port?

[.anto.]

How about disabling/enabling USB port?

I am wondering of what would you expect to happen by doing that, as I doubt that will solve the issue.

In the last 2 weeks, I have trying myself to find the solution for the issue on my 2 Antminer U3 which are intermittently stuck after hashing for more than 12 hours at 55 GH/s all-time average. I can push the hash rate to above 60 GH/s, but they become more unstable. When they are stuck, as everybody else on this thread have mentioned, the only solution is to power cycle them. Perhaps I could build automatic power switch controlled by Arduino board, but I think that is too much of hassles. I also tried to clean and re-apply the best thermal compound that I could find, but that only helps stabilise a little bit.

Unlike everybody who experienced the same issue, I am using BFGMiner 5.2.0 on my WiFi router which is running OpenWrt 14.07 where I plugged both miners to. If you would like to read the story of my experience, you could have look on this issue page.

I am using the usbreset utility to try to flush anything on USB interface before restarting BFGMiner process. But when Antminer U3 refuses to work, BFGMiner cannot communicate with the ASIC chips even when the USB interface is up and running.


OOhh... by the way, this is my first post here in this forum, so hello everybody

Cheers,

Anto

[Mikestang]

I am using BFGMiner 5.2.0

What is your command line to use the U3 w/5.2.0?  Do you use the timing function, or ignore it?  Thanks.

[.anto.]

I am using BFGMiner 5.2.0

What is your command line to use the U3 w/5.2.0?  Do you use the timing function, or ignore it?  Thanks.

Hi Mikestang,

As I wrote on the issue list page of BFGMiner that I previously pointed out, I am using the parameters voltage=x775, clock=x0882 and timing=0.0162. As far as I understood, all 3 parameters are critical to the performance of Antminer U3. I have played around with all of those 3 parameters, but I didn't have time to try all possible combinations. I usually use the config file as it is easier to maintain the settings. But if I would use a command line which includes those 3 parameters, I would do it as below assuming that the miner is connected to /dev/ttyUSB0.

Code:

bfgminer --scan antminer:/dev/ttyUSB0 --set antminer:voltage=x775 --set antminer:clock=x0882 --set antminer:timing=0.0162 -o <mypool> -u <myusername> -p <mypassword>

My target is to have stable miners at around 55 GH/s average hash rate. From what I have observed, Antminer U3 is more stable with VDD below 0.8 V. But if we set it too low, e.g. below 0.75 V (minimum VDD of BM1382), it does not behave as expected. That is why I chose 0.775 V as 225 MHz clock (x0882) requires at least 0.75 V according to Antminer U3 user guide.

Now, the timing parameter is the most difficult one to define for me. Perhaps because there seems to be no documentation about it or I could not find any. There seems to be no relation between the timing parameters and the other two.

I did quite a lot of trial and errors to get the right figure (as I thought it so). Even on the same Antminer U3, after changing the timing parameter to some different values, I could not get relatively same hash rate when I set it back the the previous value. I sometime need to power cycle the miner. So the timing parameter seems to be varied amongst different Antminer U3. You possibly would not get the same hash rate as I did. Perhaps you could use my figure above as your reference. You will get lower hash rate if you increased that figure, and vise versa. As I mentioned before, if the hash rate didn't change after you change the timing, you might need to power cycle the miner. And you need to wait at least 10 minutes until the hash rates stabilised.

Cheers,

Anto

[efodix]

How about disabling/enabling USB port?

I am wondering of what would you expect to happen by doing that, as I doubt that will solve the issue.

Well, this other guy said he was able to get his working again only by unplugging and replugging the USB cable, no power cycle whatsoever. So I was thinking, disabling and enabling USB can be done programatically, if it does the same thing.

[-ck]

How about disabling/enabling USB port?

I am wondering of what would you expect to happen by doing that, as I doubt that will solve the issue.

Well, this other guy said he was able to get his working again only by unplugging and replugging the USB cable, no power cycle whatsoever. So I was thinking, disabling and enabling USB can be done programatically, if it does the same thing.

There is no such mechanism that can be done in software. I already said cgminer did everything it could do via software.

[efodix]

How about disabling/enabling USB port?

I am wondering of what would you expect to happen by doing that, as I doubt that will solve the issue.

Well, this other guy said he was able to get his working again only by unplugging and replugging the USB cable, no power cycle whatsoever. So I was thinking, disabling and enabling USB can be done programatically, if it does the same thing.

There is no such mechanism that can be done in software. I already said cgminer did everything it could do via software.

Yeah, I know, just mentioned it in the case you missed something

Oh well, then Arduino relay is the only way to go.

[.anto.]

Well, this other guy said he was able to get his working again only by unplugging and replugging the USB cable, no power cycle whatsoever. So I was thinking, disabling and enabling USB can be done programatically, if it does the same thing.

As I mentioned on my first ever post on this forum, I am using usbreset utility of OpenWRT on my WiFi router where the miners are plugged in. I thought that could help resetting the state of the USB interfaces. But there seems to be no problem on the USB interface at the miners' side as they are always alright since the reset commands always returns "Ok". I guess there must be something else inside the miner that is randomly stuck.

[Laviathon]

What would you guys say is the optimum Difficulty for a U3.  I have a set of 3 mining on Slush's that i bought before my other big miners.  Just cant stomach to turn them off.   What do you think I should try to set the difficulty in order to maximize them.