Topic: [DIY] - Reward $100 | Antminer S1/S3 Blade on Raspberry Pi - page 18. (Read 82179 times)

He works with a voltage of about 1V)

A lot of the early posts talk about only connecting RX and TX, no mention of ground. Even some of the earlier pictures IIRC didn't connect ground. I had tried ground but was facing the damn silkscreen reversal issue.
I imagine my pl2303s would've worked too.

Note for people trying this after me and facing issues:

***
Try reversing RX and TX lines on the UART.
Connect Ground between blade and UART.
Use the FireWalkerX git.
Make sure you are in the right USB group, and that /dev/ttyUSB0 is created with the right permissions. If not, check the udev rules file from the git.
Ask for help on here. Be clear with your issues.
**

It's strange mine are 2013/12/16 and I have 100uf 10v on them. Taltalum 107 A

I don't understand how it can be a diff voltage ... make no sense ?

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

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

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

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

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

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

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

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

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

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.

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)

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

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.

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.

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

^^^ 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?

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.