Just make sure you get the polarity right.

You can put bare wires in the green screw terminals.

If you have two power cables, and one board, plug them both into the board. If you have multiple boards, stick each power cable in a different board. The more power cables you have in parallel, the better.  However, do not use two different PSUs together in a single board.

I was actually thinking that the user interested in having better statistics would volunteer to do the work themselves

If someone wanted to get per-chip statistics, the better way would be to have a dynamic list, which grows automatically when a new chip is mentioned in the results.

Of course, with the number of chips growing into the hundreds, the value of knowing exactly what happens in each individual chip starts to diminish. EDIT: also, measuring these statistics in the driver, with a high difficulty setting, produces very erratic per-chip results, unless you measure over very long times.

And some new firmware reports the wrong value

Also, the OneStringMiner devices allow a simple serial connection to connect multiple boards through 1 'master' board connected to a USB port (potentially resulting in hundreds of chips). The firmware automatically detects and counts these boards, but this is done in parallel with the USB enumeration/initialization, so the number of chips could increase some time after the miner application request the version string. In theory, the user could even dynamically add some extra boards after the device has been running (although this would not be a common procedure).

Maybe the problem is that the firmware version string still reports "2 chips", but when it submits results, it provides a chip number 0 through 5. That's the only thing I can think of that would be different between the devices.

Not sure where the 2 job queues come from, but the firmware internally uses a single queue with room for 4 jobs. That's the same on bi-fury and hex-fury. The only difference is that the hex-fury jobs are processed faster because there are more chips, but this should be transparent for the driver.

For the OneStringMiner version with the serial bus, the job queue has been extended to 16 (but we're still experimenting with that), because it supports a total of 16 boards with 15 chips each, so it goes through the work a lot faster.

4 chips isn't enough to do a string design, so it would require a 10 Amp DC/DC converter, adding cost and board space. For the same space and price, you could make a 6 chip string design like we did.

Indeed. Obviously, the problem is not the cost of the components, it's the availability.

The protocol is exactly the same as for the bi*fury devices (and also the same for the One String Miner), so cgminer already supports them.

First post has been updated with prices, by the way.

The higher the temperature, the quicker the chips will wear out, but I don't have hard figures about the expected lifetime at different temperatures. (I don't know that anybody has ever done a thorough characterization) However, considering that the reward of mining goes down as the difficulty rises, I would expect the optimal to be closer to 70-75 than to 50-55. But that's just a WAG.

Maybe not on price, but it's easy to beat them on customer service.

Congrats! Very happy to see these devices for sale.  I'll be glad to assist in answering technical questions on this thread.

Correct. But if you send less values, the last clock value will be replicated for all remaining chips.

Sending unnecessary flush commands is bad for performance, since it wipes the entire work queue inside the device. For typical bitcoin mining, the device works fine without flush, as it will automatically flush when a new block is detected. Also, it is unnecessary to send target or maxroll repeatedly. They only need to be send again when they're changed.

Also, a low maxroll value is also bad for performance. For instance, with maxroll = 0, a single OSM board needs about 11-12 work items per second to keep busy. And if the boards are chained through the serial link, they could require nearly 200 work items per second. That's a lot. Setting maxroll to 60, only requires 1/60th of the workload, so about 1 work item every 5 seconds for a board.

In addition, it is good to send the pool difficulty to the board using 'target' command, to avoid unnecessary traffic going the other way.

We'll change the firmware, but note that the 'chip' parameter was never intended to be used to calculate work load. Instead, if the board requires more work, it sends the 'needwork <jobs>' command to the miner. This is a much more accurate representation of exactly how many jobs are required by the firmware to ensure smooth mining.

There's no hard limit, but more chips increases the chance of a single bad chip blocking the communication. Also, the longer the chain, the slower the communication. First generation M/H board design has 256 chips in a single chain, 2nd generation has 4x64.

We are working with others to get both the 15-chip One String Miner, as well as the 6-chip hex*fury produced.

It's a USB 2.0 miner, but with higher power requirements, so a 2.0 Hub + extra power is just what you need.

I tried hashing the test vectors but got no response from the chip. This was still using a single chip. Next step is to  assemble a second board with the other sample chip.