Net ook iets besteld bij thuisbezorgd.nl en betaald met bitcoins. Ging snel en probleemloos. Enige nadeel is dat de prijs van de maaltijd achteraf steeds hoger wordt

That's why I ordered my board in June.

If it was an early design review, it would be fun

For chaining you just connect 2nd chip to 1st chip without level shifters. The whole chain runs at 1.8V, and you only need to convert to 3.3V between first chip and host.

Correct. The speed of the chips automatically goes up with the voltage, so if you reduce the resistor, it increases the voltage, and the speed of the internal oscillators.

The hardware has different solder jumper options. They can be made for 2.5W level, and I've gotten close to 4 GH/sec that way. But I expect most people would prefer to use a bit more power, and stick them in a powered hub.

The 2.5W/4GH setting can still be useful though. It's a nice introduction to bitcoins and bitcoin mining that doesn't require any additional investments or setups.

The 1.8V is not a reference voltage, but the supply power for the SPI I/O circuitry on each chip.

When you reverse a board in the M-BOARD connector, it doesn't swap GND with 12V wires, but it swaps the GND/12V with the 1.8V SPI section on the other side, and it puts the 12V straight into the chips. Especially the first and last chip in the chain will get the full effect, and are the most likely to fry.  The power regulator may still be okay. The fuse is probably still good too.

Also, BTC Guild had/has problems, so a bunch of people switched pools.

I'll check out the protocol in more detail later, but one thing I'll ask right away... can you add the exact format for the work string and nonce/timestamp, with a few examples so people can test their implementation by feeding the same work and checking the results.

That's true, but then they really use the exact same information, so a broadcast actually makes sense. KNK was describing a scenario where information is broadcast, but the miners only pick what's relevant to them. That's very much like your own directed traffic implementation layered over multicast.

Careful when measuring the core voltage. Don't make a short, or you'll get spitzensparken. There's a lot of amps available, very eager to take a shortcut.

Wouldn't it make more sense to use directed data, and send each miner only the information he needs to have ? Multicast doesn't save bandwidth, because each miner needs different work anyway.

But why couldn't you do that over one communication channel (per MS/MH) ?

Why add unnecessary complexity with 2 pairs of endpoints, or 2 other connections? You can simply mix various kinds data in one channel, and sort it out in the application.

OC is still possible, but you'd have to modify a resistor value.

In my table, there are 36 rows and 21 columns (0 also counts), and 36*21=756. The code does % 24, so you'd expect 24 columns, but colums 5-7 are skipped, so only 21 left.

Check the chainminer sources, fix_nonce() function.

Also, the different fixups aren't distributed equally. The -0x00800000 fixup is needed half the time, no fixup a third, and - 0x00400000 in the rest of the cases. So, if you try them in that order, you'll minimize the number of hashes needed in the software. Or use the method that chainminer uses to try to guess the correct fixup from the core (doesn't always work: some cores have two different possible fixups)

I did a test on the S-HASH board. For one chip,  I marked all cores that returned a valid nonce.


The same test on another chip shows three missing rows:


The test has not run for very long, so some of the unmarked cores may still get a hit later.

Of 16 chips total, 10 have found nonces in all cores. The other 6 all have one or more missing rows at the top.

There's a clear pattern when you map the X/Y coordinates from the core to the variant, so it's not a communication problem, but a systematic issue.