I have only 4 blades and 2 cp2102 (I have bought them per $8 per piece) just now but already purchased 2 more (about $2,6 per piece).
What is much more important I think is to solve how to get proper information about how chips are running, about their status "x" or "o" and temperature. Have You any idea how to do it? In original S1 unit there is kernel module which very probably does it, send that info into some virtual device where cgi-bin script is reading it. But depends on if those informations are there where we are connected now or if there is need to attach another pin of the blabe.
the original version from bitmain get the temp info when they read the last calculated hash, i will need to see if there is more info hiding in the data that we recieve from the blade, or if it was something the pic handled on the control board.
in regard to timing:
this is how ive learned the chips do their magic, you send the data to the chip, and just before it is done calculating the hash, the chip needs to get a cancel order, then read the hash, so, if your too fast with the timing, you cancel unfinshed calculations, if your too slow, it sits and wait for new orders... theirfor timing needs to be correct.
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!)