[DIY] - Reward $100 | Antminer S1/S3 Blade on Raspberry Pi

[pekatete]

repo with changes from idonthave and changed timing settings

to set the timings you now can just type the timing in ms instead of the 0.55, so

--bmsc-options 115200:55

working on more changes

https://github.com/FireWalkerX/cgminer-bmsc

ive changed the USB timeout on github, please try that

Just recompiled that and same result, only this time the board does not get recognised at all.
PS. I assumed you only changed the usbutils.c file, so I just replaced that rather than re-download the entire repo.

hmm interresting, since the timeout only says "ill wait x amount of time, for the device, which i changed from 999 ms to 2000 ms, that change works on linux, maybe its your libusb dll that is of older date? or does it get compiled with cgminer?

edit : i have reverted the repo to previous timeout

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);

[CHAOSiTEC]

repo with changes from idonthave and changed timing settings

to set the timings you now can just type the timing in ms instead of the 0.55, so

--bmsc-options 115200:55

working on more changes

https://github.com/FireWalkerX/cgminer-bmsc

ive changed the USB timeout on github, please try that

Just recompiled that and same result, only this time the board does not get recognised at all.
PS. I assumed you only changed the usbutils.c file, so I just replaced that rather than re-download the entire repo.

hmm interresting, since the timeout only says "ill wait x amount of time, for the device, which i changed from 999 ms to 2000 ms, that change works on linux, maybe its your libusb dll that is of older date? or does it get compiled with cgminer?

edit : i have reverted the repo to previous timeout

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);

have you tried with the drivers from silab?

http://www.silabs.com/products/mcu/pages/usbtouartbridgevcpdrivers.aspx


hmmm could you try setting --hotplug 0 and see if it helps with the error messages

[idonothave]

repo with changes from idonthave and changed timing settings

to set the timings you now can just type the timing in ms instead of the 0.55, so

--bmsc-options 115200:55

working on more changes

https://github.com/FireWalkerX/cgminer-bmsc

ive changed the USB timeout on github, please try that

Just recompiled that and same result, only this time the board does not get recognised at all.
PS. I assumed you only changed the usbutils.c file, so I just replaced that rather than re-download the entire repo.

ensure Yourself if wires are fixed properly. I use such workaround to fix them:

[pekatete]

ensure Yourself if wires are fixed properly. I use such workaround to fix them: <snip> ... </snip>

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

have you tried with the drivers from silab? ....

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).

[CHAOSiTEC]

well, im currently looking into connecting 2 boards to 1 cp2102, i get to set freq on all 64 chips, but currently timing out on golden nonce test...

[pekatete]

well, im currently looking into connecting 2 boards to 1 cp2102, i get to set freq on all 64 chips, but currently timing out on golden nonce test...

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.

[CHAOSiTEC]

well, im currently looking into connecting 2 boards to 1 cp2102, i get to set freq on all 64 chips, but currently timing out on golden nonce test...

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.

im working directly off my github version, so far i have had no luck, ive even tried to disable the detection routine, and pretended everything "was fine"

[pekatete]

well, im currently looking into connecting 2 boards to 1 cp2102, i get to set freq on all 64 chips, but currently timing out on golden nonce test...

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.

im working directly off my github version, so far i have had no luck, ive even tried to disable the detection routine, and pretended everything "was fine"

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?

[CHAOSiTEC]

well, im currently looking into connecting 2 boards to 1 cp2102, i get to set freq on all 64 chips, but currently timing out on golden nonce test...

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.

im working directly off my github version, so far i have had no luck, ive even tried to disable the detection routine, and pretended everything "was fine"

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?

its the area where it tests the golden nonce, in driver-bmsc.c just trying to bypas this area to see if i can get it to start hashing

[pekatete]

well, im currently looking into connecting 2 boards to 1 cp2102, i get to set freq on all 64 chips, but currently timing out on golden nonce test...

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.

im working directly off my github version, so far i have had no luck, ive even tried to disable the detection routine, and pretended everything "was fine"

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?

its the area where it tests the golden nonce, in driver-bmsc.c just trying to bypas this area to see if i can get it to start hashing

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

Code:

static void bmsc_initialise(struct cgpu_info *bmsc, int baud){ 
... 
}

[zziggi]

perhaps this table of frequencies and timings will be useful )

https://bitcointalk.org/index.php?topic=526060.msg9170433#msg9170433

[CHAOSiTEC]

well, im currently looking into connecting 2 boards to 1 cp2102, i get to set freq on all 64 chips, but currently timing out on golden nonce test...

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.

im working directly off my github version, so far i have had no luck, ive even tried to disable the detection routine, and pretended everything "was fine"

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?

its the area where it tests the golden nonce, in driver-bmsc.c just trying to bypas this area to see if i can get it to start hashing

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

Code:

static void bmsc_initialise(struct cgpu_info *bmsc, int baud){ 
... 
}

----------------start nonce------------------
 [2014-11-08 18:08:26] Bmsc send golden nonce
 [2014-11-08 18:08:27] Bmsc recv golden nonce timeout code 2 recieved: 0000000000 - should have recieved: 000187a2
 [2014-11-08 18:08:27] -----------------start freq-------------------
 [2014-11-08 18:08:27] Send frequency 82078106
 [2014-11-08 18:08:28] Send freq getstatus 8

[CHAOSiTEC]

perhaps this table of frequencies and timings will be useful )

https://bitcointalk.org/index.php?topic=526060.msg9170433#msg9170433

yep, have it as a file on my laptop :-p

[pekatete]

well, im currently looking into connecting 2 boards to 1 cp2102, i get to set freq on all 64 chips, but currently timing out on golden nonce test...

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.

im working directly off my github version, so far i have had no luck, ive even tried to disable the detection routine, and pretended everything "was fine"

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?

its the area where it tests the golden nonce, in driver-bmsc.c just trying to bypas this area to see if i can get it to start hashing

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

Code:

static void bmsc_initialise(struct cgpu_info *bmsc, int baud){ 
... 
}

----------------start nonce------------------
 [2014-11-08 18:08:26] Bmsc send golden nonce
 [2014-11-08 18:08:27] Bmsc recv golden nonce timeout code 2 recieved: 0000000000 - should have recieved: 000187a2
 [2014-11-08 18:08:27] -----------------start freq-------------------
 [2014-11-08 18:08:27] Send frequency 82078106
 [2014-11-08 18:08:28] Send freq getstatus 8

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.

[CHAOSiTEC]

well, im currently looking into connecting 2 boards to 1 cp2102, i get to set freq on all 64 chips, but currently timing out on golden nonce test...

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.

im working directly off my github version, so far i have had no luck, ive even tried to disable the detection routine, and pretended everything "was fine"

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?

its the area where it tests the golden nonce, in driver-bmsc.c just trying to bypas this area to see if i can get it to start hashing

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

Code:

static void bmsc_initialise(struct cgpu_info *bmsc, int baud){ 
... 
}

----------------start nonce------------------
 [2014-11-08 18:08:26] Bmsc send golden nonce
 [2014-11-08 18:08:27] Bmsc recv golden nonce timeout code 2 recieved: 0000000000 - should have recieved: 000187a2
 [2014-11-08 18:08:27] -----------------start freq-------------------
 [2014-11-08 18:08:27] Send frequency 82078106
 [2014-11-08 18:08:28] Send freq getstatus 8

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.

it sends a known nonce to the asics, and expects to recieve the 000187a2 but the error code it recieves is a communication timeout, and does not recieve any data.

[idonothave]

well, im currently looking into connecting 2 boards to 1 cp2102, i get to set freq on all 64 chips, but currently timing out on golden nonce test...

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.

im working directly off my github version, so far i have had no luck, ive even tried to disable the detection routine, and pretended everything "was fine"

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?

its the area where it tests the golden nonce, in driver-bmsc.c just trying to bypas this area to see if i can get it to start hashing

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

Code:

static void bmsc_initialise(struct cgpu_info *bmsc, int baud){ 
... 
}

----------------start nonce------------------
 [2014-11-08 18:08:26] Bmsc send golden nonce
 [2014-11-08 18:08:27] Bmsc recv golden nonce timeout code 2 recieved: 0000000000 - should have recieved: 000187a2
 [2014-11-08 18:08:27] -----------------start freq-------------------
 [2014-11-08 18:08:27] Send frequency 82078106
 [2014-11-08 18:08:28] Send freq getstatus 8

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.

it sends a known nonce to the asics, and expects to recieve the 000187a2 but the error code it recieves is a communication timeout, and does not recieve any data.

Better to order one more cp2102 I think. But good luck

[CHAOSiTEC]

well, im currently looking into connecting 2 boards to 1 cp2102, i get to set freq on all 64 chips, but currently timing out on golden nonce test...

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.

im working directly off my github version, so far i have had no luck, ive even tried to disable the detection routine, and pretended everything "was fine"

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?

its the area where it tests the golden nonce, in driver-bmsc.c just trying to bypas this area to see if i can get it to start hashing

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

Code:

static void bmsc_initialise(struct cgpu_info *bmsc, int baud){ 
... 
}

----------------start nonce------------------
 [2014-11-08 18:08:26] Bmsc send golden nonce
 [2014-11-08 18:08:27] Bmsc recv golden nonce timeout code 2 recieved: 0000000000 - should have recieved: 000187a2
 [2014-11-08 18:08:27] -----------------start freq-------------------
 [2014-11-08 18:08:27] Send frequency 82078106
 [2014-11-08 18:08:28] Send freq getstatus 8

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.

it sends a known nonce to the asics, and expects to recieve the 000187a2 but the error code it recieves is a communication timeout, and does not recieve any data.

Better to order one more cp2102 I think. But good luck

its called curiousity :-p

well we have the software side running as it should, now we just need the prototype, or order 15 more cp2102 :-/

[idonothave]

well, im currently looking into connecting 2 boards to 1 cp2102, i get to set freq on all 64 chips, but currently timing out on golden nonce test...

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.

im working directly off my github version, so far i have had no luck, ive even tried to disable the detection routine, and pretended everything "was fine"

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?

its the area where it tests the golden nonce, in driver-bmsc.c just trying to bypas this area to see if i can get it to start hashing

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

Code:

static void bmsc_initialise(struct cgpu_info *bmsc, int baud){ 
... 
}

----------------start nonce------------------
 [2014-11-08 18:08:26] Bmsc send golden nonce
 [2014-11-08 18:08:27] Bmsc recv golden nonce timeout code 2 recieved: 0000000000 - should have recieved: 000187a2
 [2014-11-08 18:08:27] -----------------start freq-------------------
 [2014-11-08 18:08:27] Send frequency 82078106
 [2014-11-08 18:08:28] Send freq getstatus 8

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.

it sends a known nonce to the asics, and expects to recieve the 000187a2 but the error code it recieves is a communication timeout, and does not recieve any data.

Better to order one more cp2102 I think. But good luck

its called curiousity :-p

well we have the software side running as it should, now we just need the prototype, or order 15 more cp2102 :-/

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.

[CHAOSiTEC]

well, im currently looking into connecting 2 boards to 1 cp2102, i get to set freq on all 64 chips, but currently timing out on golden nonce test...

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.

im working directly off my github version, so far i have had no luck, ive even tried to disable the detection routine, and pretended everything "was fine"

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?

its the area where it tests the golden nonce, in driver-bmsc.c just trying to bypas this area to see if i can get it to start hashing

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

Code:

static void bmsc_initialise(struct cgpu_info *bmsc, int baud){ 
... 
}

----------------start nonce------------------
 [2014-11-08 18:08:26] Bmsc send golden nonce
 [2014-11-08 18:08:27] Bmsc recv golden nonce timeout code 2 recieved: 0000000000 - should have recieved: 000187a2
 [2014-11-08 18:08:27] -----------------start freq-------------------
 [2014-11-08 18:08:27] Send frequency 82078106
 [2014-11-08 18:08:28] Send freq getstatus 8

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.

it sends a known nonce to the asics, and expects to recieve the 000187a2 but the error code it recieves is a communication timeout, and does not recieve any data.

Better to order one more cp2102 I think. But good luck

its called curiousity :-p

well we have the software side running as it should, now we just need the prototype, or order 15 more cp2102 :-/

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.

[pekatete]

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!)