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.

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.

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.

1397 and 1398 mostly look to be pin-compatible, but the documentation I have says they're not entirely so. 1398 operates on a much different V/I which makes it fairly non-suitable for single-chip operations. I've looked into it, and the main regulator engineering would be difficult and probably pretty inefficient. A series string like we did for the R606 would be a lot easier to manage. In any case, a direct chip swap from 1397 won't work.

If we shipped a stick, it will have put up at least 220GH set to 400MHz across a minimum of 24 hours on my tester. Performance beyond that is not guaranteed. Even with that criteria, we had a high percentage that just plain didn't pass muster and needed a chip replaced. With these guys it really is a lottery.

So in June my people convinced me to change webhosts and get a better managed email frontend. This jacked up some of the website stuff. I'm in the process of migrating back because the recommended outfit is not good. That's why the file link is dead. It'll come back someday, hopefully early next year.

It's cool to see people are still interested in this project.

The 17e series I believe use a different chip, BM1396. The S15 and S17/e chips (BM1391, BM1396, BM1397) are for the most part pin-compatible. 1396 and 1397 have one functional pin difference, but also a different core count and optimal voltage parameters.

The different modes are passing data left to right, or right to left. There's a Mode pin which gets tied low for one mode, and left floating for the other. This makes serial power and data in a single copper layer pretty simple to achieve.

Linux, always linux. My testers run Debian, which Raspbian and Ubuntu are also built from. I run a beaten-into-submission Win7 on some machines; anything newer isn't really allowed inside the building.

I factory-test these on an old Dell 755: to give a hint at the age, service tag says support ended 11 years ago. 14 sticks per machine, 400MHz.

Don't know if you have multiple USB busses on that machine, but if you do, split the load up. I run seven per bus.

The last chip I saw a datasheet for was the BM1385 from the S7. Everything after that we had to work off repair guides and reverse-engineer the rest.

Hey bigdaddy, yes that's the correct place. Stock is in the 1.45V neighborhood.

Kano would have to tell you for sure, but I believe it's an artifact of some testing we did on a part of the protocol we weren't 100% sure about. It's nothing you need to worry on.

Oh hey Phil. I've been doing business with MFB for a few years now, never had any problems. That's mostly supply side but Ellis also helps me source some materials, USB cables and the like. Done more than $40k in business overall, all good.

Fan slows down when miners are connected? Miners aren't able to run full speed?

Probably your hub is underpowered.

If you do build something out with renewables, I'd be interested in seeing pics of the setup. Always interested in green energy here at the Gekko.

Oh yeah also TTBit copied the product/serial config off one of my sticks and cloned it across all of theirs so they all came up with the same serial number. What a joker.

"Share above target" is probably something with the pool expecting a faster miner (more shares coming in) and it could take a few minutes to retarget.

NiceHash and proper cgminer don't work well together, because NiceHash requires some added protocol stuff that's demonstrably insecure and kano refuses to support it.

RockMiner was selling a clone of one of my sticks so blatantly a ripoff that the publicity shots were my device spray-painted black and the shiny parts photoshopped back in.

TTBit ripped off of my work, botched the design into a fire hazard in three separate ways, then built it with grey-market chips.

Please don't do that.

Officially I'm not allowed to endorse that strategy because the USB jacks themselves aren't rated for that kind of current.

But yes, each pair of ports has 6 total amps available. Check the underside label for pairings.

Just as a note, all sticks are tested for a minimum of 12 hours at 400MHz and must average at least 220GH (80% speed) during this test to be cleared for shipping.

These sticks don't run well at low speeds. You don't buy a Ferrari to drive Miss Daisy. These chips were made to go FAST and they tend to choke while slow. The higher the clock, if the voltage is stable, the closer they'll run to true. If you want to overclock one but it's stalling in low speeds, you need to --gekko-start-freq to a higher speed, and if it still has trouble stalling, --gekko-tune-up to a lower step threshold.

For instance, I noticed some sticks have trouble below 200MHz and some have trouble below 300. For most, 300MHz is past the breakover point where they start running well. Therefore my test script includes:

--gekko-compacf-freq 400 --gekko-start-freq 300 --gekko-tune-up 85

which means it targets 400MHz, starts ramping from 300MHz (instead of the default 200), and will step up when the measured hashrate breaks 85% of expected (instead of the default ...90-95%?)

So Sledge, it's likely that your sticks are not faulty at all. It's more likely that you need to adjust command line parameters to force it past the sluggy bottom end and into the smoother high revs. If it doesn't level out above 300-400MHz, that's when adjusting the volt screw could start to make a difference.