I ordered out two batches of seven S7LN last week, one via UPS and one via DHL. The UPS arrived on Tuesday and I haven't heard a thing about fees of any kind. The DHL order, shipped a day earlier and also scheduled to have arrived on Tuesday, got hung up in China about customs, got Ohio because they needed more info for customs, and now it's hung up in St Louis waiting for payment of customs fees. I might get them on Monday.

I'm pretty disappointed; it was sort of a test and I expected more from DHL given that I've received packages from China via DHL in under 30 hours total transit time. Both orders were identical in size and merchandise cost, the only differences being carrier and the resulting slight variation in cost of shipping.

Back when the S7 was new and expensive, I got probably a dozen FedEx invoices for customs duties due because of hosting customers direct-shipping.

That is handy, depending on how easy it is to interface to. But do we really need a quad-core? (hint - the answer is "no").

What specific model of what devboard computer gets picked is important to the overall discussion, but I wouldn't mind deferring it for a bit. If enough people want wifi, that certainly adds weight to one supporting it natively.

A slave board is possible, but if there's a way to do without it I'd prefer that. I think the fewer proprietary and also essential parts there are, the better. Dealing with warranty stuff sucks from both ends, especially if there's no workaround to get your miner at least back to limping while waiting for replacements.

Are there any decent wifi modules that work with the Pi via USB? I'm assuming so, that seems like a very simple and common problem but I don't really use wifi so I've never had to look it up. What I'm thinking currently is have a Pi as an internal controller, and expose ethernet, at least one USB and probably some status LEDs on the front panel. Hashboards would connect directly to the Pi by USB. Worst case your Pi craps out and you're waiting on a replacement, you should still be able to tie the boards to an adjacent miner or other computer via hub. With a setup like that, the hashboards become the only proprietary (and therefore difficult to source) electronics, and they would be easy to run off a variety of nonproprietary controllers, which minimizes a lot of the issues people have with, say, Antminer BeagleBoners and IO boards shooting craps and losing a month of hashtime and money out of pocket waiting for very specific replacement parts existing in limited quantities (if at all) from exactly one source in the world.

I generally don't like unnecessary complexity because it tends to add failure points. Yes I know using USB for interconnectivity is adding a layer of complexity to a problem which could be solved in a simpler way, but it does so in a way that reduces the overall cost of failure. A layer of complexity which adds a layer of redundancy or reliability is okay - like RAID5. It's not perfect, but the benefits merit the extra effort.

Enabling power to the hashboards does not need to be accomplished using external switches in any way, provided the hashboards have an onboard regulator (which they will if I have any say in the matter). One only needs control of the buck controller's ENABLE pin (which NotFuzzy stated while I was typing this up). No power will get to the hashing chips if the buck is shut down, so the board-level microcontroller should be able to control this in addition to determining operating voltages. I like the idea of making a software power-cycle of individual hashboards possible, and an advanced driver could be implemented that watches for a hung board then forces a hardware/software restart. That would be really handy for automatic tuning especially at the bottom-end voltage range where node-level voltage imbalances have the most effect on overall stability. Being able to force a total power-down of all ASICs would also be good for mitigating damage from an overheat condition resulting from fan failure.

Every Avalon6 that has come in for my hosting (all from BlockC, so whatever image they provided on the SD already installed with the bundled Pi) was already set to DHCP and had no trouble picking up an address on my 10.0.x.x networks. Never had to touch network settings on any of them.

Oh hey Kilo, we should catch up sometime.

Hopefully fourth time's the charm...





If you're looking for something in any way akin to the U3, you're in the wrong thread.
That said, thanks for the support. Hopefully whatever ends up getting built is worth buying.

It's easier to keep track of if there are fewer add-on parts strung along in the middle, especially since it won't cost any extra or be any extra work to build it into the board. That adapter you linked is the same hardware as on USB Block Erupters, AntMiner U1/2/3, my Compacs, New R-Box and a bunch of other stuff. It is easier to find for an end user, but (as Novak and the AM Tube found out) people sometimes still have problems with incredibly simple things. Idiotproofing is your friend - well, assuming "you" will be doing any kind of customer support. Most customers, at least the ones who ask questions, are idiots.

Well, we've already noted that it's annoying to find replacements for the USB converter Avalon uses, and made specific mention of how easy it is to find microcontrollers with USB capability built in. So, if going USB why require an annoying converter when you can just integrate it onto the board?

USB has also been raised specifically because it doesn't limit you to one controller type. It's easier for everyone if the thing comes with a controller already, but with open software and USB connection you could replace that controller with almost anything you wanted. "Not hard to replace parts" is definitely a key desirable feature.

No USB dongles. No external boards for fan control.

My hosting VLANs are all handled in an old 24-port Cisco multiplexing off a pfSense router with VPN. Works pretty well. Also, I had a cousin missed a family reunion about ten years back because he got arrested for counterfeiting - probably with something lame like a photocopier or, at best, inkjet printer and scanner. Noodlehead.

Also. I think we're in agreement that requiring, or even requesting, VLANs for a consumer environment is probably a bad idea.

An internal Ethernet-connected controller using off-the-shelf hardware like a Pi makes sense. Is USB good enough for bussing the boards to the controller internally? That would certainly make troubleshooting easier for end users, and allow a lot of flexibility in custom deployments - as well as ease of connecting multiple units in the event of a controller failure. Heck, with a bit of playing you could probably even mount a bunch of boards in a rack case if you wanted to, which would be good for that guy from earlier.

One concern, already mentioned but worth rolling over again, with using a base controller and having all functions handled at board level is fans. If it's a one-fan unit like the Avalon6, one board would have to be designated as the fan driver. This is simple enough to do if, upon startup, the boards check for a fan installed (easy enough with a tach line) and report to the controller who owns it. This gets a bit tricky if multiple boxes end up tied to a single controller, since the controller won't know which two boards are on the same fan. Some way of assigning pairs, perhaps with serial numbers in a config file, would have to be conjured up that needs to be straightforward. It'd be nice if that function was implemented in a webconfig also, because not everyone knows what "SSH" means or how to use it. An easy means to ID boards without jacking with wiring, like flashing an LED, would be necessary. Of course the controller should automatically handle this if only two boards are connected, and the only manual intervention needed would be when multiple boards/boxes are tied together.

I just have gotten used to not having a stupid boss I have to blame things on, and who can tell me to violate my principles for a paycheck. Freedom is worth the effort.

My one-employee business runs VLANs, but that's only because of the hosting subnet. A miner requring the customer to use VLANs very much violates the "simple" requirement.

I think a lot of how "powerful" a Pi is with regard to controlling multiple miners is dependent on how work is distributed. I don't know the numbers for Avalon6 but one Pi could handle something like 50 of the Avalon4 units.
Considering NICs, that's actually one of the main limitations of the Pi is the ethernet is slow since, if I'm remembering right, it shares a bus with USB. Adding USB NICs might not be a great idea.

Also requesting your buyer to buy a $200 PC to control a miner is not a path I'd like to go down.

I think, all said, if I were putting Ethernet on the miner I'd just as soon put a full controller in it like on an Antminer.

There's no question that ethernet connections are going to be a lot more resilient and reliable for a large deployment of machines. I think with good control software leveraging the cgminer API, configuring multiple miners on independent network connections is not going to be much more difficult than configuring multiple miners on a common controller. This also removes the common controller as a single point of failure.

I like the idea of using something off-the-shelf like a standard Pi, that the user can buy replacements for all over. I'd prefer to not have that plug into a proprietary IO board for simplicity's sake, but without knowing more about the GPIO header on the Pi it may be necessary. If the boards used USB they could plug directly into USB on the Pi, and then anyone enterprising could hook the boards up to anything he wanted. I'll do some more learning about the Pi's GPIO and see what busses are available, because connection-wise it'll probably be more reliable to use a pinned header than a USB jack.

Also, for the third time,

Which means, for the purpose of this discussion, any consideration for industrial farms and especially rack-mounters goes right out the window. Don't care at all, it's a whole different discussion. I've got a thread from sometime last year, similar type of discussion, about attributes for an open-source rackmount design indended for internal or semi-internal server PSUs and internal blades in the S1 formfactor, if you want to look that up. The conversation fell by the wayside when any optimism I had for being able to make those boards last year evaporated.

Like I've mentioned a couple times in the last few days (I think it's been suggested here, and explicitly stated in the Community Miner thread), I have been asked to help with a miner development project and one of the side benefits is being able to piggyback their resources for my own project. So that's what's happened to the project to replace boards on the S1.

It'd be nice to make it adjustable without requiring modification or dismantling of the miner itself. Maybe not feasible, but it'd be nice.

I was thinking the other night, what about making a small board with two 18-pin jacks that would plug inline of the cable? Put a micro on that board which is tied to the TX line and listens for a pause in transfers from the 'Boner to the hashboard, and then injects the four-byte code for whatever voltage you want? It should be possible to set it up as adjustable, and even with dual hot- and cold-run settings with a delay inbetween.

When you say "the com line is held by the BBB" do you mean it's busy, or it's actively pulled high to resist any data getting pushed in from another source? Is the 4-byte volt code pushed out at 115200? Because if the PIC can listen that fast, and the TX line is togglable, all you should need is about 400uS in the clear to change the voltage.

For the check, might be worth looking at the crc5 function in driver-icarus.c since cmd_buf is in use for a 3-byte command to set voltage and 4th byte checksum generated with that function for I believe the AntMiner U3. May be completely unrelated, but it's worth looking at.

Not sure if it's exactly what you're looking for, but https://www.bitmaintech.com/support.htm?pid=00720160615035302444KTs9xiKF06B2 has S9 firmware downloads. There's also a menu link on the side claiming to have instructions for flashing firmware to an SD card.

Ease of setup is essential, but I also want to look at overall cost, reliability and fault tolerance. A controller per miner ensures no one box can affect the operation of another, but also has the highest cost.  A single controller for a fleet of miners is the cheapest and easiest to configure, but also provides a nice single point of failure. A single controller with chained boxes means if you pull any one cable, every miner downstream is also disconnected. Using a single controller with a tree structure of connected boxes reduces (but does not remove) this problem, and still leaves you with the controller as a single point of control but also failure.

I like the idea of the single controller being something generic and replaceable like the Pi. If your Avalon6 controller craps out, you don't have to email warranty claims and wait a week for them to deny your claim. Just go to any of a thousand online vendors and pick up a new one for like $20 - or if you're that worried about it, already have one standing by just in case. Avalon sending a Pi with the SD card already imaged is really nice.

The easiest busses for consumers to work with, as far as setting up a tree of connections using readily available hardware is concerned, would be Ethernet and USB. I'm in favor of USB from the standpoint of ease of interface (you can get $2 microcontrollers with full USB capability) and availability of software to build upon, but Ethernet does make distribution easier what with better cabling and generally more reliable hardware. The problem with ethernet comes from controlling it - either the miners have to be on a private network and a dual-NIC controller is present, or the miners exist on the same network which adds work to detection and preventing control overlaps.

Oh yeah, I was ecstatic when the S5s started showing up with DHCP enabled by default. Very glad to see that change. My entire hosting is run off static leases on the DHCP server, makes everything super easy.

If you're going with my standard settings, the miner would draw at most about 430W wall. So that's no more than 400W DC, which means probably 20W controller/fans and 190W to the boards. If you've got 16AWG cabling that can be done with one cable per board, but two is better.

I think one of the problems is, you assume I have a more firm grasp on the full meaning (and implication of that meaning) of terms like "semi-smart contract" and "SADO" than I actually do. Please explain like this is the first time the listener has ever heard those phrases. Like I said, I'm generally opposed to overlaying things not "transfer money from A to B" on the blockchain so I admittedly have ignored all discussions on that line. I put enough time into hardware without getting mixed up in philosophy.

That said, my philosophy on "money" disagrees with the statement that "money is the destination of everything". Money, to me, is a tool just like anything else. It's a construct that allows me to turn stuff into different stuff, and effort into reward. Money is not the goal, money is a means of translating work and stuff into the goal - whatever that goal may be. But yeah, most agreements or contracts do hinge on turning work into money or stuff into money, which for one side is work into money and the other side money into the goal. I've just never liked the idea of "having lots of money" being the goal in itself, because money is useless by definition if it's not being used.