GekkoScience has a new stickminer that does 300+GH

[n0nce]

One could de-solder it, test it, & determine it' value.
So if it screwed up it could be replaced.
PITA for sure, but . . .

BTW, not surprised to hear that it sometimes de-solders itself. There's a reason that on the 17 series hash boards Bitmain puts heatsinks on both sides of the pcb. High power consumption SMDs regularly thermally sink thru their power connections on the underside of the chip.

I have another stick which is fine; so I might actually do this, not sure yet whether to take that risk. I still hope for a response from GekkoScience team. Not sure why not to release this info since it's so trivial to RE.

[Biffa]

Sure looks like a power supply decoupling cap to me since there is a polarity mark on the largest component on the backside of the hash chip PCB (2 pin component).

Right - makes sense, thanks guys! I just assumed diode since it has the distinct polarity mark which diodes also have. But it seems a cap makes more sense in this part of the circuit.
I'm surprised your works without the cap in place, @Biffa! Then I'll see if I can get it working simply without that.

Would still be great to hear what component this is (specifications) so it can be replaced if it is missing or blows / melts like in that case.

The stick should still run without that part. My first prototypes didn't have it; I just put it on there to help compensate with wiggly power from weaker USB ports and it kinda sounds like your USB port is not weak.

[sidehack]

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.

[PupTentacle]

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.

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.

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.

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

"... nor were there any reasonable hubs that would do the 20V spec."

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.

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.

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

[sidehack]

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.

[n0nce]

~

Images are down

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.

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

[NotFuzzyWarm]

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.

The point is that because USB is a master/slave protocol the functions of two USB-C ports on a USB-C dock has to be split up to allow for more than one master. The laptop is the master of the data portion and the power brick is master of the power portion. It's rare to see more than two USB-C ports on a dock because the USB protocol doesn't really allow for more. If a dock has more than two USB-C ports then the other USB-C ports will have some limits on the port functions to avoid having to deal with more than one master, or the dock is using a more complex protocol like Thunderbolt that is not master/slave but peer/peer.

So still sounds like that a PD port is only to be used for power or data but not both at the same time.

[sidehack]

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.

[419mining]

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.

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
 

[jeyzeus]

future pods

 

[n0nce]

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.

[PupTentacle]

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.

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

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.

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

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.

The point is that because USB is a master/slave protocol the functions of two USB-C ports on a USB-C dock has to be split up to allow for more than one master. The laptop is the master of the data portion and the power brick is master of the power portion. It's rare to see more than two USB-C ports on a dock because the USB protocol doesn't really allow for more. If a dock has more than two USB-C ports then the other USB-C ports will have some limits on the port functions to avoid having to deal with more than one master, or the dock is using a more complex protocol like Thunderbolt that is not master/slave but peer/peer.

So still sounds like that a PD port is only to be used for power or data but not both at the same time.

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]

[flat4power2]

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

[NotFuzzyWarm]

<snip
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]

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.

[o_solo_miner]

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

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.

[flat4power2]

thanks
I'm in France

[o_solo_miner]

I'll look into solo working with 0.21 when I get to doing that - give it a little while
But no, 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.

Hi Kano, could you give us an update?

Not done yet.
Working on pool code.

Hi Kano, two month now, any update for the fix of cgminer?

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.

[NotFuzzyWarm]

I'll look into solo working with 0.21 when I get to doing that - give it a little while
But no, 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.

Hi Kano, could you give us an update?

Not done yet.
Working on pool code.

Hi Kano, two month now, any update for the fix of cgminer?

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.

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.

[o_solo_miner]

I'll look into solo working with 0.21 when I get to doing that - give it a little while
But no, 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.

Hi Kano, could you give us an update?

Not done yet.
Working on pool code.

Hi Kano, two month now, any update for the fix of cgminer?

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.

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.

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.

[NotFuzzyWarm]

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