A better test would be to power the card and measure voltage at the top of the Pulse inductor. If you get ~0.75v there (or whatever it's adjusted to), the power circuit (including that capacitor) is probably fine. I only say "probably" because I just fixed a board that was missing a cap on the back side. Before replacing that tiny back-side cap, the voltage at the Pulse top was correct, but the card wouldn't hash stably.
okay, i measured, it was 0.3V or 0V, what i can do next?
okay, lets start at the top:
1) you are forcing tuning to run at 55 when you use "aIfDSo 55". the fact you are seeing more than 10% errors means you should not have them higher than 53 or 54. change them to auto-tuning. (AIfDSo)
2) a few chips (such as 52) are set as "aifdso". this wont work in the bitfury system unless you were forcing custom timing clocks and other info to the chip (you aren't). change them to AIfDSo.
3) where are 1-30?
4) Your chips are producing way to many errors. half of their hash rate is actually errors. You need to cool your chips better. The chips currently at zero likely switched off because the autotuning was overwhelmed by the high error rate. you need to have good cooling fans, and likely add some heatsinks.
5) if you havent yet, update your chainminer following the method mentioned several times in this thread.
do the above and then check again. it should resolve 90% of your hashrate issues. as for the 0.3V you are measuring, try again after the changes. if its still <0.6V, check the values of the resistors R01F and R02F. in a board with capacitors these should be 1.0 and 1.25 k(ohm) respectively. In a board without capacitors they should be -?- and 1.7k(ohm) respectively (i dont know the R01F value for the board, but its likely not 1.0k like the first version)
if your resistors are not these values, thats the issue. if they are correct, then its onto the next step. probably the small TI chip found right beside them (it has about 12 or 14 pins) that is responsible for bringing 12v->0.7v
Wait... are you saying that for chips that don't work/generate too many errors, setting them as aifdso doesn't work?? if not, what additional information needs to be provided to actually turn them off?? I can see a bunch of zero's in that line, which that seems to indicate they are technically switched off, so I don't understand why you're saying that aifdso alone doesn't fix the problem.... Thx for clarifying...