New Official AMT Thread

[Stan-O]

Well just a suggestion about creating a new board...  you know that the A2 chip set has identical pin layouts.. so if we want to get serious about mining then we could source our chips directly from Innosilicon and save a bundle.

I inquired with them and a single A1 chips is around $45.   So if you go with your own created boards and maybe a mineral oil (or immerssion)... and then locate yourself beside a hydro-electric damn,  then you have a good chance at being profitiable with Bitcoin mining!

Ants, even the power hungry S1's, are very profitable for me. Even without the current rise in BTC value my 9-Ant pharm is 3/4 'paid off' in just under 3 month of running. I used the quotes because tonight I'll be using most of the BTC earned to order a s2 from Bitmine...

Solid hardware those S2s. A few people bitching over the shipping snafus but they are making geniuine attempts to remedy that for shipping. I got mine in pretty good shape just needed to reseat the cards is all. I got one and it hashes at 960-1200Ghs. No OC needed.

why buy s2's, when you can underclock/undervolt the s1's, and get the same w/GH as the s2?

buy 7 s1's, run them at 160GH/160W, and it will cost you about $1400.  then you would need to spend an extra couple hundred for a 1200W PSU, or 2 750-850s.   total cost=$1700-1800, instead of $2244 for an s2.  

s2 price has come down a lot, so i guess having it all in one neat package would be an advantage over 7 s1's.  i go for cost savings, as i have plenty of room.

 link to s1 how-to

https://bitcointalk.org/index.php?topic=526060.0

[1714940562]

1714940562

[1714940562]

1714940562

[1714940562]

1714940562

[opieum2]

Well in some scenarios it makes sense to have the nice neat package. Honestly the fact that the S2 comes with rail kits is a huge win for me personally. I can mount them and call it a day. No need to create modified setups. Its just a rack n stack and thats it.

[NotFuzzyWarm]

why buy s2's, when you can underclock/undervolt the s1's, and get the same w/GH as the s2?

buy 7 s1's, run them at 160GH/160W, and it will cost you about $1400.  then you would need to spend an extra couple hundred for a 1200W PSU, or 2 750-850s.   total cost=$1700-1800, instead of $2244 for an s2.  

s2 price has come down a lot, so i guess having it all in one neat package would be an advantage over 7 s1's.  i go for cost savings, as i have plenty of room.

 link to s1 how-to

https://bitcointalk.org/index.php?topic=526060.0

Too bulky. Will say my pharm looks pretty neat though with the blue LED fans I put on the Ants. Running them 4 per 24" wide shelf.
Hmm, gonna check out undervolting as would not break my heart to lower power a bit. Pulling around 3.8kw right now for the pharm running 1.65-1.9TH total. Couple hundred for a psu? Way to much! I've been paying $40-50 for new HP 1200w 1U high server psu's through Amazon. Takes a little wiring to use them but work great.

[Stan-O]

why buy s2's, when you can underclock/undervolt the s1's, and get the same w/GH as the s2?

buy 7 s1's, run them at 160GH/160W, and it will cost you about $1400.  then you would need to spend an extra couple hundred for a 1200W PSU, or 2 750-850s.   total cost=$1700-1800, instead of $2244 for an s2.  

s2 price has come down a lot, so i guess having it all in one neat package would be an advantage over 7 s1's.  i go for cost savings, as i have plenty of room.

 link to s1 how-to

https://bitcointalk.org/index.php?topic=526060.0

Too bulky. Will say my pharm looks pretty neat though with the blue LED fans I put on the Ants. Running them 4 per 24" wide shelf.
Hmm, gonna check out undervolting as would not break my heart to lower power a bit. Pulling around 3.8kw right now for the pharm running 1.65-1.9TH total. Couple hundred for a psu? Way to much! I've been paying $40-50 for new HP 1200w 1U high server psu's through Amazon. Takes a little wiring to use them but work great.

i suppose i need to get some of those server psu's.  The desktop ons are way too expensive, like you said.

one of my buddies was telling me about his 5 ants. by undervolting/underclocking, his electric bill goes down $120/month, and his mining revenue only goes down $30-40/month.  not a bad trade off.  plus they are cooler and quieter.

[Stan-O]

Well in some scenarios it makes sense to have the nice neat package. Honestly the fact that the S2 comes with rail kits is a huge win for me personally. I can mount them and call it a day. No need to create modified setups. Its just a rack n stack and thats it.

the single device aspect of the s2 is definitely a plus.  it all depends on your situation.  i have plenty of room in my garage, so would be looking for the cost savings, as opposed to how much room they will take up.

just another option to lower the cost of HW, and give you a quicker ROI. 

[NotFuzzyWarm]

i suppose i need to get some of those server psu's.  The desktop ons are way too expensive, like you said.

one of my buddies was telling me about his 5 ants. by undervolting/underclocking, his electric bill goes down $120/month, and his mining revenue only goes down $30-40/month.  not a bad trade off.  plus they are cooler and quieter.

These are the ones I use, rated for 900w on 115vac, 1,200w on 220vac http://www.amazon.com/1200W-HP-DL580G5-Supply-440785-001/dp/B002P5XUA0/ref=pd_sim_sbs_pc_4?ie=UTF8&refRID=0RR4R5ZBJ24X4E6JSP8N You will use less power as well as they are >96% efficient vs 80-86% for regular PSU.

How to wire them http://www.rcgroups.com/forums/showthread.php?t=2100680
Instead of using a resistor between pin-1 and pin-4 I wired a lil' switch to them for easy turn-on/off. Close the connections and the outputs turn on.

To feed 2 OC's Ants I run two 12ga wire pairs from the PSU and terminate each pair with 2 (4 total) 12" PCIe extender cables from Frozen CPU. Cut the socket ends off of course. Think the cables were around $8 each.

[opieum2]

It is possible to get the driver to do this. It is one reason I am requesting docs on the driver. If it is using the standard A1 driver then I would just need to modify it. But I am largely working blind with the driver side now. I have been reading up a bit on driver coding as its not my strength. But I got enough of a handle on it I think I can make it run a delay just long enough for the hardware to initialize properly.

How much have you read up on the A1's actual chip coms? I see in the pdf on github there are a lot of chip-level detect/response options. Out of my range on the software coding end there but see a lot of possibilities in the command list...

We did rewrite the driver a bit, but moreover wrote in an easy to use i2cdetect app which allowed us to try and set all boards to a specific voltage through the trimpot. For what ever reason, our version of the board (could be the trimpot, could be something else that we never figured out) did not allow the settings of the trimpot to be remembered, hence the default voltage ended up resulting in .92-.94. By creating this extra script, we were able to set all boards at once. It was later implemented in bitmines UI update.

command as follows:

amt-setup

amt-setup dpot (5c-64  seems to be the safe zone)  

depending on the board, components used, heatsink. Where bitmine programs all boards right off the line, we didn't have the luxury.

depending on your board - 5c (higher voltage value)  64 (lower voltage value)  63-64 worked best on pb boards.  In an attempt to try anything, we did a few hundred boards with led, hoping for a better solder between the chips.

scale 5a -5b - 5c -5d- 5e 5f - 60 -61 -62 -63 -64

amt-setup dpot 5d

amt-setup apply

(you've just set a new value - prior to hashing, take a dvm place black to ground and red to any cap next to a chip, you'll get the core voltage)

amt-setup mode

amt-setup mode 16000:720000:2000  this is the under clocked default mode which should be in mode 1.  scale ( 0 - 1 -2 )  correlates to (power saver, nominal, turbo)

set a new mode

amt-setup mode 1 16000:720000:2000

amt-setup apply

amt-setup mode 2 16000:760000:4000

amt-setup apply  

The script also allows for redressing boards among a few other tools which came in handy when individually diagnosing/testing each board on different lots which came out. As we discovered the variation in board performance, and couldn't set the voltage directly on the trimpot, this was the only alternative we could come up with. After we implemented this the initial overall board success went from 2 out of 10 to 4-5 out of 10 off the line, the rest resulting in no chip chain detected from the line, and and extra 20-30% of the successful 40%-50% of new boards off the line, resulting in no chip chain after 2-3 minutes of hashing as well. So out of 10 boards produced, 2 survived.

Why didn't we stop running them and figure out the problem?

We had been constantly met with "Our advise is to keep running, we will address the problems and fix the boards as soon as we understand the problem but since some do work, don't you think you should just ship the ones that and get to the bad ones later".  At the time he had a point, it was more important to deliver. Still looking 100's of bad board daily btw. Things like that were followed by promises of fixing bad boards among several other things.

Anyway, for those of you which have a dvm and know what your doing please play around with the amt-setup options. Reggie is an example of someone that it go it to work with those tools.  In general, we didn't publicize that script in such detail because it allows for direct overclocking, and overclocking leads to RMA anyway which you put it.

Here is my output running the command. This was with a single card plugged in....this is using your default image. Of course this on the bad miner. There is hope here....it FOUND the one card I have plugged in. 0x28 is the card found. That is the first or last in the chain. Either way it found it. BUT the value is invalid. Which means this script needs adjustment as its not setting the values in i2cset correctly Or they are the wrongly formatted. Any suggestions? I have one truly bad card that wont allow the system to power up. The other 4 on this miner appear to be detectable. So there is hope, but I would need the right value to bring it up. I will play with the values a bit and see what kicks up.

Code:

root@AMT-Miner:~# amt-setup dpot 5d
# AMT Miner Setup tool (C) Copyright 2014 AMT Ltd.

# Sun Feb 23 08:05:30 UTC 2014 # New dpot value {dpot=5d}
root@AMT-Miner:~# amt-setup apply
# AMT Miner Setup tool (C) Copyright 2014 AMT Ltd.

# Sun Feb 23 08:05:32 UTC 2014 # Applying settings ...
# Sun Feb 23 08:05:32 UTC 2014 # {addrs=0x28 0x29 0x2A 0x2B 0x2C} {dpot=5d}
# Sun Feb 23 08:05:32 UTC 2014 # * Checking for board at address {addr=0x28} ... [OK] Error: Data value invalid!
Usage: i2cset [-f] [-y] [-m MASK] I2CBUS CHIP-ADDRESS DATA-ADDRESS [VALUE] [MODE]
  I2CBUS is an integer or an I2C bus name
  ADDRESS is an integer (0x03 - 0x77)
  MODE is one of:
    c (byte, no value)
    b (byte data, default)
    w (word data)
    Append p for SMBus PEC
[Setup] Error: Data value invalid!
Usage: i2cset [-f] [-y] [-m MASK] I2CBUS CHIP-ADDRESS DATA-ADDRESS [VALUE] [MODE]
  I2CBUS is an integer or an I2C bus name
  ADDRESS is an integer (0x03 - 0x77)
  MODE is one of:
    c (byte, no value)
    b (byte data, default)
    w (word data)
    Append p for SMBus PEC
[Verify] 0x6300
[OK]
# Sun Feb 23 08:05:32 UTC 2014 # * Checking for board at address {addr=0x29} ... [OK] Error: Data value invalid!
Usage: i2cset [-f] [-y] [-m MASK] I2CBUS CHIP-ADDRESS DATA-ADDRESS [VALUE] [MODE]
  I2CBUS is an integer or an I2C bus name
  ADDRESS is an integer (0x03 - 0x77)
  MODE is one of:
    c (byte, no value)
    b (byte data, default)
    w (word data)
    Append p for SMBus PEC
[Setup] Error: Data value invalid!
Usage: i2cset [-f] [-y] [-m MASK] I2CBUS CHIP-ADDRESS DATA-ADDRESS [VALUE] [MODE]
  I2CBUS is an integer or an I2C bus name
  ADDRESS is an integer (0x03 - 0x77)
  MODE is one of:
    c (byte, no value)
    b (byte data, default)
    w (word data)
    Append p for SMBus PEC
[Verify] 0x6300
[OK]
# Sun Feb 23 08:05:32 UTC 2014 # * Checking for board at address {addr=0x2A} ... [OK] Error: Data value invalid!
Usage: i2cset [-f] [-y] [-m MASK] I2CBUS CHIP-ADDRESS DATA-ADDRESS [VALUE] [MODE]
  I2CBUS is an integer or an I2C bus name
  ADDRESS is an integer (0x03 - 0x77)
  MODE is one of:
    c (byte, no value)
    b (byte data, default)
    w (word data)
    Append p for SMBus PEC
[Setup] Error: Data value invalid!
Usage: i2cset [-f] [-y] [-m MASK] I2CBUS CHIP-ADDRESS DATA-ADDRESS [VALUE] [MODE]
  I2CBUS is an integer or an I2C bus name
  ADDRESS is an integer (0x03 - 0x77)
  MODE is one of:
    c (byte, no value)
    b (byte data, default)
    w (word data)
    Append p for SMBus PEC
[Verify] 0x6300
[OK]
# Sun Feb 23 08:05:32 UTC 2014 # * Checking for board at address {addr=0x2B} ... [OK] Error: Data value invalid!
Usage: i2cset [-f] [-y] [-m MASK] I2CBUS CHIP-ADDRESS DATA-ADDRESS [VALUE] [MODE]
  I2CBUS is an integer or an I2C bus name
  ADDRESS is an integer (0x03 - 0x77)
  MODE is one of:
    c (byte, no value)
    b (byte data, default)
    w (word data)
    Append p for SMBus PEC
[Setup] Error: Data value invalid!
Usage: i2cset [-f] [-y] [-m MASK] I2CBUS CHIP-ADDRESS DATA-ADDRESS [VALUE] [MODE]
  I2CBUS is an integer or an I2C bus name
  ADDRESS is an integer (0x03 - 0x77)
  MODE is one of:
    c (byte, no value)
    b (byte data, default)
    w (word data)
    Append p for SMBus PEC
[Verify] 0x6300
[OK]
# Sun Feb 23 08:05:33 UTC 2014 # * Checking for board at address {addr=0x2C} ... [OK] Error: Data value invalid!
Usage: i2cset [-f] [-y] [-m MASK] I2CBUS CHIP-ADDRESS DATA-ADDRESS [VALUE] [MODE]
  I2CBUS is an integer or an I2C bus name
  ADDRESS is an integer (0x03 - 0x77)
  MODE is one of:
    c (byte, no value)
    b (byte data, default)
    w (word data)
    Append p for SMBus PEC
[Setup] Error: Data value invalid!
Usage: i2cset [-f] [-y] [-m MASK] I2CBUS CHIP-ADDRESS DATA-ADDRESS [VALUE] [MODE]
  I2CBUS is an integer or an I2C bus name
  ADDRESS is an integer (0x03 - 0x77)
  MODE is one of:
    c (byte, no value)
    b (byte data, default)
    w (word data)
    Append p for SMBus PEC
[Verify] 0x6300
[OK]
root@AMT-Miner:~#

[NotFuzzyWarm]

No idea there but have to ask, is the I2C only for setting core voltages or does it serve other functions as well? They aren't passing the hashing data over it as well are they?

More to the point, need a current schematic of at least the regulator stage from AMT (Listening AMT_Miners?) The Bitmine reference board uses a fixed value set by resistors (as do Ants - been reading up on undervolting them ergo...)

The A1 regulator should be able to be hard wired to start at any voltage we want by changing a resistor value and still be programmable. Anyone got a part number on the regulator chip? Most likely starts with LTCxxx

Makes for nice safe starting and would allow a more stand-alone kinda operation if we can find a sweet spot vs clock speed. Again - need a current schem.

[rodeoclownicp]

how come you havent updated the prices on your website

[FrictionlessCoin]

I don't get it,  why is the program called I2Cset when the chipset doesn't use I2C but rather SPI?

[regtable69]

how come you havent updated the prices on your website

i believe everything on the sit front end has to stay "as is " but the back end they can update or add to the site i.e forums but for the legal purpose they cant "alter" the existing information

[opieum2]

I don't get it,  why is the program called I2Cset when the chipset doesn't use I2C but rather SPI?

I believe there is an i2c to SPI bridge, which would explain the need for both and why they are both detected.
I am still understanding those aspects a bit more as I am finding I need the information to make potentially bring the boards back to life.

http://www.i2cchip.com/mix_spi_i2c.html is one resource (of many I found)

The good news is that it might be possible to bring the cards back provided I can find the right command to bring them back. The AMT-setup dpot command (in my previous post) do not appear to work at all as they are coming up with an invalid value. That just means it doesn't work. I am reading through the AMT script to understand the issue.

As you can see in the above I get [OK] Error: Data value invalid! is a sign that the code might not be correct. OR something else is wrong. Hopefully AMT can clear this particular piece up.
The card on the chain is found so that's positive. BUT the command to set it is invalid (bad). I know at this point I have 7 cards that are potentially zombiefiable (new word to add to webster dictionary), I have 3 working cards (not messing with that) and 1 totally dead card that will prevent any sort of power up (need to check it for shorts)

On the hardware side I tried something based on ISAWHIM's mention of the potential board short from the PCB touching the metal cage. I taped up the edges where the cards contact the metal I had hoped on a long shot that might actually bring up a card or two, but no dice

That said least now that is a potential issue that is mitigated. I think the boards COULD be brought back with software. Maybe not all but some of them. The fact that the i2cset commands was not actually taking because the value was invalid would be a good reason why this happened. I am currently testing now with AMT's default firmware before I move on to the porting process (which I have partially done). I figure it might be best doing it with what is already available before reinventing the wheel. If I get the cards back up then I will proceed with the next steps of porting over to the new firmware.

I think there is progress tho seeing as the cards are detected but nonfucntional at this point. Hopefully not beyond the point of recovery.

EDIT: To add I am working on the i2cset commands to do all this manually if I have to (not something I recommend to anyone not experienced in this sort of thing), and seeing how the script interacts with that. If I can manually do this bypassing the script I will modify the existing scripts to issue the correct commands and add comments in the scripts for proper use. Its fairly trivial to add the usage part.  That might actually get the hardware working. While the progress is slow (in my opinion) its progress that's happening. My time is limited so I really only put in a couple hours a day on this at most.

[sabre]

how come you havent updated the prices on your website

i believe everything on the sit front end has to stay "as is " but the back end they can update or add to the site i.e forums but for the legal purpose they cant "alter" the existing information

No that's incorrect. They made some cosmetic changes to the website just a couple days ago so the website is not locked down. As I had stated before, for lawsuit discovery purposes you would just make a copy of the website which would suffice and that is what would be submitted in the court case.

AMT not updating their website is just AMT being AMT.

[AMT_miners]

how come you havent updated the prices on your website

i believe everything on the sit front end has to stay "as is " but the back end they can update or add to the site i.e forums but for the legal purpose they cant "alter" the existing information

No that's incorrect. They made some cosmetic changes to the website just a couple days ago so the website is not locked down. As I had stated before, for lawsuit discovery purposes you would just make a copy of the website which would suffice and that is what would be submitted in the court case.

AMT not updating their website is just AMT being AMT.

Chuckle. No we're updating it all together, changing direction and strategy as you'll see. for the moment we're kind of just leaving at as it until everything is finished, a day or two tops.

[AMT_miners]

We'll get back to the other technical questions a bit later today.

[opieum2]

We'll get back to the other technical questions a bit later today.

Thanks looking forward to it.

[regtable69]

I don't get it,  why is the program called I2Cset when the chipset doesn't use I2C but rather SPI?

I believe there is an i2c to SPI bridge, which would explain the need for both and why they are both detected.
I am still understanding those aspects a bit more as I am finding I need the information to make potentially bring the boards back to life.

http://www.i2cchip.com/mix_spi_i2c.html is one resource (of many I found)

The good news is that it might be possible to bring the cards back provided I can find the right command to bring them back. The AMT-setup dpot command (in my previous post) do not appear to work at all as they are coming up with an invalid value. That just means it doesn't work. I am reading through the AMT script to understand the issue.

As you can see in the above I get [OK] Error: Data value invalid! is a sign that the code might not be correct. OR something else is wrong. Hopefully AMT can clear this particular piece up.
The card on the chain is found so that's positive. BUT the command to set it is invalid (bad). I know at this point I have 7 cards that are potentially zombiefiable (new word to add to webster dictionary), I have 3 working cards (not messing with that) and 1 totally dead card that will prevent any sort of power up (need to check it for shorts)

On the hardware side I tried something based on ISAWHIM's mention of the potential board short from the PCB touching the metal cage. I taped up the edges where the cards contact the metal I had hoped on a long shot that might actually bring up a card or two, but no dice

That said least now that is a potential issue that is mitigated. I think the boards COULD be brought back with software. Maybe not all but some of them. The fact that the i2cset commands was not actually taking because the value was invalid would be a good reason why this happened. I am currently testing now with AMT's default firmware before I move on to the porting process (which I have partially done). I figure it might be best doing it with what is already available before reinventing the wheel. If I get the cards back up then I will proceed with the next steps of porting over to the new firmware.

I think there is progress tho seeing as the cards are detected but nonfucntional at this point. Hopefully not beyond the point of recovery.

EDIT: To add I am working on the i2cset commands to do all this manually if I have to (not something I recommend to anyone not experienced in this sort of thing), and seeing how the script interacts with that. If I can manually do this bypassing the script I will modify the existing scripts to issue the correct commands and add comments in the scripts for proper use. Its fairly trivial to add the usage part.  That might actually get the hardware working. While the progress is slow (in my opinion) its progress that's happening. My time is limited so I really only put in a couple hours a day on this at most.

Type amt-setup dpot 0xvalue not dpot value then amt-setup apply. That should work

[opieum2]

Ahh yea thats what I thought. I was not 100 percent on it. Ok I will try that. Thanks.

[NotFuzzyWarm]

Re-found another thermal management company I had forgotten about http://www.thermacore.com/default.aspx
Ta boot, they are located in Lancaster PA..

[opieum2]

I don't get it,  why is the program called I2Cset when the chipset doesn't use I2C but rather SPI?

I believe there is an i2c to SPI bridge, which would explain the need for both and why they are both detected.
I am still understanding those aspects a bit more as I am finding I need the information to make potentially bring the boards back to life.

http://www.i2cchip.com/mix_spi_i2c.html is one resource (of many I found)

The good news is that it might be possible to bring the cards back provided I can find the right command to bring them back. The AMT-setup dpot command (in my previous post) do not appear to work at all as they are coming up with an invalid value. That just means it doesn't work. I am reading through the AMT script to understand the issue.

As you can see in the above I get [OK] Error: Data value invalid! is a sign that the code might not be correct. OR something else is wrong. Hopefully AMT can clear this particular piece up.
The card on the chain is found so that's positive. BUT the command to set it is invalid (bad). I know at this point I have 7 cards that are potentially zombiefiable (new word to add to webster dictionary), I have 3 working cards (not messing with that) and 1 totally dead card that will prevent any sort of power up (need to check it for shorts)

On the hardware side I tried something based on ISAWHIM's mention of the potential board short from the PCB touching the metal cage. I taped up the edges where the cards contact the metal I had hoped on a long shot that might actually bring up a card or two, but no dice

That said least now that is a potential issue that is mitigated. I think the boards COULD be brought back with software. Maybe not all but some of them. The fact that the i2cset commands was not actually taking because the value was invalid would be a good reason why this happened. I am currently testing now with AMT's default firmware before I move on to the porting process (which I have partially done). I figure it might be best doing it with what is already available before reinventing the wheel. If I get the cards back up then I will proceed with the next steps of porting over to the new firmware.

I think there is progress tho seeing as the cards are detected but nonfucntional at this point. Hopefully not beyond the point of recovery.

EDIT: To add I am working on the i2cset commands to do all this manually if I have to (not something I recommend to anyone not experienced in this sort of thing), and seeing how the script interacts with that. If I can manually do this bypassing the script I will modify the existing scripts to issue the correct commands and add comments in the scripts for proper use. Its fairly trivial to add the usage part.  That might actually get the hardware working. While the progress is slow (in my opinion) its progress that's happening. My time is limited so I really only put in a couple hours a day on this at most.

Type amt-setup dpot 0xvalue not dpot value then amt-setup apply. That should work

Ok I ran the 0x5d and that worked. Still no joy on the single card. It claims it ok verified everything but only one card is actually plugged in. So I have to check what its actually verifying now. OR its configuring the backplane. Not sure tho. Also tried the lowest setting 64 just to keep things in a conservative state. I want to make sure I dont pop anything. Since the card is not actually starting its hard to say what the issue is. Not sure what you guys ran into on your end with this.

If there were any instances of reviving the card that bit of info would be good here. I might be able to automate this process IF there is one to automate.