I do not wish to "rub salt in the wounds" of those who've bricked their machines, but the cardinal rule with this throw away tech is "if it ain't broke, do not fix it!"
There was NO good reason to update any S3 type rig with the Nov firmware. Yes I know it was supposed to fix the reset button and bitmain publicised its release more than any other I've known, but still, there was no need.
The reason I did not even bat an eyelid was because it purported to fix an issue that I had no need for, aka the reset button. My S3 types were running OK to well and have never had a reason to use the reset button. Most nuances that I have encountered with the S3 types are mostly down to my limited IT knowledge, but a quick google search usually resolves those (if not a post in these hallowed pages).

I am aware this post is not sticky, but I'll say it while I can;

If it ain't broke, don't fix it!

Use $50SPECIALOFFER when checking out to claim your discount

I would steer clear of setting voltages on that. There are quite a few un-knowns about the Nov firmware update (mainly for the PIC), but I have seen a tech from bitmain advising NOT to alter voltage.
A word to a wise man is enough.

I disagree with the crowd that say you should not build your own. You certainly can, as in building a PC, but need to garner a bit of knowledge (not much really) about ASICs in relation to cryptocurrency if you are not going to lose your lot. You'll also have to find suppliers e.g the manufacturers that make the dragon type rigs (the bitmain window closed with the discontinuing of the S1 upgrade kit, that would have been a nice one for you!). If you want to fabricate your own boards, there are ASIC manufacturers that will sell you the chips so you can make your own design, bitfury used to (I think they are bust!), blackarrow do etc.

Depending on why you want to build your own there are options galore if you put the time in to research. If you are just looking to mine and hoard BTC, then you're better off buying off the shelf stuff (bitmain, spoondoolies etc).

Just my 2 pence!

I also have a similar problem with my 5 module one, but the non hashing module does not show up at all in the gui. I looked at the debug log and the module is not detected on initialisation. this only started about a week ago but was running OK.

If you have 2 CP2102, you can connect one to each board and mine away! cgminer will recognise the boards (so long as you have the right drivers compiled in), but you will probably have to run them with the blue wire hack for temp control.

First, you need to ensure that your C1 is NOT running the November firmware before you can change the default setting. This thread is beyond that scope, but a lot has been said in the S3 discussion and support thread.

The datasheet setting for the freq range of 225 (which I'd say 218.75 falls) is 0.72v, so I'd test with a voltage setting of 0720 which should be more than adequate for that freq.

Again, do at your own risk!

That was tongue-in-cheek stuff, but yeah, I thought if anyone was going to have a clue about what the hell was going on, it was going to be you. In the meantime, dog1965 seems to have a historic attachement to machine language, so he's going to run a rule over the file .... fingers crossed. Any other clever clogs about and conversant with machine language, do not feel shy!

I catch the drift .... I think ..... yes, I think so.
Anyhow, is it possible to dis-assemble this machine language further into C++? The image above only shows a small fraction of the data, possibly less than 1% ....

Another clever clogs about .... very well. If you need anything from me, post here or drop me a PM.

Not being one to take good advice when given some, after realising the miner_pic.hex file was an ASCII file, I decided to deploy my secret reference material (read google) and seem to have found something, though I can not make any sense of it. I am sure bitsolutions, the clever clogs on our side, can so here goes.

1. My reference material suggested a site to view a hex file: http://en.webhex.net/
On visiting the site, I browsed to the file and uploaded the miner_pic.hex file

2. On the next screen, I scrolled to the bottom of the box and clicked on the Export link

3. When the Export screen was loaded, I un-checked the Headline, Offsets and Readable Characters check-boxes then clicked on the Export button on that screen.

4. I was then presented with the hex data in a web page. I had not mentioned this, but earlier,  my reference material had also suggested to me an online dis-assembler here : http://www2.onlinedisassembler.com/odaweb/

5. I copied all the exported hex data (Ctrl + A then Ctrl + C) then flicked over to the dis-assembler, clicked on the Platform button and changed it to avr (this may b wrong), and in the box below that I pasted the hex data into it.

The page then did a little spinning wheel and after a short while, spewed out something like this:



Now the easy bit, @bitsolutions or any of you clever clogs out there, can you make any sense of that?

I do not think that cgminer was updated in the Nov firmware ... but could be wrong. Aside from that, since they made a dog's dinner out of the pic_firmware, I can not for the life of me see else-where performance enhancements could have been made.

Here's an interesting thought, would it not be nice if you wrapped one good bin file firmware update for us mere mortals? Here I mean one that has the correct and properly working hex file plus a working filesystem. that would be nice.

On another note, I managed to extract that hex file from one of my S3's (keep it for a rainy day) using MinGW on Windows. When I call file on the hex, it says it is ASCII text, with CRLF line terminators! I am tempted to open it up in notepad .....

Right, this is getting a bit confusing for me, but never mind, I appreciate all the information.

So to recap, there is absolutely no reason whatsoever to update firmware to the Nov 2014 release aside from the fix to the web UI, which fix can be applied by a single line via ssh.

Am I correct in this or have I missed something that is obvious to you?

Very well then, it seems they have even cleverer people at bitmain than I gave them credit for, my bad.
Now if you do not mind throwing some light on the issue that is perturbing me, so here goes:

Aside from the pic firmware in the Nov release (which you cleverly established to have been fiddled with by bitmain), what advantage has the rest of the update in the Nov release is there to be had over that in the Oct release? Seems to me a simple and complete reset to the  13th Oct 2014 firmware rather than fudging the two would do nicely. Ofcourse, I am speaking from a postion of utter ignorance, so bear with me there).

You are a very clever person bitsolutions. Now, can you kindly tell us how to open and read the code in that hex file please? If these jombas from bitmain are not going to be honest with us, their customers, then I think they've earned us the right to pore over their little secrets. I thank you in advance.

You are now raising the possiblility that you have not bricked the board ... do you have any other S3+'s on your network and if so is any of them on the default static IP?
When you flash a unit that (usually) is on DHCP, th web UI will NOT register a response because the flashing resets the IP to the default one and turns the network settings to static. Thus you have to log onto the default static IP (192.168.1.99) rather than the on you had on DHCP. And if you have 2 units on the default IP, ofcourse one will not show up on your network, and that will be the last to ry to use that IP (which in this case is the rebooting / reflashed rig).

Those looking to replace their controller boards - bitmain are a bit awkward with their controllers, and I do not know why? Last I tried to get a replacement on, I was quoted $110 (if I recall + shipping), or given the option to order an S3+ to have the controller shipped with that order. But when I chose to go the $110 route but with EMS shipping - not DHL / UPS (which was like 2 weeks wait), they never followed through for some obscure reason. I got fed-up jumping through hoops, so you better brace yourselves!

There you go, I have put up a poll on the thread, hopefully we'll get a good response. i've also left it open so anyone can view the results.

With regard to getting different people to carry out the tests and collating the results, I'll leave that to yourself to start the thread for that. You can start off with an empty table listing the freqs and voltages that you want, then people can opt to do the test by posting a message before they start, stating the freq & voltage they are testing, then posting results when they are done and you filling in the table in the OP.

Ain't no shame in that ma friend .....

To be honest, I've (and many more out there!) have run a good number of that range - ofcourse tending to the OC side - but not for long enough (IMO) to be authoritative enough to form the definitive guide, also undocumented!
Saying that, the full range may be overkill and lack any useful result over and above what we already know, thus I'd suggest voltage increments of .25v over a 6hr period minimum. If anyone has 10 or more S3+'s, that would be trivial, then again, they'd have to "sacrifice" their earnings. If you only have a coupl of S3+'s, it won't require a herculian effort, but trivial it won't be.
Thus IITravel01, start a fund to get this off the ground and I am sure you won't be shy of takers!

I have asked here before but never got an answer, so I'll try again.
When I call the api from my S3 via a scheduled tasks (cron job) and a script to restart via the API call:
cgminer stops hashing but does not restart.

The line that calls the script in scheduled tasks is:

Via putty, I have run the cgminer-api vrsion command and get this (in case it is relevant).

My question is: Why is cgminer not restarting and am I missing any arguments to the API call?[/code]