New Official AMT Thread

[regtable69]

Been staying quiet on here up to press due to not wanting to be a fan boy or amt shill as i have been called.

*update*
Mine and mellorbos rig has had 100% uptime since arrival minus user issues being putty shutdowns ethernet cables dropping out and general wtf moments.
 tried a variety of alt coins some work better than others but evidently give the same 0.03 btc a day.

share sizes have now dropped from the original 80000 sats btc th approx 59000 sats btc. no special anything just lots and lots of fans and the gigantic antec case fan on top.

on a side not the rig is keeping the room it is in at a steady 34*c in the late uk evening a little more through peak sun.

i to recieved an invoice for the order recieved hopes im receiving another one :-)

glad to see your still in here amt despite having 90% of your tongue cut out.

[1714156707]

1714156707

[1714156707]

1714156707

[1714156707]

1714156707

[1714156707]

1714156707

[1714156707]

1714156707

[NotFuzzyWarm]

Mmm. Guess we gave them somethings to chew on for a while

[opieum2]

Mmm. Guess we gave them somethings to chew on for a while

I requested some driver info so I can get these things working. That is my hold up at the moment. I might be able to get it working without the driver info, I am still working at it.

[FrictionlessCoin]

Mmm. Guess we gave them somethings to chew on for a while

I requested some driver info so I can get these things working. That is my hold up at the moment. I might be able to get it working without the driver info, I am still working at it.

Why do you need a new driver when a couple of folks supposedly don't have a problem running the system?

[ISAWHIM]

Mmm. Guess we gave them somethings to chew on for a while

Yes I noticed the large negative ground-shielding, surrounded by large positive plates, which is the essence of an electrical capacitor. (Two plates of opposite polarity, separated by a layer of non-conductive medium.) Might explain the electrical run-off that is causing the VR to bump-up in time, which leads to ever-increasing voltage, leading to more capacitance, leading to more increasing voltage.

I am just not sure why one board does this, over another board, being all of the same design. With exception to the issue of substituted parts that may be leading to the failure. So hard to see some of the numbers of the smaller components.

I will be mapping-out the contacts tonight, and grinding-down one heat-sink, a fraction of a MM, which should be enough to avoid any thermal-grease issues, avoid all potential through-hole contacts, and give a more localized point of pressure contact. With less metal resting against the PCB itself.

I will be grinding the contact points about 1 MM smaller than the exposed metal, since the excess compound will squish-out to that small gap.

Going to look at the caps, and check the values.

P.S. I got my invoice today... Though it indicates the incorrect price. I paid $6089.00 not $5599.00 as the invoice indicates. (That was the earlier price, which I had just missed. I had to pay the $6089.00 price. Which is indicated on the AMT website invoice.)

[ISAWHIM]

Mmm. Guess we gave them somethings to chew on for a while

I requested some driver info so I can get these things working. That is my hold up at the moment. I might be able to get it working without the driver info, I am still working at it.

Why do you need a new driver when a couple of folks supposedly don't have a problem running the system?

Because some of us do...

That is like windows saying, why patch windows, it works for a few... xD

Though, for my situation, where I am seeing the miner increase in hashing over time, on the faulting cards... It will not make much difference. It was the faulting cards stopping the rest of the cards from operating normally. However, something is still causing the boot-up failure to stop at "MONITOR".

In all honesty, I want the new software, just so I can tune the hashing-power, where I can not now. Especially when the errors get so high, that the hashing-power indicated on the screen, is not reflected in the hashing-results in the pool, due to the errors being obviously not sent, or rejected by the server after being sent. However, that is not my primary concern at the moment. My concern is getting more than 2 cards running.

Also, getting hold of at-least one more heat-sink, so I can run my system as 3 and 3 cards. At the moment, I only have five heat-sinks. Three are on cards that no longer function. (Well, they no longer show in the system, when hooked-up.) The power-supply I have coming, has no use until I can get at-least three more cards running. So I at-least have five hashing.

[FrictionlessCoin]

Mmm. Guess we gave them somethings to chew on for a while

I requested some driver info so I can get these things working. That is my hold up at the moment. I might be able to get it working without the driver info, I am still working at it.

Why do you need a new driver when a couple of folks supposedly don't have a problem running the system?

Because some of us do...

That is like windows saying, why patch windows, it works for a few... xD

That assumes that the hardware is different,  don't we have the same hardware?

[ISAWHIM]

Mmm. Guess we gave them somethings to chew on for a while

I requested some driver info so I can get these things working. That is my hold up at the moment. I might be able to get it working without the driver info, I am still working at it.

Why do you need a new driver when a couple of folks supposedly don't have a problem running the system?

Because some of us do...

That is like windows saying, why patch windows, it works for a few... xD

That assumes that the hardware is different,  don't we have the same hardware?

Apparently, not... I have two separate mountings of the same boards. But even with the same hardware, every individual component in every system is not the same, just "similar". You happened to get one with components that all work well in harmony. I, in this case, have components that obviously need "tuning" or "replacement". (Tuning to run them so they don't over-shoot "operational function". As they start working fine, but as they run, they change operation, running into a state that can't be managed with the "stock settings", which can only be changed, at the moment, by puttying into the RasPi.)

It is like your RAM, that you purchase, runs great at stock speeds and voltages... mine, purchased from the same MFG, starts producing errors, demanding less voltage and slower timing... (Or the same timing, but my setting of 20Khz, is actually running at 22Khz, due to MFG of other components. Thus, I have to lie and set mine to 18Khz to make it actually produce 20Khz, to compensate for the drift of the other components, or for the variations in my component over yours.)

Perfect example is your CPU... It is sold as 2.5Ghz, but your may be running at 2.4572332GHz, and mine at 2.637434234GHz, though we both have the exact same stock settings. (Which, if you notice, changes at ever reboot. Your CPU never runs at the same exact frequency, ever, and drifts while running and heating up.)

In this case, 2.63+ causes my CPU to crash when I open notepad. xD That 0.007434234 extra GHz, is enough to push it over the edge.

[NotFuzzyWarm]

Mmm. Guess we gave them somethings to chew on for a while

Yes I noticed the large negative ground-shielding, surrounded by large positive plates, which is the essence of an electrical capacitor. (Two plates of opposite polarity, separated by a layer of non-conductive medium.) Might explain the electrical run-off that is causing the VR to bump-up in time, which leads to ever-increasing voltage, leading to more capacitance, leading to more increasing voltage.

I am just not sure why one board does this, over another board, being all of the same design. With exception to the issue of substituted parts that may be leading to the failure. So hard to see some of the numbers of the smaller components.
<snip>

Close enough fer gument work as they say

Welcome to the world of power RF design. Specifically what is called 'lumped component' effects. Refers to the various interactions that go on at frequencies starting around 500mHz and up.

While the switching regulators probably only run around 100-150kHz their response bandwidth is several mHz. More to the point the rise/fall times of the waveforms produced will be on the order of only a few ns (100's of mHz). Those 2 things put us in the be-very-careful zone when the loads (ASIC's) are spread around as they are. Remember, we are not talking about an infinitely stiff pure DC source drive a purely resistive load.

That DC source WILL have a high frequency component to it and it is driving a very high frequency pulsed load. (What is the clock freq anyway?) Very easy for local run-away voltages to crop up from resonances. Think of it as ringing with a fair bit of power behind it. If you do ham or CB radio is called excessive SWR and leads to a blown transmitter... Is why local bypassing at the chips is needed.

Putting bigger caps close to the buck inductors certainly helps give a stiff power source at that point but it is what happens between there and the chip that can cause trouble. And - where is the Vdd sensed for the regulator? At the big caps or close to the furthest away chips (kinda remote-sensing)? All things considered, best is at the main big caps.

Soo many questions on this...

[opieum2]

Mmm. Guess we gave them somethings to chew on for a while

I requested some driver info so I can get these things working. That is my hold up at the moment. I might be able to get it working without the driver info, I am still working at it.

Why do you need a new driver when a couple of folks supposedly don't have a problem running the system?

Because some of us do...

That is like windows saying, why patch windows, it works for a few... xD

That assumes that the hardware is different,  don't we have the same hardware?

The idea here is to make sure the driver picks up and tunes things properly. It was enough for bitmine to do the same and release a version of their firmware as well. However there are components that require detection. Like the backplane is not being picked up in my current iteration. I should be getting similar results running cgminer -DT on the firmware I am building out as I do on the regular firmware. But as I am not I need to figure out what changed in the driver. AMT would have this answer. It would save alot more time than having to reverse engineer the driver. I may go that route anyway.

[NotFuzzyWarm]

Is it possible to implement looking for a simple 'I'm alive' signal from the cards for a few seconds to give them a chance to wake up before starting the device present scan? Kinda a reverse PWR_OK function. Or quick & dirty, just delay the scan for a few seconds after power up?

Delay the start of cgminer a few sec to let other background devices come alive first?

Actually, raises the question of how the power-up Vdd voltage is set. Hopefully it is hard wired to start at a safe voltage until told otherwise - right?... What happens if +12v is applied without backplane communications?

 A while ago on BFL's blog it was said the Monarchs start up at Turbo voltages until coms are established. Power input is around 1.5x normal during that time... Dunna know if they addressed that or if the chips just needs a kick in the butt to start up. Sound familiar (kick) from the A1 dev thread ISA?

[Stan-O]

Anyone else get the "invoice" email with the revised dates? Mine was stated at 4/29/2013 when in fact I was promised miners within 3-4 weeks from the original date, in the end I got my miners in early April BUT they don't work and have no confirmation or update on whether I am getting replacements or not. I was offered 2 replacement miners on the 10th, I accepted but have gotten no follow up.


On the hardware side....damn I had not even considered the heatsink as a source of the shorts.....Just an oversight since its such an obvious and needed piece of hardware....alternately, couldn't a small copper plate be inserted in between each chip? Sort of how CPU heatsinks function. Put a copper plate/shim in between the chips and the heatsink it would actually eliminate that particular problem. Both sides greased up to keep it held in somehow. maybe as a getto solution crazy glue the corners to keep it fixed and grease up both sides of the shim to insure contact with both. The copper thermal transfer would work in a pinch and would be a nice workaround to the shorting issues that MIGHT be caused by the heatsink...

Also sorry to hear your card died. This was the same issue I observed in almost every instance (one card was DOA and never worked). Most of the others did the same thing within minutes. The ones I have running now I figure are on borrowed time. The only working miner I have is an Antminer s2. Despite the shipping issues It works well. All parts are solid. AND well built. For ALOT less than the AMT miners were. The irony is the Antminer runs at 1.2 some of the time (usually 1056).

i got an invoice this morning.  havent been through the several pages on this thread to see why.  why the invoice?

[opieum2]

Apparently reworking the site. No other details were given.

[NotFuzzyWarm]

i got an invoice this morning.  havent been through the several pages on this thread to see why.  why the invoice?

So far no word on that. Rather like the Cheshire Cat no?

[opieum2]

Is it possible to implement looking for a simple 'I'm alive' signal from the cards for a few seconds to give them a chance to wake up before starting the device present scan? Kinda a reverse PWR_OK function. Or quick & dirty, just delay the scan for a few seconds after power up?

Delay the start of cgminer a few sec to let other background devices come alive first?

Actually, raises the question of how the power-up Vdd voltage is set. Hopefully it is hard wired to start at a safe voltage until told otherwise - right?... What happens if +12v is applied without backplane communications?

 A while ago on BFL's blog it was said the Monarchs start up at Turbo voltages until coms are established. Power input is around 1.5x normal during that time... Dunna know if they addressed that or if the chips just needs a kick in the butt to start up. Sound familiar (kick) from the A1 dev thread ISA?

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.

[NotFuzzyWarm]

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...

[AMT_miners]

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.

[AMT_miners]

i got an invoice this morning.  havent been through the several pages on this thread to see why.  why the invoice?

So far no word on that. Rather like the Cheshire Cat no?

An accountant not familiar with qb online tried to export client sales list from qb and sent everyone an invoice instead. Getting mails all day about it. Nothing to worry about.

[AMT_miners]

Mmm. Guess we gave them somethings to chew on for a while

I requested some driver info so I can get these things working. That is my hold up at the moment. I might be able to get it working without the driver info, I am still working at it.

Why do you need a new driver when a couple of folks supposedly don't have a problem running the system?

Because some of us do...

That is like windows saying, why patch windows, it works for a few... xD

That assumes that the hardware is different,  don't we have the same hardware?

The idea here is to make sure the driver picks up and tunes things properly. It was enough for bitmine to do the same and release a version of their firmware as well. However there are components that require detection. Like the backplane is not being picked up in my current iteration. I should be getting similar results running cgminer -DT on the firmware I am building out as I do on the regular firmware. But as I am not I need to figure out what changed in the driver. AMT would have this answer. It would save alot more time than having to reverse engineer the driver. I may go that route anyway.

Bitmine bought up the markets components from the same vendors, resulting in thousands of the sets of the same components on each board. It was the proper way to do it.

Our MFG/SMD fac  bought from different vendors, third parties, and brokers and "where ever we could find them". Claiming it didn't matter. Resulting in different comps from different mfg's on different boards, making some work and some not. "But all the parts are exactly the same value".  Actually no, after a few weeks of analysis we've found several parts from several different lots with substantially different values resulting in anywhere from 20,000 to 40,000 mmf differences. All of this is our fault, we chose the mfg, we're not blaming anyone, just trying to give those of you working on diagnostics and idea as to why the components and comp mfg's/types/sizes  seem to differ somewhat. Our rep is ruined sure, but at least the mfg added the extra 4%-8% on his parts resale margin.

[regtable69]

Is it possible to implement looking for a simple 'I'm alive' signal from the cards for a few seconds to give them a chance to wake up before starting the device present scan? Kinda a reverse PWR_OK function. Or quick & dirty, just delay the scan for a few seconds after power up?

Delay the start of cgminer a few sec to let other background devices come alive first?

Actually, raises the question of how the power-up Vdd voltage is set. Hopefully it is hard wired to start at a safe voltage until told otherwise - right?... What happens if +12v is applied without backplane communications?

 A while ago on BFL's blog it was said the Monarchs start up at Turbo voltages until coms are established. Power input is around 1.5x normal during that time... Dunna know if they addressed that or if the chips just needs a kick in the butt to start up. Sound familiar (kick) from the A1 dev thread ISA?

Voltage does sky rocket. If i remember rightly if you leave out the gpio cable by accident voltages go to 0.92 ish. But as its not mining its ok but you must switch off and put gpio cable back in otherwise i fear it may blow a chip or two from prolonged exposure.
What amt have said previously is what we had done to revive our boards and had the vddc as high as 5.0 voltages crept to 0.87-0.88 max and mined well but tuned back down again to save blowing anything hence why one card seems to under run