Topic: New Official AMT Thread - page 86. (Read 149472 times)

It's now May 20th. It has been 5 months and still no miner..... Or refund..... Or communication for that matter. I thought AMT wanted to turn things around? Doesn't seem like that's going to happen ever.....

So whats going to happen AMT ? can we get the boards replaced some how or give us something maybe some hashing power maybe you guy should just mine for us ... or are you guys that's it done not ever going to make it right we made a bad decision in dealing with you guys ?

That is a shame. They really should know better than that. I hate seeing people taking advantage of other just to make a quick buck.

I'm not sure how that helps us with hardware that has already blown. It's been well documented, and then used for diagnostics by the guys here to try and figure out whats up.

I mean I know this message will be gone in a second excuse they apparently want to delete anything I post regardless of temperament.

It sucks when you are cordial in your dealings but are essentially blown off. That is what is resulting in bad reputation. The parts issue are completely understandable once communicated.

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

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.

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.

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.

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

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.

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

Apparently reworking the site. No other details were given.

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

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?

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.

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

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.

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