If everything works how I think it should, anyone with a PIC programmer and a screwdriver could rework any S7 to run undervolted. At the same numbers as estimated above, a full 135-chip S7 would run 3TH at under 700W. I don't actually know how good it'll be until I do some more testing, and once I have functional writeable boards I can start measuring actual power draws. I'm really gonna try and get it working tomorrow, pretty excited anyways. I have a working flowchart drawn up for the I2C comms, but I'll need to learn some of the instruction set and the specifics of the chip to be able to get the timings right.

Nope. ATX, CPU, and the 6-pins running off it look to be a custom job maybe 8 inches long. I'd like to use it as a PSU for my file server but I'll have to make the Molex jacks for it.

If it'll hit 0.18 - that's a stretch. You'll probably lose 5% in the buck, then add 30W for fans and controller, and 10% to the PSU, gives you 450W wall. Still almost twice the hashrate of an S5 for 3/4 the power draw, and probably a lot quieter given a sealed chassis and push-pull fans.

It looks like I'll be working on code this evening and probably tomorrow, so who knows but I might not actually have it working by burger time.

Alright. I'll keep working on my end and see what I come up with.

The only S7 blade I had access to before yesterday was a roasted 54-chip from a Batch 1 miner, or I'd have been working on this around February.

If I'd had the budget I'd have bought one ages ago just for this reason, but it wasn't until I sold the rest of my Compac batch and Bitmain had one for $300 that I was able to bite.

Think you can write a bit-bang I2C capable of sending a single two-byte instruction, waiting for a minute and sending another? The pick-and-place is keeping me pretty busy today but in spare moments I'm looking up details on I2C timings and such, next step is learning the PIC instruction set and breadboarding a bit.

I've got a server PSU and board, if you can run it on >200VAC it'll put out 1200W and hooks up 12x PCIe cables for about $90

If you want it at a good price, wait until about September.

In what? A monopoly is only worthwhile if you intend to abuse it, but if you abuse this coin it disappears.

I bet you could. The 47C it's currently running, it's only got the pusher fan installed. I bet with both, even with both blades powered up, it'd be a lot cooler.

I'm not going to hardware-hack the other blade, gonna use that as a guinea pig for software changes, so I won't be able to report on that for a while. But there's probably talk about it in the S7LN thread.

And by "154-chip" obviously I mean "162-chip", which is to say 54 chips per board. Whoops.

If it's a 154-chip, it's straight off the PSU with no regulation. The later 135-chip batches are regulated. As far as I know, the setpoint is not affected by the PSU voltage.

So, first thing first. This talk is pretty much specific to the 135-chip S7 version. The earlier 154-chip batches, what with the taller string and fixed voltage, are already as good as they're going to be without a regulator inline of your power supply. But the 135-chip is a bucked string, meaning it's got that regulator built into the board.

It looks like the stock voltage setpoint for an S7 is about 10.3V, or in the 690mV-per-node setpoint. That's about right for 700MHz according to the BM1385 datasheet. A lower-clocked S7 might have a lower voltage setpoint. I just received an S7LN, which is built for 600MHz on two blades; I measured the setpoint at 10.16V or 677mV per node.

The setpoint voltage is fixed. There is no knob to turn to change this.

HOWEVER...

The regulator's voltage is set by a digital potentiometer - more specifically, a digital rheostat (MCP4017). Basically a variable resistor whose resistance is determined by feeding it a number through a serial line. The default value is right in the middle, which is why some "dead" S7 will start to 9.3V - because the value isn't getting updated, so it stays on the middle setting. What should happen is the value gets updated by a little microcontroller (PIC12F1572), which pushes out a fresh value from memory as soon as it kicks on.

That's why Bitmain wants you to power the controller on last (or at least one potential reason), is because the DPOT and PIC get power from the 3.3V wire on the 18-cable to the controller. The "off" value of the DPOT is maximum, so the thing starts to well under 9V; as soon as the circuits see that 3.3V coming in from the controller, the DPOT lights up to center and a short time (a number of milliseconds) later the PIC sends it the number Bitmain gave 'em. If that PIC is toasted, that's when you sit at 9.3V and your S7 is only good for about 450MHz.

At the end of the S7 board are two headers. One two-pin header, GND and tied to a pin on the PIC. One six-pin header, wired up just right for In-Circuit Serial Programming of the PIC. What this means is, with the right basic hardware you should be able to pull firmware off the PIC or update it with your own.

One pin of the PIC, which can be configured for serial data, is tied to the TX pin on the 18-cable. Whether this means it can receive serial data from the controller or not is up to conspiracy theorists to decide. Does Bitmain have a secret version of S7 controller firmware which can change the voltage and they're keeping it for themselves? Maybe. Who knows. For the purposes of the immediate discussion, this is moot.

The PIC12F1572 does not have I2C hardware. Which means the protocol and timings would have to be implemented in software. Since we are talking to only a single device so we don't have to handle collissions, and it responds fast so clock stretching is unnecessary, and since we're only writing so getting responses is unnecessary anyway, it should be pretty straightforward.

I have generated a chart, not of every possible voltage the DPOT can set (since a lot of the voltages are so close together) but of more than half of them. I found hex values corresponding to every 10mV per node from 770mV down to 580mV, which is probably enough granularity for most people.

So what I'm thinking of doing is seeing about writing a basic custom firmware for the PIC, which still unfortunately implements fixed voltage but which can be updated easily to any voltage you want. What I'd probably do is have a set of files, each one labeled with its final setpoint voltage. The PIC would be programmed to set the voltage about 5% high for about a minute, which will help with bootup, warmup and the like. Then it would drop down to the setpoint.

I'm going to be up to my eyeballs in Compac and PSU board manufacture for the next couple weeks, so if anyone already has experience with PICs (and with bit-banging I2C) I'd certainly be interested in sharing what I know and some guinea pig hardware. Otherwise it'll be a hit-or-miss project for me, that probably shouldn't take more than a day or two except it'll be in odd hours between things. That, and I've never programmed PIC and I haven't done any microcontroller coding in about six years.



Guts of the thing - you can see my PICKit that I used to pull firmware and which I'd use to update with new once I can. Also the Bus Pirate currently attached in place of the PIC and feeding values to the DPOT directly.





This setup is currently set at 9.14V (610mV per node) and running at 450MHz stable. You'll probably complain that the error rate is way high. But of the 852 errors noted, 848 of them were from the first 3 minutes while it was warming up and I was still jacking around with the voltage.

If anyone's interested in donating toward this project, 1CoLDs7XNi8ehyFnGWicUhgBGb7Kw42Ugi

The cables on my PSU look pretty tidy, but yeah there's definitely dust inside.

On another note, my warranty is voided. I'm currently running one blade at 9.13V (610mV per node average) and 450MHz for 1TH at expected ~200W board-level. It's stable, 1 reported error in the last 15 minutes. I don't have an actual power measure, been doing other things.

I ended up yanking the PIC and talking to the DPOT directly, so I ran out a chart of 10mV (node-level) increments from 580 up to 770, the full range of the regulator. If I find time this weekend I might try and write a quick-and-dirty firmware for the PIC that sets the voltage at about 105% for 30 seconds or so and then takes it down to setpoint. I can run out a series of hex files based on the desired setpoint voltage, and then anyone with a screwdriver and PICKIT (I'm using a PICKit3, can be found readily enough for $30-50) can customize each board's voltage by accessing the ISP header after taking off the rear fan. I started discussing this process over in the Cheap S7 Repair thread, but maybe I should make a new one.

Looks like the default setpoint on this guy was 10V even rather than the ~10.3V of a full S7, which makes sense if it's designed to operate at 600MHz.

Got a HEX dump off a working PIC. In free time I'm gonna play with either figuring out this firmware to see if it takes in voltage data, or maybe just write a new one that I know does. The 6-pin header on the board is indeed an ICSP header. The ICSP clock and data lines correspond to the PIC's clock and data lines for its half-duplex sync transceiver; the DPOT's SCL is tied into the same clock but SDA runs to a GPIO pin so the PIC must be bit-banging I2C for the pot. That might actually be good news; if the PIC is taking in volt-change commands on the header, that keeps the DPOT separate from getting garbage data and hosing up the setpoint. Tomorrow I need to get to manufacture but today I'm gonna play with the PIC, see if I can at least alter the default voltage by day's end. With the S9 dropping and the halving coming down, just having a lower-fixed-voltage option for the S7 that doesn't require obviously-warranty-voiding hardware changes would be nice. See about hitting 3TH at 700W stable.

Definitely will be pulling from some of the info in this thread.

EDIT - looks like RA5 on the PIC, which can be set up as a receive pin for the internal USART, is wired to the TX pin on the 18-pin controller jack. Doesn't look like anything is tied to RX, but the chip is definitely capable of listening to the controller. Makes me wonder if Bitmain has a secret cgminer that sends out volt-setting parameters.

I haven't looked at the control hardware enough to know what the TX and RX pins on the 18-pin are tied to. Is it a hardware UART that's easily library-accessible from the OS? Because that could make things interesting.

More EDIT - I decided to start a fresh thread, since though it's peripherally related to this "repair" the idea is altered and extended quite a bit.

It came out of the box fully assembled. Ethernet and C13 and you're off to the races.

5-minute average 2716GH, temps 46 and 49, fans at 2880. I'm not a good reference for "how loud is this" because I have a high tolerance for fan noise; slept near a computer for the last 15 years, heated my living room with A1 Dragons and underclocked S4 the last two winters, and my desk is about 40 feet from 100KW of hosted machines. But I will say, I can't even hear it running sitting next to the S4+ (...whose PWM lines were clipped so the fans are rolling 4KRPM).

Sometime I'll put it in a quiet room next to an S3 and see how it compares. But now that I know it works I think I'm gonna do some hacking.

Mine just arrived. Gonna have some fun with it, but first...






Can someone confirm if that's the S2 PSU? I only ever bought a kit new, which didn't have the PSU, and neither did the secondhand machine I picked up a long time later.

Nice to see they got taller heatsinks instead of just leaving voids. That's what I was worried about. Reckon the added surface area improves heat transfer to air for quieter fan speeds at the same frequency as a standard S7.

Probably. You might have to pigtail the tach line back to the fan connector on the controller; I don't know how they behave with only one fan reporting speed.

If it picks up in cgminer-gekko but doesn't mine (or spits only errors), start turning the voltage knob clockwise to increase the voltage. At some point it should level out. Take a moment to go over the troubleshooting tips in the first post.