Bitcoin Forum

Bitcoin => Hardware => Topic started by: sidehack on June 08, 2016, 11:22:24 PM



Title: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 08, 2016, 11:22:24 PM
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.

http://gekkoscience.com/img_stash/S7LN/DSCN2309.JPG

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.

http://gekkoscience.com/img_stash/S7LN/DSCN2310.JPG

http://gekkoscience.com/img_stash/S7LN/1_hour_610_450.PNG

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


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: ZedZedNova on June 08, 2016, 11:56:35 PM
Interesting project for sure. Looking forward to the updates.

Cheers,

- zed


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: NotFuzzyWarm on June 09, 2016, 12:47:30 AM
Interesting...
On the batch ones, is the string voltage set by what the PSU provides (at the PCIe plugs) or a fixed board-level buck? I ask because I have a b1 at work that has oc'd beautifully - set to 700MHz both ck and M's Miner Monitor pegs its average hashrate @ 5.43THs with peaks of 6THs and higher  :o I have a b5 that does almost as well. Wonder what they would do with a tad more Vcore done by raising the PSU voltage a tad? ;)


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 09, 2016, 01:00:31 AM
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.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: NotFuzzyWarm on June 09, 2016, 01:14:19 AM
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.
8)
So if I dial up the output from a IBM 2kw supply another 1/10v or more, things might get interesting...

Sidenote: After the bonded T1 service at work that supplies the VOIP phones and i'net being down since ~ 7:30 this morning, as of 1 hour ago it looks like it's back up. I left 2 s5's powered up there to watch on ck pool. That outage dropped me 86.4THs for (over) 14hrs.  :'( More of a bugger is that now I just don't feeling like going 20 miles to bring it all back up. That can wait til the morning I...


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 09, 2016, 01:57:07 AM
And by "154-chip" obviously I mean "162-chip", which is to say 54 chips per board. Whoops.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: adaseb on June 09, 2016, 02:03:45 AM
So since each blade is about 200 watts, can these operate at close to the S3 noise levels? Your temps are 47C can you run these S7 safely at like 60C with a slower fan speed?



Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 09, 2016, 02:23:04 AM
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.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: RichBC on June 09, 2016, 05:56:18 PM
Good to see someone hacking this... I have some PIC hacking experience as was part of a team that reverse engineered and reprogrammed the PIC in the Scalextric Digital Powerbase. Have Pickit 2 and Logic Analyser etc, however no 135 Chip S7. I will look into solving that if the couple of S5 I have on ebay sell.

Rich


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 09, 2016, 06:06:58 PM
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.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: RichBC on June 09, 2016, 06:59:14 PM
Yes probably but like you have a lot of other stuff on my plate at the moment. I had however when I first saw the 135 chip S7 bought some PIC12F1572 and some MCP4017 so time permitting can knock something up without an S7. Will PM you with and email as might be interesting to look at the hex code you have downloaded.

Rich


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 09, 2016, 07:03:28 PM
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.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: yslyung on June 09, 2016, 07:41:03 PM
wow !!! thx for the experiment & find, keeping an eye on this for sure.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: philipma1957 on June 09, 2016, 08:13:34 PM
wow !!! thx for the experiment & find, keeping an eye on this for sure.

a 2 board  7 lite down clocked to 2000gh doing .18 watts a gh would be a 360 watt machine.

it would be a decent item


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 09, 2016, 08:20:47 PM
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.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: kipper01 on June 09, 2016, 10:34:48 PM
Cant wait to see what you come up with sidehack.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: philipma1957 on June 09, 2016, 10:42:08 PM
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.

so 450 to 2000gh  is .225 watts` per gh

with a titanium maybe 430 watts  or .215 watts a gh.

good numbers don't know how many I would get , but at least one.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 09, 2016, 11:04:44 PM
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.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: NotFuzzyWarm on June 10, 2016, 12:41:15 AM
Me likey. Me likey a LOT!
Considering with the 3 s7's I had planned taking off line at home (being replaced with ma s9 whenever it gets here) and the 2x batch-18 um, spares, I have. This is looking very good: After undervolting the farm to stably run ~ 4THs per miner pulling under 700w (edit, 1,100w) each would let me put most if not all the s'7s I have back online with still less than my current power budget. 'Taint ran the #'s but  methinks more THs ta boot :D

Tossing a coin into the tip jar for this!


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 10, 2016, 01:19:16 AM
Actually, 4TH would be more like 1100W.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: NotFuzzyWarm on June 10, 2016, 01:31:54 AM
Actually, 4TH would be more like 1100W.
Still nice shaving of the power. More #'s for me to play with to see how much hash & 'spare' miners I can fit in my power budget.

edit: re: my free power (at work) advantage. While playing with numbers turns out I'm using 23kw there which at our rate works out to just s tad under $1,600/mo. ;) Anywho, after deducting that from what the entire farm brings in including what is at home, I'd still NET around $5k/mo. Think I might talk to my Partner about setting up an automatic Coinbase xfr to the company each mo to be nice, eh?

I can certainly afford the BTC2.7-2.8 per month and it'd help a bit towards our current massive R&D expenses piling up for this year. To date that is somewhere close to $450k and climbing fast. That's not counting the usual price of a very nice Ultrafast laser from Trumpf http://www.us.trumpf.com/en/products/laser-technology/products/solid-state-lasers/short-pulsed-lasers/trumicro-series-5000-femto-edition.html (http://www.us.trumpf.com/en/products/laser-technology/products/solid-state-lasers/short-pulsed-lasers/trumicro-series-5000-femto-edition.html) that is so far on a FREE 6/mo loan to us from them... OTH, I have nice shiny new toys to play, er, I mean do mid-Pico down to high Femto-sec time scales material interaction tests with. With a selectable choice of IR/Green/UV wavelengths no less.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 10, 2016, 02:53:36 AM
One of these days I really wanna hang out at your shop.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: NotFuzzyWarm on June 10, 2016, 03:24:54 AM
One of these days I really wanna hang out at your shop.
If you are ever up here in area feel free  to stop by. Current work is to once again leapfrog ahead of what our few competitors can provide. Since the last industry jump I did back in 2007 they are slowly figuring how we do what we do so bloody fast and tiny. http://www.industrial-lasers.com/articles/2007/11/processing-ceramic-substrates.html (http://www.industrial-lasers.com/articles/2007/11/processing-ceramic-substrates.html) (edit: note the article was our 1st release of Public information. In 2010 we skyrocketed speeds to now 5x those mentioned...) The LED lighting explosion going on everywhere is a direct result of what I came up with back then re: micro-machining ceramics for die heat spreaders in the emitter chips and other high power density chips. The actual emitter dies are smaller than the then-current thermal/electrical via sizes *were* back then. We shattered that limitation so more emitters in same package size. Figure another 2-3 years tops and they will be offering what we do today if they can work a way around our patents.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: hurricandave on June 10, 2016, 04:49:30 AM
This will sound stupid but, would the controller care if you pulled the fans and ran them from a separate speed controller like a evercool twister or equivalent?


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: Unacceptable on June 10, 2016, 07:37:41 AM
One of these days I really wanna hang out at your shop.
If you are ever up here in area feel free  to stop by. Current work is to once again leapfrog ahead of what our few competitors can provide. Since the last industry jump I did back in 2007 they are slowly figuring how we do what we so so bloody fast and tiny. http://www.industrial-lasers.com/articles/2007/11/processing-ceramic-substrates.html (http://www.industrial-lasers.com/articles/2007/11/processing-ceramic-substrates.html) The LED lighting explosion going on everywhere is a direct result of what I came up with back then re: micro-machining ceramics for die heat spreaders in the emitter chips and other high power density chips. Figure another 2-3 years tops and they will be offering what we do today if they can work a way around our patents.

https://i.imgur.com/M9Xohub.gif


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: philipma1957 on June 10, 2016, 08:28:18 AM
This will sound stupid but, would the controller care if you pulled the fans and ran them from a separate speed controller like a evercool twister or equivalent?

yes  it would care but you could splice the tach wire into the controller and fool the unit.

not sure why you would do all that since you can set fan to 20 or 30%


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 10, 2016, 09:10:07 PM
[farnsworth]Good news, everyone![/farnsworth]

So I spent the day learning how to program in PIC. I have established that I can write code to the micro, and I can see a toggling clock output at pretty much exactly the rate I expected. I'm working on a bit-banging I2C routine and if this were a normal day I'd probably not go home until it was finished and working. However, it's Friday which means running errands before shops close at 5 and then it's burger time.

Otherwise, well, I'd probably be reporting results by about 7PM. That's how well things are going, that I expect it would only take another 3 hours to establish that I have functional I2C communication.

After that, I'd need to clean up the delay routines (right now I'm just inserting the right number of NOPs, but I should use actual loops instead) and then set up a timer for about 5 minutes so I can feed it a starting (hot) value and then, after a few minutes and cgminer is up and running and the chips are warmed up, I can feed it a running (cold) value automatically.

I really need to get back to manufacture, but this is such a freakin' cool project and coming together pretty well so I'll probably try and finish the code up tomorrow and let a test board run over the weekend.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: yslyung on June 10, 2016, 09:24:57 PM
itchy hand here, can't wait to see some awesome results.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: RadekG on June 10, 2016, 10:56:27 PM
Thank you Sidehack for continuing in my work. By the way, I found custom firmware from Germany which promises undervolting from WWW panel, so it seems they found our missing key - secret command to control PIC through controller board.

https://www.zwilla.de/de/downloads/custom-firmware-antminer-s7/

 


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 11, 2016, 04:48:52 AM
I figured it was there, probably part of the reason Bitmain never updated their repository for S7 stuff because they didn't want people to know about it. When I saw a UART line on the micro was tied into the TX line on the controller really gave it away. Wish I'd been able to look into this stuff months ago, but it's been a long time since I had the money to buy miners near release to figure them out. I think the AM Tube in August 2014 was about the last, which was fun because Novak and I were finding and solving problems with those before most of North America even had 'em yet.

I'm having so much fun that I'm gonna continue what I'm working on, and also because that link isn't working for me.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: RichBC on June 11, 2016, 06:55:29 AM
Always fun to have a Midnight Oil Burning project on the go. :)  I guess there also has to be a strong possibility that work on the 135 Chp S7 voltage control will translate to the S9?


Rich


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: yslyung on June 11, 2016, 10:58:00 AM
Thank you Sidehack for continuing in my work. By the way, I found custom firmware from Germany which promises undervolting from WWW panel, so it seems they found our missing key - secret command to control PIC through controller board.

https://www.zwilla.de/de/downloads/custom-firmware-antminer-s7/

 

it's fake me thinks & this guy is a cheat too. there's a thread but it didn't last long, kano & cryptoglance chimed in too.

asking $ for something that don't work & did NOT ask permission from cryptoglance to use their software.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: adaseb on June 11, 2016, 12:15:00 PM
Thank you Sidehack for continuing in my work. By the way, I found custom firmware from Germany which promises undervolting from WWW panel, so it seems they found our missing key - secret command to control PIC through controller board.

https://www.zwilla.de/de/downloads/custom-firmware-antminer-s7/

 

it's fake me thinks & this guy is a cheat too. there's a thread but it didn't last long, kano & cryptoglance chimed in too.

asking $ for something that don't work & did NOT ask permission from cryptoglance to use their software.

Don't think that will actually change the voltage. They released something similar for the S3/S5 but all it did was adjust the voltage in the "advanced" tab but we all know that since the voltage was fixed it didn't do anything.



Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 11, 2016, 12:20:36 PM
Looking through the thread, that's kinda what I was figuring too.

Don't worry guys, mine will work and I won't be charging for it.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: RichBC on June 11, 2016, 01:07:24 PM
Looking through the thread, that's kinda what I was figuring too.

Don't worry guys, mine will work and I won't be charging for it.

The other giveaway is that it makes no mention of only working on a 135 chip S7.

Rich



Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: philipma1957 on June 11, 2016, 01:30:27 PM
Looking through the thread, that's kinda what I was figuring too.

Don't worry guys, mine will work and I won't be charging for it.

I was thinking should we chip in and order an s-9 for you to play with?

An s-9 doing .08 watts would be very nice gear.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: yslyung on June 11, 2016, 01:41:10 PM
Looking through the thread, that's kinda what I was figuring too.

Don't worry guys, mine will work and I won't be charging for it.

yours will defo work, no need to charge, i'm sure many are willing to donate willingly to you.

we know you always do a good job ;) & sharing.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 12, 2016, 12:21:26 AM
Tentative success!

I was running into no end of trouble getting anything except delay loops to work, when after about 4 hours I realized I didn't know how to declare variables properly so the compiler was dumping everything into the same register. So I fixed that, and two hours later I have working bit-bang I2C with ACK/NACK recognition for two-byte data in a 164-opcode program. Not bad for never programming PIC before. This was fun.
Anyways. It has a 20mS delay loop after turnon, to let things settle out, and then passes a hot value to the DPOT. After about 3:15 or so it passes the cold value, and actually continues to pass the cold value again every 3:15 after that. I could just as easily tell it not to do that, but eh, no harm no foul.

Anyways I've got it pushed to my hacked-up board running 650mV hot and 620mV cold at 450MHz. It's worker 1BTCMUSEuM1uy4mCce9JGisMZD15RTG7em_S7LN on solo.ckpool for anyone wanting to watch the stats. I'm gonna let it run until tomorro after lunch, and then if it's looking good I'll reinstall the PIC, put the same code on the second board and let 'em both run overnight. If it's still looking good on Monday I'll upload an archive of HEX files for different cold-running values (with a corresponding hot-running value of ~5% higher) so y'all can play around. And I've got access to a full 3-board S7 to jack with too, should be fun.

The gold medal will of course go to reverse-engineering the PIC firmware to figure out what command is sent from the controller to adjust the voltage from software. But I'm not up to that.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: navigatrix on June 12, 2016, 01:37:19 AM
Actually, 4TH would be more like 1100W.

I'm in. Check your tip jar...

Thanks for this.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 12, 2016, 03:17:21 PM
Well the one blade's been running solid at 620mV (9.3V, down from 10.0V stock) and 450MHz (1TH) for about 15 hours now. This afternoon I'll do some more testing of the absolute bottom end efficiency and overall power use, generate some charts and plots for y'all. I'll go ahead and work up a stock S7 as well.

Just wondering, would anyone be interested in a group buy of S7 or S7LN pre-flashed to the desired improved efficiency setpoint for a moderate markup (maybe $20-30), tested and reshipped within the US within one or two days of arrival at my shop?


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: kipper01 on June 12, 2016, 06:50:25 PM
Well the one blade's been running solid at 620mV (9.3V, down from 10.0V stock) and 450MHz (1TH) for about 15 hours now. This afternoon I'll do some more testing of the absolute bottom end efficiency and overall power use, generate some charts and plots for y'all. I'll go ahead and work up a stock S7 as well.

Just wondering, would anyone be interested in a group buy of S7 or S7LN pre-flashed to the desired improved efficiency setpoint for a moderate markup (maybe $20-30), tested and reshipped within the US within one or two days of arrival at my shop?

My S7 already sitting in your shop.  :P  Feel free to take a look at it if you like.  :)


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: Biodom on June 12, 2016, 07:02:42 PM
Actually, 4TH would be more like 1100W.

there is also a 'funny' S7 batch 6, which was a prototype for later batches.
This batch is 4.05th at 1042W +extra at the wall per specs.
Do you think that this one can be improved or is it efficient already?
it's rated voltage is 11.6-13v.
thanks


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: philipma1957 on June 12, 2016, 07:24:52 PM
Well the one blade's been running solid at 620mV (9.3V, down from 10.0V stock) and 450MHz (1TH) for about 15 hours now. This afternoon I'll do some more testing of the absolute bottom end efficiency and overall power use, generate some charts and plots for y'all. I'll go ahead and work up a stock S7 as well.

Just wondering, would anyone be interested in a group buy of S7 or S7LN pre-flashed to the desired improved efficiency setpoint for a moderate markup (maybe $20-30), tested and reshipped within the US within one or two days of arrival at my shop?

maybe an  an s-7ln for me works,

 but do you think the s-9 can do this?  and drop to 9.3v if so  it may end up being an amazing value.

I have 4 s-9's two coming on tues-weds  two in 12 days or so. I think I will run 3 s-9's in the array and one with my buddy in his office.

Then run your s-7ln in house for fun along with the eth coin gear.

Maybe some research on s-9's will allow for them to go down to .090 or .085 per gh


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 12, 2016, 07:53:22 PM
I would guess any regulated-string S7 variant would be improvable.

I would also guess the S9 would be improvable. 63 chips is seriously dense though, so they might already be running them close to bottom end. I have an S9 being delivered for hosting this week that I could spend an hour with if the owner allowed it, but I don't like experimenting with other folks' hardware.

I'll try and work out some efficiency curves for the S7LN this afternoon, might bring it home and run it here at the house to get an idea of noise. Should probably bring a stock S3 as well for comparisons, since me saying "it's not that loud" doesn't mean anything to almost literally everyone else (I have a very high tolerance for fan noise).

So, something like a hacked S7LN group buy might be in order?


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: philipma1957 on June 12, 2016, 11:07:56 PM
I would guess any regulated-string S7 variant would be improvable.

I would also guess the S9 would be improvable. 63 chips is seriously dense though, so they might already be running them close to bottom end. I have an S9 being delivered for hosting this week that I could spend an hour with if the owner allowed it, but I don't like experimenting with other folks' hardware.

I'll try and work out some efficiency curves for the S7LN this afternoon, might bring it home and run it here at the house to get an idea of noise. Should probably bring a stock S3 as well for comparisons, since me saying "it's not that loud" doesn't mean anything to almost literally everyone else (I have a very high tolerance for fan noise).

So, something like a hacked S7LN group buy might be in order?

Sending pm.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 12, 2016, 11:53:03 PM
I don't actually own a Kill-A-Watt and none of the stores I looked at in town apparently carry it, so I just threw together a metered socket with 0.1A resolution. The miner is currently powered off a Dell Z750P PSU. At hot voltage (650mV) I market 120V 2.1A, and when it switched to cold voltage (620) I mark a solid 120V 1.9A for 228W - that's the controller, both fans and a single board clocked at 1012GH for a device-level efficiency of 0.225J/GH

With both boards and the stock PSU, the current is bouncing between 3.4 and 3.5 amps. If we call it 3.45A, that's 414W for 2.03TH at 0.204J/GH - which definitely makes me happy.

I'll do more measures tonight (it's friggin' hot at the shop so I'll run it at home where I can also get a good "how annoying is this" sound gauge) and put up some more numbers on different setpoints.

EDIT - except that I moved some hex files over to a thumbdrive and then left it plugged into the workbench machine and didn't realize until I was already at home. So I won't be testing other voltage setpoints tonight. Whoops.

Also I have interest to the tune of 3 machines so far for a group buy.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: Biodom on June 13, 2016, 01:00:07 AM
I don't actually own a Kill-A-Watt and none of the stores I looked at in town apparently carry it, so I just threw together a metered socket with 0.1A resolution. The miner is currently powered off a Dell Z750P PSU. At hot voltage (650mV) I market 120V 2.1A, and when it switched to cold voltage (620) I mark a solid 120V 1.9A for 228W - that's the controller, both fans and a single board clocked at 1012GH for a device-level efficiency of 0.225J/GH

With both boards and the stock PSU, the current is bouncing between 3.4 and 3.5 amps. If we call it 3.45A, that's 414W for 2.03TH at 0.204J/GH - which definitely makes me happy.

I'll do more measures tonight (it's friggin' hot at the shop so I'll run it at home where I can also get a good "how annoying is this" sound gauge) and put up some more numbers on different setpoints.

EDIT - except that I moved some hex files over to a thumbdrive and then left it plugged into the workbench machine and didn't realize until I was already at home. So I won't be testing other voltage setpoints tonight. Whoops.

Also I have interest to the tune of 3 machines so far for a group buy.

while doing this, did you still had to power all 7 PCIe connectors or 4+1=5 was enough?
As far as wattage goes, it should be OK with 5.
Some people might be interested in selling the PSU on the aftermarket and powering two or even three with one EVGA 1300.
Using splitters one can up the number of connectors on 1300w EVGA to at least 12 easily.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 13, 2016, 01:07:05 AM
When I was bench-testing I only had 2 cables plugged into the board.

Here at the house, I locked the fan to 30% and it's about the same noise as a window fan on low sitting at the same distance. Pretty unobtrusive for my house. Temps at 44 and 46 in a 75F ambient.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: philipma1957 on June 13, 2016, 01:28:01 AM
I don't actually own a Kill-A-Watt and none of the stores I looked at in town apparently carry it, so I just threw together a metered socket with 0.1A resolution. The miner is currently powered off a Dell Z750P PSU. At hot voltage (650mV) I market 120V 2.1A, and when it switched to cold voltage (620) I mark a solid 120V 1.9A for 228W - that's the controller, both fans and a single board clocked at 1012GH for a device-level efficiency of 0.225J/GH

With both boards and the stock PSU, the current is bouncing between 3.4 and 3.5 amps. If we call it 3.45A, that's 414W for 2.03TH at 0.204J/GH - which definitely makes me happy.

I'll do more measures tonight (it's friggin' hot at the shop so I'll run it at home where I can also get a good "how annoying is this" sound gauge) and put up some more numbers on different setpoints.

EDIT - except that I moved some hex files over to a thumbdrive and then left it plugged into the workbench machine and didn't realize until I was already at home. So I won't be testing other voltage setpoints tonight. Whoops.

Also I have interest to the tune of 3 machines so far for a group buy.

while doing this, did you still had to power all 7 PCIe connectors or 4+1=5 was enough?
As far as wattage goes, it should be OK with 5.
Some people might be interested in selling the PSU on the aftermarket and powering two or even three with one EVGA 1300.
Using splitters one can up the number of connectors on 1300w EVGA to at least 12 easily.

I am looking to run 1. I am looking to use it with this psu.

https://www.amazon.com/gp/product/B01CE7NUIU/ref=oh_aui_detailpage_o01_s00?ie=UTF8&psc=1

I think it would do 395 watts.

I also may try to trick the fans the fans pull a lot of watts this fan below does less watts.


https://www.amazon.com/Focused-NF-F12-iPPC-3000-PWM/dp/B00KFCRATC/ref=sr_1_1?s=pc&ie=UTF8&qid=1465781203&sr=1-1&keywords=noctua+3000

goal would be to get under 390 watts


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 13, 2016, 02:44:52 AM
Well, looks like we got 5 for a group buy. I'll take that over to the right section then.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 13, 2016, 06:00:59 AM
It looks like my 640/610 profile is just fine for 400MHz, delivering 1.8TH at 340W for an efficiency of 0.189J/GH

I'm testing 425MHz on it now, and it's looking good. If it runs stable all night (I'm at zero errors five minutes into cold voltage), I can say 1.9TH at, according to my meter, 366W for 0.191J/GH. So this S7LN will go below 0.2J/GH machine-level. I was having trouble with the 630/600 profile doing anything right, but I'll check and make sure I just didn't screw up the code.

By the way, those numbers are for fans fixed at 20% (1560RPM); peak temp is 47C and it's as good as silent to me.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: notlist3d on June 13, 2016, 06:28:15 AM
It looks like my 640/610 profile is just fine for 400MHz, delivering 1.8TH at 340W for an efficiency of 0.189J/GH

I'm testing 425MHz on it now, and it's looking good. If it runs stable all night (I'm at zero errors five minutes into cold voltage), I can say 1.9TH at, according to my meter, 366W for 0.191J/GH. So this S7LN will go below 0.2J/GH machine-level. I was having trouble with the 630/600 profile doing anything right, but I'll check and make sure I just didn't screw up the code.

By the way, those numbers are for fans fixed at 20% (1560RPM); peak temp is 47C and it's as good as silent to me.

Well done on getting more efficiency with these chip's.  It's been fun to watch (I think you had first opened S7LN on site).   A efficiency upgrade to .2j upgrade is pretty amazing.  Either way congratulations it's a heck of a upgrade you have done on it.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 13, 2016, 01:51:05 PM
I'm questioning the stability of the 610mV setpoint. My first extended test last week was 610mV 450MHz, and it kicked out after about 8 hours. I ran 610mV 425MHz overnight and it kicked out after about 3 hours. But running 620mV 450MHz ran all day with no issues. The 620mV is about 0.22J/GH versus just under 0.2J/GH for 610 so I wish it was stable but I'm not so sure. Might be 620 is the best we got.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: IITravel01 on June 13, 2016, 03:31:47 PM
Well the one blade's been running solid at 620mV (9.3V, down from 10.0V stock) and 450MHz (1TH) for about 15 hours now. This afternoon I'll do some more testing of the absolute bottom end efficiency and overall power use, generate some charts and plots for y'all. I'll go ahead and work up a stock S7 as well.

Just wondering, would anyone be interested in a group buy of S7 or S7LN pre-flashed to the desired improved efficiency setpoint for a moderate markup (maybe $20-30), tested and reshipped within the US within one or two days of arrival at my shop?

I'd go for a S7-LN or two.  I'd love to see how efficient that could be with a Titanium power supply (I've got a EVGA 1,600w and a Thermaltake 1,250w I'd test with, as well as a 220v step up converter).


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: InvestexMarkets on June 13, 2016, 03:45:34 PM
This is a really interesting project you have here,  running @ 610mV - 450MHz @ 8hrs did you have recorded temps or any other recorded data you could share with us?




Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 13, 2016, 04:18:16 PM
Not really. It was a "hey this works but it's 7PM and I want to go home and eat lunch so I'll leave it on overnight" kind of test, and when I came back in the next day it had dropped out and the lifetime hashrate average was a bit over half expected so I extrapolated about how long it ran before stopping while I was not there to observe it.

I think the problem with the 610mV profile is probably balance. By the BM1385 datasheet, the chips should run 425MHz at 600mV. However, since the voltage is dropped per node according to the current use at that node, there is no perfect balance. If one node is dropping even 2% lower than the average 610mV setpoint, it's gone down to 590mV which I've found is in a range 28nm ASICs don't particularly like. The 620mV setpoint gives more leeway in node imbalances at the cost of slightly higher per-unit power use, so for now I'm recommending the 650/620 profile as the best stable bottom clock.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: InvestexMarkets on June 13, 2016, 04:28:17 PM
Not really. It was a "hey this works but it's 7PM and I want to go home and eat lunch so I'll leave it on overnight" kind of test, and when I came back in the next day it had dropped out and the lifetime hashrate average was a bit over half expected so I extrapolated about how long it ran before stopping while I was not there to observe it.

I think the problem with the 610mV profile is probably balance. By the BM1385 datasheet, the chips should run 425MHz at 600mV. However, since the voltage is dropped per node according to the current use at that node, there is no perfect balance. If one node is dropping even 2% lower than the average 610mV setpoint, it's gone down to 590mV which I've found is in a range 28nm ASICs don't particularly like. The 620mV setpoint gives more leeway in node imbalances at the cost of slightly higher per-unit power use, so for now I'm recommending the 650/620 profile as the best stable bottom clock.


Would be interesting to see if there would be a possiblity of some kind of "early warning" script that would detect the drop in volage for the node and adjusted the setpoint, haveing looked at the data sheet for BM1385 I am still wondering what other issues might arrise from the voltage drops if you persisted at the higher rates.

fantastic reading and some good development in this thread, Ill be keeping a keen eye on the progression of your project!

Thanks!


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 13, 2016, 04:49:29 PM
One problem with having a hot and cold setpoint are, since the hot setpoint is only delivered when the miner is first powered up, it's entirely possible that simply restarting cgminer after a board drops out will actually cripple the whole machine. It really requires a power-cycle - more specifically, it requires cutting 3.3V to the hashboards which would require either power-cycling the controller or some external hardware.

Since the micro listens on the TX line, I could have it just check in for traffic and if it detects there's no hashing going on (so, cgminer was killed) it resets back to hot setpoint to be ready to restart mining. I'll have to look into exactly what traffic gets sent when cgminer is still operating even though the board is down to know how to detect that condition, and I don't really have time for a while.
Possibly the code could increment the cold setpoint every time mining fails and is restarted. One problem with that is you couldn't optimize per-board since both boards would detect cgminer restarting and both increment even if only one needed it. Also, unless it was saved to EEPROM, the new setpoint would be lost every power-cycle. If it was kept, without a means of resetting back to defaults, over time the setpoint will drift higher and higher due to internet downtime, manual reboots from software and other issues.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: InvestexMarkets on June 13, 2016, 09:32:08 PM
One problem with having a hot and cold setpoint are, since the hot setpoint is only delivered when the miner is first powered up, it's entirely possible that simply restarting cgminer after a board drops out will actually cripple the whole machine. It really requires a power-cycle - more specifically, it requires cutting 3.3V to the hashboards which would require either power-cycling the controller or some external hardware.

Since the micro listens on the TX line, I could have it just check in for traffic and if it detects there's no hashing going on (so, cgminer was killed) it resets back to hot setpoint to be ready to restart mining. I'll have to look into exactly what traffic gets sent when cgminer is still operating even though the board is down to know how to detect that condition, and I don't really have time for a while.
Possibly the code could increment the cold setpoint every time mining fails and is restarted. One problem with that is you couldn't optimize per-board since both boards would detect cgminer restarting and both increment even if only one needed it. Also, unless it was saved to EEPROM, the new setpoint would be lost every power-cycle. If it was kept, without a means of resetting back to defaults, over time the setpoint will drift higher and higher due to internet downtime, manual reboots from software and other issues.

I would say once you have some time the traffic might be a good place to get some more reference from. I really like the idea of hot/cold script If only there was relm for small flash memory instead of EEPROM.



Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 13, 2016, 09:42:27 PM
The problem with updating the last setpoint is, you can't change it without reflashing the whole PIC firmware again. Unless you could talk to it via the controller's TX line, but if you can do that you might as well just write a firmware to set the voltage wherever you want via controller software. Which is probably what Bitmain's firmware already does, we just don't know the commands to make it do what we want. And I have probably already put more time on firmware than I should have, but it's the most fun I've had at work in months. Manufacturing is super boring, but it's also super necessary if I want to not go bankrupt, so I probably won't have more time until I get caught up on building stuff. Unless I get a bunch of sales on PSU boards right quick, in which case maybe a day of additional firmware dev would be a good celebration.

Anyone looking for a good PSU to run an S7 or S9 off 208/240?


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 13, 2016, 11:55:00 PM
Also, I've settled on terms for the group buy so that's live now.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: adaseb on June 14, 2016, 06:19:51 AM
This reminds me of the S4 I once had. I got it really cheap and it was crazy loud, and I had to have it in my room that I sleep in.

I remember I managed to make it almost silent at 1.3TH/s running at around 0.55W/GHS and I swapped in some S3 fans and played around with the fan controller settings. You could actually change the voltage in the control panel. No need to pencil mod.

The loudest part was actually that stock server PSU. Sure miss that miner.

Its amazing how with an undervolt and underclock you can turn the loudest miner into something manageable.





Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 14, 2016, 12:24:26 PM
I got a mostly-working S4 for free end of last year and gave it the same treatment to heat my apartment over the winter. Well, I didn't replace the fans but they did run a lot slower.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 14, 2016, 04:28:28 PM
Inbetween things today, I'll be getting some operating data from different voltages and clock setpoints. I've got a stack of pregenerated hex files for different hot/cold settings and when I put up the analysis numbers I'll also post a ZIP file with all of 'em in it within a few days.

Right now it looks like 750MHz might be just a bit high for the 720/690 profile ( .03% errors) for 3.38TH from 900W at 61C, but that's still pretty decent. I think the cold-running is about the same setpoint as a stock full S7.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: Sweminer777 on June 16, 2016, 12:34:13 PM
Inbetween things today, I'll be getting some operating data from different voltages and clock setpoints. I've got a stack of pregenerated hex files for different hot/cold settings and when I put up the analysis numbers I'll also post a ZIP file with all of 'em in it within a few days.

Right now it looks like 750MHz might be just a bit high for the 720/690 profile ( .03% errors) for 3.38TH from 900W at 61C, but that's still pretty decent. I think the cold-running is about the same setpoint as a stock full S7.


this 2 boards s7 lookssimilar to Batch6 boards.

I was looking around, took some photos too.

I can overclock abit if iset up the voltmetere to around 12.120Vis good from PSU else it gets alot of errors.

mine hashs 4050, but is doing around 4200-4400 wich is fine considering that b6 is not overclockable.

ill post some pictures soonof my boards så you can take a look on the similarity.

regards.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: RichBC on June 17, 2016, 10:00:04 AM
I have got hold of a Hash Board from a Batch 8 135 Chip S7. Have it running on the Bench with an S5 Controller Board loaded with the S7 Firmware. I have been playing with the various different firmware versions and noticed something interesting with the latest single fan release.
S7firmware-201605231558-700M-1fan-6000.tar.gz MD5:7A38217ED4B93D662F4F0EBB85006694

Immediately after power up the Pic programs the Digital pot, with my board this is with 14 which sets the string Voltage to 10.667V. However with the latest single Fan firmware I detected on the Analyser a second programming of the Pot about 37 seconds after booting. This was also to 14.

Looking at the Kernel Log and also monitoring on the Serial Interface of the BBB I see the following.

Code:
[   36.708381] clear FPGA nonce buffer..
[   37.014489] btm_tx_conf..
[   37.017098] Set asic frequency {100}..
[   37.020850] bitmain_set_pic_voltage: n = 14..
[   37.025232] set_pic_voltage cmd_buf[0]: 0xab, cmd_buf[1]: 0xb0, cmd_buf[2]: 0xe, cmd_buf[3]: 0xd4..
[   37.034503] send BC data:..0x0000: 0x03 0x00 0x00 0x1a 0xab 0xb0 0x0e 0xd4 ..
[   37.056664] send BC data:..0x0000: 0x03 0x04 0x00 0x1a 0xab 0xb0 0x0e 0xd4 .

So it looks like Bitmain might be using the the TX connection to the Pic to pass a Digital Pot setting after booting.

Looking on the Analyser there is a Burst of data on the TX, which is also echo'd 100uS later on RA4 which is connected to the 2 Pin P2 connector on the board edge.

Then 4.8mS later the Pot is programmed with 14. Unfortunately as my system programs 14 at power up and then 14 again I cannot tell if the Pic is just repeating it's inbuilt value or passing the new value.


I do not know if there will be a file that can be SSH into with this 14 Value in or if it's embedded in some Bitmain code. I cannot find a file, but if anyone knows their way around the firmware perhaps they could have a look?


Rich


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 17, 2016, 12:13:52 PM
Not unexpected. What's the voltage setting given in the cgminer.conf for that one?

Today's a short day, and also a fairly full one, so I'm not sure if I'll have time to play with this info yet. But I'll work on it.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: RichBC on June 17, 2016, 12:34:19 PM
cgminer.conf shows "bitmain-voltage" : "0706" which I suspect is not used, but could try changing it?

Rich



Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 17, 2016, 12:43:00 PM
Given that's the same number I've seen everywhere else, and have seen several different numbers written by the PIC, I doubt it's what we're looking for. But I could be wrong.

Also, when you give the values written by the PIC here and in the S7 repair thread, are you giving hex or decimal?


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: RichBC on June 17, 2016, 12:47:31 PM
Yes I have seen that number before, tried changing it but 0x14 still written. The written value is in Hex, the 14 from the kernel log I had at first assumed to be decimal but must also be hex. Not sure what I have put in the repair log, whatever it is could be either?


Rich



Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 17, 2016, 06:28:25 PM
Say, possibly dumb question. Where's the kernel log on these?


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: alh on June 17, 2016, 06:31:01 PM
Say, possibly dumb question. Where's the kernel log on these?

On most Linux based systems, /var/log/messages is it. That would have Kernel and possibly other messages. I expect cgminer to place it's logs elsewhere, though I don't really know.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 17, 2016, 06:33:00 PM
Not sure if I'm doing something wrong, but I'm getting nothing out of /var/log is why I'm asking.

EDIT - perhaps at some point I should remember it's viewable in the webconfig.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: HagssFIN on June 17, 2016, 06:45:22 PM
..
EDIT - perhaps at some point I should remember it's viewable in the webconfig.
Yeah.
My S7 (B9) shows nothing in the kernel log when I'm viewing it with Chrome, but with Microsoft Edge it works ok.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 17, 2016, 06:50:34 PM
So I just put that firmware on a stock S7. I didn't probe the I2C lines but measuring the voltage says it should have been about 0x10 (hex 16). After putting that firmware on, now I'm seeing a voltage corresponding to 0x0E (hex 14) so I reckon it actually is doing the update.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: RichBC on June 17, 2016, 07:22:14 PM
I get the kernel log in under System, seems to show initially but then of often goes blank.

So good news that it seems to take the Parameter. Just need to find where it is stored so we can change it?

Here is the full Data sent from RA4 which is connected to P2 on the board edge.

Code:
12:06:10.177  73 0E FF FF FF FF FF FF                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         s.ÿÿÿÿÿÿ
12:07:16.080  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              .................................................
12:07:16.096  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    ...............
12:07:16.137  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 ................................................................
12:07:16.178  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 ................................................................
12:07:16.217  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 ................................................................
12:07:16.257  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 ................................................................
12:07:16.273  FE                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              þ
12:07:16.289  24 24 24                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        $$$
12:07:16.305  24 24                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           $$
12:07:16.321  24 24 24                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        $$$
12:07:16.337  24 24                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           $$
12:07:16.353  24                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              $
12:07:38.305  84 00 00 11                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     „...
12:07:39.678  AB B0 0E D4                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     «°.Ô
12:07:39.694  14 33  

The first line is sent soon after Power up then the others at the times shown. They are obviously filtering the TX in some way, can only assume it is there to help debug or who knows?

Rich





Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 17, 2016, 07:29:37 PM
Right. I'll spend a bit of time trying to track down the command to TX that info. Not a lot, since I still got stuff to do and it's BURGER NIGHT.

Also thinking about it, that cmd_buf looked familiar. It's in driver-bmsc in what currently exists of bitmain's cgminer fork code, and in Icarus in U3 code. So, it's probably tied into cgminer itself and not in a script somewhere. But where is it stashed in a config? Hm...


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 17, 2016, 09:12:36 PM
http://gekkoscience.com/img_stash/S7LN/eff_chart.PNG

Decided to summarize some of the mass of data down there in a handy graph. Note the bars represent a "maximum stable GH" for each voltage level; there is none for 720mV because it was still good at 750MHz and I didn't want to take it any higher for fear of blowing the regulator. The operating frequency can be derived from the hashrate by dividing by 4.5

So here's a not quite complete but pretty extensive chart of measured performance from my hacked S7LN.

Columns:
mmm/nnn - hot starting voltage/cold running voltage
xxx - operating frequency
Calc GH - Calculated GH of two 45-chip boards at running frequency
VAC, IAC - voltage and current measurements in cold running
WAC - Watts AC, power measure during cold running (calculated value)
Calc J/GH - Calculated J/GH based on Calc GH and WAC
HW% - percentage of HW errors after 30 minutes runtime
GH - 30min - Measured average GH after 30 minutes runtime
Hash Eff - Measured GH as a percentage of Calc GH
Actual J/GH - calculated from WAC and 30min measured GH

720/720Calc GHVACIACWACCalc J/GHHW%GH - 30minHash EffActual J/GH
75033751168.810210.3020.00033831.000.302
7253262.51158.69890.3030.00032501.000.304
70031501158.259490.3010.00031651.000.300
6753037.51157.99090.2990.00030351.000.299
65029251157.68740.2990.00028890.990.303
710/710
7753487.51158.8510180.2920.00834530.990.295
75033751158.59780.2900.00133260.990.294
7253262.51168.19400.2880.00032561.000.289
70031501177.89130.2900.00031090.990.294
6753037.51177.458720.2870.00030601.010.285
65029251177.28420.2880.00029351.000.287
700/700
80036001168.59860.2740.10433650.930.293
7753487.51168.39630.2760.03334360.990.280
75033751168.059340.2770.01133681.000.277
7253262.51167.78930.2740.00132210.990.277
70031501167.458640.2740.00031641.000.273
6753037.51167.28350.2750.00030150.990.277
65029251176.98070.2760.00029401.010.275
720/690
75033751177.709010.2670.03232930.980.274
7253262.51167.608820.2700.00732430.990.272
70031501167.258410.2670.00131280.990.269
6753037.511678120.2670.00030691.010.265
65029251176.67720.2640.00029491.010.262
6252812.51186.357490.2660.00028091.000.267
710/680
7753487.51177.608890.2550.33227990.800.318
75033751157.708860.2620.09031700.940.279
7253262.51157.408510.2610.02432000.980.266
70031501176.908070.2560.01031351.000.258
6753037.51176.607720.2540.00130341.000.255
65029251176.357430.2540.00028800.980.258
6252812.51176.107140.2540.00028061.000.254
60027001175.806790.2510.00026981.000.252(approx stock)
700/670
75033751167.258410.2490.42925930.770.324
7253262.51167.008120.2490.12630580.940.266
70031501166.807890.2500.03730790.980.256
6753037.51176.507610.2500.00830301.000.251
65029251176.207250.2480.00129191.000.249
690/660
75033751167.008120.2410.50324650.730.329
7253262.51166.807890.2420.23928150.860.280
70031501166.507540.2390.10729150.930.259
6753037.51166.307310.2410.03129460.970.248
65029251166.057020.2400.00729090.990.241
680/650
70031501186.207320.2320.27026460.840.276
6753037.51186.007080.2330.09628480.940.249
65029251185.756790.2320.03228670.980.237
6252812.51185.606610.2350.00528201.000.234
60027001185.306250.2320.00026810.990.233
670/640
65029251175.606550.2240.09627560.940.238
6252812.51185.306250.2220.02727650.980.226
60027001185.206140.2270.00527031.000.227
5752587.51175.005850.2260.00125590.990.229
55024751184.705550.2240.00024340.980.228
660/630
6252812.51185.106020.2140.12526060.930.231
60027001184.955840.2160.02826460.980.221
5752587.51174.805620.2170.00525740.990.218
55024751184.555370.2170.00025031.010.215
5252362.51184.305070.2150.00023651.000.215
650/620
6252812.51175.005850.2080.34322350.790.262
60027001184.755610.2080.14024620.910.228
5752587.51184.505310.2050.04125080.970.212
55024751184.305070.2050.00924671.000.206
5252362.51184.104840.2050.00123651.000.205
50022501183.904600.2050.00022401.000.205
4752137.51183.704370.2040.00021110.990.207
45020251183.504130.2040.00020171.000.205
4251912.51183.303890.2040.00019131.000.204
40018001183.103660.2030.00017991.000.203
640/610(unstable)
5752587.51184.405190.2010.08224190.930.215
55024751184.204960.2000.02524370.980.203
5252362.51184.004720.2000.00423440.990.201
50022501183.804480.1990.00122531.000.199
4752137.51173.604210.1970.00021311.000.198
45020251183.353950.1950.00020070.990.197
4251912.51183.203780.1970.00019121.000.197
40018001193.003570.1980.00017840.990.200
630/600(unstable)
50022501193.604280.1900.00822320.990.192
4752137.51183.504130.1930.00321140.990.195
45020251183.303890.1920.00220231.000.192
4251912.51183.103660.1910.00119131.000.191
40018001182.903420.1900.00118001.000.190


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: IITravel01 on June 18, 2016, 04:38:00 PM
That chart is really informative.  Looks like the sweet spot at 650/620 is 500M to 550M.  I suspect 525M or 537.5M (should bring 2.4+TH/s at 495w, the only thing that shows bad for 550M is the HW errors creeping up) might be best.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 18, 2016, 04:49:42 PM
Yeah, 620 is a good setpoint. Assuming mine is a representative sample, the group-buy miners will be programmed with 650/620 unless otherwise specified, and shipped set at 450MHz for 2TH at a shade over 400W. That does give the owner still a lot of room to play, including getting close to stock speed (since 550MHz versus 600MHz only costs about 225GH) but saves close to 200W. All those numbers are given with free-running fans, by the way. Turning fans down will save a shade of power on fans, but as chip heat increases the chip-level power requirement increases for a given voltage and frequency. It's a tradeoff.

Once the group-buy batch miners start arriving about Tuesday I'll be able to get measures from a bigger sample set and compare.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: philipma1957 on June 18, 2016, 04:54:48 PM
Picture this your office is too fucking cold over ac'd by morons and you can not make it comfortable  without a space heater

so instead of this space heater in the office

https://i.imgur.com/oLk1RhV.jpg

set the s-7ln to these settings and run at cksolopool  gives you a shot at a block  around 140-150 times a day

https://i.imgur.com/ufpzWhy.png


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: NotFuzzyWarm on June 18, 2016, 05:12:11 PM
or -- find a way to fit s7 chips inside of that fluid-filled heater for immersion 'cooling' and dead-silent hashing...
Just find a way to vary the wattage (voltage) applied to the strings to give proportional control of temp vs just an on-off thermostat.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 18, 2016, 05:19:08 PM
Probably best to try that with something better than S7 chips, especially with the halving and that S7 is going on a year old. But the idea is sound (as it always has been).

With board-level power measurements it would be easy to write a control program that optimizes the voltage and hashrate for a given power dissipation and target error rate.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: IITravel01 on June 18, 2016, 05:20:35 PM
I've got a couple Titanium power supplies that I want to try these on to see how efficient I can get a setup going (a SilverStone 800w Titanium and a Corsair 1500w Titanium that I'll try to run two on).  Since a power supply is most efficient at about 50% load, a EVGA 1000w Titanium on 220v (should add an approx. 2% additional eff.) should deliver a sweet spot with a whole setup with one miner when the S7-LN is set at 537.5M (495w).


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 20, 2016, 10:34:21 PM
http://gekkoscience.com/img_stash/S7LN/S7LN_HEX.zip (http://gekkoscience.com/img_stash/S7LN/S7LN_HEX.zip)

The above link is a ZIP archive containing some 17 hex files. The one called "S7LN_PIC_FIRMWARE.hex" is the original unmodified firmware found on the hashboards in my S7LN.

The remaining files are called "S7LN_userselect.X.production.AAA-BBB.hex" where AAA represents the cold running voltage and BBB is the hot running, in millivolts average per node.

I have cold-running files from 580mV to 690mV, where the hot is 30mV higher. I also have three files that set both hot and cold to the same for 700, 710 and 720mV - at those points, a clock rate that would require a higher voltage to start would also draw enough power to smoke out the whole board. Pretty sure anyways. I've tested up to 775MHz and 1020W wall (stock setting was 680W on my unit) without finding an unstable clock on even 710mV and I don't want to catch my boards on fire.

Anyway. If you want to make use of this, find yourself a PIC programer (I use a PICKit 3 that I've had since about 2013) and grab the MPLAB IDE software. What you'll actually need is the IPE side (Programming, rather that Development) but I'm not sure it's possible to download just the IPE without getting the whole thing.

If you remove the outlet fan from the unit, at the end of the boards you will see eight pinholes - one pair, and one set of six. The six are the ISP header into which you'd plug your PICKit.
http://gekkoscience.com/img_stash/S7LN/these_holes.JPG

The lowermost hole of the six corresponds to the header-socket hole on the PICKit that has been flagged (on mine there's a while triangle pointing to it).
http://gekkoscience.com/img_stash/S7LN/pickit3_attached.JPG

You'll want to set the IPE "Device" drop-down to PIC12F1572. Under the "Settings" select Advanced Mode, and once in there click Power, set VDD to 3.3V and check "Power Target Circuit from Tool". For that to work right you're going to want to unplug the 18-pin cable from the board before you program it.

Once that's all configured, plug your PICKit into the board (you might need some wires or pins to connect the header socket of the programmer to the holes on the board) and click "Connect". If you did everything right, there ought not be any errors. Might get a box pop up saying something about low-volt programming and voltage mismatches or some such; just click "OK" and carry on. As far as I can tell it doesn't matter for this application.
You should be able to read existing code off the chip, which you can see in Memory View (View -> Show Memory). If you would like, click "Read" to pull all the existing firmware off and File->Export->Hex to save a backup copy just in case.

Click the "Browse" button associated with the Source path, and navigate to the new hex file of your choosing. Once that's loaded, click "Program" to push the new program to the board.

Make sure you plug the 18-pin cable back in before trying to mine again.

The program will turn on your board to the hot-start voltage value upon power-up of the controller board. The S7's software, once the OS is booted, will run cgminer for about a minute to get things warmed up and then restarts it fresh. My board firmware will start the cold running voltage about 35 seconds into the second cgminer run. If you're watching on a kill-a-watt, the power consumption should drop about 10% or so when it kicks over to cold-running.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: yslyung on June 20, 2016, 10:56:32 PM
lazy to read, PIC pls, it tells a million words :P

thx for sharing & the hardwork sidehack ! u the man.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 20, 2016, 11:02:20 PM
Yeah, but text doesn't carry near the data payload of a picture and I don't cater to lazy folks.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: NotFuzzyWarm on June 20, 2016, 11:05:07 PM
Yeah, but text doesn't carry near the data payload of a picture and I don't cater to lazy folks.
True but -- I did read it and have to say that a picture or 2 of the header connections and if ya have it. a pn for the header needed would be very helpful... You can always just resize the pics to a lower rez or compress more.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 20, 2016, 11:07:02 PM
Everything's just a standard 0.1" holes; once you pull the fan and look at the board it should be pretty obvious what's what.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: NotFuzzyWarm on June 20, 2016, 11:17:32 PM
Everything's just a standard 0.1" holes; once you pull the fan and look at the board it should be pretty obvious what's what.
Cool, so just a standard strip pins header I take it.
If I can get a few of the s7's down to be able to run off of DPS1200 @ 120v (so 800w) it would let me stash one in my office and the inspection room to replace the s5's there....


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 20, 2016, 11:26:54 PM
Yeah, it's pretty standard.

I bet 550MHz and 630mV would do you about 800W and give you 3.7TH per machine. 620mV might do that frequency stable but it's the threshold speed for that voltage on my machine. If yours has a bit slower chips it might not run stable without pushing the voltage a bit more. Also consider that it'll run hotter for about a minute and a half (maybe around 850W?) until it drops into cold voltage, so hopefully the PSU is good for that.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: RichBC on June 21, 2016, 11:29:46 AM
First off , good job on the revised Firmware. I have tried the files and they work as described.

Next just want to caveat my comments that follow with the fact that I am not running on a S7LN but a board from a Batch 8 135 chip Miner with an S5 controller Board programmed with the latest  S7 Single Fan Firmware. So some comments may be specific to this setup as opposed to a standard S7LN?


Finally a few comments from my first play...

1) You need a PicKit 3 I had a PicKit 2 but the  PIC12F1572 is not supported.

2) On connecting the Software reports.

Target Device ID (0x3050) does not match expected Device ID (0x3051).

You can then continue, and on checking the Device ID Memory it shows the correct 3050

3) After the initial Hot & then Cold programming the Digi Pot is reprogrammed with the Cold Programming at approx 3 Minute intervals. Not sure if this is deliberate or if there is an unintended loop?

4) I tried to reload the original firmware, both a copy that I saved and the one in the Zip, neither of them ran.

In addition the one from the Zip reports

Warning: S7LN_PIC_FIRMWARE.hex contains code that is located at addresses that do not exist on the PIC12F1571.
Code incompletely loaded.

sidehack not sure if you have retried the original firmware?


Rich


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 21, 2016, 12:25:17 PM
Continuing to loop the cold value is known behavior as mentioned earlier in the thread. I could have coded the loop to kick out after the second write but it's not hurting anything.

I have not tried writing the firmware back after telling the IPE it's the wrong chip with only 1.75KB of code space instead of the required 3.5KB and also the wrong device ID, but I can see why it would throw the errors you're reporting.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: RichBC on June 21, 2016, 09:35:52 PM
Continuing to loop the cold value is known behavior as mentioned earlier in the thread. I could have coded the loop to kick out after the second write but it's not hurting anything.

I have not tried writing the firmware back after telling the IPE it's the wrong chip with only 1.75KB of code space instead of the required 3.5KB and also the wrong device ID, but I can see why it would throw the errors you're reporting.


OK all my mistake, for some reason when programming I selected PIC12F1571 instead of PIC12F1572

The original code loads and runs fine when you select the correct chip....

What was interesting is that the Code saved by Sidehack set my voltage initially to 10.055V whereas when the write from cgminer came in it set it to 10.663V confirming that  the initial Pic voltage is then overwritten by the new value.

Even more interesting was that on rebooting the initial write set to 10.663V as well, so I think they are saving the new value in the Pic.


Rich


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 21, 2016, 09:49:20 PM
Huh, interesting. Yeah, my S7LN was set to right around 10V (0x1B, which measured out as 10.16V on my DMM) which is definitely low for a stock S7 designed for 650 or 700MHz.

Interesting that it saves the value. Maybe they do some initial testing with their software-voltable firmware to bin the boards, and since the value they settle on is stored on the board they can then hook them up with the not-software-voltable firmware they give to customers.

Do you have a dump of the TX data that gets sent to the board when it lights up, that looks like what sets the voltage? It would be interesting to write a little program for the BBB to spoof that, but I'm not sure whatall they do for UART multiplexing on the IO board. And since their cgminer source hasn't been updated since the S5, which I don't know if it's compatible...


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: RichBC on June 21, 2016, 09:59:50 PM
Post #76 on the previous page is a dump of what is sent from RA4 which I think might be the Pic echoing the key data? Getting a bit late here but will check Tomorrow what the complete TX data is, however there is a lot of stuff there nothing to do with the Pic.

Yes the original firmware from your Dump writes 0x1B and the Latest Single fan Firmware writes 0x0E

Also worth noting that I have only so far seen this behaviour with the latest Single Fan firmware.


Rich


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 21, 2016, 10:07:06 PM
Right, I recall now you did already post that. Sorry.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: RichBC on June 21, 2016, 10:14:20 PM
It would be interesting to write a little program for the BBB to spoof that, but I'm not sure whatall they do for UART multiplexing on the IO board. And since their cgminer source hasn't been updated since the S5, which I don't know if it's compatible...

Probably the easiest way to confirm the operation of the Pic would be to break the TX line to the Pic and connect to a Terminal Emulator TX along with RA4 to RX?


Rich


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: aarons6 on June 21, 2016, 10:18:01 PM
im watching this thread.. and if i can comprehend what is happening.. are you guys saying you can electronically adjust the voltage on the s7? making it more efficient?


i searched pickit3 and it seems like a controller of some sorts.. do you just plug it in and upload the firmware? is it usb? or do you need to do like a jtag setup? if so do you leave it attached when you are done?
is there soldering involved or are there holes you can push pins through?




sorry for all of the questions, but i think i need this.. my s7 needs to be more efficient if i am to continue using it after the halving.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: RichBC on June 21, 2016, 10:29:25 PM
Pickit 3 is an ICSP programmer, it is USB, it can be temporarily connected without soldering by just stressing sideways pins inserted into the 5 through plated holes on the edge of the board to reprogram the Pic. It does not have to be left connected.

Rich


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 21, 2016, 10:29:55 PM
I did take some pictures when I worked up the first-round LNs today. I'll get those added to the explanation post.

Also, based on your TX dump and what I'm seeing in your kernel log (confirming with my own), I'd guess the "AB B0 0E D4" is the command for adjusting voltage, where the third byte (0E) is the volt-setting command. I'll test this later on a factory-firmware board.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: aarons6 on June 21, 2016, 10:55:27 PM
Pickit 3 is an ICSP programmer, it is USB, it can be temporarily connected without soldering by just stressing sideways pins inserted into the 5 through plated holes on the edge of the board to reprogram the Pic. It does not have to be left connected.

Rich

sweet. i have to get one.. and see if i can figure out what you guys are talking about lol..


right now im running my s7 @ 600M because i only have one wall outlet.. it runs around 4th and its about 1120W.
by the chart on page 4 i see that if i do this i can run it at 650/620 and it will be only 800W.

this means i can still mine bitcoin with my s7 after the halving until it no longer produces 60$ a month.. which would be around 300,000,000,000 difficulty at todays bitcoin price..
instead of right now after the halving i instantly go unprofitable..

i like this idea.. it might even allow me to get another s7 and save up for a s9 when they get cheaper.

does anyone know how to do this with an avalon 6?

is this what i need?
http://www.ebay.com/itm/like/121743226502?lpid=82&chn=ps&ul_noapp=true






Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 21, 2016, 11:09:53 PM
To run 600MHz stable, you're probably going to want at least 640mV, which will cost you more like 900W. Still a fair sight better than stock. The best you could feasibly do at 620 is about 550MHz for 3.7TH at 800W but maybe that's the setpoint you're talking about.

Pictures are up showing where to plug in the programmer.

There is no way to do this with an Avalon6, just like you can't do it on a 162-chip S7.

Yes, that looks like what you need. If you get one with a ribbon cable it'll make hooking it up to your miner boards easier.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 22, 2016, 11:52:19 PM
The post with the massive data table has been updated with even more data. It's okay, because right at the top I put a graph summarizing it all.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: aarons6 on June 23, 2016, 01:58:00 AM
wow looks sweet.. when i get my pickit 3 im going to be shooting for the 620mv @ 575 or highest to get the .2


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 23, 2016, 02:19:18 AM
Quote
5752587.51184.505310.2050.04125080.970.212
55024751184.305070.2050.00924671.000.206

620mV@575 burns an extra 24 watts for an effective 41GH increase for a margin of 0.59J/GH by those numbers, because you lose so much hashrate to errors and instability. Better off staying at 550MHz. My criteria for maximum stable hashrate (which I used to generate the graph) was less than or equal to 0.01% HW errors, because I noticed past that threshold the hashrate would suffer noticeably - averaging 98% or less of expected versus 100% +/- 1%. Now maybe your miner will handle it, worth testing, but from what I've seen so far I don't expect it to work that well.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: in2tactics on June 23, 2016, 12:02:27 PM
When it comes to modding your S7 or S7-LN with sidehack's voltage modification, there are quite a few PICkit 3 options available via eBay. The majority of those are PICkit 3 clones from China. It may just be me, but I prefer the real deal. Anyway, I just ordered a PICkit 3 In-Circuit Debugger and the PICkit 3 Programming Cable Kit (extension cable) from Microchip Technology Inc. for ~$50 shipped (overnight). It is the real deal, so that may be something to consider.

http://www.microchipdirect.com/

You can get 20% off the PICkit 3 In-Circuit Debugger using the code 2MILLSOLD.

PICkit 3 In-Circuit Debugger can be found under PG164130. $47.95 (before 20% off)

PICkit 3 Programming Cable Kit can be found under TPROG001. $4.00

Overnight shipping was the only shipping option, but it was only a tad under $7.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: RichBC on June 23, 2016, 03:21:35 PM
I hooked up a terminal emulator to a PIC on the Bench running the Bitmain code. Connected the Emulator TX to RA5 and RX to RA4.

On Power up the Pic sends 73 0F FF FF FF FF FF FF                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    
It then responds to inputs from the Terminal. As expected the key Bytes are AB B0 0E D4

AB & B0 introduce the value to be written which in this case is 0E (14 decimal) D4 is some sort of Check Byte which I have not worked out, although I am sure it is obvious. Here are the correct check Bytes for some of the values.

Value   Check   Response
00   D8   18
01   D5   15
02   C2   02
03   CF   0F
04   C9   09
05   C4   04
06   D3   13
07   DC   1E
08   DF   1F
09   D2   12
0A   C5   05
0B   C8   08
0C   CE   0E
0D   C3   03
0E   D4   14
0F   D9   19
10   D6   16
11   DB   1B
12   CC   0C
13   C1   01
14   C7   07
15   CA   0A
16   DD   1D
17   D0   10
18   D1   11
19   DC   1C
1A   CB   0B
1B   C6   06
1C   C0   00
1D   CD   0D
1E   DA   1A
1F   D7   17
20   C4   04
21   C9   09
22   DE   1E
23   D3   13
24   D5   15
25   D8   18
26   CF   0F
27   C2   02
28   C3   03
29   CE   0E
2A   D9   19
2B   D4   14
2C   D2   12
2D   DF   1F
2E   C8   08
2F   C5   05
30   CA   0A
31   C7   07
32   D7   10
33   DD   1D
34   DB   1B
35   D6   16
36   C1   01
37   CC   0C
38   CD   0D
39   C0   00
3A   D7   17
3B   DA   1A
3C   DC   1C
3D   D1   11
3E   C6   06
3F   CB   0B
40   C5   05
41   C8   08
42   DF   1F
43   D2   12
44   D4   14
45   D9   19
46   CE   0E
47   C3   03
48   C2   02
49   CF   0F
4A   D8   18
4B   D5   15
4C   D3   13
4D   DE   1E
4E   C9   09
4F   C4   04


The pic then responds with your 4 Bytes plus two additional Bytes, first Byte as in the table above followed by 33

I then tried hooking up the emulator to a live Miner and during the Boot Phase you can write values to the Pic which are then remembered. Except.... that with the latest Single fan firmware they are then overwritten with the value from cgminer. You cannot then rewrite values as the Com line is held by the BBB.

I have not tried but it is probably the case with other versions of firmware which do not seem to write a value, that your entered values would not be overwritten. Alternatively if you were to break the connection from the BBB to the RX on the Pic that would also solve the problem.

So bottom line is that there is a mechanism with a Terminal connected to write values directly to the Pic. Further work needed to come up with the best way to use it.


Rich






Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 23, 2016, 03:36:06 PM
I was thinking the other night, what about making a small board with two 18-pin jacks that would plug inline of the cable? Put a micro on that board which is tied to the TX line and listens for a pause in transfers from the 'Boner to the hashboard, and then injects the four-byte code for whatever voltage you want? It should be possible to set it up as adjustable, and even with dual hot- and cold-run settings with a delay inbetween.

When you say "the com line is held by the BBB" do you mean it's busy, or it's actively pulled high to resist any data getting pushed in from another source? Is the 4-byte volt code pushed out at 115200? Because if the PIC can listen that fast, and the TX line is togglable, all you should need is about 400uS in the clear to change the voltage.

For the check, might be worth looking at the crc5 function in driver-icarus.c since cmd_buf is in use for a 3-byte command to set voltage and 4th byte checksum generated with that function for I believe the AntMiner U3. May be completely unrelated, but it's worth looking at.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: RichBC on June 23, 2016, 03:48:06 PM
All work done without much checking so room for error... but once booted and when the BBB starts sending Data the TX line seems to be actively held high preventing the Terminal from writing.

Yes 115200, 8 Bit Data, no Parity, 1 Stop bit.

Did not spend much time looking for the check, just worked some of them out the hard way, but made quite easy by the response from the Pic.

Yes inserting something in the 18 Pin jacks path would work. or with some versions of the firmware and simple single point setting might just need a terminal & a PC?


Rich



Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 23, 2016, 04:08:00 PM
It'd be nice to make it adjustable without requiring modification or dismantling of the miner itself. Maybe not feasible, but it'd be nice.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: RichBC on June 23, 2016, 04:50:28 PM
Yes agreed absolute best would be something that left the Miner unchanged in both Hardware & Firmware terms and could be removed. So your plug in module in the 18 Pin leads would do the trick.

Rich


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: HagssFIN on June 25, 2016, 06:34:53 PM
This could be possible with the S9 as well?
Next to the PIC there is a one set of six pinholes.
https://i.imgur.com/XtgoBxg.jpg
----

Thanks for the instructions by the way, I might buy a Pickit 3 and do this hack to my 3-board Antminer S9 batch 9 which I'm planning to use with a 1000W Enermax.

I'm looking forward to try these settings which should give the 3-board miner ~4.218Th/s (calc) hash rate:
https://i.imgur.com/QXI3Btf.jpg
Of course the possible HW error rate has some effect on the actual hash rate and I'll have to see about that.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: RichBC on June 25, 2016, 08:24:00 PM
This could be possible with the S9 as well?
Next to the PIC there is a one set of six pinholes.

Yes 6 Holes next to Pic virtually guarantees an ICSP connection.

Rich


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: HagssFIN on June 25, 2016, 08:46:47 PM
This could be possible with the S9 as well?
Next to the PIC there is a one set of six pinholes.

Yes 6 Holes next to Pic virtually guarantees an ICSP connection.

Rich

Alrighty, that was what I was thinking as well.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 26, 2016, 05:42:14 AM
It is an ISP header. I pulled firmware off the PIC and had the chip identified within about half an hour of one coming in the building. But I was not allowed to make modifications, nor dismantle enough to take direct measurements, so I don't know hex/volt pairs or anything for it. I also can pretty much guarantee that my S7 hex files won't work on it.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: gt_addict on June 26, 2016, 05:21:04 PM
Come on everyone. Just four more people to buy one of sidehacks superb S7ln's so he can get another order in!!

p.s. Can you tell I'm a bit impatient for my one  ;D :D


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: RadekG on June 26, 2016, 08:56:23 PM
This could be possible with the S9 as well?
Next to the PIC there is a one set of six pinholes.

----

Thanks for the instructions by the way, I might buy a Pickit 3 and do this hack to my 3-board Antminer S9 batch 9 which I'm planning to use with a 1000W Enermax.


A did quick measurements of my S9B2:

Voltage across chain: 8.72V
Voltage comes up after while, so I guess Bitmain finally added some safety protections. I hope it can shut down voltage in case of overheat (not tested).
Voltage doesn't change in case of _STOP_ condition (unplugged fan).

Finally, based on different thread, we can 99% confirm voltage CAN BE adjusted by software:

https://enforum.bitmain.com/bbs/topics/3554

Bitmain has a new firmware with higher voltage (based on higher chip temps claimed by Bitmain). We should check first batch firmware for voltage change.



Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: IITravel01 on June 29, 2016, 12:13:19 AM
Sidehack,

My 2 S7-LN's just arrived thanks, turned one on and saw the original firmware installed (Mar 2016) is older than the one listed on BitMain's site (of May 2016).  Will there be any problem with updating the firmware to the newer one with your mod. or will that erase the mod. you did on it?


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 29, 2016, 12:29:03 AM
No, that just updates the controller software and shouldn't have any effect on what I did.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: IITravel01 on June 29, 2016, 12:53:56 AM
OK, here's something interesting I've found with the S7-LN.  Others can verify.  Since the exhaust of the Enermax 1000w Gold power supply is pointing forward I switched the fans of the S7-LN around so it also exhausts to the front.  The temp. sensor must me in the back because before I let it run for 15 minutes at 512.5M is settled between 47 and 48 degrees C and the fans ran at 2,880 rpm.  Now that they're facing the other direction the temp sensor is showing 40-43 degrees C and therefore the fans are only running at 2,400 rpm which is noticeably more quiet, which probably shaves a watt off the usage also.  If you want it quieter, I suggest you try it.  Does it lower the temp, probably not and it's probably the temp sensor at the rear so with the fans in the original position the hotter air is going over the sensor, with them reversed the temp. sensor is probably reading the cooler air.

Also switching the 1000w Gold Enermax to a 1000w Titanium EVGA is running about 11w lower at the wall.  From 508w to 497w.

Update:  The 1st S7-LN runs stable at 525M, anything higher starts throwing errors and losing ASICs.  At 525M with the EVGA 1000w Titanium it's pulling about 509w at the wall at about 2.4TH/s with the fan at 2,520rpm and the temp. showing 41-45 C with no HW error after 15 minutes.

Update 2:  The 2nd S7-LN runs stable at 512.5M, but it's running about 0.036 HW errors at that speed.  On the Enermax 1000w Gold power supply it was pulling about 501w at the wall at 512.5M, switching to a 850w Gold power supply it pulling 519 watts at the wall (461w after the power supply according to a display showing 90.7 efficiency), and the S7-LN is still showing about the same error rate so it's not the power supply.  Same temps and fan speed as the 1st with the fans turned around.  (Noticeably more quiet, might be more than just the slower fan speed, I think in the rear there's space between the fan the heatsinks, in the front the heatsinks are right behind the fan, this space may be causing the lower fan volume)  It's doing about 2,260 TH/s for the first half hour.  Update:  I dropped this one down to 506.25M and the HW errors are about 0.025 with it doing about 2.25 TH/s pulling 453w after the power supply.

So both pull about 1,030w-1,035w at the wall with 4.650 TH/s.  Not bad as this is about the same as four S5's that would pull about 2,400w or close to one 3 blade S7 pulling about 1,430w at the wall (if both could do 525M with 0.00% HW errors then it would match a full S7 but only pulling about 1,040w, that's 400w less or almost a 30% reduction in power used).

I ordered a SilverStone 800w Titanium power supply for the 2nd S7-LN ($170 from Newegg.com, I've ordered this power supply twice from Amazon.com and they shipped the 750w Platinum version so I think they may have the UPC code mixed up in their system) so it should drop the wattage down around 10w less.

As for manually setting the fan speed.  If you do that, will the fan speed increase when the ambient room temperature goes up?  With the auto mode, it does.  For example when I did the initial settings the fans ran at 2,520 but now the room has gone up to 90 F and the fans have increased to 2,640 rpm.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 29, 2016, 01:07:19 AM
There's also an option to manually set the fans to whatever speed you want.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: in2tactics on June 29, 2016, 02:29:20 AM
There's also an option to manually set the fans to whatever speed you want.

True, I generally just lower the fan speed until I notice an increase in temp. Trial and error, it works most of the time. :P


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: philipma1957 on June 29, 2016, 02:45:05 AM
There's also an option to manually set the fans to whatever speed you want.

have you received  second batch from dhl?


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 29, 2016, 03:01:16 AM
Yeah, customs hangups. I got it squared away this morning but, even if it had been in time to make the truck, I wouldn't have been at the shop to receive them. Units should be in my hands tomorrow morning and going out Thursday afternoon. Sorry about the delays.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: philipma1957 on June 29, 2016, 04:05:00 PM
Yeah, customs hangups. I got it squared away this morning but, even if it had been in time to make the truck, I wouldn't have been at the shop to receive them. Units should be in my hands tomorrow morning and going out Thursday afternoon. Sorry about the delays.

happens at least they are near ready to ship out.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on June 29, 2016, 05:06:10 PM
Yeah, but the last tracking update is still "shipment on hold" from yesterday morning and the local route usually would have the boxes dropped off at least an hour ago. Looks like the ball is dropped again.

UPDATE - apparently word that fees were paid yesterday at 8AM didn't get to the depot until this morning at 10AM after the truck was already out. So, packages will be delivered tomorrow and miners will go back out Friday.

Sometime in the next couple weeks I think I'm gonna work on a snap-in hardware solution to changing voltages. I don't know enough about the software on the S7 controller to have an idea how to write a program tapping into the TX lines, but I'm confident I can do it externally. Could be interesting.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: HagssFIN on July 10, 2016, 10:43:05 PM
I got a Pickit 3 from Ebay and did a little tweaking to use a Enermax Revolution 87+ 1000W PSU (from my old S2) with Antminer S7, B9.

Here are the results:
Antminer S7
Hash rate: 4.390Th/s (40min avg)
Voltage setting: 640/670mV  
Frequency: 650 Mhz

Power supply: Enermax Revolution 87+ 1000W
Voltage: 227 VAC
Current: 4,9 A
Power (at wall): 1112,3 W
Power (from the 12VDC, approximately, with 0.87 efficiency): 967,701 W

Meter: HT Instruments HT7011, used for both voltage and current measuring
https://i.imgur.com/t1BvS4p.jpg


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: IITravel01 on July 11, 2016, 04:42:10 AM
What's the original default hot starting voltage/cold running voltage for the blades on the S7 (not the S7-LN)?


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: citronick on July 14, 2016, 04:26:43 AM
@sidehack

I have an existing S7-LN, can I apply your mod to get the lowered wattage?

Is it a firmware mod?

If HW mod, then I will out of luck with getting this S7-LN down to lower power consumption.

Thanks


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on July 14, 2016, 04:36:34 AM
This thread contains all the answers to those questions.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: aarons6 on July 14, 2016, 04:41:27 AM
@sidehack

I have an existing S7-LN, can I apply your mod to get the lowered wattage?

Is it a firmware mod?

If HW mod, then I will out of luck with getting this S7-LN down to lower power consumption.

Thanks

most of the how-to info is on this post.
https://bitcointalk.org/index.php?topic=1504228.msg15298837#msg15298837


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: percy_tc on July 14, 2016, 08:44:20 PM
would be great to have a video about the process.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: BryanC on July 15, 2016, 01:50:00 PM
Sidehack -
You are a gentleman and a scholar. Applied your firmware to my S7-LN, with these results:

Before:
~2700 GH/S
Temp: 48-49
Fans: ~2800
Watts: 724


After:
~2050 GH/S
Temp: 42-44
Fans: 2280
Watts: 430

Watts measured with a belkin in-line meter.

That is brilliant. Daily power cost drops from $1.91 to $1.14 and overall profitability more than doubles.
[edit]Check your tip jar![/edit]


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: BryanC on July 15, 2016, 03:46:37 PM
So, additional question: Intermittently, Chain 1 has shown up with all xxxxx, or with 1 chip x'd. Disconnecting the ribbon cable was a real mother*ucker - could damage to the control cable account for that? Again, it's intermittent. Power cycling will result in one of those error states, or a non-error state. It seems that if I power down and "fiddle" with the cable, it comes back up in the non-error state.

So, that's a point for the DIYers on the S7-LN - it would be better to remove the power supply and have plenty of room to work the control cable off while supporting the socket to ensure you don't damage the cable or the socket.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: BryanC on July 15, 2016, 10:19:48 PM
... And now it's gone totally wonky, with one board showing 33 chips and the other showing 43. Looks like I have some more work to do!


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: alh on July 15, 2016, 10:49:39 PM
... And now it's gone totally wonky, with one board showing 33 chips and the other showing 43. Looks like I have some more work to do!

Can you revert to the original Bitmain setup? I'd try back there to see if it's related to your changes, or something else.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: BryanC on July 16, 2016, 12:29:31 AM
Yes - I dumped the existing firmware before writing the new one. Will give that a shot tonight.

... And now it's gone totally wonky, with one board showing 33 chips and the other showing 43. Looks like I have some more work to do!

Can you revert to the original Bitmain setup? I'd try back there to see if it's related to your changes, or something else.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: BryanC on July 16, 2016, 05:29:30 AM
Ohhhhkay.
Reverted to the original firmware, and everything behaved normally.
Programmed to 650/620, and the strange behaviour returned (showing less than 45 chips per chain - not showing xxx's, but just showing fewer ooo's)
Programmed to 660/630 @ 550m, and it was wonky for the first power cycle (hundreds of HW errors), but after another power cycle it's running with zero errors (one error after another 10 minutes), about 2500 GH/s drawing 560 watts.

I guess that, for whatever reason, these boards won't tolerate the 650/620.

(I would post screenshots, but I'm assuming I don't have that feature until I'm out of "Newbie" status)


... And now it's gone totally wonky, with one board showing 33 chips and the other showing 43. Looks like I have some more work to do!

Can you revert to the original Bitmain setup? I'd try back there to see if it's related to your changes, or something else.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on July 16, 2016, 05:35:00 AM
I know 610 and 600 are specifically labeled "unstable" in the chart, but it's also noted in places that 620 isn't always reliable either. A lot of the group-buy miners weren't stable until 630 or 640. I did each of those on a per-board basis. I've got an S7 right now that has been dropping one board at like 670 for 550MHz so it really depends on the hardware. If a board runs unstable or drops out, the voltage is too low.

Know that the S7LN restarts cgminer. It runs for about a minute to warm up the chips (during which time you'll see hundreds of errors) and after that it should kill and restart clean. The firmware shifts to cold running about 30 seconds into the restarted process. At least that's how it should work - sometimes cgminer doesn't restart and you're left with the jillion errors.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: BryanC on July 16, 2016, 05:47:53 AM
Thanks for the additional info... It looks like 630 might not be the ticket either. I've got one board only showing 44 chips, and a half dozen HW errors.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on July 16, 2016, 06:04:41 AM
I'd watch for a HW percentage below 0.01 - that's when I started noticing the effective hashrate dropping out. Make sure to keep fans low too; these boards really like to be kept above about 45C to run stable and at low powers it takes almost no fan to do that, especially with the oversized heatsinks in the LN.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: IITravel01 on July 16, 2016, 09:02:47 PM
Decided to try and see if I can do this myself.  Ordered a Pickit 3 and have a S7 that's not doing anything right now.  

Goal:
To try to get the 3 blades running at the same speed one of my S7-LN with sidehack's mod. is running which is 660/630 mV I believe (I'd initially set the modded S7 at the sweetspot of 550M=806w and increase speed until HW errors start showing up, or at 670/640 mV running at 587.5M=900w).  With the 2 blades/boards on the modded S7-LN it's running at 562.5M at 0.0001% HW errors.  This brings about 2,531 GH/s consuming about 550w, so with 3 blades that would bring about 3,8 TH/s consuming about 825w (of course 575M at 3.88 TH/s and 843w with near 0.00% HW errors would be even better goal at 630 mV).  That connected to a EVGA SuperNOVA 1000w P2 ($180) should be a pretty efficient setup for a S7 without the need to purchase any more splitters or adapters as there is 10 PCIe connectors with the power supply (oddly the T2 model doesn't come with the same cable set).  (If money isn't an objection, Thermaltake has a unique 1,250w power supply for $350 that can monitor the electrical usage via a celphone app. that might be interesting to some miners out there.  You'll have to get 2 of these adapters https://www.amazon.com/Express-adapter-inches-sleeved-Angeles/dp/B005H3KH9E/ref=sr_1_1?ie=UTF8&qid=1468701899&sr=8-1&keywords=EPS+to+PCIe as well as figure out how to convert 4 of the PCIe 8-pin connectors to 6-pin connectors.)

I bet this would become a pretty popular hack to the S7's (batches with 135 ASIC) if it's easy to do and obviously these hacked models would sell for more after you're done with the S7.  Anyone know what a S7 pulls from the wall at 562.5M unmodded?  Edit:  Pulled out my Kill-A-Watt.  It's about 1,175w at the wall connected to a Corsair 1,500w Titanium.  So that means about 350w reduction, that's about 29.8% I think (default on the S7 is 690 mV or 700 mV I believe, that's how they get 1,293w=4.72 TH/s at 700M?).  Who would't rather have a S7 that uses about 30% less electricity at the same speed, even if it did only 3.8 TH/s, unless you've got free electricity?  If BitMain sold the power supply bracket separately, I bet you could sell a S7-LW (Low Wattage) version with the EVGA 1000w P2 together as a set.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on July 16, 2016, 09:11:54 PM
I've got a few I'll be doing similar work to, with intent to resell. I should probably be doing that today but it's Saturday and I want to sit on my couch instead. Probably start on it tomorrow.

At 825W you can get away with 2 cables per board (assuming they're not garbage cables), so a less-well-outfitted PSU can still do the job.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: Gahs on July 20, 2016, 03:47:07 PM
If this S7 improvement venture is successful, are you going to have an equipment that will perform almost as good as a S9? Because that will mean not having to buy a S9 in long run.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on July 20, 2016, 03:57:13 PM
No, it's really not possible to get the S7 reliably below 0.2J/GH which is still twice the power of the S9. Check the chart on page 4.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: NotFuzzyWarm on July 20, 2016, 11:43:20 PM
Arrg...
Got the PICkit3 programmer,, dl'd the latest software for it http://pic-microcontroller.com/download-mplab-ide/ All well there, installed to Win7just fine. Problem is with "You'll want to set the IPE "Device" drop-down to PIC12F1572".

Guess what device is not in the drop down list? Closest match the sw will let me do is PIC12F1501 and that throws a mismatched device ID# error when trying to connect.... Possibly that device was removed in a recent 'update"?

Ideas on getting maybe an older device lib for the programmer to use?

Also details: you mentioned disconnecting the 18pin cables to control board.
Done that.
Using the PICkit to power the device with 3.375v.
So, do the hash boards need their normal +12v power to them or is the MCU for each strictly powered from the programmer?

EDIT: Looking at microchips site for the PIC12F1572, http://www.microchip.com/wwwproducts/en/PIC12F1572 its data sheet starts with:
"PIC12(L)F157X microcontrollers combine the capabilities of 16-bit PWMs with Analog to suit a variety of applications"

I'll try that tomorrow as I recall seeing the LF version listed... Really wanna get my my 22 online s7's knocked down in power. Looking to run using 625MHz vs default 700 for clock as that produces 4.1THs vs 4.7THs, should be a good target for when I can get the Vcore reduced ;)


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on July 21, 2016, 01:28:58 AM
You could probably get 625MHz at around 660mV, which would be a decent reduction from stock power use. The two I worked up today look to be pretty good; one of them is hitting 550MHz at 630mV with almost zero errors. I couldn't quite keep boards from dropping out at 575.

The MCU is programmed only from the 3.3V line from the controller. No power needs be connected to the hashboards or anything else for programming to work right, but disconnecting the 18-pin will prevent voltage from flowing back from the hashboard into the controller which overcurrents the PICKit.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: VonSpass on July 21, 2016, 01:37:10 AM
Interesting; I have not been following the BTC mining tweaks lately - good old Bitmain always performs beyond advertised numbers!


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on July 21, 2016, 11:17:20 PM
Not sure if anyone's interested, but I'm having good luck working up S7s to run 4TH under 1000W off a DPS1200 PSU so I've got some available in the sales board. I'm working on a deal with a guy who is retiring a mine, so I should probably have more of these in the future.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: NotFuzzyWarm on July 22, 2016, 01:58:49 PM
Found my problem (no PIC12F1572 device listed): Microchip has at least 2 different programming solutions and the first one I found is version 8.08, the programming software you need is v3.35 found here http://www.microchip.com/mplab/mplab-x-ide

Starting to play with me s7's and as rather expected looks like each board can need different Vcore settings. On my 1st one modded, a batch 16 1-fan, I can run board-1 @ 630mv all the way up to at least 600MHz. For boards 2 & 3 I had to use 650mv. Power dropped from 1,330w down to 995-1,010w and that is with a 120-220v step-up xmfr between my UPS and the PSU.
Most excellent.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: IITravel01 on July 22, 2016, 03:29:49 PM
Found my problem (no PIC12F1572 device listed): Microchip has at least 2 different programming solutions and the first one I found is version 8.08, the programming software you need is v3.35 found here http://www.microchip.com/mplab/mplab-x-ide

Starting to play with me s7's and as rather expected looks like each board can need different Vcore settings. On my 1st one modded, a batch 16 1-fan, I can run board-1 @ 630mv all the way up to at least 600MHz. For boards 2 & 3 I had to use 650mv. Power dropped from 1,330w down to 995-1,010w and that is with a 120-220v step-up xmfr between my UPS and the PSU.
Most excellent.

Thanks for the update.  I ordered my Pickit 3 through amazon and didn't realize it would be shipped from Hong Kong, so it's taking longer than expected.  You answered one of my questions in your post, do different boards need different voltages and can they work at different voltages in the same S7.  What kind of HW errors are you getting?  I'm wondering if different boards need different voltages, then the sweet spot for one board (like 630 mV is 550M) won't be the same as the other (like 650 mV is 600-625M), but this might cause one board to start getting errors (like the 630 mV might not do so well at 600M).  There's no way to set the speed for different boards in the same S7, is there?


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: NotFuzzyWarm on July 22, 2016, 03:50:19 PM
Running different voltages for the boards in the s7 is fine. What I was seeing during tests is that when voltage was to low a board would be stable for maybe 5-10 min and then dropped out. Once the voltage is where the chips on a board are happy then the s7 performs as normal. Once I got the boards dialed in the overnight HW errors for this s7 was 0.005%.

No you cannot use different speeds between the boards in a s7.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: philipma1957 on July 22, 2016, 11:58:49 PM
If this S7 improvement venture is successful, are you going to have an equipment that will perform almost as good as a S9? Because that will mean not having to buy a S9 in long run.

No but a quiet 950 watt machine getting .22 watts still has some value.

My buddies office  can use 1 s-7 and 1 s-7ln this winter  with power at 2.4 cents.

Right now I run 1 s-7ln  and I may grab a modded s-7 from sidehack in early sept.

they would run from sept to may using only 2.4 cent power.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: IITravel01 on July 26, 2016, 06:59:54 PM
http://gekkoscience.com/img_stash/S7LN/S7LN_HEX.zip (http://gekkoscience.com/img_stash/S7LN/S7LN_HEX.zip)

The above link is a ZIP archive containing some 17 hex files. The one called "S7LN_PIC_FIRMWARE.hex" is the original unmodified firmware found on the hashboards in my S7LN.

The remaining files are called "S7LN_userselect.X.production.AAA-BBB.hex" where AAA represents the cold running voltage and BBB is the hot running, in millivolts average per node.

I have cold-running files from 580mV to 690mV, where the hot is 30mV higher. I also have three files that set both hot and cold to the same for 700, 710 and 720mV - at those points, a clock rate that would require a higher voltage to start would also draw enough power to smoke out the whole board. Pretty sure anyways. I've tested up to 775MHz and 1020W wall (stock setting was 680W on my unit) without finding an unstable clock on even 710mV and I don't want to catch my boards on fire.

Anyway. If you want to make use of this, find yourself a PIC programer (I use a PICKit 3 that I've had since about 2013) and grab the MPLAB IDE software. What you'll actually need is the IPE side (Programming, rather that Development) but I'm not sure it's possible to download just the IPE without getting the whole thing.

If you remove the outlet fan from the unit, at the end of the boards you will see eight pinholes - one pair, and one set of six. The six are the ISP header into which you'd plug your PICKit.
http://gekkoscience.com/img_stash/S7LN/these_holes.JPG

The lowermost hole of the six corresponds to the header-socket hole on the PICKit that has been flagged (on mine there's a while triangle pointing to it).
http://gekkoscience.com/img_stash/S7LN/pickit3_attached.JPG

You'll want to set the IPE "Device" drop-down to PIC12F1572. Under the "Settings" select Advanced Mode, and once in there click Power, set VDD to 3.3V and check "Power Target Circuit from Tool". For that to work right you're going to want to unplug the 18-pin cable from the board before you program it.

Once that's all configured, plug your PICKit into the board (you might need some wires or pins to connect the header socket of the programmer to the holes on the board) and click "Connect". If you did everything right, there ought not be any errors. Might get a box pop up saying something about low-volt programming and voltage mismatches or some such; just click "OK" and carry on. As far as I can tell it doesn't matter for this application.
You should be able to read existing code off the chip, which you can see in Memory View (View -> Show Memory). If you would like, click "Read" to pull all the existing firmware off and File->Export->Hex to save a backup copy just in case.

Click the "Browse" button associated with the Source path, and navigate to the new hex file of your choosing. Once that's loaded, click "Program" to push the new program to the board.

Make sure you plug the 18-pin cable back in before trying to mine again.

The program will turn on your board to the hot-start voltage value upon power-up of the controller board. The S7's software, once the OS is booted, will run cgminer for about a minute to get things warmed up and then restarts it fresh. My board firmware will start the cold running voltage about 35 seconds into the second cgminer run. If you're watching on a kill-a-watt, the power consumption should drop about 10% or so when it kicks over to cold-running.

When you write "...If you would like, click "Read" to pull all the existing firmware off and File->..."  Do you mean click "Read Device ID" in the "View" upper menu bar?

Do we need to program each board individually (3 of them in the S7) or is one enough (as in are we programming the controller board on top via the board or programming each board)?  I ask this as I'm examining my S7 and notice that of the 3 boards, the header has a few of the holes soldered closed (one has all holes closed and the other has 3 of the 6 closed) on 2 of the 3 boards.  Nevermind, I realize that that doesn't make sense if we have to disconnect the 18 wire cable.  Why would the holes be soldered closed?


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: RichBC on July 26, 2016, 07:55:23 PM
When you write "...If you would like, click "Read" to pull all the existing firmware off and File->..."  Do you mean click "Read Device ID" in the "View" upper menu bar?

Do we need to program each board individually (3 of them in the S7) or is one enough (as in are we programming the controller board on top via the board or programming each board)?  I ask this as I'm examining my S7 and notice that of the 3 boards, the header has a few of the holes soldered closed (one has all holes closed and the other has 3 of the 6 closed) on 2 of the 3 boards.  Nevermind, I realize that that doesn't make sense if we have to disconnect the 18 wire cable.  Why would the holes be soldered closed?

Read means the Read button in the centre of the screen that will read the contents of the Pic on the hash board. This can then be saved using File & Export.

Each of the 2 /3 Boards has to be done individually as there is a Pic on each board. If the holes are soldered closed it means that Bitmain has not properly masked them during the flow solder process. Perhaps if these were early boards they did not program the Pic after assembly?


Rich


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: NotFuzzyWarm on July 26, 2016, 07:55:41 PM
re: holes soldered closed
So far I've ran into that on 3 boards in different miners. Does not follow batches, it just seems random. I first saw that on a b6 and last saw it on a b18. No idea why Bitmain did that.

What I did was just leave those boards as stock. I suppose one could use a solder-sucker to clear the holes...

No we are not programming the BB controller -- we are programming just the MCU on each board.
Yes EACH board has to be programmed but they do not have to use the same settings. eg. a miner can have 2 boards set to 650/680mv and another can remain as stock (holes plugged) or it can be at a different voltage setting that keeps it happy.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on July 26, 2016, 07:59:11 PM
I've also seen it on a few boards; I cleared the holes and programmed them as usual. Most of the miners I've sent out didn't have the same voltage across each board; they were all tested individually for coldest stability at a given frequency and then tested as a whole. It'd be the same concept as running several Compacs off the same hub but each one set to a different core voltage, whatever that stick needed to work best.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: IITravel01 on July 26, 2016, 08:27:35 PM
When you write "...If you would like, click "Read" to pull all the existing firmware off and File->..."  Do you mean click "Read Device ID" in the "View" upper menu bar?

Do we need to program each board individually (3 of them in the S7) or is one enough (as in are we programming the controller board on top via the board or programming each board)?  I ask this as I'm examining my S7 and notice that of the 3 boards, the header has a few of the holes soldered closed (one has all holes closed and the other has 3 of the 6 closed) on 2 of the 3 boards.  Nevermind, I realize that that doesn't make sense if we have to disconnect the 18 wire cable.  Why would the holes be soldered closed?

Read means the Read button in the centre of the screen that will read the contents of the Pic on the hash board. This can then be saved using File & Export.

Each of the 2 /3 Boards has to be done individually as there is a Pic on each board. If the holes are soldered closed it means that Bitmain has not properly masked them during the flow solder process. Perhaps if these were early boards they did not program the Pic after assembly?


Rich

Thanks, I missed that middle "Read" button there on the "Operate" page.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: aarons6 on July 26, 2016, 09:59:09 PM
i picked up one of these modded s7s from sidehack..
with the stock fans i was having trouble keeping it running at night.. even lowering the fans to 20% was not enough to keep the boards warm enough.. once they got to 40c or so they will shut off.

we are having pretty good weather here, but it still cools off at night.. upper 50s at night and 80s during the day.


i put on a pair of AFB1212-SHE fans i got for my s5s.
https://www.amazon.com/Delta-Electronics-AFB1212SHE-120x120x38mm-connector/dp/B004Y1HLA8

these fans do have a bit more of a whine to them than the stock fans.. but the air flow is slower and the s7 doesnt whistle, over all i think they are more quiet. like a s5.

running them at AUTO they seem to be running pretty good at 600 speed. right at 4000 ghs and using 1023 at the wall. my unmodded s7 at 600 speed uses 1280 watts.
they speed up to about 3400 rpm during the day and slow down to around 3100 at night. they max out at 3600 so there is still room for when it gets hotter.
the temps are holding right at 55-64c.



i think you can flash the 1-fan rom on it and just use one stock fan.. not sure tho.. i didnt try. i might try it on my other s7 when i get the pickit3 i ordered from china.


overall the mod is well worth it.. you dont lose much speed (actually i was running my s7 at 600 already) and you lose almost 300 watts. you do have to do something with the fans tho, the boards need to be above 50c to stay stable.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: IITravel01 on July 26, 2016, 10:49:09 PM
It appears that I was able to program the 1 board without the soldered holes, but only after I increased the voltage from the programmer from the VDD: 3.3 v to 3.55 v.  Now to test it.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: RichBC on July 27, 2016, 05:22:30 AM

i think you can flash the 1-fan rom on it and just use one stock fan.. not sure tho.. i didnt try. i might try it on my other s7 when i get the pickit3 i ordered from china.


I have tried the 1 Fan Rom and it runs fine with a single fan.


Rich



Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: HagssFIN on July 28, 2016, 06:52:31 PM
The hacked S7-LN from the group buy is working nicely, thanks again Sidehack and Phil!  :)

I have now some measurements for you Phil.
The PSU I'm using is Super Flower Golden Green SF-500P14XE 500W.
The meter used for both voltage and current, with my test setup is HT Instruments HT7011 clamp meter.
Voltage is approx. 222 VAC
Current is approx. 2.0 A
So the power at the wall is approx. 444 W

Not bad.  8)

It is almost the same as you measured Phil (442W).


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: IITravel01 on July 31, 2016, 09:07:17 PM
I wanted to update my results on my modded S7.  So a little disappointed that my 3 boards each needed a different mV setting to run stable.  One at 630, one at 640 and one at 650 mV.  But they seem to work out now OK.  I was able to program the boards even though they had soldered holes by firmly pushing the pins to the soldered holes and after a while was able to get them to program (3.55 V worked for me).  Here's the results.  With 5 additional case fans and a fan controller and a ASUS wireless AP the S7 running at 562.5M was pulling about 919 watts on an EVGA 1600w T2 Titanium (so that would be closer to 900w without the additional equipment).  Stock runs about 1,175w at 562.5M, so that's about 270w less (-23%).  At 562.5M it pulls about 3.9 TH/s with 0.003-0.006% HW errors.  The fans running at 33% manual = 48 on two outer boards and 56 on the middle board temps. (C).  So it would have been nice if all the boards would have been stable at the same mV setting, it still came out pretty well.  Well worth the price of the PickIt 3 programmer and the effort put into it.  Thanks Sidehack.
 


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on July 31, 2016, 09:46:38 PM
Maybe half the S7LN and pretty much none of the S7 that I've worked up have had the same minimum stable voltage for any given frequency. Since each board has so many chips on it, in series, probably randomly scattered with regard to per-chip performance, there are too many variables to expect uniform performance at the edge cases.

Good results though. 900W for 3.9TH is pretty solid.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: aarons6 on August 05, 2016, 11:29:15 PM
i got my pickit3 today and i modded my other s7..
so far i have it running at 550 with 660 on all 3 boards. im at 956w @ 3700 ghs..
im using the s5 fan as intake and a afb1212she has exhaust.


looking at the back does anyone know how the boards are numbered??

1-2-3 or 3-2-1?

i can run them at 650 but board number 1 drops out after awhile and goes to 30c. it did turn back on after about 5 minutes..

at 640 i start to get x's all over.

edit..

these things love the heat.. i lowered the fans down to 60% and the temps are now upper 50s to mid 60s.. sucks on automatic they are pretty much full speed.. :(
my watt usage went down to 848-850, my speed is right at 3700.. errors are 0003-0005%

that puts me at .23j/ghs

i still think i can drop a couple boards down to 650.. maybe ill try that tomorrow.. not sure how much more watt savings tho 10mv would be..


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: bitgameSolo on August 09, 2016, 03:40:59 PM
Really appreciate this thread thanks! There seem to be different versions sellers of the pickit3. As a noob is there a standard I should order? expect to pay about $65? Also this thread suggest this mod will only work with the 135 chip BM miner. I will try the s7, but if I'm going after an S5 mod I should look elsewhere?


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on August 09, 2016, 03:43:01 PM
For reasons which have probably been explained extensively, it only works with 135-chip S7 and not 162-chip S7 because you're adjusting the output voltage of the main regulator on the board and with 162-chip miners there is no main regulator to adjust. The same applies to the S5.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: aarons6 on August 09, 2016, 09:57:04 PM
Really appreciate this thread thanks! There seem to be different versions sellers of the pickit3. As a noob is there a standard I should order? expect to pay about $65? Also this thread suggest this mod will only work with the 135 chip BM miner. I will try the s7, but if I'm going after an S5 mod I should look elsewhere?

i got this one
http://www.aliexpress.com/item/PICKIT3-Programmer-PIC-ICD2-PICKit-2-PICKIT-3-Programming-Adapter-Universal-Programmer-Seat-FZ0508-Free-Shipping/1967812035.html?spm=2114.13010608.0.54.j30t2e

it took a few days to get here to usa.. about 10.. but it worked..

keep in mind the pool makes a huge difference on the power on the s7..
while i can run kanos pool with 640s on all boards.. i cant solo mine or mine peercoin without bumping mine up to 680 :(


i dunno why..


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: NotFuzzyWarm on August 09, 2016, 11:48:03 PM
Possibly related to most pools limiting the share rate each miner gets? Done to smooth out the pool servers data loading and keep it reasonably fair for the wide range of miner speeds folks are using. I *think* most try and keep it around 8 shares/sec by adjusting the ShareDiff higher/lower as needed to average that share rate, no? That in turn limits how much 'work' the miner is doing at any given time.

When Solo mining I'd hope the only throttle is the miner vs pool access fairness...


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on August 10, 2016, 01:18:16 AM
I could see it being an issue from mining starting and stopping instead of being fed continuous work, if the boards cool down and drop out before mining kicks back up. That shouldn't be affected by share diff but by availability of work.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: salsa321 on August 10, 2016, 01:22:37 AM
Awesome thread :) keep posted thread loke this


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: NotFuzzyWarm on August 10, 2016, 01:49:17 AM
Along these lines, just how much does ShareDiff affect actual 'work' (power used) load? If the dif is not too hard and share rate is too low do the ASIC's spend time idling and just twiddling their thumbs so to speak?

I know that Antpool samples throughput every 1/2hr and as a result ShareDiff bounces up and down pretty wildly whereas on Kano it changes every minute or so. On Antpool the diff would often go up down 25% or more and stay there for the 1/2hr, Kano, just a few % each change. Naturally, more samples in a shorter time translates to better and more accurate averaging response time...


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on August 10, 2016, 02:06:26 AM
Share diff only affects what shares are sent to the pool and has no effect on the work being done. The chips idle when work is not sent from the server and cgminer has nothing to feed them with. Bitmain chips (at least up through BM1384) return all shares diff 1 and higher and cgminer filters out the results based on what the pool is asking for.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: aarons6 on August 10, 2016, 03:01:30 AM
I could see it being an issue from mining starting and stopping instead of being fed continuous work, if the boards cool down and drop out before mining kicks back up. That shouldn't be affected by share diff but by availability of work.

it could be this..

i know some pools, like zpool the temps on the board drop down about 5c.. i think its because the pool switches coins very often.



if they go under around 53c they drop out and cgminer needs to be restarted to turn back on..

i made a sh script to check for that.. sucks you have to run it every time you reboot the miner, but it runs until you shut it down.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: in2tactics on August 10, 2016, 04:17:45 AM
Really appreciate this thread thanks! There seem to be different versions sellers of the pickit3. As a noob is there a standard I should order? expect to pay about $65? Also this thread suggest this mod will only work with the 135 chip BM miner. I will try the s7, but if I'm going after an S5 mod I should look elsewhere?

I posted my recommendation for getting the PICkit3 direct from the manufacturer Microchip Technology Inc. here: https://bitcointalk.org/index.php?topic=1504228.msg15332015#msg15332015

The pricing is not bad considering you know it is not a gray market item. The company only offers overnight shipping to the United States and it costs about $7. I think my total cost for the PICkit3, extension cable, and overnight shipping was ~$50.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: fvineyard on August 10, 2016, 04:35:27 AM
If you happen to have an edu email address you can also get a 25% student / academic discount from microchipDIRECT. My order was just under $48 shipped for the PICkit 3 + the Programming Cable Kit.

You can find it cheaper but shipping was fast and that price works for me.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: in2tactics on August 10, 2016, 05:37:08 AM
If you happen to have an edu email address you can also get a 25% student / academic discount from microchipDIRECT. My order was just under $48 shipped for the PICkit 3 + the Programming Cable Kit.

You can find it cheaper but shipping was fast and that price works for me.

Wow, I wish I had known that when I ordered. I guess I should not complain about a 5% difference.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: RichBC on August 10, 2016, 09:00:32 AM
If you happen to have an edu email address you can also get a 25% student / academic discount from microchipDIRECT. My order was just under $48 shipped for the PICkit 3 + the Programming Cable Kit.

You can find it cheaper but shipping was fast and that price works for me.

Wow, I wish I had known that when I ordered. I guess I should not complain about a 5% difference.

I have over the Years bought several PicKit 2 & 3, all clones from China and not had a single problem. If you can put up with the delivery time then you can pick up a Pickit3 for $12 including shipping.


Rich



Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: in2tactics on August 10, 2016, 10:51:45 AM
I have over the Years bought several PicKit 2 & 3, all clones from China and not had a single problem. If you can put up with the delivery time then you can pick up a Pickit3 for $12 including shipping.


Rich

I do not like to support the gray market. That is my personal opinion. The choice is totally up to you.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: bbOOmm on August 11, 2016, 07:36:45 PM
I have been loosely following this topic and thought of this...

All this work, hacking, specific hardware, coding etc .... wouldn't it be easier to literally bypass the whole regulator circuit and supply the chains with a dialed down voltage directly from the power supply? I've been able to get DPS-1200FB power supplies to operate in the 10.5VDC to 11VDC area. There has to be some large solder traces that once the green epoxy is cleaned off, can become a solder point for injecting voltage -after- the regulator circuit.

I did something similar when the connectors for the Avalon miners -- way back when --- roasted the connectors and burnt the boards - I soldered directly to the boards to get them mining again.

Just an idea, I have not looked at the S7 boards to see if it actually can be done space/location wise - the only times I have looked at them were to clean and verify nothing is getting cooked. But with the S7's becoming un-profitable in WI because of electrical rates, I just might take one out of production and play with it.

Unless I find a hashboard or a whole S7 I can play with...



Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on August 11, 2016, 07:51:03 PM
10.5V is somewhere between stock and overvolt for the 135-chip miner. Not helpful at all.

I'm not sure I'd describe plugging a ribbon cable into 6 pinholes and clicking "flash" as more difficult than pulling boards and scraping mask and soldering into heavy copper planes.

The good thing about a firmware hack is it frontweights all the work. You spend a day figuring it all out, and then you only need five minutes per machine to make the change instead of spending half a day figuring it all out and then an hour per machine making the change.

Undervolting from the PSU would work on 54-chip boards that don't have a built-in regulator.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: bbOOmm on August 11, 2016, 09:06:41 PM
As I said, I was loosely following this topic - not reading every little tidbit (think speed reading) ... so my understanding of what you are trying to achieve is probably a wee off. It just seemed like a lot of reverse engineering and experimenting to come to the result of having control over the voltage regulator, not to mention the purchase of an interface to get that access.. hence my comment of bypassing the regulator altogether. I'm sorry if that was of any offense or sounding abit ...derrrr

So its simply undervolting the chip chains to obtain a more efficient Hash/watt ratio? No cgminer tweaks? No bitmain controller tweaks?, just the PIC tweak to undervolt.

If anyone gets bored ... could you make a posting with the step by step how to - minus the theory, whys and results for each step. That page 4 posting is very informative, then reading around the whole topic to gather other tidbits;  for some people, that may seem a little too much info and become discouraged to even try because it seems too complicated and technical. I can understand it, but putting myself in someone else's shoes, some of the screwdriver and duct tape wizards out there just may have a hard time grasping the concept, let alone have the patience to read all the details.

you know, a simple summary,

1) plug in miner
2) plug in PICkit
3) download file xyz
4) press flash
5) reboot

Kind of instructions post for the modifications. Maybe stickied to the first page....



Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on August 11, 2016, 09:29:02 PM
Well, it's a lot of work for one person to do the reverse-engineering. That's why I posted everything including the new code, so you don't have to "reinvent the wheel". I also already had a PIC programmer.

Yes, the entire point is to make the regulator adjustable. I am of the opinion that a fixed-volt regulated string is the worst overall topology. It does still have an efficiency gain over low-volt VRMs but none of the modularity and it's less efficient than an unregulated string so what's the point anyways, just an excuse for the manufacturer to reduce chip counts and save money.
However, an adjustable regulated string is, my opinion, the overall best topology. It's the most efficient and cheapest means of still having adjustable core voltages, which being able to lower core voltages over time can substantially extend the viable life of a miner. Amazing how you can take a thing from "those greedy bastards" to "wow this is actually pretty nice" with just the one little change.

And if someone else wants to make a simple and boring step-by-step with none of the reason why you're doing what you're doing or why it's actually a good idea, go for it. People stopped asking me for help with their homework ages ago because they figured out I'd actually help them learn how to do their own homework instead of do it for 'em. Course I'm also the guy who is disappointed by people who drive cars and don't understand their basic concepts.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: in2tactics on August 12, 2016, 03:35:31 AM
..... Course I'm also the guy who is disappointed by people who drive cars and don't understand their basic concepts.

That last bit made me chuckle.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: bbOOmm on September 01, 2016, 04:30:06 PM
Has anyone tried this with the regular ol S7 - the later models with the voltage regulation?

I just took my S7's out of the rack for a cleaning, and while they are out, I'm thinking of doing this mod.

However, I'm not sure if this mod is an S7LN only thing. I have S7 Batch 9's and Batch 11's; is there anything different in comparison to the S7LN's other than the control board firmware and one extra hashboard?


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: RichBC on September 01, 2016, 05:18:20 PM
Has anyone tried this with the regular ol S7 - the later models with the voltage regulation?

I just took my S7's out of the rack for a cleaning, and while they are out, I'm thinking of doing this mod.

However, I'm not sure if this mod is an S7LN only thing. I have S7 Batch 9's and Batch 11's; is there anything different in comparison to the S7LN's other than the control board firmware and one extra hashboard?

Mod is equally valid for any of the later 135 chip S7 fitted with Buck Converter.


Rich



Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: IITravel01 on September 01, 2016, 06:37:47 PM
I did it to my regular S7 and it worked fine, but you'll have to find which level of voltage will work with each board.  I had to use 3 different volt. settings for each of the 3 boards in my S7, to get the lowest effective setting.  Was pretty easy to set up.  Only problem I had was many of the holes were filled with solder, but with some experimentation I found that you could still program by firmly pushing the contacts to the soldered holes.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on September 01, 2016, 07:00:45 PM
I did it to about half a dozen S7 (and resold most or all); my experience is pretty much the same as the above poster. The only difference between S7 and S7LN boards is heatsink size.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: bbOOmm on September 01, 2016, 08:20:48 PM
Awesome. I'll hack em tonight.

Thanks



Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: Entropize on September 01, 2016, 11:50:54 PM
I can testify, I've got on of Sidehack's modded 135 chip S7s and it's been humming away at over ~4.25Th/s much lower than stock voltage quite happily.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: bitgameSolo on September 15, 2016, 03:30:23 PM
I see in the hex files there is  "S7LN_PIC_FIRMWARE.hex" .... the original unmodified firmware for S7LN. Does anyone know how to get the 135 chip S7 (non-LN) version of the original unmodified firmware? I thought I read somewhere when dealing with firmware to back up my current firmware but wasn't sure how ... thought there might be one posted somewhere.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on September 15, 2016, 03:46:45 PM
I've got a copy of that also.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: HagssFIN on September 15, 2016, 03:53:41 PM
I used one these hex files with PICkit3 for undervolting and underclocking a S7, batch 9  and everything went smooth.
I sold that miner but I'm going to do the same thing again soon to a S7 when the S9 arrives and I rearrange my miners and PSUs.
Here is my setup:
Quote
Antminer S7, 640/670mV,  4.223Th/s (60 min avg), 625 Mhz

Power supply: Enermax Revolution 87+ 1000W
Voltage: 227 VAC
Current: 4,7 A

Power (at wall): 1066,9 W


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: fanatic26 on September 15, 2016, 06:37:08 PM
For those looking to mass mod without having to experiment with every single board to find the most stable number I have done some testing.

Running later batch S7s at 660/690 with frequency at 600 they are doing on average 960w @ 3.95TH
I also removed the back fan and flashed the S7-F1 firmware to save even more power. Temps are better with 1 fan modded version than a stock version at my location.


https://i.imgur.com/i1JSrYZ.jpg


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on September 15, 2016, 06:49:19 PM
Your error rate is higher than I'd shoot for, but 960W/4TH is a pretty good setting. I've set up several in that neighborhood.

Cool to see this effort still in use. Been a couple months since I plugged the tip jar (1CoLDs7XNi8ehyFnGWicUhgBGb7Kw42Ugi) so I'll do that again now.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: fanatic26 on September 15, 2016, 08:11:37 PM
Yea that probably wasnt the best unit to show off with. Most are more like this one as far as the error rate goes

https://i.imgur.com/iD5e3RG.jpg


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: bitgameSolo on September 19, 2016, 02:12:07 PM
I used one these hex files with PICkit3 for undervolting and underclocking a S7, batch 9  and everything went smooth.
I sold that miner but I'm going to do the same thing again soon to a S7 when the S9 arrives and I rearrange my miners and PSUs.
Here is my setup:
Quote
Antminer S7, 640/670mV,  4.223Th/s (60 min avg), 625 Mhz

Power supply: Enermax Revolution 87+ 1000W
Voltage: 227 VAC
Current: 4,7 A

Power (at wall): 1066,9 W

So that is 1067W/4223GH. Or 0.252w/GH. You obviously lowered the watt draw, but I'm confused as to whether you are running more efficient as s7 is rated at .25J/GH, right?


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: HagssFIN on September 19, 2016, 02:17:24 PM
I used one these hex files with PICkit3 for undervolting and underclocking a S7, batch 9  and everything went smooth.
I sold that miner but I'm going to do the same thing again soon to a S7 when the S9 arrives and I rearrange my miners and PSUs.
Here is my setup:
Quote
Antminer S7, 640/670mV,  4.223Th/s (60 min avg), 625 Mhz

Power supply: Enermax Revolution 87+ 1000W
Voltage: 227 VAC
Current: 4,7 A

Power (at wall): 1066,9 W

So that is 1067W/4223GH. Or 0.252w/GH. You obviously lowered the watt draw, but I'm confused as to whether you are running more efficient as s7 is rated at .25J/GH, right?
You have to take the PSU efficiency in account.
The consumption in 12VDC side is maybe something like 0.88x1067W =938.96W (I used 0.88, since it is 87+ efficiency PSU with almost 100% load)
And the efficiency for S7 is then about 0.222.. J/GH.

The number Bitmain gives for the miner efficiency doesn't take the PSU into account (power at wall -efficiency).

I'm getting the most hash out with the Enermax PSU by using these settings.
With 650Mhz frequency the load is too much for this PSU and it occassionally turns off.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: aarons6 on September 19, 2016, 06:37:06 PM
I used one these hex files with PICkit3 for undervolting and underclocking a S7, batch 9  and everything went smooth.
I sold that miner but I'm going to do the same thing again soon to a S7 when the S9 arrives and I rearrange my miners and PSUs.
Here is my setup:
Quote
Antminer S7, 640/670mV,  4.223Th/s (60 min avg), 625 Mhz

Power supply: Enermax Revolution 87+ 1000W
Voltage: 227 VAC
Current: 4,7 A

Power (at wall): 1066,9 W

So that is 1067W/4223GH. Or 0.252w/GH. You obviously lowered the watt draw, but I'm confused as to whether you are running more efficient as s7 is rated at .25J/GH, right?

the s7 is rated at .25j/gh but it realistically is around .31-.33j/gh
even worse if you are on 110v


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on September 19, 2016, 07:46:17 PM
Yeah, a lot of the stock S7s I saw were pulling 1400W for 4.73TH off 208V which puts 'em right around 0.3J/GH - the early 54-chip boards didn't have regulators and ran at a lower per-chip core voltage so they actually did hit about 0.25 (and I've seen some below 0.22J/GH with an undervolted PSU and 550MHz) but Bitmain didn't update the advertised efficiency specs when they redesigned it to be worse. 0.25J/GH out of a 135-chip S7 is decent.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: bitgameSolo on September 20, 2016, 08:16:56 PM

i think you can flash the 1-fan rom on it and just use one stock fan.. not sure tho.. i didnt try. i might try it on my other s7 when i get the pickit3 i ordered from china.


I have tried the 1 Fan Rom and it runs fine with a single fan.

Rich


How to flash the 1 Fan Rom? Aren't all of the .hex files from sidehack are for the 2 fan version? Is there a second firmware besides firmware on individual boards that can be flashed.. maybe on the central board? So we are playing with sub-firmware for the blades or something with this hack?


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: RichBC on September 20, 2016, 08:22:43 PM

i think you can flash the 1-fan rom on it and just use one stock fan.. not sure tho.. i didnt try. i might try it on my other s7 when i get the pickit3 i ordered from china.


I have tried the 1 Fan Rom and it runs fine with a single fan.

Rich


How to flash the 1 Fan Rom? Aren't all of the .hex files from sidehack are for the 2 fan version? Is there a second firmware besides firmware on individual boards that can be flashed.. maybe on the central board? So we are playing with sub-firmware for the blades or something with this hack?

You are correct the 1 Fan Rom Flash is Bitmain firmware for the main BBB controller. The sidehack .hex files are for the PIC controller on the individual hash boards.

Rich


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: aarons6 on September 20, 2016, 09:53:47 PM
So ive had my s7s for quite awhile now.. hacking them i ran into a some issues..

so far i have my boards at 660mv and im running the s7s at 525m
this puts me at 3500ghs right at 900 watts.. for .257j/ghs

one of the issues i have is at random times one of the boards drop out.. it goes to 30c and the hash rate drops down to 0 on that board.. a simple restart of cgminer fixes this.

this seems to happen worse if the board is cold.. i get about the best performance from the boards if they are kept above 60c.

this is where the other issue i am having starts.. the auto fan sucks.. its set to like 80-100 pwm and not much lower..

on my s7s i used the fans from my s5s that i have laying around as the intake fan and a delta afb1212she as exhaust.
https://www.amazon.com/Delta-Electronics-AFB1212SHE-120x120x38mm-connector/dp/B004Y1HLA8

this keeps the s7 nice and cool.. but since we are getting into winter, the problem i had was during the day i have to set to 60% fan and at night  i have to set to 40% fan.

so i made a script.. if anyone wants it here it is..
what this script does is 3 things..
one it reboots the cgminer every 6 hours.. i mine on zpool and for some reason if you went longer then that your speed would start to drop down and it affected payouts.
two it checks the hash rate, and reboots cgminer if it drops below a set amount.
three, it checks the temps, and sets the fan to stay within the set temp range..
it also has a 70c cutoff, that sets the fans to 100% if any board hits 70c.

all these values can be adjusted.. you may have to tweak the temp one to keep the fan from being slowed down and sped up over and over..
installing this script is easy.. just save this text as hashcheck.sh and upload it to the /config folder in the s7 with winscp. then make it executable by clicking properties and checking the X box.
you then ssh into the s7 and run the script /config/hashchecksh.sh &
dont forget the & this allows you to close putty and have the script stay running..
this will also make a hashcheck.txt file in the config you can read to see whats going on.

in order for this to work, before running it, you have to have the box checked for manual fan speed.. then save and restart and run this script.
also every time you turn off and on the s7 it will need to be ran again.


tell me if you guys have any issues.. or think of ways to make it better.

Code:
#!/bin/sh
restart=21600 # 6 hours in seconds
echo $(date) "| hashcheck monitor started. reboot every $restart seconds or if lower then $minhash "  > /config/hashcheck.txt
echo $(date) "| tempcheck monitor started."  >> /config/hashcheck.txt
restartcount=0

######adjust here
minhash=280000 #min hash rate 2800.00 ghs without the decimal.
minfan=30 #min fan speed
maxfan=100 #max fan speed
mintemp=59 #min avg temp
maxtemp=64 #max avg temp
pwm=80 #starting pwm speed
#######

/etc/init.d/cgminer.sh stop > /dev/null
sleep 5
sed -i "/bitmain-fan-pwm/c\"bitmain-fan-pwm\" : \"$pwm\"," /config/cgminer.conf  && \
/etc/init.d/cgminer.sh start > /dev/null
sleep 60

while true
do


T=$(cgminer-api stats | grep 'temp_avg] =>' | cut -c 18-)
T1=$(cgminer-api stats | grep 'temp1] =>' | cut -c 15-)
T2=$(cgminer-api stats | grep 'temp2] =>' | cut -c 15-)
T3=$(cgminer-api stats | grep 'temp3] =>' | cut -c 15-)
E=$(cgminer-api summary | grep 'Elapsed]' | cut -c 17-)
S=$(cgminer-api | grep 'GHS 5s] => ' | cut -c 16- | tr -d '.')
HASH=$(cgminer-api | grep 'GHS 5s] => ' | cut -c 16-)

if [ $T1 -gt "70" ] || [ $T2 -gt "70" ] || [ $T3 -gt "70" ] && [ $pwm -lt "100" ]; then
pwm=100
restartcount=$((restartcount+1))
restarthash=$(cgminer-api | grep 'GHS 5s] => ' | cut -c 16-)
restarttime=$(date)
elapsedtime=$E
echo $(date) "| failed too hot: setting fan to 100 % $restarthash GH/s $T1 $T2 $T3 DEG $T AVG"  >> /config/hashcheck.txt
/etc/init.d/cgminer.sh stop > /dev/null
sleep 5
sed -i "/bitmain-fan-pwm/c\"bitmain-fan-pwm\" : \"$pwm\"," /config/cgminer.conf  && \
/etc/init.d/cgminer.sh start > /dev/null
echo $(date) "| miner restarted $restartcount times: $restarthash GH/s $T1 $T2 $T3 DEG $T AVG , at $restarttime for $elapsedtime seconds" >> /config/hashcheck.txt
sleep 60
continue
fi

if [ $E -gt $restart ]; then
restartcount=$((restartcount+1))
restarthash=$(cgminer-api | grep 'GHS 5s] => ' | cut -c 16-)
restarttime=$(date)
elapsedtime=$E
echo $(date) "| miner scheduled restart $restartcount times: $restarthash GH/s $T1 $T2 $T3 DEG $T AVG , at $restarttime for $elapsedtime seconds" >> /config/hashcheck.txt
/etc/init.d/cgminer.sh stop > /dev/null
sleep 5
/etc/init.d/cgminer.sh start > /dev/null
sleep 60
continue
fi

if [ $S -lt $minhash ] && [ $E -gt "120" ]; then
echo $(date) "| rechecking in 120s low hash : $HASH $T1 $T2 $T3 DEG" >> /config/hashcheck.txt
sleep 120
S=$(cgminer-api | grep 'GHS 5s] => ' | cut -c 16- | tr -d '.')
E=$(cgminer-api summary | grep 'Elapsed]' | cut -c 17-)
T=$(cgminer-api stats | grep 'temp_avg] =>' | cut -c 18-)
T1=$(cgminer-api stats | grep 'temp1] =>' | cut -c 15-)
T2=$(cgminer-api stats | grep 'temp2] =>' | cut -c 15-)
T3=$(cgminer-api stats | grep 'temp3] =>' | cut -c 15-)
HASH=$(cgminer-api | grep 'GHS 5s] => ' | cut -c 16-)
if [ $S -lt $minhash ]; then
restartcount=$((restartcount+1))
restarthash=$(cgminer-api | grep 'GHS 5s] => ' | cut -c 16-)
restarttime=$(date)
elapsedtime=$E
echo $(date) "| failed low hash : $restarthash GH/s $T1 $T2 $T3 DEG $T AVG" >> /config/hashcheck.txt
/etc/init.d/cgminer.sh stop > /dev/null
sleep 5
/etc/init.d/cgminer.sh start > /dev/null
echo $(date) "| miner restarted $restartcount times: $restarthash GH/s $T1 $T2 $T3 DEG $T AVG , at $restarttime for $elapsedtime seconds" >> /config/hashcheck.txt
sleep 60
continue
else
echo $(date) "| recovered: $HASH MH/s $E seconds $T1 $T2 $T3 DEG $T AVG" >> /config/hashcheck.txt
fi
fi

if [ $T -lt $mintemp ] && [ $pwm -gt $minfan ] && [ $E -gt "120" ]; then
echo $(date) "| rechecking in 120s low temp : $HASH GH/s $T1 $T2 $T3 DEG $T AVG" >> /config/hashcheck.txt
sleep 120
S=$(cgminer-api | grep 'GHS 5s] => ' | cut -c 16- | tr -d '.')
E=$(cgminer-api summary | grep 'Elapsed]' | cut -c 17-)
T=$(cgminer-api stats | grep 'temp_avg] =>' | cut -c 18-)
T1=$(cgminer-api stats | grep 'temp1] =>' | cut -c 15-)
T2=$(cgminer-api stats | grep 'temp2] =>' | cut -c 15-)
T3=$(cgminer-api stats | grep 'temp3] =>' | cut -c 15-)
HASH=$(cgminer-api | grep 'GHS 5s] => ' | cut -c 16-)
if [ $S -lt $minhash ]; then
restartcount=$((restartcount+1))
restarthash=$(cgminer-api | grep 'GHS 5s] => ' | cut -c 16-)
restarttime=$(date)
elapsedtime=$E
echo $(date) "| failed low hash : $restarthash GH/s $T1 $T2 $T3 DEG $T AVG" >> /config/hashcheck.txt
/etc/init.d/cgminer.sh stop > /dev/null
sleep 5
/etc/init.d/cgminer.sh start > /dev/null
echo $(date) "| miner restarted $restartcount times: $restarthash GH/s $T1 $T2 $T3 DEG $T AVG , at $restarttime for $elapsedtime seconds" >> /config/hashcheck.txt
sleep 60
continue
else
if [ $T -lt $mintemp ] && [ $pwm -gt $minfan ]; then
pwm=$((pwm-5))
restartcount=$((restartcount+1))
restarthash=$(cgminer-api | grep 'GHS 5s] => ' | cut -c 16-)
restarttime=$(date)
elapsedtime=$E
echo $(date) "| failed too cold: setting fan to $pwm % $restarthash GH/s $T1 $T2 $T3 DEG $T AVG" >> /config/hashcheck.txt
/etc/init.d/cgminer.sh stop > /dev/null
sleep 5
sed -i "/bitmain-fan-pwm/c\"bitmain-fan-pwm\" : \"$pwm\"," /config/cgminer.conf  && \
/etc/init.d/cgminer.sh start > /dev/null
echo $(date) "| miner restarted $restartcount times: $restarthash GH/s $T1 $T2 $T3 DEG $T AVG , at $restarttime for $elapsedtime seconds" >> /config/hashcheck.txt
sleep 60
continue
else
echo $(date) "| recovered: $HASH GH/s $E seconds $T1 $T2 $T3 DEG $T AVG" >> /config/hashcheck.txt
fi
fi
fi

if [ $T -gt $maxtemp ] && [ $pwm -lt $maxfan ] && [ $E -gt "120" ]; then
pwm=$((pwm+5))
restartcount=$((restartcount+1))
restarthash=$(cgminer-api | grep 'GHS 5s] => ' | cut -c 16-)
restarttime=$(date)
elapsedtime=$E
echo $(date) "| failed too hot: setting fan to $pwm % $restarthash GH/s $T1 $T2 $T3 DEG $T AVG" >> /config/hashcheck.txt
/etc/init.d/cgminer.sh stop > /dev/null
sleep 5
sed -i "/bitmain-fan-pwm/c\"bitmain-fan-pwm\" : \"$pwm\"," /config/cgminer.conf  && \
/etc/init.d/cgminer.sh start > /dev/null
echo $(date) "| miner restarted $restartcount times: $restarthash GH/s $T1 $T2 $T3 DEG $T AVG , at $restarttime for $elapsedtime seconds" >> /config/hashcheck.txt
sleep 60
continue
else
echo $(date) "| normal operation: fan at $pwm % $HASH GH/s $E seconds $T1 $T2 $T3 DEG $T AVG" >> /config/hashcheck.txt
fi



sleep 60
done





Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on September 20, 2016, 11:57:13 PM
That looks handy as heck. The worst problem with low-voltage stability on these is cold boards. They really do like that 60C and up, so being able to thermostatically keep them in that range is nice.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: bitgameSolo on September 21, 2016, 08:12:57 PM
s7 running at 620/650 525Mhz. Pulls 860W at wall and 3.5Th/s. So I'm at .246w/Ghs. Only problem is all 3 boards drop somewhere between 1 hour and 1.5 hours. Temperatures were between 60/60/63 and 64/64/66. Obviously I have stability issues but I suppose it is not temperature related? Should I step up 10mv or to 537Mhz?


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: NotFuzzyWarm on September 21, 2016, 08:27:27 PM
s7 running at 620/650 525Mhz. Pulls 860W at wall and 3.5Th/s. So I'm at .246w/Ghs. Only problem is all 3 boards drop somewhere between 1 hour and 1.5 hours. Temperatures were between 60/60/63 and 64/64/66. Obviously I have stability issues but I suppose it is not temperature related? Should I step up 10mv or to 537Mhz?
Yeah I'd try 630/650. That is where most of mine run. Out of 16 s7's I still have on-line one or 2 boards had to go even higher to be stable.

I can also verify the effects of temp. Of those 16 s7 miners ever hour or so 4 would periodically drop 1 card for ~5min before it came back up on its own. Their temps were in the low to mid 50's. Dropped fan speeds to get them up to 60-70C and after 6 hours so far no more dropouts :)


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: bitgameSolo on September 26, 2016, 05:21:09 PM
So ive had my s7s for quite awhile now.. hacking them i ran into a some issues..

So this script must manually be re-run every 6 hours or as long as there is no power failure its ok? Also check box for manual fan speed but also leave at 100% ?


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: aarons6 on September 26, 2016, 05:47:09 PM
So ive had my s7s for quite awhile now.. hacking them i ran into a some issues..

So this script must manually be re-run every 6 hours or as long as there is no power failure its ok? Also check box for manual fan speed but also leave at 100% ?

no the script runs every one minute after you run it once.. in a repeating loop
and yes you check the box for manual fan speed, you can set the speed at 100 or anything really.

you only have to restart it if you power off the s7.

this should also work with the s7ln but you need to change the min hash rate to 180000 instead of 280000


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: bitgameSolo on September 26, 2016, 06:31:59 PM
tell me if you guys have any issues.. or think of ways to make it better.

With stock settings and also sidehack mod, I think every time cgminer restarts and loads/connects the fans shoot 100% for 30 seconds or so as they settle into their manual settings (my ambient air is cool so I set to 60%). I assume there is no way to control this as the script can't run until after cgminer loads? Or is it only with power cycles that the fans will blast after the script is running? Basically it would be nice to avoid the unnecessary startup fan blasts.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: aarons6 on September 26, 2016, 08:29:42 PM
tell me if you guys have any issues.. or think of ways to make it better.

With stock settings and also sidehack mod, I think every time cgminer restarts and loads/connects the fans shoot 100% for 30 seconds or so as they settle into their manual settings (my ambient air is cool so I set to 60%). I assume there is no way to control this as the script can't run until after cgminer loads? Or is it only with power cycles that the fans will blast after the script is running? Basically it would be nice to avoid the unnecessary startup fan blasts.

i dont understand what you are saying..


the fans only go to 100% when the miner itself is first powered on.. then it reboots and the fans are set to the speed you specify.

my script doesnt reboot the whole miner, just cgminer.

the only time my script sets the fans to 100% is if the boards go over 70c.

unless it needs 100% to keep them between 60-65 avg temp.

my s7s are usually around 40-45% fan.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: bitgameSolo on September 27, 2016, 05:52:28 PM

i dont understand what you are saying..


the fans only go to 100% when the miner itself is first powered on.. then it reboots and the fans are set to the speed you specify.

my script doesnt reboot the whole miner, just cgminer.

the only time my script sets the fans to 100% is if the boards go over 70c.

unless it needs 100% to keep them between 60-65 avg temp.

my s7s are usually around 40-45% fan.

OK sorry I know what I said was confusing. I'm testing these at home and want to try your script and am just trying to figure out if it will help with the startup noise referred to below. I've been restarting the s7 at the wall a lot. This is approx what I'm hearing with fans.
At Boot: first 60 seconds quiet barely any fan.
seconds 60-85: loud 100% fan
seconds 85-100: fan slows to my manual setting of 30%
seconds 100-105: fan kicks back up to 100%
seconds 105+: fan goes back down to manual setting 30%

Thx for reply above, I'm going to give your script a shot and see what changes.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: gt_addict on September 27, 2016, 08:03:08 PM
That's exactly the routine my S7LN does when I reboot it. After I hit the reboot button it:-

stops hashing - fans go full speed for 30-45 seconds - goes down to manual speed setting for 10-15 seconds - then full speed for another 10-20secs - then resumes normal hashing and fan speed settings (20% fan speed).

That's the normal sequence as far as I know as the reboot button on the GUI says (this may take 90seconds).


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on September 27, 2016, 08:10:46 PM
Probably the only way around it is to intercept the PWM signal to the fan and route it thought a circuit to impose a maximum duty cycle. If you use the rising edge to trigger a pre-timed one-shot and AND that with the original pulsetrain, the lower duty cycle will win out and it's all done in hardware but that won't fix 100% duty cycle. Using a microcontroller to sample duty cycle and output a pulsetrain of the lesser of preset max duty cycle and controller-mandated duty cycle would give you a maximum.

Hm, I wonder if that would be worth making anyway.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: bitgameSolo on September 29, 2016, 02:24:49 PM
Probably the only way around it is to intercept the PWM signal to the fan and route it thought a circuit to impose a maximum duty cycle. If you use the rising edge to trigger a pre-timed one-shot and AND that with the original pulsetrain, the lower duty cycle will win out and it's all done in hardware but that won't fix 100% duty cycle. Using a microcontroller to sample duty cycle and output a pulsetrain of the lesser of preset max duty cycle and controller-mandated duty cycle would give you a maximum.

Hm, I wonder if that would be worth making anyway.

wow it sounds like you know what you are doing. I've been testing these at home and can't do any restarts too early in AM or late in PM due to the startup noise. the only thing I was thinking was to put a splitter on each fan and manually switch it over to a dummy fan during startup cycle. Not sure if any other low cost fans even work on this. Also not sure the other fan would make less noise but maybe if it was smaller or maybe could put a pencil through and not allow it to spin at all. Then switch back at about 110 seconds.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on September 29, 2016, 02:35:31 PM
I'm working on a little microcontroller PWM driver today which will come in handy for three different projects. Maybe if I have some free time next week I'll see about coding a duty cycle detection onto it and make a max-fan-speed inline module.

If you wanted to circumvent the auto fan entirely, you could probably use a standard fan speed controller and just make sure the tach line is plugged in so your miner controller still sees the fan as spinning.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: bitgameSolo on October 05, 2016, 01:50:43 PM
I'm working on a little microcontroller PWM driver today which will come in handy for three different projects. Maybe if I have some free time next week I'll see about coding a duty cycle detection onto it and make a max-fan-speed inline module.

If you wanted to circumvent the auto fan entirely, you could probably use a standard fan speed controller and just make sure the tach line is plugged in so your miner controller still sees the fan as spinning.

Ok sweet. I do not know how to design/code PWM drivers but maybe I'll try a standard fan speed controller mod in the meantime.

I see there are some sellers of replacement fans that claim "contrary to the original S7 fans these will not MAX-POWER at start-up. Instead, they will remain at low RPM until the S7 initialized. This helps the power supply power and overall performance. " I wonder what they are doing to achieve this?


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: bitgameSolo on October 10, 2016, 02:12:36 PM
i tried out a lower RPM fan with manual knob and tach line. I only had one to test so I kept one original s7 fan at the rear. Manual knob fan worked fine, but I noticed that rather than start at low/quiet RPM for original s7 fan (as it typically does for about 45 seconds before linux/cgiminer initializes), the stock s7 fan starts at max RPM immediately after power up. I'm guessing that machine recognizes one fan is not stock and so it defaults to max spin on the fan that is stock.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: bitgameSolo on October 10, 2016, 05:09:18 PM
also does anyone know what makes the individual hashing boards start back up again? I have tried some of the lower value PIC settings at 400 mhz on a single board and when it drops it will not try to come back up and start hashing again. The same board at more modest 630mV/550 settings will come back up and start hashing again after 5-8 minutes if it drops out.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: fanatic26 on October 10, 2016, 07:19:47 PM
What is it exactly that causes the boards to drop out at the lower voltage? Is it a hardware error issue or is it something else? I have been flashing 660/690 because its what i have found to be universally stable but it really doesnt get them down into the power efficiency level that I want.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: aarons6 on October 10, 2016, 07:29:28 PM
What is it exactly that causes the boards to drop out at the lower voltage? Is it a hardware error issue or is it something else? I have been flashing 660/690 because its what i have found to be universally stable but it really doesnt get them down into the power efficiency level that I want.

no idea but it does seem to be heat and pool specific.

my boards will run 650 on kano's pool pretty stable but the pool i use zpool needs 670.

they also tend to shut off if they drop below 55ish deg.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: aarons6 on October 10, 2016, 07:32:14 PM
i made a few changes to my script.. on one of my s7s it would start beeping and show 0 hash.. so i made the script reboot cgminer when that happens.. i dunno tho if it was internet or the pool.
just copy this in a file called hashcheck.sh in the /config folder of the s7 with permissions of 0744 in winscp. ssh in and run /config/hashcheck.sh &

to calculate the minhash value take the avg speed and times it by .75 this worked for me.
and set pwm to whatever you have your fan running at.. might need to be higher like 40 or 50.

Code:
#!/bin/sh

######adjust here
restart=21600 # 6 hours in seconds
minhash=290000 #min hash rate 2900.00 ghs without the decimal.
minfan=20 #min fan speed
maxfan=100 #max fan speed
mintemp=60 #min avg temp
maxtemp=65 #max avg temp
pwm=30 #starting pwm speed
#######

echo $(date) "| hashcheck monitor started. reboot every $restart seconds or if lower than $minhash "  > /config/hashcheck.txt
echo $(date) "| tempcheck monitor started."  >> /config/hashcheck.txt
restartcount=0

/etc/init.d/cgminer.sh stop > /dev/null
sleep 5
sed -i "/bitmain-fan-pwm/c\"bitmain-fan-pwm\" : \"$pwm\"," /config/cgminer.conf  && \
/etc/init.d/cgminer.sh start > /dev/null
sleep 120

while true
do


T=$(cgminer-api stats | grep 'temp_avg] =>' | cut -c 18-)
T1=$(cgminer-api stats | grep 'temp1] =>' | cut -c 15-)
T2=$(cgminer-api stats | grep 'temp2] =>' | cut -c 15-)
T3=$(cgminer-api stats | grep 'temp3] =>' | cut -c 15-)
E=$(cgminer-api summary | grep 'Elapsed]' | cut -c 17-)
S=$(cgminer-api | grep 'GHS 5s] => ' | cut -c 16- | tr -d '.')
HASH=$(cgminer-api | grep 'GHS 5s] => ' | cut -c 16-)

if [ $T1 -gt "75" ] || [ $T2 -gt "75" ] || [ $T3 -gt "75" ] && [ $pwm -lt "100" ]; then
pwm=100
restartcount=$((restartcount+1))
restarthash=$(cgminer-api | grep 'GHS 5s] => ' | cut -c 16-)
restarttime=$(date)
elapsedtime=$E
echo $(date) "| failed too hot: setting fan to 100 % $restarthash GH/s $T1 $T2 $T3 DEG $T AVG"  >> /config/hashcheck.txt
/etc/init.d/cgminer.sh stop > /dev/null
sleep 5
sed -i "/bitmain-fan-pwm/c\"bitmain-fan-pwm\" : \"$pwm\"," /config/cgminer.conf  && \
/etc/init.d/cgminer.sh start > /dev/null
echo $(date) "| miner restarted $restartcount times: $restarthash GH/s $T1 $T2 $T3 DEG $T AVG , at $restarttime for $elapsedtime seconds" >> /config/hashcheck.txt
sleep 60
continue
fi

if [ $E -gt $restart ]; then
restartcount=$((restartcount+1))
restarthash=$(cgminer-api | grep 'GHS 5s] => ' | cut -c 16-)
restarttime=$(date)
elapsedtime=$E
echo $(date) "| miner scheduled restart $restartcount times: $restarthash GH/s $T1 $T2 $T3 DEG $T AVG , at $restarttime for $elapsedtime seconds" >> /config/hashcheck.txt
/etc/init.d/cgminer.sh stop > /dev/null
sleep 5
/etc/init.d/cgminer.sh start > /dev/null
sleep 60
continue
fi

if [ -z "S$" ] || [ $S -eq "0" ]; then
restartcount=$((restartcount+1))
restarthash=$(cgminer-api | grep 'GHS 5s] => ' | cut -c 16-)
restarttime=$(date)
elapsedtime=$E
echo $(date) "| failed low hash : $restarthash GH/s $T1 $T2 $T3 DEG $T AVG" >> /config/hashcheck.txt
/etc/init.d/cgminer.sh stop > /dev/null
sleep 5
/etc/init.d/cgminer.sh start > /dev/null
echo $(date) "| miner restarted $restartcount times: $restarthash GH/s $T1 $T2 $T3 DEG $T AVG , at $restarttime for $elapsedtime seconds" >> /config/hashcheck.txt
sleep 60
continue
fi


if [ $S -lt $minhash ] && [ $E -gt "120" ]; then
echo $(date) "| rechecking in 120s low hash : $HASH $T1 $T2 $T3 DEG" >> /config/hashcheck.txt
sleep 120
S=$(cgminer-api | grep 'GHS 5s] => ' | cut -c 16- | tr -d '.')
E=$(cgminer-api summary | grep 'Elapsed]' | cut -c 17-)
T=$(cgminer-api stats | grep 'temp_avg] =>' | cut -c 18-)
T1=$(cgminer-api stats | grep 'temp1] =>' | cut -c 15-)
T2=$(cgminer-api stats | grep 'temp2] =>' | cut -c 15-)
T3=$(cgminer-api stats | grep 'temp3] =>' | cut -c 15-)
HASH=$(cgminer-api | grep 'GHS 5s] => ' | cut -c 16-)
if [ $S -lt $minhash ]; then
restartcount=$((restartcount+1))
restarthash=$(cgminer-api | grep 'GHS 5s] => ' | cut -c 16-)
restarttime=$(date)
elapsedtime=$E
echo $(date) "| failed low hash : $restarthash GH/s $T1 $T2 $T3 DEG $T AVG" >> /config/hashcheck.txt
/etc/init.d/cgminer.sh stop > /dev/null
sleep 5
/etc/init.d/cgminer.sh start > /dev/null
echo $(date) "| miner restarted $restartcount times: $restarthash GH/s $T1 $T2 $T3 DEG $T AVG , at $restarttime for $elapsedtime seconds" >> /config/hashcheck.txt
sleep 60
continue
else
echo $(date) "| recovered: $HASH MH/s $E seconds $T1 $T2 $T3 DEG $T AVG" >> /config/hashcheck.txt
fi
fi

if [ $T -lt $mintemp ] && [ $pwm -gt $minfan ] && [ $E -gt "120" ]; then
echo $(date) "| rechecking in 120s low temp : $HASH GH/s $T1 $T2 $T3 DEG $T AVG" >> /config/hashcheck.txt
sleep 120
S=$(cgminer-api | grep 'GHS 5s] => ' | cut -c 16- | tr -d '.')
E=$(cgminer-api summary | grep 'Elapsed]' | cut -c 17-)
T=$(cgminer-api stats | grep 'temp_avg] =>' | cut -c 18-)
T1=$(cgminer-api stats | grep 'temp1] =>' | cut -c 15-)
T2=$(cgminer-api stats | grep 'temp2] =>' | cut -c 15-)
T3=$(cgminer-api stats | grep 'temp3] =>' | cut -c 15-)
HASH=$(cgminer-api | grep 'GHS 5s] => ' | cut -c 16-)
if [ $S -lt $minhash ]; then
restartcount=$((restartcount+1))
restarthash=$(cgminer-api | grep 'GHS 5s] => ' | cut -c 16-)
restarttime=$(date)
elapsedtime=$E
echo $(date) "| failed low hash : $restarthash GH/s $T1 $T2 $T3 DEG $T AVG" >> /config/hashcheck.txt
/etc/init.d/cgminer.sh stop > /dev/null
sleep 5
/etc/init.d/cgminer.sh start > /dev/null
echo $(date) "| miner restarted $restartcount times: $restarthash GH/s $T1 $T2 $T3 DEG $T AVG , at $restarttime for $elapsedtime seconds" >> /config/hashcheck.txt
sleep 60
continue
else
if [ $T -lt $mintemp ] && [ $pwm -gt $minfan ]; then
pwm=$((pwm-2))
restartcount=$((restartcount+1))
restarthash=$(cgminer-api | grep 'GHS 5s] => ' | cut -c 16-)
restarttime=$(date)
elapsedtime=$E
echo $(date) "| failed too cold: setting fan to $pwm % $restarthash GH/s $T1 $T2 $T3 DEG $T AVG" >> /config/hashcheck.txt
/etc/init.d/cgminer.sh stop > /dev/null
sleep 5
sed -i "/bitmain-fan-pwm/c\"bitmain-fan-pwm\" : \"$pwm\"," /config/cgminer.conf  && \
/etc/init.d/cgminer.sh start > /dev/null
echo $(date) "| miner restarted $restartcount times: $restarthash GH/s $T1 $T2 $T3 DEG $T AVG , at $restarttime for $elapsedtime seconds" >> /config/hashcheck.txt
sleep 60
continue
else
echo $(date) "| recovered: $HASH GH/s $E seconds $T1 $T2 $T3 DEG $T AVG" >> /config/hashcheck.txt
fi
fi
fi

if [ $T -gt $maxtemp ] && [ $pwm -lt $maxfan ] && [ $E -gt "120" ]; then
pwm=$((pwm+2))
restartcount=$((restartcount+1))
restarthash=$(cgminer-api | grep 'GHS 5s] => ' | cut -c 16-)
restarttime=$(date)
elapsedtime=$E
echo $(date) "| failed too hot: setting fan to $pwm % $restarthash GH/s $T1 $T2 $T3 DEG $T AVG" >> /config/hashcheck.txt
/etc/init.d/cgminer.sh stop > /dev/null
sleep 5
sed -i "/bitmain-fan-pwm/c\"bitmain-fan-pwm\" : \"$pwm\"," /config/cgminer.conf  && \
/etc/init.d/cgminer.sh start > /dev/null
echo $(date) "| miner restarted $restartcount times: $restarthash GH/s $T1 $T2 $T3 DEG $T AVG , at $restarttime for $elapsedtime seconds" >> /config/hashcheck.txt
sleep 60
continue
else
echo $(date) "| normal operation: fan at $pwm % $HASH GH/s $E seconds $T1 $T2 $T3 DEG $T AVG" >> /config/hashcheck.txt
fi



sleep 60
done


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: bitgameSolo on October 10, 2016, 09:46:18 PM
i made a few changes to my script.. on one of my s7s it would start beeping and show 0 hash.. so i made the script reboot cgminer when that happens.. i dunno tho if it was internet or the pool.

sweet. I'm not very good at reading the code but you are saying that the script will restart the miner when it shows 0 hash and starts beeping or will it restart cgminer when either of those situations happen. meaning it would restart when beeping for any reason (internet loss, too hot, other beep reason).


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: aarons6 on October 10, 2016, 09:57:33 PM
i made a few changes to my script.. on one of my s7s it would start beeping and show 0 hash.. so i made the script reboot cgminer when that happens.. i dunno tho if it was internet or the pool.

sweet. I'm not very good at reading the code but you are saying that the script will restart the miner when it shows 0 hash and starts beeping or will it restart cgminer when either of those situations happen. meaning it would restart when beeping for any reason (internet loss, too hot, other beep reason).

Yep


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: bitgameSolo on October 12, 2016, 04:18:23 PM

so i made a script..
tell me if you guys have any issues.. or think of ways to make it better.


Is there a way to add something which will prevent a reboot if "N" reboots attempted in "M" minutes? If the s7 fails to achieve boards over 55 degrees then a reboot is a good practice. If the s7 fails to achieve boards over 55 degrees after 5 reboots in 20 minutes then a "do not reboot" is a good practice. This is because too many consecutive reboot loops without hashing is a waste of power. If the 5th reboot does not start hasing then there is a good chance the 6th reboot will not either.  Or additionally a "do not reboot for "H" hours after "N" consecutive reboot loops" would take that notion a step further.

I'm not sure this is possible just throwing it out there.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: aarons6 on October 12, 2016, 05:39:08 PM

so i made a script..
tell me if you guys have any issues.. or think of ways to make it better.


Is there a way to add something which will prevent a reboot if "N" reboots attempted in "M" minutes? If the s7 fails to achieve boards over 55 degrees then a reboot is a good practice. If the s7 fails to achieve boards over 55 degrees after 5 reboots in 20 minutes then a "do not reboot" is a good practice. This is because too many consecutive reboot loops without hashing is a waste of power. If the 5th reboot does not start hasing then there is a good chance the 6th reboot will not either.  Or additionally a "do not reboot for "H" hours after "N" consecutive reboot loops" would take that notion a step further.

I'm not sure this is possible just throwing it out there.

it is possible but i never really ran into this.


if you set the pwm to what you think it should be, when you start the script it will only reboot when it needs to.

the only reason it would reboot 5 times in a row is if you set the pwm to 80 and you needed like 50 or 40.. its set to drop in 5 increments.

also its just rebooting cgminer, not the whole miner.. so its not really using any extra power.. you lose maybe 10 seconds of mining.





Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: HagssFIN on October 31, 2016, 08:02:12 PM
Has anyone figured out the HEX files for the Antminer S9?
I wonder if this same procedure could be done to the S9.  :)


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: NotFuzzyWarm on October 31, 2016, 09:06:06 PM
Has anyone figured out the HEX files for the Antminer S9?
I wonder if this same procedure could be done to the S9.  :)
I'd assume it can/could be done with pre-batch-16 miners that are using the old firmware. Batch-16 and higher with the auto-tune pretty sure this will not work.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: bbOOmm on November 03, 2016, 05:41:40 PM
Anyone looking for a couple bone stock S7's to hack?

I thought I'd post here to see if anyone needs a couple to hack, instead of posting them on eBay.

I have 1 - S7 B9 and one S7 B11 for sale. I'm asking $425 USD each or $800 USD for the pair.
Able to accept BTC, ETH-HF or Peercoin as payment... or if in the USA, a good ol bank cashiers check from a US BANK.(There will be a short hold time to clear the check)
Continental USA SHIPPING INCLUDED!
International Shipping Available but at cost.
Unit(s) will be shipped the day after payment has cleared - Tracking number(s) will be provided.

They come with the original packaging and box!

Both are in good running condition. Always disassembled every couple months and cleaned to keep the operating temps low.

No abnormal noise, no dead chips, no burnt connectors.

They have not been hacked, and only have been overclocked for about a week of run time after the warentee expired to analyze cost vs profit vs risk of failure. It turned out that with my electrical cost, it was not beneficial to OC so for the most of their 1 year of running, they were stock clocked.

They will be shipped with the defaults set and labeled with the batch number.

If interested, either contact me via private message, or contact me via email at big.banana.tech &^%_AT_%^&_gmail_!^#_DOT_#^!com

I ship only via FedEX or UPS - your choice.

Thank you

Dave Schmidt
Kewaskum, WI 53040
USA





Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sloopy on November 20, 2016, 06:13:20 AM
Has anyone figured out the HEX files for the Antminer S9?
I wonder if this same procedure could be done to the S9.  :)
I'd assume it can/could be done with pre-batch-16 miners that are using the old firmware. Batch-16 and higher with the auto-tune pretty sure this will not work.

I have the same question. Has anyone done it?
My Pickit3 should be here on Tuesday. I am going to play with some S7s to make sure I have the steps down.
I use a "PIC" in my daily work for years with Allen Bradley PLCs. From what I have read here the steps sound almost identical.
Go online, save a copy of the current "program" in memory, edit the "program", or load a new "program".
With the AB software you then had another step to save to eeprom and done.

This all sounds simple and thanks to sidehack for the work with the pictures and hex files. There will be a tip on the way.
I think all I need are the hex values for the S9. I should be able to look at what is there to begin with and work backwards from that value.

I have another S9 with a hashboard which has stopped showing up at all. I have inspected the locations noted in the thread Simple S9 repair/overclock guide: https://bitcointalk.org/index.php?topic=1661115.0
So, I hope the voltage change will help.

Suggestions are appreciated.

BTW I know Sidehack did the work and collected information  for this S7 / LN thread, but thanks to all who contribute. Hearing input from others either performing the "hack", or have knowledge regarding the components is very helpful as well.

Thanks to all who contribute.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on November 20, 2016, 06:16:37 AM
I highly doubt the S7 hack will work on an S9. Not sure how they alter the voltage but it's a different method, the parts required for the S7 hack to work aren't there.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: HagssFIN on November 20, 2016, 10:41:59 AM
Is it the missing DPOT?
I located the PIC which is PIC16F1704 by Microchip in these pictures of the hash board,
but I could not find a DPOT.
https://c2.staticflickr.com/8/7454/27832785916_635bd20eef_o.jpg
https://c2.staticflickr.com/8/7393/27832763046_597dbe45c0_o.jpg
(Pictures (C) dogiecoin.com)


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: captinkid on December 18, 2016, 07:51:29 PM
Has anyone figured out the HEX files for the Antminer S9?
I wonder if this same procedure could be done to the S9.  :)
I'd assume it can/could be done with pre-batch-16 miners that are using the old firmware. Batch-16 and higher with the auto-tune pretty sure this will not work.

I have the same question. Has anyone done it?
My Pickit3 should be here on Tuesday. I am going to play with some S7s to make sure I have the steps down.
I use a "PIC" in my daily work for years with Allen Bradley PLCs. From what I have read here the steps sound almost identical.
Go online, save a copy of the current "program" in memory, edit the "program", or load a new "program".
With the AB software you then had another step to save to eeprom and done.

This all sounds simple and thanks to sidehack for the work with the pictures and hex files. There will be a tip on the way.
I think all I need are the hex values for the S9. I should be able to look at what is there to begin with and work backwards from that value.

I have another S9 with a hashboard which has stopped showing up at all. I have inspected the locations noted in the thread Simple S9 repair/overclock guide: https://bitcointalk.org/index.php?topic=1661115.0
So, I hope the voltage change will help.

Suggestions are appreciated.

BTW I know Sidehack did the work and collected information  for this S7 / LN thread, but thanks to all who contribute. Hearing input from others either performing the "hack", or have knowledge regarding the components is very helpful as well.

Thanks to all who contribute.

I'm working on fixing a softbricked hashboard on the s9, being able to read the firmware off of a good board and write it to one with bad data might be the ticket. I have the 3200 block code for the autotune version, but I need to wait for my pickit to arrive before I can read the code from the pre autotune version as they didn't include it in the firmware.

Hopefully if I can read a good copy from a working pre autotune board I can write it back to the post autotune softbricked boards.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: Dragonizer on March 21, 2017, 09:10:09 PM
Jeez i just read ALL that as a newbie and i'm more confused  ???

ALL i want to do is check th e pic Voltage controller is worker on a dead S7 !!!!

Do i need to re -read...or can someone help me on how to check it or even where it is, i KNOW its not on he side of the board with capacitors......

If anyone can help it would be GREATLY appreciated..

Drag


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: NotFuzzyWarm on March 21, 2017, 10:25:21 PM
Well, PM Sidehack about it. You seem pretty on-target with your questions so I think you can learn much about the s7 power from him. Specifically, information on checking voltages (and changing them). Tell him I referred you to him ;)


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on March 21, 2017, 10:30:26 PM
He's already talked to me. I told him yesterday what's said in this and other threads - when the PIC is shot, the board boots up to about 9.3 volts instead of over 10 volts. Without a bus sniffer or a good scope to check the I2C lines into the DPOT that's the best way to know if it's working or not.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: Dragonizer on March 22, 2017, 12:56:47 AM
He's already talked to me. I told him yesterday what's said in this and other threads - when the PIC is shot, the board boots up to about 9.3 volts instead of over 10 volts. Without a bus sniffer or a good scope to check the I2C lines into the DPOT that's the best way to know if it's working or not.

So i have no way of checking my standard Fluke Multimeter (I'm an Industrial sparky by trade, so from 12v to 11Kv, any card like this would just go in the bin or sent away to the likes of you guys for repair, but fom reading 100's of threds it is ONLY a oltage measurement i need to check, i have saved the parameters of expecte voltage.

I have read so many threads and had a few bottles i'm going Dizzy....

ONE thing that i think i am correct on is that it can not be a faulty pic (which i can't find or test..lol),  the reason being-

1. I have all boards showing with no missing xxxxxx or any -----------, all 0000's.
2. The temps are showing and are low as expected (not mining) BUT it does show on my pool (so I/O board, Beagle Board /BB ok)
3. All 3 chains of 45 Asics are showing healthy.
4, Fans are running at a presumed speed since i have NO Outut/Gh's ??? Pool requesting for power...

I'm going back to search on how to check the chip and where it is located and can i can i test it with a standard fluke Multimeter, I know the parameters.

Cheers guy's for putting up with me.
 
Drag


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: NotFuzzyWarm on March 22, 2017, 01:36:33 AM
Well for a start, what is the voltage into and out of the big power inductor? One side should be fed from the PCIe plug through MOSFETS and will be a chopped 12v, the output side needs to 10v or more depending what the PIC is setup for. (Sidehack confirm?) Somewhere in this thread the output is mentioned.

Anyhow, if the low side of the inductor is less than that, probably dead PIC and the regulator/dpot is working off of preset defaults. If the voltage is zero the I'd guess the FET's failed open but typically they fail as a short.

I suppose if you have a PICkit programmer you can follow the heart of this thread and try to readout what the PIC has stored in it. After saving that (possibly corrupt) file might as well see if the PIC can accept a reprogram for lower voltage better eff...


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: Dragonizer on March 22, 2017, 05:20:57 AM
t
Well for a start, what is the voltage into and out of the big power inductor? One side should be fed from the PCIe plug through MOSFETS and will be a chopped 12v, the output side needs to 10v or more depending what the PIC is setup for. (Sidehack confirm?) Somewhere in this thread the output is mentioned.

Anyhow, if the low side of the inductor is less than that, probably dead PIC and the regulator/depot is working off of preset defaults. If the voltage is zero the I'd guess the FET's failed open but typically they fail as a short.

I suppose if you have a PICkit programmer you can follow the heart of this thread and try to readout what the PIC has stored in it. After saving that (possibly corrupt) file might as well see if the PIC can accept a reprogram for lower voltage better eff...

I have tried x5 psu's bit get the same situation/problem....I do not Know if i need a PIC programmer, as i do not know id]s my pic is withing ing the the correct parameters (Voltage).

I do have various pic programmers from over the years for old |NTL/Virgin pics, plus xbox  etc....

I just need to the pic first, do my faults (AS ABOVE), relate to a dodgy chip ?

Can anyone confirm this, i've read and read/saved 70 odd replies, ans still do not know which pic it is it is ' i have a Willem/Nexus programmers..lol and i have a Pic Programmer somewhere, not sure where it is but remember putting in the 6 pin chips...MUST off been to to with 'Ful package TV' YEARS ago 15 years ago at least...

Thanks guys, i will keep searching..


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: aarons6 on March 22, 2017, 07:38:55 AM
t
Well for a start, what is the voltage into and out of the big power inductor? One side should be fed from the PCIe plug through MOSFETS and will be a chopped 12v, the output side needs to 10v or more depending what the PIC is setup for. (Sidehack confirm?) Somewhere in this thread the output is mentioned.

Anyhow, if the low side of the inductor is less than that, probably dead PIC and the regulator/depot is working off of preset defaults. If the voltage is zero the I'd guess the FET's failed open but typically they fail as a short.

I suppose if you have a PICkit programmer you can follow the heart of this thread and try to readout what the PIC has stored in it. After saving that (possibly corrupt) file might as well see if the PIC can accept a reprogram for lower voltage better eff...

I have tried x5 psu's bit get the same situation/problem....I do not Know if i need a PIC programmer, as i do not know id]s my pic is withing ing the the correct parameters (Voltage).

I do have various pic programmers from over the years for old |NTL/Virgin pics, plus xbox  etc....

I just need to the pic first, do my faults (AS ABOVE), relate to a dodgy chip ?

Can anyone confirm this, i've read and read/saved 70 odd replies, ans still do not know which pic it is it is ' i have a Willem/Nexus programmers..lol and i have a Pic Programmer somewhere, not sure where it is but remember putting in the 6 pin chips...MUST off been to to with 'Ful package TV' YEARS ago 15 years ago at least...

Thanks guys, i will keep searching..

the PIC is a 12F1572.. its powered by 3.3v

i used a pickit3.
the program i used is MPLAB IDE 3.5

the hex files are in this thread..

id start by flashing the default ones.. think its 720mV or something.. altho i run my s7s at 670mV with speed 600. it puts them at 4000GH/s and about 980 watts at the wall.

here is the how-to and the download link for the hex files
https://bitcointalk.org/index.php?topic=1504228.msg15298837#msg15298837

here is where you get the software
http://www.microchip.com/mplab/mplab-x-ide



Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: Dragonizer on March 22, 2017, 10:38:27 AM
Cheers mate that was EXACTLY what i was looking for, can't find my pic programmer yet, pretty sure i only used to program chips for the rapid fire/extra 2 buttons on the Xbox...lol


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on March 22, 2017, 12:38:59 PM
You know, the first few paragraphs of the first post in this thread told you the PIC part number, as well as what the PIC does in the circuit and what to look for to diagnose a dead one. Except for explicitly stating what ISP programmer to use, it answered basically all of your questions from the last few days.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: Dragonizer on March 22, 2017, 04:12:44 PM
You know, the first few paragraphs of the first post in this thread told you the PIC part number, as well as what the PIC does in the circuit and what to look for to diagnose a dead one. Except for explicitly stating what ISP programmer to use, it answered basically all of your questions from the last few days.

I have read that post and have noted the 2 pin header is ground and the 6 pin is connected to the pic, but what i can not find is which pin on the 6 in header i need to measure voltage on or do i do it between the 8pin pic and GND and or between one of the 6 pin headers and ground.

http://ww1.microchip.com/downloads/en/DeviceDoc/40001723D.pdf

You mention it is a PIC12F1572, I have googled the hell out of , trying to learn,'ve evn had a USN scope on the pic i presume it is, but i can get no info off it.

From what i think i correct the 2 header GND are labelled P2, the 6 pin header that connects to an 8 pin PICip12F1572 is labeled P1.

I'm sill learning but if his is the chip it looks VERY simple to replace....BUT i can not find any info at what points between GND and/or the the PIC or 6 pin header

http://imgur.com/a/TMHhK

I am SORRY if i am frustrating people BUT i am still learning as a newbie, i hope you can take this into consideration, even the mention of the PIC12F1572 had me googing the board fo it, searching forum for hours and even using a USB scope to see if i could find it lablelled 'PIC12F1572'

Do i simply need to measure between VSS and VDD or VSS and GND pin.


Cheers


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on March 22, 2017, 04:29:49 PM
Remember when I mentioned you should do some research on how buck regulators work?

Note also the explanation in the first post. The PIC sends a signal to the digital potentiometer tied to the buck regulator, and that adjusts the voltage. Remember how NotFuzzyWarm told you to measure your voltage at the big inductor?

Note how in this thread there's talk of using a PIC programmer on the 6-pin header. That's because the 6-pin header is ONLY USED TO PROGRAM THE PIC. There is no measuring of voltage going on there. The voltage people are referring to (~9V for a dead PIC, >10V for a working one) are measured at the buck regulator output. That's been stated multiple times in this thread and the potentiometer fix thread.

Also note that the 8-pin SOIC I told you to look at says "1572" on it. That's the PIC12F1572.

So what you do is exactly what's been told to you so far. You fire up the board (make sure it's got 12V power and is plugged to the IO board by the 18-pin cable) and measure the main buck regulator output voltage (at the inductor). If it's around 9.3 volts, your PIC isn't setting the voltage probably because it's dead. Buy a new one, flash it with the firmware given in this thread (aaron6 linked you to it) and then power up the board again, see if the voltage is better.

If you power up the board and it's reading over 10 volts, this is not the fix you need.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: Dragonizer on March 22, 2017, 04:51:28 PM
Remember when I mentioned you should do some research on how buck regulators work?

Note also the explanation in the first post. The PIC sends a signal to the digital potentiometer tied to the buck regulator, and that adjusts the voltage. Remember how NotFuzzyWarm told you to measure your voltage at the big inductor?

Note how in this thread there's talk of using a PIC programmer on the 6-pin header. That's because the 6-pin header is ONLY USED TO PROGRAM THE PIC. There is no measuring of voltage going on there. The voltage people are referring to (~9V for a dead PIC, >10V for a working one) are measured at the buck regulator output. That's been stated multiple times in this thread and the potentiometer fix thread.

Also note that the 8-pin SOIC I told you to look at says "1572" on it. That's the PIC12F1572.

So what you do is exactly what's been told to you so far. You fire up the board (make sure it's got 12V power and is plugged to the IO board by the 18-pin cable) and measure the main buck regulator output voltage (at the inductor). If it's around 9.3 volts, your PIC isn't setting the voltage probably because it's dead. Buy a new one, flash it with the firmware given in this thread (aaron6 linked you to it) and then power up the board again, see if the voltage is better.

If you power up the board and it's reading over 10 volts, this is not the fix you need.

I have red up on buck regulators, ant that the PIC is just a digital pot, and people are just replacing it with a standard screw pot.

What i don't know is where the 'BIG Inductor' is even after reading his thread ?

When i have replaced pics in the past i have always programed them via my PIC Programmer, just plug it into the correct slot/position on programming board and 'flash it' with the  FW aaro6 linked me.

I tried to find a pic with '1572, but not ecen my usb scope could pick it up, why not just state it is labelled U3 on pcb, and the 6 in header linked to the pic is P1 and the GND P2 ?

I am still reading the threads and looking on how to 'measure the main buck regulator output voltage (at the inductor)' ???

Why does a blank i need to flashed via the 6 pin header?  Never seen tha done beore always used a PIC prgrammer board and relevent program....

Cheers



Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on March 22, 2017, 05:12:58 PM
what is the large  coil like thing ?

You might also want to do some research on how buck regulators work. The coil-like thing is a coil.

Well for a start, what is the voltage into and out of the big power inductor?

The regulator's voltage is set by a digital potentiometer ... The default value is right in the middle, which is why some "dead" S7 will start to 9.3V ... the value gets updated by a little microcontroller (PIC12F1572), which pushes out a fresh value from memory as soon as it kicks on.

Why are you using a USB scope to look for 1572? It's something you look for with your eyes. It's written on top of the chip. Without a board in front of me I have no idea what the silkscreen label is, but I do know it's the 8-pin SOIC device with PIC12F1572 written on it. Which is all information you had.

But anyways, first thing you need to do is measure the voltage at the place you've been told to measure the voltage (I'm pretty sure there are even clearly labeled pictures in the potentiometer fix thread). If it's not in the range you've been told to look for to see if the PIC is dead, you don't need to worry about all the other information you were given because it's not the fix you need - which is also information you were given.

Sorry if my criticality comes across as dickish. I'm well aware I tend to expect more out of people than they're used to and am frequently disappointed, but I don't intend to change. It either makes people leave me alone or work to be better, which in the long run are both winning outcomes.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: NotFuzzyWarm on March 22, 2017, 05:14:05 PM
Remember when I mentioned you should do some research on how buck regulators work?

Note also the explanation in the first post. The PIC sends a signal to the digital potentiometer tied to the buck regulator, and that adjusts the voltage. Remember how NotFuzzyWarm told you to measure your voltage at the big inductor?

Note how in this thread there's talk of using a PIC programmer on the 6-pin header. That's because the 6-pin header is ONLY USED TO PROGRAM THE PIC. There is no measuring of voltage going on there. The voltage people are referring to (~9V for a dead PIC, >10V for a working one) are measured at the buck regulator output. That's been stated multiple times in this thread and the potentiometer fix thread.

Also note that the 8-pin SOIC I told you to look at says "1572" on it. That's the PIC12F1572.

So what you do is exactly what's been told to you so far. You fire up the board (make sure it's got 12V power and is plugged to the IO board by the 18-pin cable) and measure the main buck regulator output voltage (at the inductor). If it's around 9.3 volts, your PIC isn't setting the voltage probably because it's dead. Buy a new one, flash it with the firmware given in this thread (aaron6 linked you to it) and then power up the board again, see if the voltage is better.

If you power up the board and it's reading over 10 volts, this is not the fix you need.

I have red up on buck regulators, ant that the PIC is just a digital pot, and people are just replacing it with a standard screw pot.

What i don't know is where the 'BIG Inductor' is even after reading his thread ?

When i have replaced pics in the past i have always programed them via my PIC Programmer, just plug it into the correct slot/position on programming board and 'flash it' with the  FW aaro6 linked me.

I tried to find a pic with '1572, but not ecen my usb scope could pick it up, why not just state it is labelled U3 on pcb, and the 6 in header linked to the pic is P1 and the GND P2 ?

I am still reading the threads and looking on how to 'measure the main buck regulator output voltage (at the inductor)' ???

Why does a blank i need to flashed via the 6 pin header?  Never seen tha done beore always used a PIC prgrammer board and relevent program....
Cheers
I think you have one of the very early batch number s7's... They have no Vcore regulator, the ASICs are directly fed from the PSU.

I think we kit a key point about the s7's - and s9's: What batch number is it? With the s7 batches 1-5 with 54 chips per board have NO Vcore voltage control. ergo no DPOT, no regulator chip, no inductor, etc. and I think no PIC. Only the later batches with 45 chips have the Vcore regulator goodies...


All the chips are in 1 big series string with Vcore set by how many chips in the string divided into the PSU supply voltage. As with any string topology, any break in the string from a bad chip or bypass cap and the whole board dies.

A decent read on buck regulators, https://en.wikipedia.org/wiki/Buck_converter


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: Dragonizer on March 22, 2017, 05:27:51 PM
what is the large  coil like thing ?

You might also want to do some research on how buck regulators work. The coil-like thing is a coil.

Well for a start, what is the voltage into and out of the big power inductor?

The regulator's voltage is set by a digital potentiometer ... The default value is right in the middle, which is why some "dead" S7 will start to 9.3V ... the value gets updated by a little microcontroller (PIC12F1572), which pushes out a fresh value from memory as soon as it kicks on.

Why are you using a USB scope to look for 1572? It's something you look for with your eyes. It's written on top of the chip. Without a board in front of me I have no idea what the silkscreen label is, but I do know it's the 8-pin SOIC device with PIC12F1572 written on it. Which is all information you had.

But anyways, first thing you need to do is measure the voltage at the place you've been told to measure the voltage (I'm pretty sure there are even clearly labeled pictures in the potentiometer fix thread). If it's not in the range you've been told to look for to see if the PIC is dead, you don't need to worry about all the other information you were given because it's not the fix you need - which is also information you were given.

Sorry if my criticality comes across as dickish. I'm well aware I tend to expect more out of people than they're used to and am frequently disappointed, but I don't intend to change. It either makes people leave me alone or work to be better, which in the long run are both winning outcomes.

I understand your frustration, if you was to ask me about certain isolations, EICR tests, permits, earth loop impedance, remote I/O, Ifix, Calculating motor size/torque/Rpm /Wattage etc i would be the same.....lol

I wish your first answer to ' what is the coil thing' i presumed it was some form of inductor BUT on Youtube some nutter ( i will find it and and post it, i will make you even angrier as i think he is checking the main caps with ONLY a Mulimeter..lol
)  If you has said it was  the inductor i would have been testing this ages ago...

Anyway thanks again for 'putting up with'

'I will be back'....lol


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: NotFuzzyWarm on March 22, 2017, 05:58:54 PM
I do hope you caught https://bitcointalk.org/index.php?topic=1504228.msg18293399#msg18293399 right after Sidehack's reply... Your s7 does not have the regulator talked about in this thread nor the 'Cheap and simple repair of S7 hash board' thread... No big honking power inductor (and 54 chips) = no Vcore regulation.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: Frank-White on March 25, 2017, 06:33:20 PM
for the tinkerers: broken batch 7? 45 asics.

http://www.ebay.de/itm/BITMAIN-ANTMINER-S7-batch7-Hashboard-SOLD-AS-IS-defect-/302263224410?hash=item46604ac85a:g:FmEAAOSwol5Y1nRZ


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: Dibblah on March 25, 2017, 07:15:33 PM
for the tinkerers: broken batch 7? 45 asics.

http://www.ebay.de/itm/BITMAIN-ANTMINER-S7-batch7-Hashboard-SOLD-AS-IS-defect-/302263224410?hash=item46604ac85a:g:FmEAAOSwol5Y1nRZ

Ugh. I would strongly suspect that the sense line shorted to ground (given the not quite precise soldering) and therefore put 12v or so across the chain, which would be 'only' 0.8v if averaged. But the chips don't level out well at high voltages, so it's likely to have blown a group of ASICs.

Not bad value if that's the only fault on the board.



Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: blissz on October 29, 2017, 04:24:40 PM
Any chance that this could work on an antminer d3? Or is the code on the microcontroller very specific for each type of asic?
I really would like have the ability to undervolt the d3 boards (without too much underclocking) and see how much it can be undervolted before it gives any errors.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: NotFuzzyWarm on October 29, 2017, 04:44:54 PM
Any chance that this could work on an antminer d3? Or is the code on the microcontroller very specific for each type of asic?
I really would like have the ability to undervolt the d3 boards (without too much underclocking) and see how much it can be undervolted before it gives any errors.
a. While related to BTC via the s7 connection, this really belongs in altcoins - and AFAIK Sidehack could care less about alts.

b. Does that altcoin miner use autotune? Since it uses 16nm node chips I suspect it does. If so - forget it as autotune miners cannot be changed.

c. As far as code being the same, you would need to see what PIC they use. If it is the same as the one in s7 yes you can talk to it but autotune will override what you program in.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on October 29, 2017, 05:39:14 PM
Whether or not autotune miners can be changed depends on how the controller code would react to failing to set the board-level voltage. Failing to get any response out of the PIC at all.

Honestly I have no idea about the D3. I've never seen one, and I'm certainly not going to buy one just to mess with. I know this S7 hack doesn't work on the S9, as its regulator control system is completely different.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: blissz on October 29, 2017, 09:54:19 PM
Whether or not autotune miners can be changed depends on how the controller code would react to failing to set the board-level voltage. Failing to get any response out of the PIC at all.

Honestly I have no idea about the D3. I've never seen one, and I'm certainly not going to buy one just to mess with. I know this S7 hack doesn't work on the S9, as its regulator control system is completely different.

thanks for the answer on the s9. I am aware this topic is for the bitcoin miner, but as it's made by the same brand, you probably can help us a bit forward.
The miner allows for manual settings the frequency of the asics, but I really don;t like the power usage vs hashrate graph. I.e. 500mhz = 1200watt, 250 = 600 watts etc...
I am pretty sure there is quite some room for undervolting.

Here is a clear pic of the circuit power circuit on the hashing board. It differs from the s7 unfortunately.
 I really want to know what that "ADP BDY +" chip is for, as that's probably driving the mosfet switching power supply circuit isn't it?

https://preview.ibb.co/f4gAqm/20171027_132530.jpg (https://ibb.co/jvA3Am)

My goal is to lower the voltage and power usage a bit to get better efficiency.
Not sure if it makes sense, but here are some things I consider to tame the beast a bit:

- Try to mess a bit with the resistors near the "ADP BDY +" chip and see if it affects the output voltage
- capture the serial data to the hashing boards, to see if it makes any sense...
- somehow lower the 12v rail voltage by hacking the power supply. (hopefully the circuit won't compensates for that)



Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on October 29, 2017, 10:20:27 PM
Changing your 12V won't do anything, until you get your 12V rail below the output voltage of the main regulator. At that point it'll either start to freak out, shut down, or best case hit 100% duty cycle and push your rail straight through. But it's very likely you don't have a power supply both that adjustable and that powerful.

The circuit looks more like what's on an S9, which I haven't spent enough time around to know how to mess with. By merit of they're still effing expensive. If I had a chip-dead donor board with a good regulator I could at least try to play with it, but I'd also have to have time. In addition to manufacturing and my own miner R&D and other projects I just got volunteered to help a friend build a custom 3D printer for his lab work, so free hours are scarce.

It's likely possible to hack the PIC and make the thing volt-adjustable like an S7, but the circuit's not the same and the mechanism won't be the same either.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: blissz on November 01, 2017, 10:07:34 PM
I started a topic on the D3 with a hardware mod. This is for steady hands only for now  8)
https://bitcointalk.org/index.php?topic=2346161.0


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: jbonifacio on January 15, 2018, 11:36:09 PM
Here's an updated script that tries to keep temps consistent. What I added was the ability to view/fetch the logs though http.

Code:
#!/bin/sh
#
# Installation instructions:
#   - Place in /config/hashcheck.sh
#   - Set execute flag on file (chmod 0744)
#   - Create log file: touch /config/log.txt
#   - Create link to view from http: ln -s /config/log.txt /www/pages/.
#   - Run with: /config/hashcheck.sh &
#
# How to obtain log from http
#   - http://[ip of miner]/log.txt
#
# ADJUST THESE VARS ONLY --------------------------------------
#
restart=14400    #hours in seconds
#minhash=290000  #min hash rate 2900.00 ghs without the decimal
minhash=100000   #min hash rate 2900.00 ghs without the decimal
minfan=12        #min fan speed
maxfan=34        #max fan speed
mintemp=60       #min avg temp
maxtemp=65       #max avg temp
pwm=20           #starting pwm speed
maxloglines=70   #max log lines to save in file
#
#--------------------------------------------------------------

resetcgminer () {
    restartcount=$((restartcount+1))
    restarthash=$(cgminer-api | grep 'GHS 5s] => ' | cut -c 16-)
    elapsedtime=$E

    if [ "$1" = "1" ]; then
        logger "| applying new fan speed"
        sed -i "/bitmain-fan-pwm/c\"bitmain-fan-pwm\" : \"$pwm\"," /config/cgminer.conf
    fi

    logger "| restarting cgminer"
    /etc/init.d/cgminer.sh stop > /dev/null
    sleep 5
    /etc/init.d/cgminer.sh start > /dev/null

    logger "| miner restarted: $restarthash GH/s, $T1 $T2 $T3 deg ($T avg), up at $restarttime for $elapsedtime seconds"
    tailit
    sleep 60
}

getstats () {
    S=$(cgminer-api | grep 'GHS 5s] => ' | cut -c 16- | tr -d '.')
    E=$(cgminer-api summary | grep 'Elapsed]' | cut -c 17-)
    T=$(cgminer-api stats | grep 'temp_avg] =>' | cut -c 18-)
    T1=$(cgminer-api stats | grep 'temp1] =>' | cut -c 15-)
    T2=$(cgminer-api stats | grep 'temp2] =>' | cut -c 15-)
    T3=$(cgminer-api stats | grep 'temp3] =>' | cut -c 15-)
    HASH=$(cgminer-api | grep 'GHS 5s] => ' | cut -c 16-)
}

logger () {
    echo $(date +%Y-%m-%d:%H:%M:%S) "$1 " >> /config/log.txt
}

tailit () {
    tail -$maxloglines /config/log.txt > /config/log2.txt && cp /config/log2.txt /config/log.txt
}

rm /config/log.txt
touch /config/log.txt

logger "| hashcheck monitor started. reboot every $restart seconds or if hash lower than $minhash Ghs"
logger "| tempcheck monitor started"

restartcount=0
T=0
T1=0
T2=0
T3=0
PCT="%"

resetcgminer 1

sleep 60

while true
do
    getstats

    if [ $T1 -gt "75" ] || [ $T2 -gt "75" ] || [ $T3 -gt "75" ] && [ $pwm -lt "100" ]; then
        pwm=100
        logger "| failed too hot: setting fan to 100$PCT, $restarthash GH/s, $T1 $T2 $T3 deg ($T avg), $restartcount restarts"
        resetcgminer 1
        continue
   fi

   if [ $E -gt $restart ]; then
        logger "| miner scheduled restart: $restarthash GH/s, $T1 $T2 $T3 deg ($T AVG), up for $elapsedtime seconds"
        resetcgminer 0
        continue
   fi

   if [ -z "S$" ] || [ $S -eq "0" ]; then
        logger "| failed low hash: $restarthash GH/s, $T1 $T2 $T3 deg ($T avg), $restartcount restarts"
        resetcgminer 0
        continue
   fi


   if [ $S -lt $minhash ] && [ $E -gt "120" ]; then
        logger "| rechecking in 120s low hash: $HASH $T1 $T2 $T3 deg, $restartcount restarts"

        sleep 120

        getstats

        if [ $S -lt $minhash ]; then
            logger "| failed low hash: $restarthash GH/s, $T1 $T2 $T3 deg ($T avg), $restartcount restarts"
            resetcgminer 0
            continue
        else
            logger "| recovered: $HASH MH/s, $E seconds, $T1 $T2 $T3 deg ($T avg), $restartcount restarts"
        fi
   fi

   if [ $T -lt $mintemp ] && [ $pwm -gt $minfan ] && [ $E -gt "120" ]; then
        logger "| rechecking in 120s low temp: $HASH GH/s, $T1 $T2 $T3 deg ($T avg), $restartcount restarts"

        sleep 120

        getstats

        if [ $S -lt $minhash ]; then
            logger "| failed low hash: $restarthash GH/s, $T1 $T2 $T3 deg ($T avg), $restartcount restarts"
            resetcgminer 0
            continue
        else
            if [ $T -lt $mintemp ] && [ $pwm -gt $minfan ]; then
                pwm=$((pwm-2))
                logger "| failed too cold: setting fan to $pwm$PCT, $restarthash GH/s, $T1 $T2 $T3 deg ($T avg), $restartcount restarts"
                resetcgminer 1
                continue
            else
                logger "| recovered: $HASH GH/s, $E seconds, $T1 $T2 $T3 deg ($T avg)"
            fi
        fi
   fi

   if [ $T -gt $maxtemp ] && [ $pwm -lt $maxfan ] && [ $E -gt "120" ]; then
        pwm=$((pwm+2))
        logger "| failed too hot: setting fan to $pwm$PCT, $restarthash GH/s, $T1 $T2 $T3 deg ($T avg), $restartcount restarts"
        resetcgminer 1
        continue
   else
        logger "| normal operation: fan at $pwm$PCT, $HASH GH/s, $E seconds, $T1 $T2 $T3 deg ($T avg), $restartcount restarts"
   fi

   tailit

   sleep 60
done


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: surferdudemi on January 31, 2018, 10:00:28 PM
Early on, a post mentioned the temp sensor.  Has anyone figured out which chip it is?  The PIC looks like it's at the air inlet side of the board, so I don't think it's just reading an internal sensor.  Most of the chips I see around the board are voltage regulators with SMT discretes around them.  I've got one board that reads zero and one that reads low and intermittently shows what I think is the correct value.

Thanks


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: fanatic26 on January 31, 2018, 10:28:41 PM
The temp sensor of the s7 is baked into the chip. From what I recall it pulls the temp data from the very last chip in the string (chip 45 closest to the regulator)


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on January 31, 2018, 10:31:46 PM
You sure it's not reading from the SO-8 TMP75 in the center of the board using I2C via the TSCL and TSDA lines on the cable connector?


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: fanatic26 on January 31, 2018, 11:14:40 PM
You sure it's not reading from the SO-8 TMP75 in the center of the board using I2C via the TSCL and TSDA lines on the cable connector?

Ill have to dig out my documentation to confirm but that is what I remember from the hardware training I received from bitmain last year in China.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on February 01, 2018, 12:14:14 AM
You're not thinking the S9, are you?


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: surferdudemi on February 01, 2018, 05:57:38 AM
You sure it's not reading from the SO-8 TMP75 in the center of the board using I2C via the TSCL and TSDA lines on the cable connector?

Ill have to dig out my documentation to confirm but that is what I remember from the hardware training I received from bitmain last year in China.

All of the chips show "o", so it seems odd that the temp value would be bad / wrong on two boards when the chips appear to be functioning properly.  There are multiple posts about the temp problem (I Googled it, not on here), but I could not find any info about where the sensor is so I could inspect it on the board.

People have mentioned that Bitmain had the schematics available, and that they were pulled.  Did copies survive anywhere?  Didn't see any with a Google search - even in the images which sometimes show stuff you don't see in the regular search results.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: fanatic26 on February 01, 2018, 05:56:35 PM
You're not thinking the S9, are you?


Apologies, it seems that I was thinking s9. I pulled out my s7 maintenance guide and confirmed I was mixing the two up.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: Sweminer777 on February 02, 2018, 03:49:02 PM
any form to, revive this boards, when they show 00000000000000000000000000000 but do not hash? what can be done or work around?


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: fanatic26 on February 02, 2018, 04:35:31 PM
any form to, revive this boards, when they show 00000000000000000000000000000 but do not hash? what can be done or work around?

There are many reasons for it not hashing, we would need more info to help you. I would recommend making a post in the support section with your full kernel log so people can help.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on February 26, 2018, 09:16:26 PM
To the guy whose post was recently deleted, asking about D3 hacking, someone on the previous page mentioned looking into it.

I started a topic on the D3 with a hardware mod. This is for steady hands only for now  8)
https://bitcointalk.org/index.php?topic=2346161.0



(Moderator's note: This post was edited by frodocooper to remove an off-topic portion of the post.)


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: FNT on March 02, 2018, 10:23:50 AM
Hi sidehack,

Thanks for replay... and sorry for off topic posting.
I checked the post of D3 completly, but I found no hex file of D3.

About the S7, how have you made the settings in the hex file for the S7?
Have you just modified the memory where the voltage settings are stored or did you
have done the work from scratch do code the voltage settings?

Thanks for info!

Bye, FNT


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: NotFuzzyWarm on March 02, 2018, 02:34:56 PM
Hmm, might this explain my donated old Ant45s7b6 briefly showing up on Kano last night? Someone fiddling with it and a PIC programmer? ;)


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on March 02, 2018, 03:06:12 PM
Why would someone have bought it six months ago or whatever and not run it or change pool configs? That's weird.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: NotFuzzyWarm on March 02, 2018, 04:31:37 PM
No idea unless they only changed pool-1 and it failed over to one of the other original settings for pool-2 or 3. It last reported to Kano's pool 13 hrs ago.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: FNT on March 04, 2018, 03:51:59 PM
Hi,

@notfuzzywarm: not that miner, as hashboard is here on the table,
all pools set to mine. It's an other ant45s7.

Any hints about the PIC?

Bye


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: Breeze on April 17, 2018, 12:12:40 PM
Anybody have an idea why i cant connect?
https://www.dropbox.com/s/xocgink55xkclrq/fail.JPG?dl=0
https://www.dropbox.com/s/xocgink55xkclrq/fail.JPG?dl=0



Moderator's note: This post was edited by frodocooper to remove inline image tags.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on April 17, 2018, 12:33:35 PM
Plenty of ideas, but it's not too helpful without knowing what you've done to get there.

Is your kit plugged in backward? Did you disconnect the 18-pin cable to the control board?


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: Breeze on April 17, 2018, 12:38:53 PM
Plenty of ideas, but it's not too helpful without knowing what you've done to get there.

Is your kit plugged in backward? Did you disconnect the 18-pin cable to the control board?

I set the voltage 3.3. Arrow on the pickit is down, like in the picture. Have a pin cable. Yes, have dissconnected the 18 pin cable from the boars.
Now i'm gonna try older version of the IPE 3.35


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: Breeze on April 17, 2018, 12:42:34 PM
Code:
2018-04-17 14:38:44 +0200 - Completed loading IPE.


*****************************************************

Connecting to MPLAB PICkit 3...

Currently loaded firmware on PICkit 3
Firmware Suite Version.....01.51.08 *
Firmware type..............Enhanced Midrange

Now Downloading new Firmware for target device: PIC12F1572
Downloading bootloader
Bootloader download complete
Programming download...
Downloading RS...
RS download complete
Programming download...
Downloading AP...
AP download complete
Programming download...

Currently loaded firmware on PICkit 3
Firmware Suite Version.....01.43.35
Firmware type..............Enhanced Midrange

Programmer to target power is enabled - VDD = 3,300000 volts.
Unable to connect to the target device.
Failed to get Device ID


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: Breeze on April 17, 2018, 12:50:49 PM
Now it connect when i use "Low Voltage Power" in the Power menu.
But have this error:
Code:

*****************************************************

Connecting to MPLAB PICkit 3...

Currently loaded firmware on PICkit 3
Firmware Suite Version.....01.43.35
Firmware type..............Enhanced Midrange

Programmer to target power is enabled - VDD = 3,300000 volts.
Target Device ID (0x0) is an Invalid Device ID. Please check your connections to the Target Device.

EDIT: Got it working now. It works when i have the 18-pin cable connected to the board. It's some random shit.....
Testing board #1 now  :)


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: House Xylander on June 22, 2018, 04:06:12 AM
Having issues with programming my S7 (45 Asic) boards.

I am using the MPLAB IPE v3.35

The Low voltage checkbox has to be checked as well or it will not connect for me.

The target id keeps coming up as (0x0) and says its invalid. If I select ok it connects but still has the target ID error.

I can read and export original firmware

When I try to Program the board with any of the Hex files, I get the following:

"2018-06-21 22:57:42 -0500 - Programming...

The following memory area(s) will be programmed:
program memory: start address = 0x0, end address = 0xaf
configuration memory

Device Erased...

Programming...
program memory
Address: 0 Expected Value: 2805 Received Value: 0
Failed to program device
2018-06-21 22:57:45 -0500 - Programming failed
Pass Count: 0"

I would appreciate any help on this matter.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: House Xylander on June 29, 2018, 02:06:31 PM
Having issues with programming my S7 (45 Asic) boards.

I am using the MPLAB IPE v3.35

The Low voltage checkbox has to be checked as well or it will not connect for me.

The target id keeps coming up as (0x0) and says its invalid. If I select ok it connects but still has the target ID error.

I can read and export original firmware

When I try to Program the board with any of the Hex files, I get the following:

"2018-06-21 22:57:42 -0500 - Programming...

The following memory area(s) will be programmed:
program memory: start address = 0x0, end address = 0xaf
configuration memory

Device Erased...

Programming...
program memory
Address: 0 Expected Value: 2805 Received Value: 0
Failed to program device
2018-06-21 22:57:45 -0500 - Programming failed
Pass Count: 0"

I would appreciate any help on this matter.

Resolved this by unchecking the LVP box and increasing the VDD power to 4.65
At 4.65 it connected successfully and produced the correct Target ID

I now have them running 640,630,630 respectfully at 600Mhz and kill a watt is showing a 634w average at 110v.
This cut the cost to run by about half but I fear the continued drop in the value of BTC is the next obstacle in the near future.

Any suggestions on a PSU, preferably a quieter one than the 1300w server PSU?


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: NotFuzzyWarm on June 29, 2018, 02:26:47 PM
<snip>
Any suggestions on a PSU, preferably a quieter one than the 1300w server PSU?
I've been becoming rather fond of Bitmain's APW3++ series. They are rated up to 1,200W @ 110v (1,600W @ 240v) and are quiet even when moderately loaded. Their one quirk is that if it ever shuts down from overload it takes several minutes before it will restart despite being only slightly warm .


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: jsays on June 29, 2018, 02:30:14 PM
I do not have the equipment (or experience for comfort) to do this, but I do have an S7 (45 asic) gathering dust.

Is anyone out there offering this (re)programming as a paid service?



Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: House Xylander on June 29, 2018, 02:56:38 PM
I've been becoming rather fond of Bitmain's APW3++ series. They are rated up to 1,200W @ 110v (1,600W @ 240v) and are quiet even when moderately loaded. Their one quirk is that if it ever shuts down from overload it takes several minutes before it will restart despite being only slightly warm .

Would i need 1300w since i have lowered the mv with thee hex files?
I figured 800w max for ramp up then it would settle to 630-640w.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: NotFuzzyWarm on June 29, 2018, 03:07:59 PM
Quote
Would i need 1300w since i have lowered the mv with thee hex files?
Maybe for a short time until the s7's throttle down.
Good thing is, the APW3++ is seriously de-rated. I've ran a few at 1,350-1,400w fed from 110v for several days with no issues other than the fans running at full speed. Still quieter than the hair dryer like sound from HP DP1200w supplies.

Several companies distribute the APW's, I use Blockforge.com in the US


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: House Xylander on June 29, 2018, 06:20:32 PM
Maybe for a short time until the s7's throttle down.
Good thing is, the APW3++ is seriously de-rated. I've ran a few at 1,350-1,400w fed from 110v for several days with no issues other than the fans running at full speed. Still quieter than the hair dryer like sound from HP DP1200w supplies.

Several companies distribute the APW's, I use Blockforge.com in the US

Thank you, will look into them.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: House Xylander on July 01, 2018, 03:33:20 PM
I let each board run solo on my S7 for a day or so each. I fired up the third board for a solo run last night and it immediately showed all 3 boards with "oooo"s and 48 chips.

I switch the ribbon cable out for one of the other boards - same result

I re-flashed it with different hex files, starting from 620 up to 690 - same result

Changed power supply from apw3++ 1300 to an EVGA 750 - same result

I have run out of ideas at this point and would greatly appreciate the help.


Thank you


edit: added additional info


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: jsays on July 12, 2018, 02:44:25 PM
Sidehack, or others... anyone offer (or willing to do) this as a paid service, for those of us that don't have the knowledge/comfort to do so ourselves?


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: fanatic26_ on July 12, 2018, 03:34:18 PM
Sidehack, or others... anyone offer (or willing to do) this as a paid service, for those of us that don't have the knowledge/comfort to do so ourselves?

Its really not worth the time or effort to ship it, have it done, send it back and all that nonsense. Plus when you dont like how it runs and you start to complain, nobody wants to deal with that.

Just man up and do it yourself, it costs almost nothing for a PIC programmer and then like 15 minutes of your time to actually do it.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on July 12, 2018, 04:50:53 PM
It's true. All the software is free and you can get a PICKit clone for like $20.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: jsays on July 24, 2018, 07:42:02 PM
It's true. All the software is free and you can get a PICKit clone for like $20.

I have one on order, looks like it'll arrive Friday so hoping that will be my fun for the weekend.

Had another S7 hashboard die, just won't show all the asics...so the last two boards I have are running in one machine. If I can update both of those, hoping to get them as low as 2.5Th at 600W...in which case I should actually be able to run it in the house!


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: NotFuzzyWarm on July 24, 2018, 07:57:06 PM
Depending on the condition of the chips and resulting speed/voltage the miner will be stable at, with 3 boards mine were running at ~ 3.5 to 3.9THs with fans at 20-25%, power draw was around 750W. Result is more than quiet enough for the office or home.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: NotFuzzyWarm on July 25, 2018, 03:59:37 PM
how much energy does the miner consume? ???
...
Perhaps try READING the post right above yours?


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: adaseb on July 31, 2018, 07:50:52 AM
Depending on the condition of the chips and resulting speed/voltage the miner will be stable at, with 3 boards mine were running at ~ 3.5 to 3.9THs with fans at 20-25%, power draw was around 750W. Result is more than quiet enough for the office or home.

Really surprised you got it to be quiet enough for an office with a 750W power draw.

I remember with my old Antminer S3, to get it quiet enough for a bedroom I had to undervolt and underclock so it pulled 300Watts and I was able to get away with using 2 computer case fans (from a KnCMiner Jupiter actually).

With a 750W power draw, I don't think it would be possible to make it that quiet.

But I guess everybody has different noise levels and they are all relative.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: NotFuzzyWarm on July 31, 2018, 02:21:50 PM
Quote
With a 750W power draw, I don't think it would be possible to make it that quiet.
But I guess everybody has different noise levels and they are all relative.
The UV/UC s7's get very quiet. Given 70F ambient it is quieter than the central AC. Still audible at a distance but not distracting in the least.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: adaseb on August 01, 2018, 03:34:21 PM
Quote
With a 750W power draw, I don't think it would be possible to make it that quiet.
But I guess everybody has different noise levels and they are all relative.
The UV/UC s7's get very quiet. Given 70F ambient it is quieter than the central AC. Still audible at a distance but not distracting in the least.

I guess the difference can be the hashboards.

If I recall the S3 hashboard had exposed chips, while the S7 had individual heatsinks on each chip.

So I guess the S7 needed a little less airflow since the heatsinks did a good job of absorbing most of the heat, while the S3 needed much more air.

Really temped to pick up a couple of these and just mod them for old time sakes. Been a while since I've had an Antminer and they are dirt cheap right now.

Maybe point it in ckpool solo and hope it hits a block one day.


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: potofgreed on July 21, 2021, 09:43:35 PM
BUMP

Does anyone happen to still have the hex files lying around? Sidehack's link earlier in the thread is dead. Would be much appreciated


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: lonewoof1337 on December 23, 2021, 03:52:42 PM
Hello all!


Any chance that the files needed for this mod are floating around somewhere? The link posted a few years ago at gekkoscience is dead now : (


I'd really like to do some tinkering with an S7 I just picked up.

Any help would be appreciated!

Happy holidays!


-woof


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: thierry4wd on December 26, 2021, 12:28:42 AM
Floating at my home :D

https://easyupload.io/7r7ak1


Title: Re: Hacking the S7 - improving efficiency through minor hardware manipulation
Post by: sidehack on December 29, 2021, 05:40:26 PM
So in June my people convinced me to change webhosts and get a better managed email frontend. This jacked up some of the website stuff. I'm in the process of migrating back because the recommended outfit is not good. That's why the file link is dead. It'll come back someday, hopefully early next year.

It's cool to see people are still interested in this project.