I could do it, in Missouri. You might snoop around local computer shops or TV repair guys. When I worked for the one here in town we had people coming in with random bits needing ten minutes' work every now and then.

Oh hey raskul, how ya doing. Yeah I was hoping someone would pipe up about the old BTCGarden stuff; I don't know if they really sold a lot. Definitely let me know what you have.

What, nobody has old stuff they want to get rid of? Nothing interesting but no longer (or barely) profitable?

I'm pretty sure novak tested his USB-BE hack on a Prisma as well. Tubes and Prismas are pretty interchangeable as far as controllers go.

Sometime around the middle of this year my hardware purchases shifted from "maximize the hashrate, minimize expense" to "oh that's interesting and I don't already have one". The collection is become fairly diverse but still only a fraction of what's been available over the last two years or so. We're thinking of putting together an informal "bitcoin mining museum" in a corner of the shop, and basically just poking around to see what people have they're willing to get rid of.

Right now I have a fair amount of ASICMiner and BitMain offerings, a few odds and ends (Avalon Gen1, Habanero, BA X1 etc) but that's about it. We have very few USB miners, not much with BitFury chips, not much from BFL, BTCGarden, RockMiner and a bunch of other outfits.

The budget is kinda low right now, but if you have something interesting PM me and we can talk shop. I'd prefer hardware that's fully functional, but depending on the problem (and the price), there's a lot of stuff I can fix or work around.


What we have:

ASICMiner USB BE (stock, overclock)
ASICMiner V1 Blade (stock)
ASICMiner V2 Blade (stock, overclock)
ASICMiner Cube (stock, overclock)
ASICMiner Tube (stock)
Avalon Gen1 (2 modules only)
BitBurner A1
BitFury H-cards/M-board
BitMain AntMiner U1 (stock)
BitMain AntMiner U2 (stock)
BitMain AntMiner S1 (stock, overclock, underclock)
BitMain AntMiner S2 (kit)
BitMain AntMiner S3 (stock)
BlackArrow X1 (BA controller no LCD)
BTCGarden AM-V1
Butterfly Labs FPGA (832MH Single)
Butterfly Labs Jalapeno
Butterfly Labs 60GH Single
Dragon 1T (stock)
GridSeed 5-chip
GridSeed USB (scrypt only)
HashFast Rev1 bare board
Klondike K16
NanoFury NF6
OneString
PepperMining Habanero


Inbound:
BlackArrow X1 (LCD)

Yep, ckpool in proxy mode also fixes the extranonce2 issue. ckolivas worked that one up for us I think the first day we had Tubes to test with, but he's far too busy to try and fix all the issues with AM's stratum implementation.

Hopefully novak can get some of those USB adapters worked up and distributed soon. These things seem to behave much better on a real cgminer.

Regarding hashrates for a given frequency.

It appears that each chip is capable of 8MH per 1MHz clock rate. What this means is, per chip, the gigahashrate is f*.008

Each bank of an S1 board has 8 chips, so the per-bank gigahashrate is f*.008*8 or f*.064
A full S1 has 8 banks of 8 chips, so 64 chips; the gigahashrate per frequency for the whole machine is f*0.512

Individual VRMs output voltage to only their 8 ASICs. I have observed no problems from setting adjacent VRMs to different voltages. This may come in handy if one bank has a weak chip that can't run at the same point as the rest of the banks; the voltage for that bank can be turned up slightly without any issue.

To disable a VRM, tie a 1K resistor between GND and the end of R5/R68/R40/R54 closest to the inductor. The respective resistor for each given bank ties the buck controller's EN pin high by connecting it to the tap of a 3:1 voltage divider (200K+100K) on the 12V input. A 1K will pull this low and disable the VRM. I haven't tested extensively but it appears that disabling a VRM will cut communications with all downstream banks (comms, clock, something is down), meaning that you can't disable a VRM in the middle and leave the ones on the end functional. I can do some more testing sometime and see if there's a way around this, or if I'm mistaken.

Miner furnace FTW - just brought my Dragon home to keep the living room warm last night. I need to put up pics of my radiator loop (HashFast + Habanero) sometime when I get it back to working; it's a cheap eBay radiator, nothing legit with actual road grime. Smexy setup, sir.


You don't want a Prisma for a footwarmer. They're pretty loud and also ever so slightly a fire hazard. I can attest that the Gardens are pretty quiet.

If anyone doesn't know how to change clocks, it's pretty straightforward if you know SSH.

If you're on linux, just SSH into the miner's IP address. Windows users, I recommend a program called puTTy

The default user and password are the same as the config page - root/root

You'll be looking for the file '/etc/config/asic-freq', which is a text file used as a config for setting the ASIC frequency. Pretty easy to follow that nomenclature. The fun part of editing the text file is, as far as I know, the only available editor is 'vi' - which was written back in the day when terminal connections ran on morse-code speeds and keystrokes were precious commodities. To edit text in the file, first press 'i' (or 'I", whatever - I don't think it's case-sensetive) to drop into "insert" mode. Add your values, comment out unused lines, whatever needs to be done.
Hitting ESC will take you back out of "insert" mode. The ":" character is used for commands in vi; entering ':wq!' will save and force a quit. 'reboot' will restart your miner with the new frequency settings applied.

'freq_value' - the hex number used to calculate the frequency
'chip_freq' - the frequency displayed by cgminer
'timeout' - used by cgminer for ASIC communication timing

Calculating the hex value for a given frequency is kind of a pain. Basically, the hex value needs to be backtraced to binary, and then divided into about five pieces. Starting from the MSB (most significant bit, usually the leftmost):

15 - 0
14 - BS
13:7 - M
6:2 - N
1:0 - OD

To calculate the frequency, the above-mentioned variables are tossed into an equation:

f = 25(M+1) / (N+1)(2^OD)

There are, of course, constraints to this. For one, N is a 5-bit value but can only equal 0 or 1. Additionally, the following must be true:

For BS=1, 62.5<= f <= 1000
                 500 <= f(2^OD) <= 1000
For BS=0, 37.5<= f <= 600
                 300 <= f(2^OD) <= 600

This limits the effective precision, because your denominator can now range only within {1,2,4,8} and your OD is limited based on BS and f. It usually doesn't have much effect on the end result, and frequencies can generaly be calculated within 1%.

hex	dec	bin
0	0	0000
1	1	0001
2	2	0010
3	3	0011
4	4	0100
5	5	0101
6	6	0110
7	7	0111
8	8	1000
9	9	1001
A	10	1010
B	11	1011
C	12	1100
D	13	1101
E	14	1110
F	15	1111

Binary is fairly easy to parse once you get the hang of it. At the rightmost bit (the Least Significant Bit, or LSB) you assign a value of 1. Moving left, the values double - to 2, 4, 8 and so on. It's the same as the tens places in decimal counting, except instead of increasing powers of ten (1, 10, 100) you have increasing powers of 2. If there's a '1' at any place, its associated 'place value' is added to the total. So the hex value D, or in decimal 13, is in binary '1101' - which means 1x1 + 0x2 + 1x4 + 1x8, so 1+4+8 = 13. Simple as that. Hex is just a single-digit way of expressing values between 0 and 15. Hex actually is short for "hexadecimal", in which you can see "hex" 6 and "deci" 10, so 16 total. Just as decimal runs on tens, with values being 0-9, and binary runs on twos, with values being 0-1, hexadecimal runs on 16s with values 0-15 (represented as 0-F).

For an example, say f=300. The stock config file tells us the hex for this is 0b81, so the binary version is 0000 1011 1000 0001
If we break that down into our frequency formula, we get:

0|0|0010111|00000|01

15 - 0 - 0 - 0
14 - BS - 0 - 0
13:7 - M - 0010111 - 23
6:2 - N - 00000 - 0
1:0 - OD - 01 - 1

So now we have f = 25(23+1) / (0+1)(2^1) = (25)(24)/(1)(2) = (600)/(2) = 300
f(2^OD) = (300)(2^1) = (300)(2)=600, so BS=0 applies.


I'm not entirely sure how timeouts should best be calculated, but after a bit of statistics on some working values, I figure timeout=13800/frequency - rounded to the nearest 5 - works pretty well.

I wrote up some quick code that, given a clock speed, generates the best BS, M, N, OD, and timeout and prints the data. The code is at www.gekkoscience.com/misc/set_freq.cpp if anyone's interested. Sample output for f=300:

#./set_freq
desired setpoint frequency? 300
BS: 0 M: 23 N: 0 OD: 1
Hex value: 0b81
 Resulting actual clock: 300.000000
 Error from desired clock: 0.000000 %
 Expected hashrate output: 153.600000 GH/s
 Best estimate timeout: 45

option 'freq_value'   '0b81'
option 'chip_freq'    '300'
option 'timeout'      '45'



You should be able to copy-paste the config outputs at the end directly into /etc/config/asic-freq and let it rip.

Others might like the info. I like to be thorough, after all. Really I should have done this a couple months ago, but I didn't worry a lot about messing with S1 because I've only had two since about June and, here at the shop, power is cheap enough that they're still slightly profitable at stock settings (about a nickel a day, but still).

Maybe in the next few weeks I'll do the same for a Tube. Novak's already posted instructions on hacking a USB BE into a USB serial adapter for them, after all.

That is correct. The divider pair on mine was 8200/9760. As an example, on mine I used a 5K6 resistor across the 8200 which (for ease of installation and because I had a through-hole resistor) I tied between the junction of the two adjacent resistors and the high side of a nearby output cap. That requires much less precision than attaching leads directly to the pads of a 0603 SMD component. I measured between 0.815 and 0.825 in a quick check of VRMs on the board after modification, variance mostly due to the 5% tolerance of the 5K6 resistor.
On one VRM I did replace the 8200 with a 3K3 5% and got the same results. I can post pictures of some things later on if desired. It probably wouldn't hurt to put up information about changing clock speeds as well, as that requires SSH and config file editing. I'll also include info on calculating the hex values for various frequency setpoints and the expected hashrate calculations.

I'm not entirely sure. The only problem I had with timeout settings was at the 200MHz neighborhood (200, 196, 193). At timeout 70, the draw current would bounce between about 0.8A and 0.2A (idle) as chips would start to hash, and then all drop out. I'm assuming something in the communication between controller and ASICs was hosing it; once I set timeout to 80 everything worked wonderfully.

The only thing I really saw affecting the HW rate was a Vcore too low at a particular frequency. It makes sense, as in CMOS ICs all the switching is done by charge displacements; higher voltages are required to push a given charge through a given impedance faster, and higher gate charges are required to meet source-drain impedance thresholds for switching. Setting the voltages too low will keep the weakest transistors in the IC from switching effectively, introducing bit errors in the pipeline and returning bad data.

Someone with more software knowledge of Bitmain hardware can probably tell you more about what the timeout setting actually does. I've focused so far on the hardware.

Having recently acquired some AntMiner S1 that another miner in my acquaintance was disposing of for the cost of shipping, I decided to see just how efficiently these little guys could run. With that in mind I set up a test to measure the board-level DC power draw of the mining hardware at various parameter setpoints of core voltage and clock speed.

I connected a controller to a single hashing board with three VRMs disabled. The fourth VRM was wired for precise manual output voltage adjustments in the range of 1.20-0.60V. The controller and fan were powered separately, so only the power required by the single enabled VRM and its bank of 8 ASICs was measured (the idle current from the controller-powering 3.3V buck is  considered negligible).

I used a 12V server PSU as the power source, delivered through a 0.1ohm 1% shunt resistor across which I measured the voltage drop, for input current calculations. I used an oscilloscope for the DC power input (measured at the board's connector, below the shunt) and the VRM output voltage (measured at the output capacitors). It was observed that the fan would pull 12V 1A at maximum speed, and the controller (managing 64 ASICs at 250MHz) consumed 0.34A at 3.3VDC; the maximum additional power draw past board draw, then, is expected to be around 13W. At lower board power consumption, the fan requires much less power; assuming half power for the fan, additional power draw would be around 7W.

I included stable voltage ranges for every 25MHz from 400MHz down to 150MHz, and included the stock setpoint (350MHz@1.12Vcore) and the AntMiner S2 stock setpoint (196MHz@0.77Vcore) for references. The durations of tests varied, most being between 8 and 20 minutes before sample data was recorded. I tried to run up at least a DiffA of 3000, but sometimes I got distracted and ran more; other times, I got impatient (especially during slow-clock tests) and cut it off at less (typically the 20-minute point). For the first batch of samples (400MHz) I reset the voltage after each dataset was recorded, but did not reboot the device. The calculated error data for each sample at 400MHz is based off the DiffA and HW deltas from the previous sample. For all other samples, the machine was rebooted after setting Vcore.

All measurements were taken on an AntMiner S1 with a build date of 2013/11/18, with a VRM feedback resistor pair R3/R12 of 8200 ohms and 9760 ohms, respectively. All resistor modification calculations are based on this pairing.

GH Expected: Expected gigahashrate for a bank of 8 chips at the setpoint frequency
GH Total: The total expected hashrate for a 64-chip S1 at the setpoint frequency
GH Measured: Reported average hashrate during the measurement period
DiffA: Reported DiffA by the end of the measurement period
HW: Reported HW (hardware errors) by the end of the measurement period
Volts in: DC line voltage into the hashboard, measured at the board terminals
Current in: DC line current into the hashboard, measured across the input shunt (see above)
Power in: DC line power into the hashboard ( Vin*Iin )
Vcore: Measured average VRM output voltage during the sample time
W/GH: The power per measured gigahash-per-second ( Pin/GHM )
HWE Percent: Percentage of hardware errors for the sample period ( HW/[DiffA + HW] )
W/GHE: Watts per expected gigahash-per-second ( Pin/GHE )
Vset: The VRM desired-setpoint voltage, to 0.01V
Replacement R: The resistor value required to replace the VRM feedback resistor (R3, R66, R38, R52), to achieve Vset
Parallel R: The resistor value required in parallel with the VRM feedback resistor, to achieve Vset

Setpoint MHz	GH Expected	GH Total	GH Measured	DiffA	HW	Volts in	Current in	Power in	Vcore	W/GH	HWE Percent	W/GH Expected	Vset	Replacement R	Parallel R
400	25.6	204.8	25.4	4351	0	11.60	3.91	45.36	1.125	1.79	0.00%	1.77	1.130
			25.5	6783	1	11.61	3.81	44.23	1.112	1.73	0.04%	1.73	1.110	8052	446124
			25.6	9599	21	11.63	3.71	43.15	1.100	1.69	0.71%	1.69	1.100	7889	208238
			25.3	12927	208	11.64	3.60	41.90	1.083	1.66	5.32%	1.64	1.080	7564	97523
			24.9	16639	581	11.65	3.51	40.89	1.068	1.64	9.13%	1.60	1.070	7401	75990
375	24.0	192.0	23.8	3014	0	11.65	3.49	40.66	1.110	1.71	0.00%	1.69	1.110	8052	446124
			24.3	3711	0	11.66	3.41	39.76	1.088	1.64	0.00%	1.66	1.090	7727	133856
			24.0	3089	0	11.67	3.36	39.21	1.079	1.63	0.00%	1.63	1.080	7564	97523
			24.2	3327	0	11.67	3.29	38.39	1.069	1.59	0.00%	1.60	1.070	7401	75990
			26.6	3199	0	11.68	3.23	37.73	1.060	1.42	0.00%	1.57	1.060	7239	61745
			24.1	3327	29	11.68	3.18	37.14	1.049	1.54	0.86%	1.55	1.050	7076	51622
			23.5	3071	65	11.69	3.12	36.47	1.040	1.55	2.07%	1.52	1.040	6913	44059
			22.9	3711	212	11.70	3.04	35.57	1.029	1.55	5.40%	1.48	1.030	6751	38194
350	22.4	179.2	24.4	3839	0	11.71	2.97	34.78	1.049	1.43	0.00%	1.55	1.050	7076	51622
			22.9	3327	0	11.71	2.92	34.19	1.040	1.49	0.00%	1.53	1.040	6913	44059
			22.4	3199	0	11.72	2.85	33.40	1.029	1.49	0.00%	1.49	1.030	6751	38194
			22.1	3327	0	11.73	2.80	32.84	1.019	1.49	0.00%	1.47	1.020	6588	33512
			23.8	5119	0	11.73	2.75	32.26	1.009	1.36	0.00%	1.44	1.010	6425	29689
			22.4	3071	6	11.73	2.69	31.55	0.999	1.41	0.19%	1.41	1.000	6263	26508
			22.0	3071	69	11.74	2.64	30.99	0.990	1.41	2.20%	1.38	0.990	6100	23819
			21.5	4067	229	11.75	2.58	30.32	0.979	1.41	5.33%	1.35	0.980	5937	21517
			22.0	4735	0	11.66	3.41	39.76	1.120	1.80	0.00%	1.78	1.120	8215
325	20.8	166.4	20.6	3583	0	11.75	2.56	30.08	1.010	1.46	0.00%	1.45	1.010	6425	29689
			21.2	3071	0	11.76	2.52	29.64	1.000	1.40	0.00%	1.42	1.000	6263	26508
			20.8	3071	0	11.76	2.46	28.93	0.989	1.39	0.00%	1.39	0.990	6100	23819
			21.0	3071	0	11.77	2.42	28.48	0.980	1.36	0.00%	1.37	0.980	5937	21517
			21.4	3071	0	11.77	2.36	27.78	0.968	1.30	0.00%	1.34	0.970	5775	19524
			21.2	3455	0	11.78	2.32	27.33	0.960	1.29	0.00%	1.31	0.960	5612	17781
			20.8	3071	2	11.78	2.27	26.74	0.950	1.29	0.07%	1.29	0.950	5449	16245
			21.5	4863	45	11.79	2.22	26.17	0.939	1.22	0.92%	1.26	0.940	5287	14880
			19.8	4351	172	11.79	2.17	25.58	0.928	1.29	3.80%	1.23	0.930	5124	13660
300	19.2	153.6	19.0	15743	0	11.80	2.11	24.90	0.951	1.31	0.00%	1.30	0.950	5449	16245
			18.7	3199	0	11.81	2.05	24.21	0.938	1.29	0.00%	1.26	0.940	5287	14880
			19.1	3071	0	11.81	2.02	23.86	0.931	1.25	0.00%	1.24	0.930	5124	13660
			19.0	2687	0	11.82	1.97	23.29	0.920	1.23	0.00%	1.21	0.920	4961	12562
			19.2	2431	0	11.82	1.92	22.69	0.909	1.18	0.00%	1.18	0.910	4799	11569
			18.7	2687	2	11.83	1.89	22.36	0.901	1.20	0.07%	1.16	0.900	4636	10666
			18.7	2687	32	11.83	1.85	21.89	0.890	1.17	1.18%	1.14	0.890	4473	9843
			18.2	2559	121	11.84	1.81	21.43	0.881	1.18	4.51%	1.12	0.880	4311	9088
275	17.6	140.8	17.4	3199	0	11.86	1.67	19.81	0.880	1.14	0.00%	1.13	0.880	4311	9088
			17.7	4351	0	11.86	1.63	19.33	0.870	1.09	0.00%	1.10	0.870	4148	8394
			17.8	4479	0	11.86	1.59	18.86	0.860	1.06	0.00%	1.07	0.860	3985	7754
			18.4	3455	21	11.87	1.55	18.40	0.850	1.00	0.60%	1.05	0.850	3823	7161
			17.0	3583	110	11.87	1.52	18.04	0.841	1.06	2.98%	1.03	0.840	3660	6611
250	16.0	128.0	16.2	3583	0	11.89	1.39	16.53	0.840	1.02	0.00%	1.03	0.840	3660	6611
			16.4	2559	0	11.89	1.36	16.17	0.830	0.99	0.00%	1.01	0.830	3497	6098
			16.1	3327	0	11.89	1.33	15.81	0.820	0.98	0.00%	0.99	0.820	3335	5620
			16.0	3071	4	11.90	1.29	15.35	0.810	0.96	0.13%	0.96	0.810	3172	5173
			15.2	3327	46	11.90	1.26	14.99	0.802	0.99	1.36%	0.94	0.800	3009	4754
			15.2	3839	240	11.90	1.23	14.64	0.791	0.96	5.88%	0.91	0.790	2847	4360
225	14.4	115.2	14.3	3199	0	11.91	1.12	13.34	0.789	0.93	0.00%	0.93	0.790	2847	4360
			15.0	2815	0	11.91	1.09	12.98	0.780	0.87	0.00%	0.90	0.780	2684	3990
			15.3	3071	0	11.91	1.06	12.62	0.770	0.83	0.00%	0.88	0.770	2521	3641
			14.3	3199	56	11.92	1.03	12.28	0.759	0.86	1.72%	0.85	0.760	2359	3311
			15.1	3071	121	11.92	1.01	12.04	0.750	0.80	3.79%	0.84	0.750	2196	2999
200	12.8	102.4	12.6	3199	0	11.93	0.95	11.33	0.768	0.90	0.00%	0.89	0.770	2521	3641
			12.7	4351	0	11.93	0.93	11.09	0.759	0.87	0.00%	0.87	0.760	2359	3311
			13.1	3967	0	11.94	0.91	10.87	0.749	0.83	0.00%	0.85	0.750	2196	2999
			12.5	4479	0	11.94	0.88	10.51	0.739	0.84	0.00%	0.82	0.740	2033	2704
			14.0	3583	0	11.94	0.86	10.27	0.729	0.73	0.00%	0.80	0.730	1871	2424
			12.7	3583	8	11.94	0.85	10.15	0.721	0.80	0.22%	0.79	0.720	1708	2157
196	12.5	100.0	12.8	3199	0	11.93	0.94	11.21	0.770	0.88	0.00%	0.90	0.770	2521	3641
			13.1	3199	2	11.95	0.82	9.80	0.720	0.75	0.06%	0.78	0.720	1708	2157
175	11.2	89.6	11.6	3071	0	11.96	0.74	8.85	0.719	0.76	0.00%	0.79	0.720	1708	2157
			11.2	2559	0	11.97	0.72	8.62	0.709	0.77	0.00%	0.77	0.710	1545	1904
			12.1	3327	1	11.97	0.70	8.38	0.697	0.69	0.03%	0.75	0.700	1383	1663
			9.7	3199	2	11.97	0.62	7.42	0.691	0.77	0.06%	0.66	0.690	1220	1433
150	9.6	76.8	9.6	3199	1	11.98	0.60	7.19	0.690	0.75	0.03%	0.75	0.690	1220	1433

Noteworthy data points:
- 350MHz @ 1.12Vcore, stock S1 setpoint
- 196MHz @ 0.77Vcore, stock S2 setpoint
- 225MHz @ 0.77Vcore, maximum S2 stability point at stock Vcore
- 200MHz @ 0.72Vcore, minimum stability point at 200MHz - some ASICs were unstable below this voltage, causing resets
- 175MHz @ 0.69Vcore, hashrate reports low due to one chip dropping out entirely; remaining 7 hashed well (average 1.39GH, expected 1.20)
- 150MHz @ 0.69Vcore, minimum stable at 150MHz. At 0.68Vcore all chips dropped out and reported 'X' in ASIC status

I currently have a full machine modified for operation at 250MHz@0.82V (using a 5k6 5% parallel resistor), for which the expected output is 128.0GH at a total power draw (including half-power 6W fan and 1W controller) of about 133W. I measured the power draw at 11.34V 11.52A (using a 1% 0.05ohm shunt; the PSU interface board's 5% shunt measurement reported 11.43A), for 130.6W DC power consumption. The current stats, at 0h 31m 53s operation, are 128.61GH, 59HW, 56191DiffA
This equates to a DC efficiency of 1.02W/GH with a hardware error rate of 0.1%
The fan is reporting 1020RPM, temps 41/43C in a ~65F ambient environment

A note on the maximum S2 stability point at stock Vcore: the S2 uses the same VRM hardware ( 53355DQP monolithic synchronous buck driver ) as in the S1 (and also ASICMiner Cubes and Tubes). Because the S2 is clocked and volt-set to a lower operating point, each ASIC draws far less current than the ASICs in a stock-set S1. The S1 allocates 8 ASICs per VRM; the S2 allocates 16. Therefore, at any particular setpoint on the S1, the power draw per VRM for the same setpoint on the S2 is doubled. If an S1 is stable at 0.77Vcore 225MHz, it is logical to think the S2 would be also. However, the power draw from the S2's VRMs would be twice the 12.62W seen by the S1, at 25.24W. Assuming a 90% efficient regulator (which efficiency typically drops as current increases, due to parasitic resistances in the inductor and drive FETs), that's an estimated output power of 22.72W; as we're outputting 0.77V the current draw is then 29.5A. The 53355DQP is rated for 30A, which means that you're stressing it to 98% capacity continuously. With a best-case efficiency of 95% (and a few other assumptions, to make the comparison easier), the output power is 23.98W, with an output current of 31.1A, a good 3% past rating. With this in mind, it is probably a terrible idea to try and clock an S2 up to 225MHz even if ASIC cooling was adequate.

I'm gonna be setting up some Prismas to host in the next day or two, probably on DPS2K PSUs. Definitely not in load-balanced, which shouldn't be necessary since these boards all have isolated 12V lines. A pair of Prismas shouldn't quite max out a DPS2K, maybe 110% rated. It wouldn't take much of a short to run up to OCP (about 120% rated). Hopefully we don't test that hypothesis with a "live-fire" experiment.

Thanks for the info on what's been going on.

Yeah I guess the title needs to be updated.

In any case, the prices in the first post are the current prices. We had a housecleaning sale a few weeks ago and dropped all prices, but that has ended.
We're still offering a 10% discount to anyone purchasing to power hardware from Canary or CrazyGuy Prisma GBs though, just gotta let us know that's what you're doing. There's no particular reason, just we like those guys.

Novak and I were discussing pricing the other day though, so I'll talk to him and see if we're gonna make any changes. As of right now, what it is is what it is.

You'd have to take that up with bobsag, but it's possible we could work something out. How long do you expect it'd take for you guys to do their entire batch? How many boards is that? I'm not going to make any guarantees about large quantity anything at all without a) more information about the problems and fixes, and b) consent from owners or otherwise responsible agents.

Haven't heard anything back yet. Not terribly surprised about that given the state of things, but we're definitely interested in helping solve the problem.

PM sent. We could reflow BGA ASICs but don't have the X-ray equipment to check 'em without turning 'em on. Finagling 0805 components is a regular occurrence around here, and installing, replacing and flashing microcontrollers is also pretty standard fare.

From what I gather, most of the problem is bad microcontrollers - appear to be about a TQFP-64. We could probably swap and test 50 boards here in a couple days, if we had 'em to work on and a bit more info from you on the specific issues. It would get my hosting customers up to speed a bit quicker, which I'm sure they're in favor of. Power supplies, coolers, TPlinks and cables have been standing by for between 2 and 3 months.

We don't have BGA equipment to do anything with the ASICs themselves, but anything pinned surface-mount we can probably handle.

Feel free to PM if you want to discuss anything.

I mentioned on here a bit ago, and messaged Vesi last week, about potentially doing some of the stateside repairs - specifically for the fifty-odd boards which will end up in our hosting facility. Marto, since you're around at talking, is that something you might consider?