Topic: GekkoScience has a new stickminer that does 300+GH - page 43. (Read 22553 times)

I am having the same issue with one of my Compac F's; I had been using it in the bitcoin merch 3.0 USB hub (bad idea I take it after going through this thread a bit), but the issue is still happening with the Compac F in my official GekkoScience hub.

I currently have 6 Compac F's and 1 Newpac, all of which have been working fine for a few months save now the single Compac F that won't work no matter what I try (and I've now been trying to just run them all in the GekkoScience Hub as it has 7 ports + the fan port...)

At first cgminer would recognize it no problem as well, but it started going into "Zombie" mode right away. Now, however, cgminer won't even recognize the problem compac F at all to even list it as a Zombie.

Is there anything I can do to try and trouble shoot it or such? It was working no problem for a couple months before this started happening a couple weeks ago :/ I've been running them all on either ckpool solo or a pool since getting them in October/November without issue, and I've (maybe stupidly) never overclocked any of them, all running with two USB fans to cool them as well whole time.

Any tips or thoughts would be greatly appreciated!!

Ever hear of PM?
You posted in a public area so one should expect replies from the public... 

Thank you for putting yourself in front of any critical question wich are addressed to Kano.
I am not intersted in a discussion of any sort, is it good to solo mine, who got the longest ... and so on.

First: Learn how cgminer works and what it does when it comunicate with the core software.
second: core did not breake anything, core simply get rid of an unused value inside the gbt protocol.
(Ask kano, he will confirm that)
third: it was allready fixed as a comit on vh version of cgminer but not in kanos git version for sidehacks Ferrari Miner.

My question to kano (and not you) is clear:
are you willing to change cgminer to a full working Version (in this universe)  or not, nothing more nothing less.

Then you will not be buying any BTC miners from anyone. It ain't cgminer (or the various ripped off versions of it) that is 'broken' and needs 'fixing'. It is Core that broke solo mining and as Kano already pointed out, it's far from ideal to use a version of bitcoin prior to 0.21, since when taproot activates next month, you must be running 0.21 or later.

Considering that unless you have excellent connections to the other mining nodes on the internet it is a HORRIBLE idea to mine to your own node with a high risk of finding a block and then you losing every orphan race to better connected sites, there is no pressing need for cgminer to be patched to allow doing it.

Nearly 3  month now, and no answer.
If you don't want to finish your work, say so.

@Sidehack: I will not buy a product anymore wich is not able to fullfill the BASIC task, mining on your own wallet.

thanks
I'm in France

It is a german company, with an imprint:

Ernst Heller
bitshopper.de
Bernhard-Plettner-Ring 38
91052 Erlangen
Deutschland

Tel.: +49 179/ 9754353

The phone number is a mobile number, so it will cost you a fortune, if you are outside the eu.

It would NOT change what PD can deliver. Same as with the USB charging specs the power delivery voltage is a wired negotiation between the master and slave(s) where there is a set of resistances presented by the slave device across the power wires when you plug it in. Something like either 10k, 4k or 2k as I recall. The master sees that and sets voltage output - up to 26vdc -  and current limits accordingly. The regulators in the slaves of course need to be able to handle that so if no initial handshake resistance is seen by the master the port limits output to the standard 5vdc @ 1A.

That out of the way, a USB-C PD port can both deliver power and handle data -- it's just that data has to come from/go to a different master (for data) device port. In the case of say a laptop using a powered USB-C hub with a PD port that is sized to power the laptop (up to 100w) the hub is the master for PD while the port on the laptop is the master for all data xfrs. The one cable between the laptop and powered hub handles both power to the laptop as well as data to/from it and the hub then splits off or passes through the (data only) to whatever is plugged into its data or display ports.

Hi all,
I have a problem with bitshopper.de, they don't answer to me since december when I order a CompacF
I have never receive my usb miner and they just say wait but ...
so did someone have an other solution to contact then than email ?
thanks

Good advice, I just hate hand winding transformers/inductors. But yeah, losses in stages multiply versus being additive.


My ardent hope is for your emancipation from the tedium of manufacturing (which pays the bills).

You hinted in a previous post about a new miner project that doesn't rely on BM hash chips. Per chance w/ a chip that's not made in the Pacific Rim? This is something I'd be VERY interested in. And in whatever impotent capacity willing to contribute to.

In the interim if you're not gonna' do a second run of the F I'd be interested in buying some of your leftover PCB's hanging around. Not for resale just for my personal consumption.

As always, a pleasure.
Pup

---

As Spock would say "Interesting".

So if I read that right, if PD is divorced from the master/slave (by supplying power from say a barrel connector) one could use the 4 wire USB 3.0 master/slave data protocol & achieve a higher data rate than USB 2.0. That would also allow for higher PD than 100W. Effectively limited only by the current handling of the barrel connector.

This makes sense as many USB 3.0 to SATAIII adapters have external wall warts to supply power to the SATA power port.

Did I glean that correctly?
Or am I all FUBAR & in need to re-read that reference.

Pup

[moderator's note: consecutive posts merged]

What exactly does the setscrew change? Voltage to the chip? What's the acceptable voltage (or whatever it changes) range and are there test points to measure that on the PCB? I'm a little bit hesitant to play with it.

 

I like USB-C simply because it tries to eliminate the Schrödinger USB paradox. Tripp lite did try to fix this with the Universal Reversable USB cable though, https://www.amazon.com/Tripp-Lite-Universal-Reversible-UR050-003-RA/dp/B00ESZIIRU
 

That's an effective summary of why I care so little about USB-C devices. Only two ports at a time, and no PD+data, doesn't quite mean it's useless but certainly doesn't help anything.

Now people do like USB-C cables enough that future pods are likely to have USB-C connectors, but it'll still be a basic USB2 with no power draw. Just using the cable people like.

Good link regarding USB-C PD & data transfer as well as how the various USB ports (A, B & C) are used.
Something I did not know about how USB in general does things.So still sounds like that a PD port is only to be used for power or data but not both at the same time.

Images are down

Thank you so much! What's the risk if using without cap? Can the chip be damaged?

At this time I know exactly nothing about the BM1398 protocol and cannot advise.

Remember any intermediary steps will have their own power losses, and efficiency percentages cascade. Two 90% stages in series still results in a 19% power loss, and if you 20V into 5V you still have the problem of trying to get reasonable efficiency out of an 8% duty cycle switcher. I'd be more likely to take 20V down directly with a half-bridge forward converter and custom wound transformer especially if it was a one-off. That's how a lot of your good active-PFC supplies handle bucking 350+VDC down to 12VDC at a hundred or more amps.

The eleven projects can largely be subdivided into a few project families with a decent amount of overlap. Eventually I'll be fully excised from the assembly line and can focus more on R&D. That's the dream anyway.

The operative word in your reply is "natively". While not having dug into Kano's driver to deeply it shouldn't be too difficult to add those ID's. Was more concerned that BM dramatically changed their comm protocol.


Your response answers the question, for me, as to how BM reads the 4 external board temp sensors. Thanks.

Having used a variety of USB hubs over the years concur that, by & large, they're all crap (save yours) for current handling. I was assuming I'd have to build my own w/ some beefy copper bus's for PD & the USB C connectors.


Good point on the decrease in efficiency w/ a larger VDC I/O spread. Kinda' assumed there would need to be an intermediary step down located close to the chip. Like 20V to 5V or 20V to 3.3V. Just use the 20V rail for PD to the port. The device plugged into the port would need to do the step down. Like what is used to do Li battery / Supercap charging in USB connected devices (cell phones, tablets, etc.).

In my experience, low V bucks (1.8V & 0.8V) are the realm of CPU/GPU power supplies & are usually seen as multiple units in parallel appropriately sized for the demands of the device. Which obviously would not fit in the Compac X form factor.

Eleven projects? You're a braver/smarter man than me. I wouldn't be able to juggle that many projects.

Thanks for all the clarification.
Pup

My original prototypes didn't have that part (330uF capacitor) included, but when testing with a high-impedance power source the voltage tended to sag and cause problems so I added some extra buffering. If you're using a direct connection to a decent hub, it's basically just insurance.

Kano's driver is very unlikely to work natively with the BM1398. The chips enumerate themselves on the bus with a distinct ID per generation, which the driver uses to distinguish which chip (and how many of them) it's talking to. It won't recognize the 1398's response and so won't initialize it for use.

Temperature sensing using the innards of the BM1397 also won't work natively. Bitmain implemented a register set that communicates with an external temp sensor over I2C using some otherwise unneeded pins, but this has to be built into the driver protocol. It is true that the two temp-sense-diode pins could be interfaced to any temp sensor chip and handled externally.

I've looked into using USBC PD for higher power on a device, but at the time there was no real provision for running both PD and data, nor were there any reasonable hubs that would do the 20V spec. Additionally, providing a higher voltage into the device would tend to *decrease* your conversion efficiency, unless you used something like a forward converter with a transformer to help balance out the duty cycle. The problem isn't the power into the main regulator, it's the power out. 400mV 40A bucks are a rare breed. I've looked into this and it's sorta possible but I have something like eleven design projects already in the pipeline so I'm probably not gonna do it anytime soon.