GekkoScience 2Pac/Compac BM1384 Stickminer Official Support Thread

[hercthx]

Voltage has nothing to do with the workload, just the hardware's stability. In general, the higher the voltage at a given frequency, the more stable it'll be (until heat or junction breakdowns become an issue).

The amount of work done is proportional to the operating frequency. I see about WU 1.53/MHz with a 2-chip stick, so 225MHz should run about 344 - plus or minus, because USB traffic and pool latency and whatever.

And that's what I am seeing now, OK thanks for the confirmation! Ok I'll Bump them back up to 250Mhz, And return the voltage to 1.4 as that seemed to be running fine. I just wanted to see if the 2pacs would be more efficient or stable at the lower clock with higher volt.

[sidehack]

More stable perhaps, but less efficient. The bulk of power use in a CMOS IC is the charge required to flip the transistors on and off. The current use is proportional to frequency for obvious reasons - more flips per second means more electrons moving back and forth per second. In order to flip fast enough, a higher voltage might be required in order to have more "pressure" pushing those electrons into and out of the gates fast enough to keep up, so voltage tends to increase as frequency increases. This is where your efficiency comes into play. For a given voltage, the power use is directly proportional to frequency, but as frequency increases the voltage has to as well - so power use increases from both voltage and current increases, which means more overall power per unit work.

Bitmain's original S5 announcement post (https://bitcointalk.org/index.php?topic=902305.0) has a chart for this.

[hercthx]

Cheers!

[goose1072]

Sorry if this has been answered before:

Can you control the frequency individually, I have three of them and my middle one doesn't like it when I go to 200.
The other two hash away like nothing but the middle one drops incredibly low and then dies.

I'm using:

cgminer -o stratum+tcp://us-east.stratum.slushpool.com:3333 -u MY_USERNAME --gekko-2pac-freq 150

Thanks

[sunk818]

Can you control frequency

Look under USB Management in cgminer. You can blacklist certain devices. I haven't tried in South so I don't have specific steps for you

[goose1072]

Can you control frequency

Look under USB Management in cgminer. You can blacklist certain devices. I haven't tried in South so I don't have specific steps for you

not looking to blacklist it (think it disables it when you do), even though I am not sure if it would keep that one at 100 while having the others go to 200+

[ppetrovic68]

Can you control frequency

Look under USB Management in cgminer. You can blacklist certain devices. I haven't tried in South so I don't have specific steps for you

not looking to blacklist it (think it disables it when you do), even though I am not sure if it would keep that one at 100 while having the others go to 200+

You can always try running two instances of cgminer, with different parameters.
For example, start the first one @200, with autodetect on, plug in "other two" sticks, disable autodetect after sticks are detected.
Start the second instance @150, with autodetect on, plug in the "middle" stick, and that's it.

[NoComply]

Can you control frequency

Look under USB Management in cgminer. You can blacklist certain devices. I haven't tried in South so I don't have specific steps for you

not looking to blacklist it (think it disables it when you do), even though I am not sure if it would keep that one at 100 while having the others go to 200+

You can always try running two instances of cgminer, with different parameters.
For example, start the first one @200, with autodetect on, plug in "other two" sticks, disable autodetect after sticks are detected.
Start the second instance @150, with autodetect on, plug in the "middle" stick, and that's it.

Might it be possible to run two instances and use the --usb switch to target specific devices? I haven't used the switch since initially playing around with cgminer, so I might be misrecalling the exact purpose of of it...

[sunk818]

Until you have to restart cgminer again for some reason.

The blacklist is only for that specific instance of cgminer so another instance should recognize

[ppetrovic68]

Can you control frequency

Look under USB Management in cgminer. You can blacklist certain devices. I haven't tried in South so I don't have specific steps for you

not looking to blacklist it (think it disables it when you do), even though I am not sure if it would keep that one at 100 while having the others go to 200+

You can always try running two instances of cgminer, with different parameters.
For example, start the first one @200, with autodetect on, plug in "other two" sticks, disable autodetect after sticks are detected.
Start the second instance @150, with autodetect on, plug in the "middle" stick, and that's it.

Might it be possible to run two instances and use the --usb switch to target specific devices? I haven't used the switch since initially playing around with cgminer, so I might be misrecalling the exact purpose of of it...

Sure, you can go that route. I believe that each stick has unique id that can be retrieved (at least on *nix, never tried it on Windows) and with a bit of scripting you can probably automate everything

[NoComply]

Sure, you can go that route. I believe that each stick has unique id that can be retrieved (at least on *nix, never tried it on Windows) and with a bit of scripting you can probably automate everything

Sounds familiar, I recall it being numerical in relation the the lsusb enumeration so, --usb 1, or something along those lines. Never had a real use for it personally but definitely a nice feature to have and might be suitable for goose1072.

[goose1072]

Sure, you can go that route. I believe that each stick has unique id that can be retrieved (at least on *nix, never tried it on Windows) and with a bit of scripting you can probably automate everything

Sounds familiar, I recall it being numerical in relation the the lsusb enumeration so, --usb 1, or something along those lines. Never had a real use for it personally but definitely a nice feature to have and might be suitable for goose1072.

Just tried

--usb 0-gekko-2pac-freq 200

and --usb 0-freq 200

none worked

[hercthx]

Sure, you can go that route. I believe that each stick has unique id that can be retrieved (at least on *nix, never tried it on Windows) and with a bit of scripting you can probably automate everything

Sounds familiar, I recall it being numerical in relation the the lsusb enumeration so, --usb 1, or something along those lines. Never had a real use for it personally but definitely a nice feature to have and might be suitable for goose1072.

Just tried

--usb 0-gekko-2pac-freq 200

and --usb 0-freq 200

none worked

cgminer.exe --usb :1 --gekko-2pac-freq xxx and so on... when starting cgminer with this, cg miner detects and uses the first available 2pac and ignores the rest. if you put in --usb :2, then it detects and uses the first 2 usable 2pacs and ignores the rest. and so on...

[der_wasi]

Something worth reviewing and trying out if the kernel is going down:   
https://bitcointalk.org/index.php?topic=494625.msg5932931#msg5932931

Thanks for that. Had the same issue like discussed before with the PI freezing.
Tried your solution now. Will keep you updated about success.

[cableiso]

Hello I am having a noob problem with the 2Pac.

I find that when I splice in an external supply and attach a heatsinked fan and run it at 400MHz, it makes a funny smell.  Is this a driver problem because I am using windows?  I do not see a config file option for odor.  



Here is my cgminer log, I am also getting some hardware errors but Vcore is fully turnt.  Should I swap in new feedback resistors?





Thanks for the awesome testbench, man!  But I would like to register a complaint about your via booby trapping.  I wanted to cut away the drain of the top fet so's I could run the dc-dc at 12V vin while leaving the controller and CP2102 on USB 5V, but you've got goddamn vias everywhere!  I mangled the CP's VDD line trying to island away the via between the 2 ohm and the CP's cap, and that STILL didn't separate the LV chips from the mosfets.  Where is it?  Where's the hidden via? 

[sidehack]

Pulling the 2.2ohm should isolate the buck chip from all 5V. Even the tied-high enable line pulls from below that. I put that RC on there to help isolate the buck from ripple due to input impedance when the load's cranked up.

You still have to worry about the node-level 1.8V LDOs and the LED which are tied directly to 5V.

Other than that, the high side FET's the only thing remaining.

Which, by the way, I believe the entire power section has 2 interconnected layers of power plane and 2 interconnected layers of ground plane. Didn't want trace impedance to be the reason someone's overclock attempt failed. It's not a booby trap so much as an overbuild.

I don't have one in front of me, but I think if you look just above the 5V pin on the USB jack there's a via right there. Or maybe it's under the pin. Not sure offhand. Anyway that connects the 5V line to the meandering trace powering the buck (via 2R2), the LED circuit and LDOs. Drilling that out cleanly will probably disconnect everything, and then you can inject 5V back into the line at any of the taps mentioned above. Lifting that pin will then isolate the plane going to the FET, which you can use with any voltage you want (provided your input caps don't asplode).

But please note your inductor is only rated for 17A.

[cableiso]

But please note your inductor is only rated for 17A.

I like the way you think!  I have some Wurth inductors that can tag in here if needed.

Which, by the way, I believe the entire power section has 2 interconnected layers of power plane and 2 interconnected layers of ground plane. Didn't want trace impedance to be the reason someone's overclock attempt failed. It's not a booby trap so much as an overbuild.

Yes, done the way it should be done - I was just messing with you.  I realized that as soon as I cut the top copper between USB 5V and the top fet.  I says "Wooo, power plane..  Not his first board, methinks".

Thanks for the tip on the 2.2 ohm and the drillable via.  I thought about that via, but looking at the BM1384 side it looked like there could be about 3-4 more candidates so I didn't want to risk it.  I think the controller needs to run from 5V, but the FETs and BST can do about 30V so that's why I just wanted to isolate the top FET for a 12V input feed.

How about this plan:
1) Pull the USB connector and drill the via under USB 5V
2) Cut the top fet's copper roughly in line with the inductor's copper island to prevent VIN from backfeeding into USB
3) Reattach the USB connector, and jump the USB 5V island to the buck side of the 2 ohm to supply the controller from USB 5V.  I am hoping the CP and LED/LDO are all downstream of the 2.2 ohm.
4) Replace the presumably 6.3V ceramics with 16v, and bring external 9-12V in at the top of the input caps


Please note that I realize there is no good reason to do this, other than it COULD be done. 

[sidehack]

Actually the original Compac was one of the first boards I laid out myself. It came after a couple BM1384 breakout boards, but before that Novak did most of the layouts. The 2Pac's buck circuit is almost identical to the original Compac's.

Only the buck is downstream of the 2.2ohm. It's sensitive to ripple, to the point if Vin drops below about 4.2V (I think) the buck will drop out. This causes a nice power cycling during high overclock if your hub's power lines aren't too good. The LDOs and LED aren't susceptible (the worst case is, the top node's LDO will have issues if the 5V line goes below about 2.8V) and I didn't want the extra power draw inside the ripple buffer because, you know, I^2R losses and limited capacitor storage.

If you drill out the via under the 5V pin, you shouldn't need to cut any copper planes. If you're looking to isolate the USB jack's 5V line, just drill out that via, hold the pin off the board and run a jumper from it to the uphill side of the 2R2.

[cableiso]

Yep, that's the via - thanks!

I did need to island the copper between USB and the top FET since I think the controller's PGOOD pullup goes to this copper area.  But it worked just as you said - jumping USB 5V over to the top of the 2.2 Ohm allows me to feed a (slightly) higher voltage to the input FET and it doesn't touch the controller, CP2102, LED or LDO.  Many thanks, I like having a split supply so I can monitor the 1384 current directly.



You mentioned breakout boards...  Got any spares lying around, or would you consider sharing the 1384 footprint?  I'd like to make up a couple single chip breakout boards to try to hack out some auto-tune code.  It would be open source, of course.

[sidehack]

The PGOOD is NC. Like I said, nothing on the buck ties to any 5V line that doesn't come through the 2R2.

BM1384 datasheet is, as far as I know, still accessible on Bitmain's website.