The short-term projects are

2-chip stick using BM1384, wholesale price about $30, estimated 15GH/5WDC
10-chip BM1385 pod, wholesale price about $70, estimated 250GH/60WDC

Longer-term projects are

2-chip stick using BF16, wholesale price around $40, estimated 60GH/5WDC
11-chip BF16 pod, wholesale price around $125, estimated 650GH/75WDC
33-chip BF16 S1/3/5 refit board, wholesale price unknown, estimated 2TH/200W

I have PCB layouts of all of these things already. The short-terms will probably have prototype PCBs ordered on Monday and code is being developed right now for them.

I have a working-model PCB for the 2-chip BF16 which is heavily designed for unit testing, but which on the whole is functionally identical to the final version stick (circuit-wise). The 11-chip BF16 pod will need to be revised both physically (form-factor changes) and, probably, electrically once I've gotten the 2-chip working and ironed out any kinks.

Everything on this list will have adjustable core voltage for both undervolting and overvolting. Undervolting means a longer viable lifetime due to increased efficiency. This is a mandatory feature and I will never release a miner without it.
All miners will use USB interface for ease of control - no proprietary controllers or IO boards are necessary. This is a mandatory feature and I will never release a miner without it.

Not exactly the place to be discussing that kind of thing.

Today's a designated odd-job assembly day, which includes the BW sticks from the auction and a lot of test stuff for this project, so I'll be catching up a lot of backlog next week.

That's the next step after the BF16 pod. We set the projects up specifically so about 90% of the driver/control for the pod is also done on the stick, and about 90% of the S5 refit is done on the pod. That means once the stick is figured out and working, we're more than halfway to the big guy.

Must be nice to have a family close enough to work with. That's pretty cool. Glad y'all are doing stuff well.

Must be nice to have a team.

"Enough chips" will mostly depend on what kind of terms I can get for an initial batch purchase. If I'm able to buy several thousand on a net-30 agreement or similar, that would allow for a lot of delivery before having to pay. Even buying in smaller quantities (~1000) as necessary, while not ideal, would still allow for a lot of pods.

If I could scrounge up enough for 2100 chips at the start, I could make 500 Compacs and 100 pods just in the first batch. More would be nice, but that's a good start.

Bitfury test PCBs arrived today, so sometime this week I should be able to start playing with them and working on microcontroller code. VH is still occupied with BM1384 drivers; he's figured out a lot of the S5 sniff data I sent him and I'm tasked with redoing some of the tests to provide him with better info, after which it should be pretty simple to complete a cgminer driver.

I have completed a 2-chip BM1384 Compac layout and nearly compled a pod layout; I expect by week's end to be sending off for prototype PCBs. As soon as VH's code works on a test setup built to more accurately emulate the 2pac (right now his chips are in parallel rather than serial, which cuts out a lot of shared-power issues; the final will be a string) I will open up the 3-way funding plan as discussed earlier in the thread - the 1Burger address for donations, a second address for purchases, and a third address for [anonymous] loans to be paid back out of batch sales.

Once the 2pac is functional, the old-chip pod code shouldn't be too difficult.

And there's plenty of documentation on BF16 communication that, once I figure out the basics for my microcontroller code, vh can immediately start working on drivers for it.

Speaking of which, I know a lot of people are voicing support in my general direction for all this stuff but I want to make it pretty clear - these projects would be falling on their faces if I didn't have a good coder on board. I'm gonna be sprinting to catch up just on the embedded part, no way I could have jumped in headfirst on a cgminer driver so I'm really glad vh has agreed to help. He asked to get paid a percentage of sales, which means he won't see a dime until the finished product rolls off the assembly line. He has been working his butt off in free time outside of his real job to get done everything that he has so far. So let's hear it for vh too, eh?

That's certainly weird. 650MHz should start working around 10V, but a proper pot should be able to crank it up past 11V.

If the PIC is shot, you could replace just the PIC and program it to whatever voltage you want. I've got a thread on S7 hacking that talks about how to do that. I've not actually done this fix, but I pulled from some of the research done for the PIC solution.

Did you make sure the voltage was set to at least around 10.4-10.5V? That's about what it'll take for 700MHz to mine.

I trust the standard barrel jack up to about 5A, which on 12V means 60W DC. I'm figuring on assigning the "default" power consumption for pods at 60W for that reason.

I like flexibility, and I don't know who has what kind of cables laying around already, so I'm putting on a USB-B and USB-mini. I always intended to do this, no sense arguing about it. I had to shift one of the jacks to the side (instead of having them all lined up on one end) to put in a daisy-chain PCIe jack but that shouldn't really cause a problem.

I plan on shipping pods with stick-on rubber feet. I'll probably also put in additional screwholes so folks can make little towers if they want to, but you gotta allow height clearance for the fan to move air proper since these things can be pushed to over 100W.

I think I will go ahead and put a cutoff temp sensor on the old-chip pod, set to about 90C since it'll be tucked right in there with the chips and should be pretty much at thermal equilibrium. This would be a fixed thermostat that stops mining, probably with a 20C hysteresis for cooldown.

The BF16 pod has pretty much already been laid out with slightly different dimensions, but I'll probably adjust it to the same formfactor as the old-chip pod for compatibility. I'll have the same temp sensor on there, but due to the advanced controls set we'll have on the BF16 gear it'll be able to report temps back to cgminer. If I remember, we can see about implementing a user-selectable cutoff threshold in the driver.

That's part of why I don't mind at all working with bitshopper, is the cost savings to EU people. I also really appreciate supporting local economy, wherever "local" may be (for reference, all the wire for my cables is sourced through a locally owned supply house in town), and having the assembly done in Germany keeps money a lot more local than sending it to the US or, for a lot of mining equipment, to China.

I don't currently have a plan to stretch power across pods, but it's not inherently a bad idea. One problem with doing that is if people get dumb and try to string 400W worth of pods off one cable and it burns up. I'm accounting for a barrel jack and a 6-pin PCIe; if there's room without causing trouble I could add a second PCIe so people could line up several (depending on clocking, up to about 5 comfortably) in a stack on a single good-quality cable chain.

This was in answer to pretty much the same question you just asked. We haven't set a price for licensing (I am waiting for proof that it works before moving forward) but bitshopper has already expressed interest in everything discussed in this thread - stocking 2pacs and licensing BF16 designs.

We haven't decided any numbers yet, but bitshopper and I are definitely working together on this one.

And consider doing a static config in your DHCP server.

But how much free power do you have? At what point will the person paying the power bill start to get upset about how much you're using without compensation?

There's really no way I'll be able to beat Bitmain on pricing, since I'm not paying factory price for the chips (which they can since they made the chips, I'm buying from the maker who has to profit from that sale) and I'm not paying slave-driver wages for assembly. Bitmain can beat pretty much anyone on price if they wanted to, and they've proved it in the past.

What I'd give you is a product not intended to operate continually at extreme conditions so less likely to break down, with a better warranty and certainly better warranty service, and inherent ability to undervolt for improved efficiency down the line which can greatly extend the viable lifetime. Right now on the refit boards, I'm designing for 3 independent strings per board, which means each string's core voltage can be adjusted individually. It's also possible to adjust each string's operating frequency independently, if that's built into the driver. And since each string will have its own temperature sensor, that gives a lot of flexibility for optimizing each board.


Depending on the efficiency of your power source, and how much power is eaten by fans, 0.08J/GH should be attainable.

4-wire PWM fan standard dictates the PWM driver have an open-collector output, which means it has to be pulled low for the fan to see "low" and floating means "high". Standard also states I believe 24KHz with about 4KHz of play to either side as within tolerance.

I've got an idea for a controller that wouldn't take more than about a day to put together, but it could be set to either a maximum or minimum PWM. It'd detect the controller's drive PWM and override it if it crossed threshold. Something like that would be useful for an undervolted miner or S7LN where when the miner first kicks on the fan pulls up to 100% and it's loud. Or it could give a lower threshold to limit the up-and-down throttling of the autotune miners.
Probably should have had something like this prototyped already. I figured out how to do the PWM detect and override like a month ago, just haven't gotten around to coding it.

Look into the data formats that actually go into the chip. A lot of them take in a data and a midstate, which is derived from the first round of SHA256. The chip crunches all of that with incrementing nonces until it finds at least a diff-1 share. Most chips have a means of setting a target diff within the chip, so they won't return anything less than that (to save on tying up the IO lines with discards).

Yes, it's possible. If you have something that can be crunched down into the data formats the chips can take, and all you want back is a nonce, they'll do the job beautifully.

Have you searched for the threads asking about the same question which have popped up pretty much monthly for the last couple years?

Bitcoin mining ASICs are really only good for solving double SHA256 on data in a specific format. You don't actually get the hash back out though; they only report the nonce which gives a hash corresponding to a specified difficulty threshold. Not terribly useful for anything else.

The "and give nothing in return" is the tricky part. Nobody gets as big as Bitmain by giving things out for free. May look like it, but they expect to profit somehow. Starting their own pool was just another means of getting more money in the first place, and I'll be darned if I'm gonna give anything to them.

I mean I owe Bitmain some thanks for selling me BM1384 chips in the first place, but pretty much everything else they've done in the last year and a half (crap hardware, crap support, price wars and price gouging, you name it) stinks quite a bit.

Anyways, independently designed and manufactured miners. Novak recently made the comment after hearing about all these projects - "you could basically remake the small miner market." That'd be okay; small miners have been staunchly ignored for most of the last two years.

Yeah, there's no gimmick that could ever get me to mine at antpool.