Topic: GekkoScience Compac BM1384 Stickminer Official Support Thread - page 75. (Read 268027 times)

One thing more we'd need to know, what cgminer version you are using and what compile flags you used (--enable-icarus, --enable-gekko, etc).

Alright guys. So yes, I'm a little late into the game. But having a few issues and i'm(hopefully) trying to get some support. My software skills are pretty minimal. I recently been experimenting with Ubuntu, and super new to it. So I purchased 3 of these bad boys, and im trying to get these working. So i followed the exact setup for the terminal. Got everything setup for CGminer. It is actually searching for the Gekkoscience miners. But when I plug them up, CGminer does not detect them. I tried plugging them directly to the computer, and I have tried plugging them to a powered USB hub. Nothing. I'm hoping to get some help. Thanks guys! If you need any more info please let me know.

For software gurus:

if i run Debian Linux Live Cinnamon on PC (without installing), would I be able to configure cgminer/bfgminer and run stick(s) OR It is necessary to do a full install?
thanks.

Just seen this (red), I forget who it was now (we were both looking at these), but they were told by the manufacturer (?) that these are not built to handle being pushed to the max over a long period (or something like that).

And if I remember right, no matter what you put in (12V, 15V, or 24V), it will only put out the standard USB 2.0 Amps per port (might have been a little more, but not much). So basically, just a better built powered/non-powered (basic) expansion hub.

The BM1384 Compac is based on Icarus work protocol, that is true. However, rolling gekko into Icarus I would call a bad idea, for several reasons. In short, because Icarus is convoluted enough without stuffing more into it, and because everything we make after the current Compac will use a different protocol so the module will diverge anyway. The next Compac won't use it, and nothing bigger will either.

Course, this conversation would be better if it were between Kano and Novak, since they're the ones that actually know and do.

The icarus protocol doesn't really have much to do with the ASIC itself so much as the usb controller, the full size antminers use a different protocol. Kano is basically saying gekko uses the icarus work protocol and that it should just be combined with the other icarus style devices because of that. Good to know that there is a reliable way to detect the gekko sticks other than using test work. Kano did look over the gekko code which is what those comments were based off of.

The U2 is driven by Icarus. I mentioned it specifically because I also mentioned Novak fixed the Icarus incompatibility, and that driver-gekko had everything specifically not Compac removed, therefore we must have compiled a cgminer with both Icarus and gekko enabled.

At this point I don't care what Icarus does or doesn't do. Gekko is not a replacement for Icarus. Icarus was just the functional starting point we used to write driver-gekko, and any hardware we add in the future will definitely not be based on Icarus protocol. It's seriously a mess. That the Compac works with Icarus (as a U3) is mostly Bitmain's fault for having built two generations of chip that basically behave the same.

We didn't change the PID/VID of the USB chip because leaving it in place makes drivers a lot easier. We did, however, change the product description string and serial number. bitshopper sticks were not recognized because we forgot to tell driver-gekko to look for bitshopper's product description as well as ours. That's also how BFG identifies them - in fact, Luke-Jr put together the code and data required to push those changes.

Regarding your earlier quotes from kano - I don't know if he looked at the gekko code or not, but most of what he said is wrong as far as I know. Statements specifically the opposite of true include:
"It's an addition to the icarus code, not a replacement. So it's not supposed to be a whole new module (that re-includes all the icarus code and drivers ...)"
"gekko is simply icarus + gekko combined into a new module"

How are you currently doing detection of the stick? The important part IMO is making sure that you can run other devices simultaneously with the Gekko stick so proper identification is critical for that, ideally with usb vendor and product id's since those are the most reliable(the sample work detection is a hack because vendors like bitmain and rockminer don't set usb vendor and product id's). Icarus is used for a very specific type of work handling which is why there are a bunch of devices grouped in the same driver. I think frequency ramping should be possible within the icarus driver, I remember there was even an experimental branch for rockminers that did that within the icarus driver. In your test setup is the U2 being driven by the gekko driver or the icarus driver?

We started with Icarus because the thing works as a U3. So Novak copied Icarus into gekko, then pretty much gutted it down to everything except U3 and then reworked what was left to match our specific needs. It no longer identifies the stick by sending sample work and recognizing the return format, and it ramps up the hashrate upon init instead of going straight to top speed (which makes init more reliable especially with high speeds and cheap hubs). We intend to pack code for future hardware into driver-gekko as well. It's by no means an Icarus replacement.

Also, I don't know if he's already swapped out the archives yet but yesterday Novak fixed not recognizing bitshopper sticks, and also the Icarus incompatibilities. Our test setup has been running one Gekko stick, one bitshopper stick, and one Antminer U2 on the same instance of cgminer (and all properly recognized) for about 27 hours now.

Icarus is a catch all driver for devices with a certain protocol, if you want support merged into mainline cgminer I think it needs to be in there as all the devices that use Icarus are pretty similar and duplicating code can make driver maintenance trickier. If you make a device with a different protocol then it should be separate. Can you just send ck and/or kano a sample so they can do the merge it properly themselves? It would probably only take them a day or two once they have a hardware sample.

Quotes from kano on the driver:

I have 1 of the Plugable, but it's 2.0 with same power. The 2.0 worked OK, but not as good as the Superbpag has.

http://www.amazon.com/dp/B00RM5OF70?psc=1    this one is the other one it's rated at 60 watts, your is better and its cheaper.



maybe is just my hub and batch two thu anything i throw at it just works, mines this one http://www.newegg.com/Product/Product.aspx?Item=N82E16817707235  I have it self powered at 7-24V either over a 110 or 240 line tried both but really saw no need for 240.   the PSU, i have does Output:24V 3A to match the hub.

you have to specify: were they usb 3.0 or usb 2.0 hubs?
I have 4-5 compacs running at default settings on Superpag (~11Gh ea).
As per others, I used plastic card (like old library card, LOL) to separate them when using five, otherwise heatsinks of the adjacent sticks are in contact. Plus, I used Arctic breeze fan, which I think almost everybody else use as well.

I don't know the ones in your quote, I used the following one:
http://www.amazon.com/Superbpag-Portable-Charger-Transfer-Samsung/dp/B013OK10YM

this one worked on both pi zero and pi 2.
I used it by linking through usb 2 hub, but some (Jake36) connected it directly to pi.
My reasoning behind using nonpowered usb 2.0 hub (my choice was 4-port unpowered Sabrent) as a bridge was:
1. sometimes usb 2 bridge allows for usb 3.0 hub to work
2. i wanted to connect the mouse and keyboard and usb 3 hub had some warning against using "slow" devices (such as mouse and keyboard) on it.

I am having trouble using more than 2x compaq in USB hubs.

I used Anker 7 port  60W and the Orico 36W

I tried on PIs and on Windows 10 laptop

But seems no matter which combination wont work with more than 2x at around max 200-225 MHz

That is what I was just researching now; I just wanted to start with something "known" for the current command line and build from there. Thanks for the suggestion.

It's a 69 (and counting) page thread.  Don't feel bad that you missed it.  I don't believe sidehack was suggesting you should've seen it.  Just that it's been pointed out and is a known issue.

Have you thought about just creating your own configuration file instead of generating one?  That's what I do on the Linux side and unless cgminer somehow functions differently in windows you should be able to do the same.

Thanks and sorry I missed the bug in the thread.

driver-gekko was based off Icarus. At some point we'll clean it up, and at some point we'll add to it with new hardware. Icarus itself is pretty stupid so we're not going to pack more devices into it especially when they'll need a more advanced protocol.

It's been known from the start that writing a conf from cgminer-gekko doesn't work. I don't know why, but it doesn't work. That bug's been mentioned here a dozen times already. Just generate it with regular cgminer and copy it over or something.

cgminer-gekko is Novak's thing. I'll talk to him today, as he was planning on doing some work on it over the weekend but I don't know if anything got done.

I am trying to write my .conf file from CGminer and the application keeps crashing. The file is created, but it is zero bytes/empty. I thought it might be a permission issue but even running as admin does not help (or changing the path). I am running the gekko version of CGMiner on Windows 7.

This is the error from the Windows application event log:


Faulting application name: cgminer.exe, version: 0.0.0.0, time stamp: 0x00000000
Faulting module name: msvcrt.dll, version: 7.0.7601.17744, time stamp: 0x4eeaf722
Exception code: 0xc0000005
Fault offset: 0x000143f9
Faulting process id: 0x21770
Faulting application start time: 0x01d13cb8d3aca476
Faulting application path: C:\Users\\Desktop\CGMiner\cgminer-4.9.2-windows\cgminer.exe
Faulting module path: C:\Windows\syswow64\msvcrt.dll
Report Id: 1b1dffdd-a8ac-11e5-927e-6cf049071173

Do you all have any ideas? I have searched through the forum posts but cannot seem to find this particular problem. If I screwed up and missed it, just let me know.