Bitminter client (Windows/Linux/Mac)

[basvw23]

so again i learn an new thing.. thanks
Isn't it an idea then that you can give a specific usb minor a unique name or isn't that possible?
I want the U1 do 1,6 ghz and the U2 do 2,0 GHz my server is in the my basement so it can be pretty handy i can give them an unique id to indentefy each other. it is just a suggestion, thanks for listing and good luck with improve bitminer, its already great...
regards,
bas vw

[DrHaribo]

so again i learn an new thing.. thanks
Isn't it an idea then that you can give a specific usb minor a unique name or isn't that possible?
I want the U1 do 1,6 ghz and the U2 do 2,0 GHz my server is in the my basement so it can be pretty handy i can give them an unique id to indentefy each other. it is just a suggestion, thanks for listing and good luck with improve bitminer, its already great...

You can do this today. Each has their own setting. Only problem is if they trade places, U1 on COM1 and U2 on COM2 originally. You set different speeds. Later for some reason the U1 is on COM2 and U2 on COM1, and the client will attempt to run them with wrong speeds. I think this will normally not happen if you keep them plugged into the same USB ports.

[basvw23]

thanks, and keep up the good working

[DrHaribo]

Bitminter client v1.6.0 is out.

New:

• Switch to Stratum mining protocol
• Show worker difficulty changes in the log
• Show the block's hash in the log when a block is found
• Remove display of queued work from status line (work now generated locally)

Try it now:


Note: if you were using the "port 80" option to bypass a firewall then this release will probably not work for you. v1.5.0 will still be available in the "tools" menu at bitminter.com for some time. If you have firewall issues, let me know what your needs are, or better yet, fix the firewall.

If you have a problem with 1.6.0 you can still load 1.5.0 from here: https://bitminter.com/client/1.5.0/bitminter.jnlp

If you restart the client and still see 1.5.0, try clearing your java cache. See http://www.java.com/en/download/help/plugin_cache.xml

[GuyllFyre]

so again i learn an new thing.. thanks
Isn't it an idea then that you can give a specific usb minor a unique name or isn't that possible?
I want the U1 do 1,6 ghz and the U2 do 2,0 GHz my server is in the my basement so it can be pretty handy i can give them an unique id to indentefy each other. it is just a suggestion, thanks for listing and good luck with improve bitminer, its already great...
regards,
bas vw

I'm finding that pretty much all of my U1 will run at 2GHps and that my U2s don't run any faster, even with the larger heat sink.
I think all of them probably need the resistor upgrade, then good heat sinks, and then they can be run easily at 2GHps and hopefully faster if I do it right.

-S

[pazsion]

 

thought i'd come by and say a uninstal and re-instal of 1.4.2 fixed my issues

Not too knowledgeable about these hashing rigs being talked about here.

But a good heatsink goes a long way, even if you don't see improvements in the individual programs or benchmarks. Finding software that can benchmark without stress testing will be a better guide to knowing how modifications have improved what.

You may need something to look at transfer speeds and chip speeds for the device itself, and w/e ports it's attached to.

haveing higher quality parts, such as capacitors/resistors help the voltages remain constant or for resistors, at a certain voltage range. i'm guessing people are finding its overvolting when it overclocks?

I've found a process monitor software called "process hacker 2" that is free ware. and has many tools in it that are helpful, some features are unlocked when run as an admin. this has been most helpful monitoring network and i/o etc. The software is best in the hands of an experienced pc user. But many things can be useful to all. Just be careful. Read up on anything you don't know. Ask me if you wish.

ps: again i have no experience placeing large metal objects on a antminer u1 or u2. but it seems people are putting a heatsink on the backside of the pcb, and leaveing the chips exposed. from first apperances, using thermal seems foolish directly on the pcb with some waffled? copper base?

Not using thermal would mean your not getting much use or contact with the parts your trying to cool.

Leaving the chips your trying to cool exposed limits their potential and drastically shortens their lifespan. yes i would suggest a heatsink for the entire unit. pcb and all. And delicate placement of tiny ammounts of thermal nanodiamond or 99%w/v silver. or a mix of these 2. with individual heatsinks for the chips. Get some anti-static wrap, cut some peices to lay over the edges of the chips to cover any exposed metal surfaces. I might buy some of these and try this haha.

[adbulla]

Can you also tell me how the "shift" influences my personal earnings? Will I loose some of my personal minings having less efficient hardware vs. users having more expensive hardware?

[DrHaribo]

Can you also tell me how the "shift" influences my personal earnings? Will I loose some of my personal minings having less efficient hardware vs. users having more expensive hardware?

Someone who has 10 times more hashpower will get 10 times more. Someone who has lower electricity usage (better efficiency) or cheaper electricity will have lower expenses.

[lennert1984]

I use 2 BitFury Red Fury's.
I've seen some other complaints here as well about them not working properly.

Any updates?

I keep getting thesame error.

2014.04.15 [19:36]  Probe of port COM83 failed: timeout
2014.04.15 [19:36]  Probe of port COM82 failed: timeout

The drivers are installed perfectly.

Windows 8.1 64bit


Does anyone have a solution?

[DrHaribo]

I use 2 BitFury Red Fury's.
I've seen some other complaints here as well about them not working properly.

Which driver did you install?

Are they being detected and mine for a while, but then fail? Or not being detected at all?

I have one red fury running perfectly stable. The only problem is sometimes if I stop mining and try to start again the red fury gets confused and refuses to work. Then I have to unplug it and plug it back in, and it works again. I believe this is a bug/issue with all red fury units.

[Jovim]

Hi! I already posted this issue in the " Bitmain AntMiner U1 Tips & Tricks topic" but maybe here someone can have the same issue.

I have a problem with two of my Antminer U2 (rev 1.2).

I'm using bitminter software to run those, another U2, a block erupter USB and mu GPU.

All the miners are resitor moded and thei ar getting ~1.1V

I can clock one of the U2 to 3GH/s with no/few errors but with the other two I'm only able to clock it to 1.65GH/s or sometimes to 1.75GH/s

Then I figured out one thing, imagine that Antminer n.1 (that is the one that i can clock to 3GH/s)is detected as COM10  Antminer n.2 as COM11 and Antminer n.3 as COM12.
If i change usb ports uith Antminer n.1 and antminer n.2 now antminer n.1 is detected as COM 11 and antminer n.2 as COM10 doing this and starting the antminer n.2 is now clocked at 3GH/s (wow!!! ) and n.1 was with the clock that n.2 had previously, now I set the n.1 clock again to 3GH/s and it works (its not an USB port problem) then I sitched again n.1 with n.3 and surprise surprise it started doing 3GH/s too, the i just set the clock again on the n.1 and it started doing 3GH/s too, so now i have all three doing 3GH/s.

My question is... is that a problem with bitminter or is it a problem with the Antminers?

when i try to change the clock beyond 1.65GH/s on those antminers i get this

Code:

2014.04.17 [16:08] Antminer (COM37): Tuning timers. 
2014.04.17 [16:08]  Antminer (COM37) ERROR: Selftest error. Expected nonce 0xFFFFFE0E but got 0xF9AEBE00. 
2014.04.17 [16:08]  Antminer (COM37) ERROR: Selftest error. Expected nonce 0xFFFFFE0A but got 0x8C000000. 
2014.04.17 [16:08]  Antminer (COM37) ERROR: Selftest error. Timed out at 25001 ms. 
2014.04.17 [16:08]  Antminer (COM37) ERROR: Selftest error. Expected nonce 0xFFFFFE0A but got 0x8E000000. 
2014.04.17 [16:09]  Antminer (COM37) ERROR: Selftest error. Timed out at 25000 ms. 
2014.04.17 [16:09]  Antminer (COM37) ERROR: Selftest error. Timed out at 25000 ms. 
2014.04.17 [16:10]  Antminer (COM37) ERROR: Selftest error. Timed out at 25000 ms. 
2014.04.17 [16:10]  Antminer (COM37) ERROR: Selftest error. Timed out at 25000 ms.

sometimes the "Expected nonce 0xFFFFFE0E but got 0xF9AEBE00" error does not show but the time out error shows every time i try to change the clock

I hope that I was clear enough, I'll explain better if anyone get any doubt about my problem

[DrHaribo]

Bitminter client identifies the devices by their COM number. So if they get switched then they will get the wrong settings.

I could fix this for Red Fury which reports a serial number. But I don't know how I could fix this for Antminer. I don't think there's a way to tell one device apart from the other.

[Jovim]

maybe I was not clear... the thing is that when I swap the antminers from one usb to another where the antminer that works fine was, then they start to work fine with the settings that the good antminer had (but previously they didn't get even to 2GH/s) is that a bug on the bitminter software or or is it a problem with the antminers? the antminers must have some difference but they are able to work at the same speed as I had proven with that swap.

Is there a way to disable self test? Maybe it would work fine without self test

[freddyfarnsworth]

Bitminter client identifies the devices by their COM number. So if they get switched then they will get the wrong settings.

I could fix this for Red Fury which reports a serial number. But I don't know how I could fix this for Antminer. I don't think there's a way to tell one device apart from the other.

Setting serials with the editor (which is available) on U1 and U2's is a pain, because you can only have 1 in the hub or USB ports at a time or the editor will not work properly.

I did one of mine to ANT0001 just to see as I wanted to be able to find the slow/misbehaving ones easy. Trouble is, they run fine

Editor is available for the silabs driver bios.


+++++++++++++++++++++++++++++++++++++++

P210x Customization Utility v3.0 Release Notes
Copyright (C) 2010 Silicon Laboratories, Inc.

This release contains the following components:

        * CP210xManufacturing.dll (v5.0)
        * CP210xManufacturingDLL.h
        * CP210xManufacturing.lib
        * CP210xSetIDs.exe (v3.0)
        * CP210xSetIDs_SRC.zip
        * ReleaseNotes.TXT (this file)

KNOWN ISSUES AND LIMITATIONS
----------------------------

   1.) Only CP2101, CP2102, CP2103, CP2104 and CP2105 devices are supported by this utility.

   2.) CP210xManufacturing.dll must be in the same directory as CP210xSetIDs.exe.

Release Dates
-------------

   CP210x Customization Utility v3.0 - Sep 23, 2010


REVISION HISTORY
-----------------

version 3.0
   Updated to include CP2105 support
   Now contains version 5.0 of the CP210xManufacturing.DLL
   Added Flush Buffer configuration for both CP2104 and CP2105
   Added Interface String configurations for CP2105
   Updated source code to Visual Studio 2005

version 2.3a
   Now contains version 4.1 of the CP210xManufacturing.DLL

version 2.3
   Updated to include CP2104 support
   Now contains version 3.5 of the CP210xManufacturing.DLL
   
version 2.2
   Updated software to contain an About button for easy version access
   Now contains version 3.4 of the CP210xManufacturing.DLL

version 2.1a
   No software change, but now contains version 3.3 of the CP210xManufacturing.DLL

version 2.1
   Updated for use with version 3.0 of the CP210xManufacturing.DLL that makes use
   of the 5.0 VCP driver.

version 2.0
   Changed GetNumDevices to not return an error when there are 0 devices connected.
   Fixed the "Locked Byte always 1" bug.

version 1.1
   CP210xManufacturing DLL CP210x_GetProductString, CP210x_SetProductString,
   CP210x_GetSerialNumber and CP210x_SetSerialNumber updated so that the UNICODE
   options work according to documentation, length is returned as number of characters
   without the NULL character.

   CP210xManufacturing DLL PORT_CONFIG structure updated according to documentation.

version 1.06
   CP210xManufacturing DLL CP210x_GetLockValue() changed to return 0x00 or 0x01.

version 1.05
   CP210xManufacturing DLL changed to allow support for CP2013 devices.

version 1.04
   Name of CP210x.DLL changed to CP210xManufacturing DLL.

version 1.03
   CP2102 Support added, and renamed to show support for "CP210x" devices.

Version 1.02
   Changed CP2101 DLL to return an error if a 0 length string is passed.
   GUI layout of CP2101SetIDs changed.

Version 1.01
   Max character length of the serial number changes to 63.
   Max character length of the product string changes to 126.
   CP2101_DEVICE_STRING type for the full path.
   CP2101_PRODUCT_STRING type for the the product string.
   CP2101_SERIAL_STRING type for the serial number.
   
Version 1.0
   Initial Release

[DrHaribo]

maybe I was not clear... the thing is that when I swap the antminers from one usb to another where the antminer that works fine was, then they start to work fine with the settings that the good antminer had (but previously they didn't get even to 2GH/s) is that a bug on the bitminter software or or is it a problem with the antminers? the antminers must have some difference but they are able to work at the same speed as I had proven with that swap.

Is there a way to disable self test? Maybe it would work fine without self test

The self test is that the app sends some work to the device where it knows what the answer should be. If this comes back wrong, that's not good. You'd get hardware errors while mining. It does try several times though, and if the device is able to get it right once, it will mine (and get some hardware errors, but hopefully not 100%). If it gets no good results for a while, it runs self test again.

I'm not sure what's going on there. Bitminter client treats them the same, I don't think there's a problem there. But I really don't know why one COM port would work better than another. Is there any difference between the ports? Or are they all the same (on PC, or on same hub)?

[Jovim]

maybe I was not clear... the thing is that when I swap the antminers from one usb to another where the antminer that works fine was, then they start to work fine with the settings that the good antminer had (but previously they didn't get even to 2GH/s) is that a bug on the bitminter software or or is it a problem with the antminers? the antminers must have some difference but they are able to work at the same speed as I had proven with that swap.

Is there a way to disable self test? Maybe it would work fine without self test

The self test is that the app sends some work to the device where it knows what the answer should be. If this comes back wrong, that's not good. You'd get hardware errors while mining. It does try several times though, and if the device is able to get it right once, it will mine (and get some hardware errors, but hopefully not 100%). If it gets no good results for a while, it runs self test again.

I'm not sure what's going on there. Bitminter client treats them the same, I don't think there's a problem there. But I really don't know why one COM port would work better than another. Is there any difference between the ports? Or are they all the same (on PC, or on same hub)?

Yes they are in the same computer and they are plugged directly to my pc USB's (they can deliver much more than 500mA) the thing is that I can't set a clock directly on those antminers I have to "preset" with the miner that works fine and then change. they are now working at 3GH/s for more than 4 hours with more than 10000 prof of work each and 0 hardware errors (I have active cooling to prevent over heating, a small 5V 25*25mm fan on each one does the trick). so they can effectively mine at those speeds. I just dont understand why I'm not able to set the clock directly  

[DrHaribo]

Hm, that is odd. I only have one Antminer U1 and I can change the speed up and down fine with it plugged in.

Does it help if you set their speed to 3 GH/s, see two of them fail, then restart Bitminter client?

I don't know what is causing that issue. Anyone else having such problems?

[Fluke.]

Hm, that is odd. I only have one Antminer U1 and I can change the speed up and down fine with it plugged in.

Does it help if you set their speed to 3 GH/s, see two of them fail, then restart Bitminter client?

I don't know what is causing that issue. Anyone else having such problems?

I have a similar problem with one of my Ants U2. When trying to set the speed above 1.6 GH/s the self test times out almost every time. But if I got it work after numerous times trying or with the "trick" changing with another Ant, it works fine for example at 2.0 GH/s with zero miscalculations.

[Jovim]

Hm, that is odd. I only have one Antminer U1 and I can change the speed up and down fine with it plugged in.

Does it help if you set their speed to 3 GH/s, see two of them fail, then restart Bitminter client?

I don't know what is causing that issue. Anyone else having such problems?

no, restart bitminter does not help  

I have a similar problem with one of my Ants U2. When trying to set the speed above 1.6 GH/s the self test times out almost every time. But if I got it work after numerous times trying or with the "trick" changing with another Ant, it works fine for example at 2.0 GH/s with zero miscalculations.

Yes that's what it's happening with me, but my Ants are volt moded and i can reach 3GH/s without errors

[janonathon]

I have finally filled up all my ports with ONLY U1's and U2's and have had a lot of instability and often returns back to the company with U2's vs. U1's. I've had to return 5/13 U2's and not a single one of my 21 U1's.

Since my supplier was so nice as to not to make me ship them back and simply take my word for it, I've got a handful of heatsinks to put on some U1's that don't get as much fan coverage as the others. They almost all run at 2.0 whether they're a 1 or a 2, anything more, apart from a few running 2.1, and i just get huge loads of hardware errors.

Just thought I'd throw my experiences in here.