Thats correct

System > Upgrade > Browse > Select downloaded FW and click "Flash image"

see https://bitcointalk.org/index.php?topic=699064.msg8370071#msg8370071

You are looking at the wrong file. Frequencies are set in the GUI and the file that holds these values is no longer the /etc/config/asic-freq file, but rather the file /usr/lib/lua/luci/model/cbi/cgminer/cgminer.lua (see this thread if you want to add to the freqs' list https://bitcointalk.org/index.php?topic=699064.msg8370071#msg8370071)

The source is the same source as that is available on github for version 4.7.0 so anyone an get that. The changes to source that I documented earlier in this thread are deprecated since I abandoned the --include-icarus flag, however, should anyone wnt to include the icarus driver, then the error messages from the compiler are quite instructive. Also, compiling is quite easy, you just need to install MinGW (which is also free and opensource!). It can be tedious to setup MinGW but not impossible.

However, if even after that someone still wants to get a hold of the binary I compiled and / or the code i used to compile it, just point me to where you'd like me to upload it and its yours!

PS. I did mention earlier in the thread that I was working on something else, more specifically a windows driver. I can update the thread to the effect that I have actually gone to ground to write a windows miner that uses COM ports. I am working on the initialisation of the S1 board and work division in the code, and when I have some extra time off, I'll be looking to finishing it off and showcasing it! For me, that represented a better alternative than trying to wrestle the generic cgminer code targeting multiple rigs and written in a foreign language (C++!)

I was able to compile cgminer 4.7.0 for and under windows using MinGW but not able to run it without significant errors (and at times it would not detect the board!). It therefore is not a binary that would be useful for sharing, and seeing the pre-compiled version 3.8.5 for windows reconises both the CP210x (as AMU / LIX / etc) and the PL230x (as ICA and ... ?), you would be better off getting that one, available here: https://github.com/AntMiner/AntGen1/blob/master/cgminer/cgminer-run-windows-20131224.zip?raw=true

PS. You may need to change over the TX / RX connectors on some of the modules as the lines can be twisted!

You mean a relay ... ? Something like this possibly ...

Bump

Ahem, was that meant to read consensus? Well, S3+'s are solid units, (including S3's later than batch 6) and bitmain have perfected their art with respect to these devices, with the sole exception of the firmware update shenanigans. Properly powered, they hit and exceed their rated hash-speed without batting an eyelid. I personally think more can be squeezed out of the S3+'s by re-doing the top heat-sink and using heatpads rather than the paste.

Climbed back up to near 60 ...... but those blocks are tumbling like hell, or is that just me getting excited !?

Thats just put to waste my now opened bottle of champaigne .... well, well ...... Mr Sugar you done it!

Blooy marcaroni! I know the overall hash-rate of the pool has been yoyoing this weekend, but this takes the biscuit! Now down to ~5500000 GH/s! Last block payout was SWEET!

Looking for S1's. BTC wise, PM me your acceptable price including shipping. (also see: https://bitcointalk.org/index.php?topic=850689.0 and yes I know you commented there too!)

This is the way I understand it.
1. the temp is read from the board via a pin (the temp sensor is that chip in the middle of the board). It has been mentioned in this thread what pin number this is, and as far as I can recall, the proto-board can read this too. Some chips also return their temperature individually, but I am not sure the BM1380 does this, or whether the board has been equiped to be able to read the chip temp.
2. when hashing, there is a sequence of events.

• initialise the board with the frequency you choose to run the chips at. This sets the speed at which each chip will hash and therefore you can tell (the manufacturers of the chip) how long it will take to compute the nonce, thus the timeout.
• in the initialisation, you also have a timeout number (in miliseconds / seconds ) which should be kept by the software.
• send the nonce to be searched by the chip, take note of the time sent and await a result within the timeout period. A result could be found before the alloted timespan and returned, else the chip(s) will sit idle after that.
• if a result is returned, the software then checks whether the size of the result matches (or exceeds) the difficulty requested (diff) by the pool and then sends it on to the pool, else it is trashed.

EDIT:
3. HW errors occur when the chip fails to return a value which can be caused by either a reall HW error (e.g over-heat) or when the timeout is set low and the chip does not get a chance to finish the search and return a value. Again, the software that sends work to the chips monitors this (aka count them out and count them in!)

Could you please delete the message you posted on this thread https://bitcointalk.org/index.php?topic=850689.0 ?

Seems like the REAL initialise routine just fiddles about with the usb, nothing to do with the board .... unless there is something hidden in the usb_ident structure.

[2014-11-08 18:08:27] Bmsc recv golden nonce timeout code 2 recieved: 0000000000 - should have recieved: 000187a2

That does not offer any insight, to me at least, but suffice to say, I have seen that zero number printed out in the error messages before, though I have tried to replicate it to no avail.

OK.
Since you have managed to get all 64 chips detected, then I suppose you can try to find out why it is not going past the golden_nonce test:

After this: applog(LOG_ERR, "Bmsc recv golden nonce timeout");
Add this: applog(LOG_ERR, "Bmsc recv golden nonce timeout received: %s", ret);
My C++ is useless, but that should tell us what the return is (or does it fail on the next if ... else ... ?)

EDIT: I have actually just seen the REAL initialization routine in driver-bmsc.c aka

The detection routine? Is that in reference to the CP2012 ?
I am still unsure where the bmsc code determines the number of chips since it at times initializes less than the 32 on a board, and by initializing I mean setting the frequency if you have that in the command-line, otherwise, I can not see where it does that!

Anyway back to your thingy-bob, where in code do you disable the detection routine that you refer to?

What mods have you made to the driver? I tried that with 3.8.5 and both boards were hashing the same nonce ..... thus single board speed.

The connections are OK, they work well with version 3.8.5.


Again, since the zadig USB drivers work with 3.8.5, I have not opted to try other drivers.
However, now that you mentioned the libusb, I do not add that at compile time. Also, I removed the dll from the directory and I assume the program uses the system drivers ..... which leads me to think that I may have an older version of libusb installed on the system like you insinuated earlier. I'll keep poking around and update the thread whence I have any useful info to share, otherwise, I'd prefer not to swamp the thread seeing the linux driver is working (and most people will be using that).

Totally understand.
The one edit that I did to mine was to add a sleep in the driver-bmsc.c file on line 1179, i.e cgsleep_ms(500);

Check the Miner Configuration tab and if you have an Advanced Settings tab there, then you need to OC via that tab (by selecting the desired frequency) then clicking on the Save and Apply button (bottom right hand corner)