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

[forpblat]

I am sure you will not get any blue smoke .... and yes, the way I discovered was just that way, flipped them when plugged in and cgminer spewing errors at me ... then voilla!

So far no dice with the switched RX/TX. I get flashing on the blade, but no further activity on cgminer. Stalls at:

 [2014-11-15 09:24:59] Started cgminer 4.7.0
 [2014-11-15 09:24:59] -----------------start freq-------------------
 [2014-11-15 09:25:00] Send frequency 82098110
 [2014-11-15 09:25:00] Send freq getstatus 84000400

and eventually segfaults out. Switching to the other blade without resoldered pins.

[1715198051]

1715198051

[1715198051]

1715198051

[1715198051]

1715198051

[1715198051]

1715198051

[1715198051]

1715198051

[pekatete]

I am sure you will not get any blue smoke .... and yes, the way I discovered was just that way, flipped them when plugged in and cgminer spewing errors at me ... then voilla!

Screw it, pray for no magic smoke. I'd be blown away if that was it. Two different uarts, both swapped on the silkscreening...

It is more the logic that tx on the dongle should connect to the rx on the board, but when they say pin 3 on the board is the tx, what does that mean? Is that the tx on the board or is it the pin you connect the tx from the dongle to? That is what led me to stumble upon that ..... but when I had them connected the "wrong" way, never got any blue, purple or magic smoke!

[pekatete]

I am sure you will not get any blue smoke .... and yes, the way I discovered was just that way, flipped them when plugged in and cgminer spewing errors at me ... then voilla!

So far no dice with the switched RX/TX. I get flashing on the blade, but no further activity on cgminer. Stalls at:

 [2014-11-15 09:24:59] Started cgminer 4.7.0
 [2014-11-15 09:24:59] -----------------start freq-------------------
 [2014-11-15 09:25:00] Send frequency 82098110
 [2014-11-15 09:25:00] Send freq getstatus 84000400

and eventually segfaults out. Switching to the other blade without resoldered pins.

Is this further than you've been? That screen tells me the dongle has been detected by cgminer, and if the light flashes on the board, then the board is getting communication from cgminer and if the next line reads getstatus no data finish, then the board is not succeeding in communicating back (not sure why).

[forpblat]

Is this further than you've been? That screen tells me the dongle has been detected by cgminer, and if the light flashes on the board, then the board is getting communication from cgminer and if the next line reads getstatus no data finish, then the board is not succeeding in communicating back (not sure why).

Previously (with RX->TX and TX->RX) I've had it get further where outside of this snip, the 0xea60 device is found:

[2014-11-14 20:37:13] AMU0: Read freq Comms timeout (rerr=-7 relen=0)
 [2014-11-14 20:37:13] AMU0: GetResults (amt=0 err=-7 ern=25)
 [2014-11-14 20:37:13] AMU0: Read freq Comms timeout (rerr=-7 relen=0)
 [2014-11-14 20:37:14] AMU0: GetResults (amt=0 err=-7 ern=25)
 [2014-11-14 20:37:14] AMU0: Read freq Comms timeout (rerr=-7 relen=0)

With RX->RX, TX->TX, I played with when I plugin the uart device. Right now I have with debug and starting cgminer first:

 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 3 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 10 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 5 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 1 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 8 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 3 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 2 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 3 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 2 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 13 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 8 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 3 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb

(or some other 'Read data' string depending on which time I fire this up) I still have green LED on the blade.
The blade is never formally "detected" by cgminer and hashing does not start.
My conclusion is that RX and TX were indeed swapped on the uart.

[pekatete]

^^^ If you can turn off your extra debug switch(es) then I'd be in a better position seeing where you are at, can not make sense of that for now. But yes, I bet you have not seen any of thatproverbial purple smoke yet, and aren't you glad you tried it?

[forpblat]

If you can turn off your extra debug switch(es) then I'd be in a better position seeing where you are at, can not make sense of that for now. But yes, I bet you have not seen any of thatproverbial purple smoke yet, and aren't you glad you tried it?

Ha, yep!

Here's the full output, no sudo but in the proper usb groups. It hangs here, no change. Green LED on board is flashing, no hashing, no further messages. As I speak, I'm compiling on the rpi to try it there too. I've tried one of the PL2303s too, same behaviour.

I wait until cgminer fully starts up (displaying the full console) before I plug in the USB.
 [2014-11-15 10:17:49] Started cgminer 4.7.0
 [2014-11-15 10:17:49] No devices detected!
 [2014-11-15 10:17:49] Waiting for USB hotplug devices or press q to quit
 [2014-11-15 10:17:49] Probing for an alive pool
 [2014-11-15 10:17:50] Pool 0 difficulty changed to 16
 [2014-11-15 10:17:51] Network diff set to 39.6G
 [2014-11-15 10:18:01] -----------------start freq-------------------
 [2014-11-15 10:18:02] Send frequency 82098110
 [2014-11-15 10:18:02] Send freq getstatus 84000400

And after some time, it segfaults out with classic "Segmentation fault (core dumped)".

[pekatete]

If you can turn off your extra debug switch(es) then I'd be in a better position seeing where you are at, can not make sense of that for now. But yes, I bet you have not seen any of thatproverbial purple smoke yet, and aren't you glad you tried it?

Ha, yep!

Here's the full output, no sudo but in the proper usb groups. It hangs here, no change. Green LED on board is flashing, no hashing, no further messages. As I speak, I'm compiling on the rpi to try it there too. I've tried one of the PL2303s too, same behaviour.

I wait until cgminer fully starts up (displaying the full console) before I plug in the USB.
 [2014-11-15 10:17:49] Started cgminer 4.7.0
 [2014-11-15 10:17:49] No devices detected!
 [2014-11-15 10:17:49] Waiting for USB hotplug devices or press q to quit
 [2014-11-15 10:17:49] Probing for an alive pool
 [2014-11-15 10:17:50] Pool 0 difficulty changed to 16
 [2014-11-15 10:17:51] Network diff set to 39.6G
 [2014-11-15 10:18:01] -----------------start freq-------------------
 [2014-11-15 10:18:02] Send frequency 82098110
 [2014-11-15 10:18:02] Send freq getstatus 84000400

And after some time, it segfaults out with classic "Segmentation fault (core dumped)".

Yep, the segmentation fault is a platform specific thing ..... I don't have any insight. Try running the Bitmain S1 binary rather than compiling one yourself, there's a link in this thread to it.

[forpblat]

Yep, the segmentation fault is a platform specific thing ..... I don't have any insight. Try running the Bitmain S1 binary rather than compiling one yourself, there's a link in this thread to it.

Are you referring to the Windows binary? This one? https://github.com/AntMiner/AntGen1/blob/master/cgminer/cgminer-run-windows-20131224.zip?raw=true

Bit of a pain as I have no bare-metal install of Windows. Might try USB pass-through on my virtualbox vm today.

Cheers and thanks for the help! Unfortunately I have essentially no coin to tip.

[pekatete]

Yep, the segmentation fault is a platform specific thing ..... I don't have any insight. Try running the Bitmain S1 binary rather than compiling one yourself, there's a link in this thread to it.

Are you referring to the Windows binary? This one? https://github.com/AntMiner/AntGen1/blob/master/cgminer/cgminer-run-windows-20131224.zip?raw=true

Bit of a pain as I have no bare-metal install of Windows. Might try USB pass-through on my virtualbox vm today.

Cheers and thanks for the help! Unfortunately I have essentially no coin to tip.

That was the release I was refering to but assumed / thought they had binaries for linux as well as openwrt and windows.

[zziggi]

tried to compile under xubunta 14.04   source from git repo (https://github.com/FireWalkerX/cgminer-bmsc.git)

bsmc-freq--ok finish but golden nonce timeout) under windows work ok)

[forpblat]

That was the release I was refering to but assumed / thought they had binaries for linux as well as openwrt and windows.

Not anywhere that I have seen.

Only ones here (https://www.bitmaintech.com/support.htm?pid=007201404130633105772QFG6R2u0635) are Windows.

I just tried bfgminer from the repositories and once I tell it to detect /dev/ttyUSB0, I get:

 bfgminer version 3.10.0 - Started: [2014-11-15 11:00:40] - [  0 days 00:01:24]
snip
 1            | 60.88/943.5/ 0.00Mh/s | A:0 R:0+0(none) HW:3494/100%\
 BPM 0:       |  2.61/ 1.11/ 0.00Gh/s | A:0 R:0+0(none) HW:3494/100%

Not sure if this is an improvement, I definitely see 100% error rate. I will try again later. Thanks again.

[pekatete]

Not anywhere that I have seen.

Neither have I, but I never tried as I was content with the windows binary.

I just tried bfgminer from the repositories and once I tell it to detect /dev/ttyUSB0, I get:
....
Not sure if this is an improvement, I definitely see 100% error rate. I will try again later. Thanks again.

You've got somewhere then with bfgminer! You probably need to set some initialisation strings to reduce / get rid of the errors. (I have to mention here that even with the "working" cgminer, errors are still abundant!)

[CHAOSiTEC]

did you run with or without sudo / or user permissions to usb?

This is all on Ubuntu 14.04 fwiw.

Not running with sudo (as no one should be, much better to set the proper permissions. A compromised miner running with sudo could easily infect your machine)

I'm part of plugdev, and dialout (...4(adm),20(dialout),24(cdrom),27(sudo),30(dip),46(plugdev),109(lpadmin),124(sambashare)...)

Permissions on /dev/ttyUSB0 are:

crw-rw---- 1 root dialout 188, 0 Nov 15 08:27 /dev/ttyUSB0

Also, I have /etc/udev/rules.d/01-cgminer.rules from I believe it's bitmaintech.

The USB bus is rather complicated on the laptop I'm running this on (screen digitizer, fingerswipe reader, etc). I'm going to fire up my raspberry pi and see if I can get it running there.

I've been using two different CP2102s on two different blades for now. I've run a voltmeter across the 12V pci-e connector, getting a healthy 12V. I haven't test pointed anywhere else on the blade. If the pi is unsuccessful, I will make sure the RX/TX lines are good. One of the blades has had resoldered pins to ease prototyping, the other has direct soldered to leads off the uart. It's possible the resoldered one didn't get good solder through the hole. Are these blade multilayer boards? I suspect they are.

regarding sudo, i can only agree!! i usually if all fail, i just test with sudo, to see if i missed a permission somewhere, because if it works in sudo, i fucked up :-p

another note:

my cp2102s are a bit quirky too, i ended up connecting ground from cp2102 to ground on the blade connector, and it suddenly worked...

[forpblat]

my cp2102s are a bit quirky too, i ended up connecting ground from cp2102 to ground on the blade connector, and it suddenly worked...

I was wondering about that, I tried connecting ground awhile back with the PL2303s but considering the mixed RX/TX lines and other issues, I'm not surprised it didn't work. I'll add it to the troubleshooting list!

Thanks!!

[sobe-it]

That was the release I was refering to but assumed / thought they had binaries for linux as well as openwrt and windows.

Not anywhere that I have seen.

Only ones here (https://www.bitmaintech.com/support.htm?pid=007201404130633105772QFG6R2u0635) are Windows.

I just tried bfgminer from the repositories and once I tell it to detect /dev/ttyUSB0, I get:

 bfgminer version 3.10.0 - Started: [2014-11-15 11:00:40] - [  0 days 00:01:24]
snip
 1            | 60.88/943.5/ 0.00Mh/s | A:0 R:0+0(none) HW:3494/100%\
 BPM 0:       |  2.61/ 1.11/ 0.00Gh/s | A:0 R:0+0(none) HW:3494/100%

Not sure if this is an improvement, I definitely see 100% error rate. I will try again later. Thanks again.

there may be an issue but even when its good you will get only hw errors until you have a big enough share for the pool.

 (5s):78.64G (avg):85.51Gh/s | A:5704965  R:1788  HW:466644  WU:1104.2/m
 ST: 2  SS: 0  NB: 524  LW: 9520302  GF: 0  RF: 0
 Connected to solo.ckpool.org diff 60 with stratum as user 1PJ63JUfX6q8Cf
 Block: 1a388216...  Diff:39.6G  Started: [12:15:28]  Best share: 9.58M
-------------------------------------------------------------------------
 Pool management Settings Display options Quit
 AMU 0:                | 37.46G/42.75Gh/s | A:2833893 R:640 HW:233619 WU:
 AMU 1:                | 41.58G/42.76Gh/s | A:2871132 R:700 HW:233032 WU:
m

[CHAOSiTEC]

That was the release I was refering to but assumed / thought they had binaries for linux as well as openwrt and windows.

Not anywhere that I have seen.

Only ones here (https://www.bitmaintech.com/support.htm?pid=007201404130633105772QFG6R2u0635) are Windows.

I just tried bfgminer from the repositories and once I tell it to detect /dev/ttyUSB0, I get:

 bfgminer version 3.10.0 - Started: [2014-11-15 11:00:40] - [  0 days 00:01:24]
snip
 1            | 60.88/943.5/ 0.00Mh/s | A:0 R:0+0(none) HW:3494/100%\
 BPM 0:       |  2.61/ 1.11/ 0.00Gh/s | A:0 R:0+0(none) HW:3494/100%

Not sure if this is an improvement, I definitely see 100% error rate. I will try again later. Thanks again.

there may be an issue but even when its good you will get only hw errors until you have a big enough share for the pool.

 (5s):78.64G (avg):85.51Gh/s | A:5704965  R:1788  HW:466644  WU:1104.2/m
 ST: 2  SS: 0  NB: 524  LW: 9520302  GF: 0  RF: 0
 Connected to solo.ckpool.org diff 60 with stratum as user 1PJ63JUfX6q8Cf
 Block: 1a388216...  Diff:39.6G  Started: [12:15:28]  Best share: 9.58M
-------------------------------------------------------------------------
 Pool management Settings Display options Quit
 AMU 0:                | 37.46G/42.75Gh/s | A:2833893 R:640 HW:233619 WU:
 AMU 1:                | 41.58G/42.76Gh/s | A:2871132 R:700 HW:233032 WU:
m

seems to be a speed / voltage problem, try downclocking or add a higher timing to --bmsc-options

[idonothave]

What is Your PL2303 Vendor and Device ID?

It's being seen as 067b:2303, I will try again with strictly the --enable-icarus instead of --enable-bmsc. According to lsmod, the driver is loaded properly, and /dev/ttyUSB0 is being made (until it is grabbed by cgminer)

EDIT:  [2014-11-11 15:48:32] USB init - ICA device 6:30 usbver=0110 prod='USB-Serial Controller' manuf='Prolific Technology Inc.' ser
ial=''
 [2014-11-11 15:48:32] ICA0: GetResults (amt=0 err=-7 ern=61)
 [2014-11-11 15:48:32] ICA: cgid 0 SetDataCtrl got err 0
 [2014-11-11 15:48:32] ICA: cgid 0 SetLine got err 7
 [2014-11-11 15:48:32] ICA: cgid 0 Vendor got err 0

That's what I appear to get with solely enabled icarus.

I have a sneaking suspicion this might be due to the fact that the uarts I'm using are the super-cheap (ie, counterfeit) ones. They work fine when shorting RX and TX, but might not be behaving 100% correctly.

Good. It will work. You have only find correct parameters for cgminer to make it to mine. As I compiled with --enable-bmsc I run it with those: --bmsc-options 115200:0.25 --bmsc-freq 0781. Yours should be simmilar but for icarus. I guess somebody has run it here at forum with icarus, try to find it.

edit: another workaroud is to run it as supersuser: sudo ./cgminer to allow cgminer to have full access to USB

[idonothave]

Is this further than you've been? That screen tells me the dongle has been detected by cgminer, and if the light flashes on the board, then the board is getting communication from cgminer and if the next line reads getstatus no data finish, then the board is not succeeding in communicating back (not sure why).

Previously (with RX->TX and TX->RX) I've had it get further where outside of this snip, the 0xea60 device is found:

[2014-11-14 20:37:13] AMU0: Read freq Comms timeout (rerr=-7 relen=0)
 [2014-11-14 20:37:13] AMU0: GetResults (amt=0 err=-7 ern=25)
 [2014-11-14 20:37:13] AMU0: Read freq Comms timeout (rerr=-7 relen=0)
 [2014-11-14 20:37:14] AMU0: GetResults (amt=0 err=-7 ern=25)
 [2014-11-14 20:37:14] AMU0: Read freq Comms timeout (rerr=-7 relen=0)

With RX->RX, TX->TX, I played with when I plugin the uart device. Right now I have with debug and starting cgminer first:

 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 3 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 10 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 5 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 1 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 8 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 3 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 2 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 3 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 2 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 13 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 8 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb
 [2014-11-15 09:43:08] USB: AMU0 read1 buffering 3 extra bytes
 [2014-11-15 09:43:08] Read data(5):fffbbfbbbb

(or some other 'Read data' string depending on which time I fire this up) I still have green LED on the blade.
The blade is never formally "detected" by cgminer and hashing does not start.
My conclusion is that RX and TX were indeed swapped on the uart.

did You try --icarus-options 115200?

[forpblat]

my cp2102s are a bit quirky too, i ended up connecting ground from cp2102 to ground on the blade connector, and it suddenly worked...

THAT WAS IT!!!

I connected ground on one of the blades, fired up cgminer from FirewalkerX. Boom, hashing at 65GH/s!!

uart and and blade flashing like mad.

Poolside even shows 65GH/s. Sweeeeeeeet.

Also, very low error rate on this one blade, 0.03%.

[sobe-it]

my cp2102s are a bit quirky too, i ended up connecting ground from cp2102 to ground on the blade connector, and it suddenly worked...

THAT WAS IT!!!

I connected ground on one of the blades, fired up cgminer from FirewalkerX. Boom, hashing at 65GH/s!!

uart and and blade flashing like mad.

Poolside even shows 65GH/s. Sweeeeeeeet.

Also, very low error rate on this one blade, 0.03%.

that's what i posted pages ago, hooked rx,tx,gnd and had no issues.